Loop Engineering —— Agent真正“智能”的来源

引言：同样接了大模型，凭什么有的叫Agent，有的只是chatbot？

这个问题都快被问烂了，但真能说到点子上的，没几个。

大模型本身，算Agent吗？你公司接了个模型，做出来的东西，到底是个chatbot，还是个Agent？凭直觉，大家都能感觉不一样：一个是你问一句它答一句，问完就结束；另一个会自己盯着目标，调工具、查资料、出错了重来，一步一步把事情搞完。

这个差别的根源，不在模型有多强，而在一个常常被忽略的东西——

。

本系列前几篇，我们一层层往外走：Prompt决定模型怎么思考，Context决定它基于什么思考，Harness让模型之外的执行变得可靠。但这三层加起来，还只是一堆静态的、强大的零件。

这一篇，我们就来讲这个最外环。但开篇我先把那句流行的话——"没有loop，就没有agent，只有chatbot"——说得更准确一点。因为它很抓人，却也略过头了。

一、先把那句流行的话说准确

"没有loop，就没有agent，只有chatbot。"这句话很适合做标题。但作为一个严谨的工程判断，它需要一个诚实的限定。

严格来说，

——它毕竟也"自主"地选了个工具、采取了行动。所以loop并不是"是不是agent"的开关。

更准确的表述是：

Loop决定的不是"是不是agent"，而是agent的鲁棒性和自主性——它能不能在一个不确定的环境里，持续、可靠地把任务做完。

这正好接上本系列第一篇给agent下的定义：Agent = 能在不确定环境中

任务的系统。注意"持续"和"闭环"这两个词——它们指向的，就是loop。

把chatbot和agent摆在一起，差别一目了然：

• chatbot
  ：一问一答，单向推进，无状态。它不会因为答得不好就自己重来，也不会盯着一个大目标分多步去完成。

• agent
  ：在一个闭环里运转，盯着目标，观察、判断、行动、校验，出错了就调整，做完了才停。它有状态，会自我推进。

为什么loop是"智能"的来源？这里有一个关键的洞察：

一个模型一次能做的判断有限，但把它放进一个会循环、会根据结果调整的闭环里，它就能逐步逼近一个单次调用永远够不着的复杂目标。这就像复利——单期收益不高，但持续复利之后，威力惊人。

拿招投标再具体一下这个"复利"。如果你只调一次模型——"读完这份招标文件，告诉我该不该投、报多少"——它给你的，是一次性的、信息过载下的粗判断，大概率不靠谱。但如果把它放进闭环：第一轮只判断"硬性资质是否满足"，第二轮基于这个结论再去比对历史中标价，第三轮结合前两轮再测算报价与风险……每一轮都站在前一轮的结论之上，单步的判断不难，但一圈圈叠下来，就逼近了一个单次调用永远给不出的严谨结论。

二、Loop的本质：一个由代码掌控的控制流，不是让模型自由循环

理解了loop的价值，紧接着是最容易踩坑的地方。很多人一听"让Agent自己循环"，就真的放手让大模型漫无目的地自我循环——想停就停、想继续就继续，全凭模型自觉。

这是一个非常典型的误解，而且后果可能很严重。它正是无数Agent不可靠、烧钱、失控的根源。

想象一个被"放任自循环"的招投标Agent：它读了一段条款，觉得"信息还不够，再查查吧"，于是又调了一次检索；结果还是觉得不够确定，再查、再想、再查……没有人告诉它"够了，该下结论了"。它就这样在一个判断上反复横跳，转了二十几轮，烧掉一大笔token，最后要么超时崩溃，要么给出一个和第三轮时差不多的结论。

这种"模型自己决定要不要继续"的设计，在demo里因为任务短、跑得顺，看不出问题；一到真实的复杂任务上，立刻原形毕露。

正确的认知是（这也呼应了前面几篇反复强调的）：

Loop不是让LLM自由循环，而是一个显式的、由你的代码掌控的控制流。

「12-Factor Agents」里有一条核心原则叫"掌控你自己的控制流"：循环、终止、状态更新这些骨架，应该写在你的代码里——跑一个显式的OODA式闭环、带明确的收敛启发式，而不是把控制流嵌套进prompt里、求模型自觉。

具体到每一轮，loop做的事其实很清晰：

这里的分工是决定成败的关键：

• 模型负责的
  ：在每一步，判断"下一步该做什么"。

• 工程负责的
  ：什么时候停、要不要重试、状态怎么更新、循环不能超过几轮。

把"何时停、是否继续"这种控制权交给模型，等于把方向盘交给一个会走神的司机。Loop工程的核心，就是把这个方向盘牢牢握在代码手里——

三、三种经典Loop：从ReAct到Plan-Execute

