AI智能体陷入内卷，别再死磕提示词

今年，AI Agent（智能体）领域的热度持续攀升，其中“循环（Loop）”这一概念被反复提及。

表面听来这像是一句开发者行话，但其本质只有一个：让AI告别“单次问答”模式，转而在同一任务中循环执行“采取行动→观察反馈→确定下一步”的流程。

今年6月，前谷歌工程主管Addy Osmani发表了题为《Loop Engineering》的文章，开篇即点明要义：循环（Loop）的本质，在于将“人工引导Agent”的过程，交给预先设计好的系统执行。Anthropic旗下Claude Code的负责人Boris Cherny也持有类似观点，他将当前工作归纳为“编写循环（Loop）”，让这些循环自主提示Claude并决定后续行动。

回顾以往，我们使用AI的方式基本上是“一问一答”。用户撰写提示词，模型给出回应；若答案不理想，用户再补充细节，模型再次修改。任务的推进方向，始终由人掌控。

而智能体（Agent）想要改变的，正是这一分工模式。

当人类设定目标后，智能体不应仅回复一句“我建议您这样做”，而应具备自主拆解步骤、调用工具、监测结果、调整路径的能力，直至任务圆满完成，或判断自身无法继续。

从产品视角出发，这正是“任务反馈闭环”的核心体现。

需要明确的是，这并非模型自我训练，也不是模型突然涌现出新能力。更准确的理解是：一个外部系统将模型、工具、上下文、记忆、检查器与停止条件整合封装，使AI能在同一任务中循环执行“计划、行动、观察、修正或停止”的完整流程。

这一转变意义重大。因为聊天机器人只需输出“看似合理”的回应，而智能体则必须切实推动任务向前发展。

单次回答难以胜任长周期任务

最易于理解的实例，依然是修复代码报错。

普通聊天模型面对错误日志，可能会直接生成：“这看起来像是依赖问题，您可以尝试这样修改。”

而具备闭环能力的智能体，会主动执行更多步骤。它会先读取相关文件，定位潜在错误点；完成修改后自动运行测试；若测试失败，则读取新的错误日志，再次进行修正；若反复尝试数次仍不成功，它应主动停止，说明受阻原因，而非继续盲目实验。

这套逻辑在编程场景中清晰直观，迁移至调研与办公任务，原理同样适用。

让智能体生成行业简报，它不能仅拼凑出结构完整的文章。它需先自行列出关键问题，随后搜寻资料，并能区分一手来源与二手转述。若遇到数据矛盾，还需继续补充查证，最终将结论、引用来源以及不确定之处逐一说明。

让智能体准备会议资料，它也不能只撰写一段议程。它需查阅日历、读取邮件、搜索文档、整理待办事项。当缺少必要授权或关键信息时，它应懂得暂停，并向人类求助。

所有这些任务的共同点在于：执行过程中会持续产生新状态。

网页无法访问、测试再次报错、资料相互冲突、用户初始目标甚至需要重新拆分。提示词只能设定起点，真正处理过程问题的，是闭环。

在传统多轮对话中，人类是维持循环的引擎。AI输出一版，人类审核一版，再提示它该查询什么、修改什么、停在哪里。

而在Agent的循环（loop）中，系统开始承担部分循环职责。上一步的结果会变为下一步的输入，工具返回的信息会改变后续动作，测试失败会触发新一轮修正。人类不再逐句驱动其前进，而是预先设计好这个循环的运行逻辑。

难点正向模型外部转移

因此，Agent的挑战并不局限于模型本身。

Anthropic在讨论“上下文工程”时，将Agent定义为“大语言模型在循环中自主使用工具”。他们特别强调，Agent一旦运行，会不断产生新信息，系统必须反复确定：哪些内容应进入有限的上下文，哪些信息仅作为外部引用，哪些工具应在运行时才读取。

这正是仅靠堆砌长提示词无法奏效的原因。

处理长任务时，麻烦不在于第一句话如何撰写，而在于系统如何持续整理上下文、连接工具、记录状态、检查结果。

上下文需先区分清楚：哪些是必须遵循的事实，哪些是背景信息，哪些仅是线索。工具也需分层管理：搜索、浏览器、代码执行、文件读写、邮箱、日历，不能全部交由Agent随意调用。结果检查必须成为固定动作：写稿需核实来源与时间，修代码需运行测试，做调研需列出不确定之处。

还有一个经常被低估的要素：记忆。

Addy Osmani在那篇文章中提到，长时间运行的Agent不能只依赖一次对话窗口，它需要外部的状态记录——可以是Markdown文件，也可以是项目管理看板——用于记录已完成事项和下一步计划。模型会遗忘，但项目不能。

