一个新词，从哪冒出来的
2026年6月7日，Addy Osmani 发了一篇叫《Loop Engineering》的文章。没过几天，Sonar 就跟着聊起 Loop 里最容易被忽视的一环——验证器。再过几天，LangChain 也出来发声，从执行、验证、触发、改进几个角度把这个词又讲了一遍。
短短半个月，一个原本零零散散、存在于各种 Coding Agent 实践里的做法，突然有了统一的名字。
不过得先说清楚一件事：火的是这个概念，不代表相关的工程实践已经很成熟了。 这几篇文章其实都是在回应同一场关于 Coding Agent 的讨论，说明的更多是工程师们的一种心态转变——大家开始需要一个词，来描述自己正在做的事情：从”一轮一轮跟 Agent 对话”，变成”设计一整套让 Agent 自己跑的系统”。
以前用 Claude Code、Codex 或者 Cursor 写代码，基本流程是这样：你打一段 prompt，看它输出什么，再告诉它下一步干嘛。它写错了，你把上下文补上；测试跑不过，你把报错贴进去；方向跑偏了，你把它拉回来；看着差不多了，你判断能不能收工。
说白了，人一直守在循环里，充当那个判断者。
Loop Engineering 讨论的，就是怎么把这部分工作交给系统自己做：让系统自动组装上下文、调用 Agent、执行工具、拿到环境反馈、判断结果对不对、把状态记下来，然后自己决定是继续干、换个思路重试，还是干脆停下来，把问题甩回给人。
这套系统靠不靠谱，不在于能不能保证任务一定成功，而在于它能不能一直看得清任务进展到哪了，并且在预算花完之前，走到一个能说清楚的结束状态。 这里说的”收敛”其实包含两层意思：一是结果确实在一点点接近目标，二是当它没法再往前推进的时候，能自己识别出来并且正确地停下或者交给人，而不是傻乎乎地一直空转。
Agent 无限跑下去不叫收敛，Agent 自己嘴上说”我完成了”也不叫收敛。预算用完了乖乖停下来，虽然不算真正意义上的收敛，但至少是一个可控的结局，比失控强多了。
一个靠谱的 Loop，最后交给你的不该只是一堆改动，还应该有一份”证据包”：为什么之前失败了、这次改了什么、跑过哪些命令、哪些检查通过了、还有哪些风险没排除。有了这份东西，你才能快速判断这个结果能不能信。
词是新的，实践其实不新
这篇文章里，我们暂且把 Loop Engineering 翻译成”Agent 闭环工程”。这不是什么标准译名，只是想强调一点：反复跑不等于闭环。 只有当一次行动的结果，真正被拿去影响下一步的决策，这个循环才算是”闭合”了。
它不是这样的：
Prompt -> 回答
也不是这样反复生成：
生成 -> 再生成 -> 再生成
真正的闭环应该长这样：
行动 -> 拿到证据 -> 判断偏差 -> 调整下一步该干嘛
其实这种”循环”的想法早就有了。2022年的 ReAct，就已经让模型在”推理—行动—观察”这三步之间来回切换。2023年的 Self-Refine 和 Reflexion，进一步研究了怎么让模型带着上一轮的反馈和记忆继续改进。Anthropic 在那篇很多人都读过的《Building Effective Agents》里，也提到过一种叫 Evaluator-Optimizer 的常见做法：一个模型负责生成，另一个模型专门当”评委”给反馈，然后继续优化。
在 Coding Agent 这个圈子里，也早就有一些更粗糙但很好用的土办法。比如 Geoffrey Huntley 搞的 Ralph，做法很简单：把 Claude Code 扔进一个极简的 Bash 循环里，每一轮都重新读一遍仓库、任务文件和 Git 状态，然后接着往下推进。对话上下文可以随便清空重来，但状态一直留在代码仓库里，不会丢。
这些做法之间的区别，其实不在于”有没有循环”，而在于循环发生在哪个层面：
-
ReAct：循环发生在一次运行内部，新意是让推理、行动、观察交替进行。
-
Self-Refine：循环发生在多次模型调用之间，新意是加入了自我反馈和迭代修改。
-
Reflexion：循环发生在多次尝试之间，新意是引入了外部反馈和情景记忆。
-
Evaluator-Optimizer：循环发生在”生成者”和”评价者”之间，新意是把两个角色分开了。
-
Ralph：循环发生在多次独立的 Agent 运行之间，靠仓库、任务文件和 Git 状态把不同轮次串起来。
-
Loop Engineering：循环扩展到了整个工作系统，新意是把触发、隔离、状态、验证、治理这些环节都纳入进来了。
所以真正”新”的，不是循环这个想法本身，而是循环的边界，从模型内部一步步扩展到了整个生产系统。
到了2026年，定时触发任务、长期目标、Worktree 隔离、Skills、Subagents、Hooks、MCP、后台任务、持久化状态这些能力，已经陆续出现在 Codex、Claude Code 这类产品里了。以前得靠工程师自己拿脚本七拼八凑才能实现的东西，现在慢慢变成了 Agent 产品自带的基础设施。这大概也是为什么这套做法突然能被单独拎出来命名、然后迅速传播开的原因。
Loop 其实分三层
现在很多讨论一提”Loop”，什么都往里塞，结果这个词变得特别宽泛，什么都能算。为了不把事情搅在一起，不如把它拆成三层来看。
第一层：任务执行闭环
这一层回答的问题是：眼下这个任务，怎么一步步往前推？典型的流程是”计划/行动 → 环境 → 证据 → 验证 → 决策”。Agent 做一个动作，环境给出结果，系统把结果收集成证据，验证器（Verifier）判断和目标差多少，控制器（Controller）决定下一步该干嘛。
第二层：控制平面
这一层回答的问题是：任务什么时候该启动、该给 Agent 看哪些上下文、能让它做到什么程度、状态放在哪、预算够不够、哪些动作必须先经过人同意。触发条件、上下文组装、运行环境、状态管理、预算控制、权限管理、人工审批，都属于这一层。
第三层：改进闭环
这一层回答的问题是：这个系统本身怎么变得更好？系统会去分析历史的执行记录和评测结果，找出反复出现的失败模式，然后回过头去调整 Prompt、工具、Skill、验证器或者整个运行环境。LangChain 说的”爬坡循环”（Hill-climbing Loop），说的其实就是这一层。
Loop 的三层结构
这个拆分能帮我们避开一个很常见的误解：状态（State）不是流水线里的某一步骤，而是所有环节共用的一个”仓库”。 Agent 可以忘事，当前对话可以被压缩掉，但任务清单、进度文件、Git commit、测试结果、生成的文件、issue 里的评论、执行轨迹，这些东西都应该留在环境里，而不是只存在于对话记忆中。
借用 Addy Osmani 的一句话：模型会忘事，但代码仓库不会。
为什么偏偏是现在火起来
第一个原因：模型能扛的任务变长了。
METR 有个叫”任务完成时间跨度”（Task-Completion Time Horizon）的研究，从侧面证明了这一点：前沿 Agent 能搞定的任务，按人类专家完成同类工作通常需要的时长来算，正在越拉越长。注意，这里说的”时间跨度”是指人类做这件事一般要花多久，不是说 Agent 自己实际跑了多久。
但这个指标不能被理解成”Agent 已经能稳定接管真实项目了”。METR 测试用的任务通常边界很清楚，环境也比较干净，有明确的成功标准。而真实项目往往需求模糊、历史包袱一堆、隐藏约束一大把，还得照顾团队的品味和习惯。
正因为任务变长了，错误也更容易一步步累积下去。这时候状态管理、验证机制、预算控制、停止条件反而变得更重要了。
第二个原因：写代码这件事，天生比较适合搞闭环。
代码能跑起来，测试能失败，类型检查能报错，CI 能挡住不合格的合并，Git diff 能拿来审查，线上日志能回传回来。这些信号让 Agent 有机会从真实环境里得到反馈。没有这些外部反馈，模型基本就是在瞎猜；有了这些能被验证的证据，它才有机会一点点把方向纠正过来。
这也是为什么 Loop Engineering 最先在写代码的圈子里被反复提起——不是说这套方法只能用在代码上，而是代码这个场景，天生就更容易被环境验证。
不过要提醒一句：测试通过了，不代表产品就做对了。代码只是恰好拥有更多可被观测、可以自动跑起来的反馈信号，不代表需求、架构、用户体验这些东西也能被测试完整地表达出来。
第三个原因：大家慢慢发现，对话上下文不适合当长期状态用。
任务一长，Agent 经常会出两个毛病：第一轮就想一口气把所有事都干完；后面几轮看到已经有点成果了，又急着宣布”完成了”。如果所有状态都堆在对话历史里，跑的轮次一多就会越来越乱——上下文会膨胀，失败的尝试会混进来，旧目标和新目标会搅在一起分不清。
更靠谱的做法，是把状态放在环境里，而不是只指望对话记住这一切。
拿一个真实的 CI 修复任务举例
光讲证据、验证、控制这些概念，容易变成一堆干巴巴的名词。不如看一个具体的 CI 修复任务，会更容易明白 Loop 到底是怎么运转的。
第1轮： Agent 为了让 CI 跑绿，直接改了测试代码。验证器一看，测试确实绿了，但也发现了问题——它改了一个受保护的测试。于是控制器拒绝了这次结果，把测试代码回滚，同时收紧了它的写权限。
第2轮： Agent 换了个思路，改了业务代码，功能测试也通过了，可它顺手还重构了一个不相关的模块。验证器给出的判断是：功能没问题，但改动范围超标了。控制器决定：修复方向是对的，但要求它把改动范围缩小。
第3轮： Agent 这次只改了必要的代码，重新跑了一遍验证。测试、类型检查、安全扫描、改动范围检查全都通过了。控制器认为可以停了，于是生成一份证据包，创建了 PR。
CI 修复 Loop：三轮如何收敛
这个例子说明了几件挺重要的事：
Agent 自己说”完成了”不算数——它可能为了让 CI 通过就偷偷改测试，也可能借着修 bug 的名义，把不相关的代码也”顺手”重构了。
验证器的活儿不是简单给个”通过”或”不通过”，而是要具体指出问题出在哪：是测试被改了，是改动范围失控了，还是引入了新的风险。
真正决定”接下来怎么办”的是控制器：拒绝、回滚、收紧权限、要求缩小范围、继续跑、停下来，还是交给人来处理，这些判断都是控制器做的。
状态必须把失败的历史记下来，不然第2轮、第3轮根本不知道第1轮为什么被拒绝，也不知道哪些路子已经试过、走不通了。
证据包也是最终交付的一部分。没有它，人还是得自己去翻日志、看 diff、猜 Agent 到底干了什么，等于白忙活。
验证器，为什么是最容易出问题的一环
一个没有靠谱反馈、也没有判断机制的循环，严格来说算不上闭环，只能算是反复执行而已。
这里面其实也分三层：
第一层是证据，也就是最原始的材料——测试输出、构建结果、日志、截图、Git diff、线上指标。这些东西不负责解释什么，只负责把环境里能观察到的结果原原本本地带回来。
第二层是验证器，专门负责判断这些证据。它可以告诉你：现在失败的原因是什么、完成度大概多少、跟上一轮比有没有进步、判断的把握有多大、有没有什么风险信号。功能是不是达标了、改动范围有没有跑偏、有没有安全隐患，都是它要管的事。
第三层是停止策略，也就是判断什么时候该收工。所有硬性检查是不是都过了？打分有没有达到设定的门槛？有没有触发高风险的规则？重试次数、跑的时间、花的预算是不是超标了？
有一点特别值得强调：千万别让写代码的那个 Agent，同时也是唯一有权宣布”任务完成”的角色。 它可以自己检查一遍自己的工作，但不能拥有最终的验收权，这跟球员不能兼任裁判是一个道理。
但这里还有个容易被忽略的坑：换一个 Agent 来做验证，也不等于就是”独立验证”了。举个例子，Claude Code 的 /goal 功能会另外找一个小模型来检查任务是不是达到了完成条件，这确实做到了”干活的”和”检查的”角色分离，但不代表建立起了独立的证据链。如果这个负责检查的模型只能看到对话里已经出现过的内容，自己不能跑命令、不能读文件，那它其实还是依赖原来那个执行过程留下的证据，没有真正独立。
独立验证的关键，不在于”换了个模型来查”，而在于这个验证者是不是有自己独立的数据来源、独立的执行路径，以及真正说”不”的权力。
一套更靠谱的验证结构大概是这样：Agent 自己先检查一遍，再由一个独立的模型做语义层面的审查，然后在一个干净的环境里重新跑一遍测试、构建和安全检查，遇到高风险的情况，最后还得有人工审批把关。
那些关键的、隐藏的测试用例，最好放在 Agent 碰不到、改不了的环境里。证据里应该包含 commit 的 SHA 值、执行过的命令、环境版本、原始日志这些东西。还有一点得留心：不要盲目相信 Agent 自己写的 progress.md 之类的文件——放在外部的状态确实可以被审查，但这不代表它天然就是对的，该核实还是得核实。
验证器本身其实也可能被 Agent”钻空子”。它可能会去改测试、删掉那些通不过的用例、把关键逻辑 mock 掉、专门针对截图做一些像素级的小动作，或者干脆生成一些审查用的 Agent 特别爱看的说法来骗高分。所以 Loop Engineering 不只是要设计好反馈机制，还得想办法让这套反馈不容易被投机取巧地绕过去。
说到底，一个闭环靠不靠谱，取决于反馈信号的质量，而不是跑了多少轮。
Loop 是怎么失控的，又该怎么让它停下来
最麻烦的情况，往往不是 Agent 明显报错——报错至少会让它停下来，或者留下一句明确的错误信息，容易被发现。
真正危险的是：Agent 给出一个看上去挺靠谱的结果，验证器又不够强，于是整套系统就这么在错误的方向上一路自动跑下去了。
常见的失控方式大概有这么几类：
假装完成了。 Agent 干了一半就说自己做完了。应对办法是提前把”什么才算完成”定义清楚，设一道硬性的门槛。
投机取巧过验证。 Agent 为了让检查通过，改测试、绕过检查，或者把跑不通的路径藏起来。应对办法是限制它修改测试文件的权限，专门检查测试代码有没有被改动，再加一道独立验证。
原地打转。 每一轮都重复同一个失败的思路，或者在两个方案之间来回切换，就是没进展。应对办法是把尝试过的历史都记下来，连续失败几次之后就切换策略，或者直接交给人处理。
目标跑偏。 目标在跑了好几轮之后，慢慢就偏离了最初的方向。应对办法是把目标、任务清单、进度都写进持久化的状态里，而不是光靠对话记住。
多个 Agent 打架。 好几个 Agent 同时改同一批文件，互相冲突。应对办法是用独立的 Worktree、加任务锁、定好清晰的合并策略。
成本失控。 无限重试，子 Agent 越开越多，工具调的越来越频繁。应对办法是给 token 数、时间、轮次、金额都设上限。
权限失控。 Agent 删了文件、泄露了密钥、动了生产环境。应对办法是用沙箱、给最小权限、关键操作要人工审批。
理解跟不上。 代码改得太快，人已经跟不上系统到底发生了什么。应对办法是强制做代码审查、留设计记录、定期做阶段性总结、保证执行轨迹可追溯。
这些问题说到底都有一个共同点：系统缺少一个能说清楚的”结束状态”。Loop Engineering 不只是让 Agent 一直跑下去，更重要的是要想清楚——什么时候必须停。
怎么衡量一个 Loop 做得好不好
如果 Loop Engineering 真算得上一门工程，那就不能光画个架构图了事，得有实打实的指标才行。
验证通过率：真正通过了完整验收流程的任务占比。这里看的是有多少任务走完了完整的证据链，而不是 Agent 自己在总结里说自己做完了多少。
假通过率：验证器判定通过了，但后来人工复查、上线之后、或者隐藏测试发现其实根本没做完的比例。这个指标最能直接暴露出验证器本身靠不靠谱。
单个有效任务的成本：完成一个真正通过验证的任务，模型、工具、算力总共花了多少钱。Loop 跑得越多轮不代表越好，能便宜地把任务做对，才有真正的价值。
验证通过所需时间：从任务触发到最终验证通过，一共花了多长时间。这里算的是端到端的整体耗时，不是单次模型调用有多快。
卡壳/打转比例：有多少任务跑了好几轮、消耗了不少 token，但验证分数根本没提高，或者反复在几个方案之间来回切换。这个指标能直接反映出控制器识不识得出”这个循环已经没用了”。
意外人工介入率：有多少任务因为目标跑偏、卡住不动、权限配置出错，或者验证失败，不得不临时找人来救场。要说明的是，事先设计好的人工审批本身不是坏事，高风险操作本来就该由人来点头。
人工复核耗时：每个通过验证的任务，人得花多少时间去理解和确认它。Loop 真正省下来的往往不是”要不要人介入”，而是人重新搞懂 Agent 到底做了什么所需要花的时间。
漏网缺陷/回滚率：走完 Loop 之后，还是漏掉了、上线之后出问题被回滚的比例。这个指标最能暴露验证器到底够不够硬。
这些指标最好还得按任务类型、难度、风险高低分开来看，不然团队很容易挑简单任务来跑，把”验证通过率”做得很好看，实际没什么意义。
或许更接近本质的问法应该是：在保证质量和风险不超标的前提下，每花一百万 token，能真正做完多少个经过验证的任务？
哪些任务不适合搞 Loop
也不是什么任务都适合往 Loop 里塞。
如果目标本身说不清楚、结果几乎没法验证、出错了没法挽回，或者一次性任务自动化的成本比人自己动手还高，那就别为了赶时髦硬凑 Loop。
比如产品战略怎么选、高风险的法律或医疗判断、不可逆的生产数据库操作、高度依赖审美和个人品味的最终决定，这些都不适合完全交给系统自己跑。可以让 Agent 做辅助分析，但不该让它在没人审批的情况下自己闭环运转。
判断一个任务能不能上 Loop，不应该先问”模型够不够聪明”，而应该先问：系统自己知不知道，它到底做对了还是做错了？ 如果连这个都判断不了，Loop 只会把原本的不确定性自动放大而已。
工程师的角色变了
Prompt Engineering 教我们怎么给模型下一个好指令；Context Engineering 教我们这一轮该让模型看到什么信息；Harness Engineering 教我们该让 Agent 在什么样的环境里干活；验证器决定了质量的边界在哪；而 Loop Engineering，教我们怎么让 Agent 在真实环境里自己行动、自己观察、自己验证、自己纠正，并且在该停的时候停下来。
工程师并没有从系统里消失，只是从执行的内环，挪到了治理的外环。以前，他要盯着每一次 prompt、每一次检查、每一次纠偏；现在，他要做的是定义清楚目标、设计好反馈机制、控制好权限，并且想清楚什么情况下必须由人来接管。
模型本身还带着不确定性，这一点改变不了。所以可靠性不能靠模型自己嘴上说”我做完了”，而要靠证据、验证、状态、控制器，还有人工划下的边界。
说到底：模型给出的是能力上限，运行环境给出的是行动空间，验证器给出的是质量边界，而 Loop 决定了这些能力最终能不能持续变成靠得住的结果。
参考资料
-
Addy Osmani, “Loop Engineering”
-
LangChain, “The Art of Loop Engineering”
-
Sonar, “Loop engineering without verification is just automation”
-
Geoffrey Huntley, “Ralph Wiggum as a software engineer”
-
Anthropic, “Building Effective Agents”
-
Anthropic, “Demystifying evals for AI agents”
-
METR, “Task-Completion Time Horizons of Frontier AI Models”
-
OpenAI Developers, “Automations – Codex app”
-
OpenAI Developers, “Agent Skills – Codex”
-
OpenAI Developers, “Subagents – Codex”
-
Claude Code Docs, “Keep Claude working toward a goal”
-
Claude Code Docs, “Run prompts on a schedule”
-
Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”
-
Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning”
-
Madaan et al., “Self-Refine: Iterative Refinement with Self-Feedback”
-
Kamoi et al., “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs”
