出品 | 网易智能

作者 | 小爪

编辑 | 王凤枝

今年围绕AI Agent的讨论里，一个词突然变得高频：loop。

它听起来像开发者黑话，但说白了就是一件事：让AI不再只回答一句话，而是在一个任务里反复执行同一套动作：做一步，看结果，再决定下一步。

6月，前谷歌工程主管Addy Osmani写了一篇《Loop Engineering》。文章开头表示：Loop的本质，是把"你来提示Agent"这件事，交给一个你设计好的系统来做；Anthropic Claude Code负责人Boris Cherny也说，自己的工作已经变成了"写loop"，让loop去提示Claude、判断下一步做什么。

过去我们用AI，大多是一问一答。人写提示词，模型给答案；答案不满意，人再补充，模型再改。任务怎么往前走，仍然由人负责。

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

人给出一个目标后，它不应该只回一句"我建议你这样做"，而是要能自己拆步骤、调用工具、观察结果、修正路线，直到任务完成，或者判断自己继续不了。

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

它不是模型自己训练自己，也不是模型突然长出新能力。更接近的理解是：一个外部系统把模型、工具、上下文、记忆、检查器和停止条件包在一起，让AI能在一个任务里反复执行"计划、行动、观察、修正或停止"这套动作。

这个变化很重要。因为聊天机器人只要回答得像样，Agent却要真的把事往前推。

一次回答解决不了长任务

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

普通聊天模型看到一段错误日志，可能会直接说："这里像是依赖问题，你可以试试这样改。"

有闭环能力的Agent会多走几步。它先读相关文件，找到可能出错的地方；改完以后跑测试；测试失败，就读新的错误日志，再改一轮；如果几次都不行，它应该停下来说明卡点，而不是继续乱试。

这件事放到代码里很直观，放到调研和办公里也一样。

让Agent做一份行业简报，它不能只生成一篇看起来完整的文章。它要先列问题，再找资料，区分一手来源和转述来源，遇到数据冲突继续补查，最后把结论、来源和不确定处交代清楚。

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

这些任务的共同点，是过程中会不断产生新状态。

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

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

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

难点开始转向模型外面

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

Anthropic在讨论上下文工程时，把Agent定义为"大语言模型在一个loop中自主使用工具"。它强调，Agent跑起来以后会不断产生新信息，系统必须反复决定哪些内容进入有限上下文，哪些信息只保留为外部引用，哪些工具应该在运行时再去读取。

这就是为什么只堆长提示词不够。

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

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

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

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

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

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

loop听起来很美，但它不是免费的。

一次聊天回答，通常就是一次模型调用。一个Agent loop可能要搜索、读网页、调用工具、生成计划、执行动作、再调用一个模型检查结果。每多一轮，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助手要比的，不只是回答质量。跑完任务是一件事，让人放心它是怎么跑完的，是另一件。