这也是为什么Agent产品越来越像“小型工作系统”。它不再只是一个聊天框，而是一套由自动任务、工具连接、项目知识、子智能体、状态记录和检查机制共同构成的执行环境。

最容易被忽略的事实：成本高昂

循环（Loop）这一概念听起来很理想，但它并非免费午餐。

一次聊天回答通常只需一次模型调用。而一个Agent循环可能需要先搜索、再读取网页、调用多种工具、生成执行计划、执行动作、再调用模型检查结果。每多一轮，token消耗、工具调用次数、等待时间都会成倍增加。

Addy Osmani在《Loop Engineering》中也提醒过，token成本必须谨慎控制，因为不同使用方式的消耗量天差地别。Anthropic在谈到Agent运行时探索时也指出，这种方式比预先取好数据更慢，还需要更有意识的工程设计，否则Agent可能浪费上下文、误用工具，或者陷入死胡同无法自拔。

这就是循环的第一层现实成本：费token、费工具调用、费时间，也费审核精力。

第二层成本更为隐蔽：Agent做得越多，人类就越需要检查它究竟做了什么。

如果一个Agent“修复”了12个文件、跑了4次测试、引用了8个网页，表面上看它“很努力”，可人类需要确认的要点也同步增加。它节省的是手工执行步骤，但增加了过程审计的工作量。

因此，任务闭环绝非越长越好。

一个良好的循环，要知道何时继续，更要懂得何时停止。连续失败三次应停止，预算超限应停止，遇到发邮件、删文件、提交代码等敏感外部动作应停止，遇到来源不清也应停止。

一个不会停止的Agent，本身就是风险源。

闭环也会放大错误

循环的另一个潜在风险是错误会沿着链条不断累积。

“原地打转”还算容易被发现：它一直在搜索、总结、改写，任务却毫无推进。

更危险的是另一种情况：Agent选择了一条看似合理但根基有问题的路线，然后一路头也不回地走下去。第一步信息来源错了，后面的分析就会越写越完整，离真相却越来越远；第一步判断错了，后面的修改就可能越改越离谱。它越努力，回头修正的成本就越高。

还有一类失败叫“假完成”。

这是最令人担忧的情况。它不像报错那样明显，反而看起来非常成功：步骤齐全、日志漂亮、交付物完整。但最终结果并未真正满足目标。

例如，一份调研报告结构完整、语言流畅、引用不少，但关键事实全部来自二手转述；一段代码测试刚好通过，却绕开了问题根源；一封邮件措辞语气完全正确，却发给了不该发送的人。

Agent一旦具备行动能力，权限问题会变得异常敏感。让AI提供建议是一回事，让它修改文件、发送邮件、提交代码、下单、删除内容，则是另一回事。权限、预算、日志和人工确认点，这些必须置于循环外部，由系统层控制，绝不能完全交由循环自行决定。

OpenAI前研究员Lilian Weng在讨论框架工程时也提到，权限控制和安全层应当置于那些会自我改进的循环之外。这一判断同样适用于普通Agent产品：越是能自动执行，越要把关键边界置于系统外层。

人类并未退出，只是位置转变

如果说提示词时代考验的是“如何向AI提问”，那么Agent时代考验的则是“如何定义任务系统”。

以往，人类可以随时在聊天框中提醒模型：“不对，重新查”“这个来源不行”“先别写，补上背景”“这个动作别做”。

到了Agent闭环中，这些提醒需要提前转化为规则，嵌入系统。

开发者要设计状态管理、工具调用、结果检查和停止条件。产品经理要定义任务流：用户给出什么目标，Agent能执行哪些动作，在哪里交付成果，哪个环节必须由人类确认。就连普通用户也不能只扔下一句“帮我搞定”，而必须把目标、边界和验收标准说清楚。

人类并未被移除，只是角色从“每一步都提醒它”，变成了“设计它如何自行走完这几步”。

这也是为什么Agent领域的竞争不会仅停留在模型能力上。

模型更聪明当然很重要。但当AI从聊天窗口正式进入工作流，真正能拉开差距的，恐怕是那一套循环系统谁更稳定：谁更擅长整理上下文，谁更擅长调用工具，谁更擅长检查结果，谁更能控制成本——以及，谁更懂得何时该停止。

下一代AI助手比拼的，不只是回答的质量。将任务跑完是一回事，让人类放心地知晓它是如何跑完的，是另一回事，而且可能是更重要的一回事。