业界对loop的设计，演化出了几种经典范式。理解它们，是设计自己loop的基础。

这是最基础、也最有名的一种，由Yao等人在2023年提出。它的节奏是：，然后循环。模型先想"我该干什么"，做一个动作（调工具），看返回结果，再基于结果想下一步。它边想边做边看，特别适合那种的任务。局限是：如果缺乏全局规划，它可能在中途"走偏"，绕了很多无用的弯。

它的节奏是：。模型先把整个任务拆成一个计划，再逐步执行，最后校验。相比ReAct的"走一步看一步"，它多了一个全局视角，的任务，能减少中途乱走。代价是：计划一旦在执行中被证明不对，调整起来比ReAct更笨重。

：在行动之后，让系统对结果做一次反思，把"哪里做得不好"沉淀下来，用于改进下一次。它给loop加了一层自我批判的能力。

那企业到底该选哪种？给一个实用的选型判据：

拿招投标举例——"逐条审查未知的招标条款"这种探索性强的环节，更适合ReAct，走一步看一步；而"投标书的整体准备"这种步骤相对固定、需要统筹章节顺序的环节，更适合Plan-Execute，先排好计划再逐项推进。现实中，一个成熟的企业Agent往往是的：在需要探索的子任务里用ReAct，在需要规划的子任务里用Plan-Execute，必要时再叠一层Reflexion做质量回看。别把"选哪种loop"当成非此即彼的信仰之争，它只是按任务特性选工具。

这三种是通用的研究范式。但企业生产真正需要的，是把它们的精华揉进一个更完整、更可控的loop。这才是重头戏。

四、企业级Loop：把前面所有层串成一个持续运转的系统

前面几种loop偏研究范式，企业落地需要一种更完整的版本。它的节奏是六步：

检索（Retrieve）→ 决策（Decide）→ 执行（Execute）→ 校验（Validate）→ 更新状态（Update State）→ 重复（Repeat）

这条loop最重要的地方在于，它不是凭空多出来的一种，而是

。我们逐环对应：

• Retrieve（检索）
  —— 这就是

  Context 工程
  ：为当前这一步，喂对刚好够用的信息。

• Decide（决策）
  —— 这是

  LLM 在决策点
  上做判断。

• Execute（执行）
  —— 这是

  Harness
  调度工具去执行。

• Validate（校验）
  —— 这是

  Harness 的校验器
  在拦幻觉、查约束。

• Update State（更新状态）
  —— 这是

  loop 自己的核心职责
  ：把这一步的结果正确地写进状态，供下一轮使用。

• Repeat（重复）
  —— 在受控的预算和终止条件下，进入下一轮。

看明白了吗？

Loop不生产智能、不执行工具、不组织信息——它做的是调度：决定此刻该检索什么、让谁判断、调哪个工具、何时校验、如何更新状态、要不要再来一轮。它是把Prompt、Context、Harness这些零件真正盘活成一台运转机器的传动轴。

用招投标Agent走一遍这条loop就很具体了：检索本轮要判断的招标条款与相关历史（Retrieve）→ 判断这条是否构成废标风险（Decide）→ 调用条款库做精确比对（Execute）→ 校验比对结果与引用是否真实（Validate）→ 把"该条已确认/有风险"写进任务状态（Update State）→ 进入下一条款（Repeat），直到所有条款审完、报价与风险结论产出。

这里要特别点一下

这一环，因为它是loop独有、别人替不了的职责。Context负责"喂什么"、Harness负责"怎么执行"，但"这一轮做完之后，整个任务的进度走到哪了、哪些条款已确认、哪些还悬而未决、下一轮该从哪接着干"——这份贯穿全程的任务状态，只有loop在维护。它就像项目经理手里那张不断更新的进度表：没有它，每一轮都像失忆一样从头开始，反复检索、反复确认、永远收敛不了。

五、企业落地的四个关键机制（一份Loop体检清单）

Loop跑起来容易，跑得可靠难。让一条loop真正能上生产，有四个机制必须显式设计——这是你的Loop体检清单：

• ① 终止条件（termination condition）
  ：什么情况算做完了？什么情况该停手？没有它，loop要么永不停止，要么过早收尾。招投标的终止条件可以是"所有硬性条款已核对、报价与风险结论已产出并通过校验"。

• ② 循环预算（loop budget）
  ：给每次任务设最大轮数、最大token上限。这是防成本失控的硬约束——上一篇提过，连Anthropic都坦言缺一个好用的"单次任务成本硬上限"，所以预算闸必须自己建。

• ③ 错误恢复（error recovery）
  ：某一步失败时，把错误喂回上下文让模型自我修正（self-heal）；但要设三振机制，连续失败就升级给人，绝不无限重试。

