别再死扣提示词，AI智能体开始卷Loop

今年AI圈子里，关于Agent的讨论越来越热，其中一个词被反复提到：loop。

乍一听像是开发者黑话，但说白了就一件事：让AI不再是“回答一个问题就收工”，而是在一个任务里反复执行同一套动作——做一步，看结果，再决定下一步怎么走。

今年6月，前谷歌工程主管Addy Osmani发了一篇题为《Loop Engineering》的文章。他在开头点明了核心：loop的本质，是把“你手动引导Agent”这件事，交给一个你提前设计好的系统去干。Anthropic Claude Code的负责人Boris Cherny也说过类似的话，他把自己现在的工作概括为“写loop”，让那些loop自己去提示Claude、判断下一步该做什么。

回想一下，过去咱们用AI，基本就是“一问一答”的模式。人写提示词，模型给答案；答案不满意，人再补充，模型再改。任务怎么往前走，说到底还是人在掌舵。

Agent想改变的，恰恰就是这个分工。

人给了一个目标之后，Agent不应该只回复一句“我建议你这样做”，而是得有能力自己拆步骤、调用工具、观察结果、修正路线，直到任务完成，或者它判断自己确实搞不定了。

放到产品里来看，这就是“任务反馈闭环”。

注意，这不是模型自己训练自己，也不是模型突然之间就长出了什么新能力。更准确的理解是：一个外部系统，把模型、工具、上下文、记忆、检查器和停止条件打包在一起，让AI能够在同一个任务里反复执行“计划、行动、观察、修正或停止”这一套动作。

这个转变的分量很重。因为聊天机器人只要回答得“像那么回事”就行，但Agent，必须真的把事儿往前推。

一次回答，解决不了长任务

最容易理解的例子，还是修一个代码报错。

普通的聊天模型看到一段错误日志，可能会直接生成一句：“这里看起来像是依赖问题，你可以试试这样改。”

一个有闭环能力的Agent，会多走好几步。它会先读相关文件，找到可能出错的地方；改完之后，自己跑测试；测试失败，就读取新的错误日志，再改一轮；要是反复试了几次都不行，它应该主动停下来，说明卡在了哪里，而不是继续像个无头苍蝇一样乱试。

这套逻辑放到代码里很直观，换成调研和办公场景，道理也是一样的。

让Agent做一份行业简报，它不能只是拼凑出一篇看起来结构完整的文章。它得先自己列出要回答的关键问题，然后去找资料，并且能区分一手来源和二手转述。如果遇到数据相互矛盾的情况，它还得继续补查，最后把结论、引用来源，以及哪些地方还不确定，全都交代清楚。

让Agent准备会议资料，它也不能只写一段议程。它要看日历、读邮件、找文档、整理待办事项。当缺少必要的授权或关键信息时，它还得知道停下来，向人求助。

所有这些任务的共同点是：执行过程中会不断产生新状态。

网页打不开了，测试又报错了，资料之间互相冲突了，用户最初的目标甚至需要重新拆分。提示词只能设定一个起点，真正处理过程问题的，是闭环。

在传统的多轮对话里，人是那个维持循环的发动机。AI给一版，人看一版，人再提醒它该查什么、改什么、停在哪里。

而在Agent的循环（loop）里，系统开始承担起一部分循环的职责。上一步的结果会变成下一步的输入，工具返回的信息会改变后续的动作，测试失败会触发新一轮的修正。人不再是一句一句地推着它走，而是提前设计好这个循环应该怎么跑。

难点，正在向模型外面转移

所以，Agent的难点，并不只在模型本身。

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

这就是为什么光堆砌长提示词是不够的。

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

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

还有一个经常被低估的东西：记忆。

Addy Osmani在那篇文章里提到，长时间运行的Agent不能只依赖一次对话窗口，它需要一个外部的状态记录——可以是一个Markdown文件，也可以是项目管理看板——用来记录已经做了什么、下一步是什么。模型会遗忘，但项目不能。

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

最容易被忽略的真相：它很费钱

Loop这个概念听起来很美，但它不是免费的午餐。

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

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

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

第二层成本更隐蔽：Agent做得越多，人就越需要去检查它到底做了什么。

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

所以，任务闭环绝不是越长越好。

一个好的loop，要知道什么时候继续，更要知道什么时候停下来。连续失败三次要停，预算超了要停，碰到发邮件、删文件、提交代码这类敏感外部动作要停，遇到来源不清楚也要停。

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

闭环，也会把错误放大

Loop的另一个潜在风险，是错误会顺着链条不断累积。

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

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

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

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

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

Agent一旦具备了行动能力，权限问题就会变得异常敏感。让AI给建议是一回事，让它去改文件、发邮件、提交代码、下单、删除内容，那是另外一回事。权限、预算、日志和人工确认点，这些必须放在loop的外部，由系统层来控制，绝不能完全交给loop自己做决定。

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

人没有退出，只是位置变了

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

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

到了Agent闭环里，这些提醒需要提前变成规则，嵌入系统。

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

人没有被拿掉，只是角色从“每一步都提醒它”，变成了“设计它怎么自己走完这几步”。

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

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

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