很多团队发现AI代理越用越贵，原因却出奇地简单——我们塞给代理太多信息，却没给够明确指令。
常见的操作模式是这样的：把整个代码仓库丢过去，附上12个工具、9份文档，再加一句"找出bug"。偶尔能跑通，但代价是惊人的token消耗、混乱的工具调用、漫长的执行时间，以及代理花大量时间重复人类早已知道的事情。
更多上下文看似更安全，实际上往往让工作流变得更糟。问题不在于上下文本身，而在于未经筛选的上下文。AI代理确实需要上下文，但需要的是正确的文件、正确的约束、正确的示例，以及清晰的完成标准。它们不需要所有可能相关的东西——这正是许多工作流出错的地方。一个小任务变成大规模调查，只因代理没有边界。
举个例子：让代理更新定价组件。
糟糕版本："读一遍应用，更新定价页面。"
更好版本："更新定价卡片组件。只检查components/pricing和app/pricing下的文件。不要改动计费逻辑。运行组件测试和TypeScript检查。返回简短摘要及变更文件列表。"
第二个提示词不只是更短，它是一个更小的工作流。这才是关键。
MCP等工具协议确实有用，让代理能更干净地访问外部系统。但工具访问也带来新问题：代理现在能搜索更多、阅读更多、调用更多API、收集远超实际需要的上下文。一个联网的代理很强大，一个没有工作流边界的联网代理则很烧钱。
所以很多团队问错了问题。不该只问"我的代理能访问哪些工具"，更好的问题是"这个任务需要的最小可靠工作流是什么"。这个问题会彻底改变代理的设计方式。
工作流不是一次性提示词，而是一种可重复的操作模式：何时使用、哪些文件或工具在范围内、哪些在范围外、遵循什么步骤、运行什么检查、返回什么输出格式、什么情况下触发人工交接。提示词是请求，工作流是习惯——而代理需要的是好习惯，而非再多2000字的指令。
以调试为例。与其告诉代理"调试这个问题"，不如让它遵循一个窄循环：复现错误、定位最小失败命令或测试、只检查直接相关文件、做一次聚焦修改、重新运行失败检查、若修复需要产品判断则停止。这个工作流有两个作用：防止代理漫无目的地翻遍整个代码库，同时在需要人类决策时及时停手。
核心原则很简单：给代理一个边界清晰的小工作流，胜过给它整个世界的信息让它自己摸索。
热门跟贴