• ④ 状态更新（state update）
  ：每一轮如何正确地演进状态？这里的关键工程实践是

  把执行状态（execution state）和业务状态（business state）统一管理，并做到可暂停、可恢复（pause/resume）
  ——这样任务中断了能续上，重启了不会从头再来，也不会重复劳动。

把这四个机制合在一起看，招投标Agent的loop就有了完整的"安全带"：它知道审完所有硬性条款且结论通过校验才算完成（终止条件），最多转8轮、超了就交人（预算），检索超时会重试两次、不行就升级（错误恢复），并且把"已审条款、待核疑点、当前报价草案"实时写进一份可续可恢复的状态表（状态更新）。少了任何一条，这条loop都会在某个深夜的真实流量里，以你意想不到的方式翻车。

还有一条来自一线的反直觉经验：

别试图让一个庞大的loop用精巧的逻辑扛下一切——把它拆成职责单一的小循环，每个都做到3–10步的可靠区间，超过20步就拆（这正是第二、三篇讲过的复利衰减和拆子loop）。

六、Loop的反模式：让demo翻车的几种循环

把上面的机制反过来，就是几种最常见、最致命的loop反模式。出问题时，先按这份清单排查：

• 无终止条件 → 死循环。
  模型在某个判断上反复横跳、永不收敛，loop转个不停。

  对策
  ：永远显式定义"完成"和"放弃"的条件。

• 无预算 → 成本失控（runaway cost）。
  一个开放式难题，可能让loop打转几十轮、单次烧掉惊人的token。

  对策
  ：硬性的轮数与token上限，逼近就强制收尾或升级。

• 状态丢失 / 不更新 → 重复劳动与遗忘。
  每轮不正确地更新状态，模型就会忘了自己已经做过什么，反复检索同一份资料、反复确认同一个条款。

  对策
  ：严谨的state update，并统一执行与业务状态。

• 把控制权交给模型 → 不可控。
  让模型自己决定"要不要再循环一次"，等于放弃了方向盘。

  对策
  ：终止与续行的决定，由代码的收敛启发式来做。

• 一个大loop扛所有 → 脆弱。
  用一个巨型loop+复杂恢复逻辑硬扛长链路。

  对策
  ：拆成小loop，早升级、早兜底。

这五种反模式，几乎覆盖了生产里loop翻车的绝大多数情况。它们的共同点是：

记住这条主线，排障就有了方向。

七、Loop为什么是"智能"的来源——回到最外环

走到这里，我们可以回答开篇那个问题了：为什么有的是chatbot，有的是agent？

因为chatbot只有一次固定的智能，而agent有一个把固定智能

起来的闭环。

把Loop放回那张同心圆：它是

，包在Harness之外，驱动着内部所有层——它消费Context组织好的信息、调度Harness执行的工具、决定整个系统的节奏与终点。它是让那台机器真正"动起来、转下去"的传动轴。

至此，四层runtime——Prompt、Context、Harness、Loop——我们已经从内到外走完了一遍。一台能在不确定环境里持续、可靠地完成任务的Agent机器，结构上已经完整。

回望这趟由内而外的旅程，你会发现一条清晰的主线：每往外走一层，我们解决的就是上一层管不了的问题。Prompt解决"怎么思考"，但管不了"基于什么思考"，于是有了Context；Context解决"喂什么"，但管不了"模型之外怎么可靠执行"，于是有了Harness；Harness给出可靠的执行积木，但管不了"什么时候调哪个、循环到何时停、状态怎么演进"，于是有了Loop。

而Loop，是给这台机器点火、让它持续运转的那一环。

但是，

结论：给你的Loop做一次四要素体检

这篇文章想留给你的，是一把检查loop健康度的尺子：

拿出你的Agent loop，问四个问题——有没有明确的终止条件？有没有循环预算？有没有错误恢复与升级？有没有严谨的状态更新？

四个里缺任何一个，你的loop就埋着一颗在生产里随时会爆的雷。把本篇的核心判断收成一句话：

Loop决定的是agent的鲁棒性与自主性（而非有无）；它必须是一个由代码掌控的控制流，而不是放任模型自由循环；企业级loop把Context与Harness串成一个持续运转的系统，而智能，正来自这个闭环把简单智能复利起来的过程。

如果你是技术决策者，现在就可以推动团队对现有Agent的loop做一次"四要素体检"，并重点排查那五种反模式。这往往是把一个"偶尔失控的demo"变成"稳定可控的系统"的关键一步。

最后，留一个问题，作为下一篇的引子：

我们已经把一台Agent机器从内到外搭完了。它能跑、能循环、能持续完成任务。可是——

一个不能被可靠度量的系统，是无法被迭代、无法被信任、也无法真正上生产的。如何科学地评估一个Agent系统，正是那根

——也是本系列要深入的内容。

我们下一篇见。