近日，一位 Anthropic 工程师发布了一份关于「智能体系统的循环工程」的 11 页资料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之后，视为 AI 编程进入下一阶段的关键方法。

这份资料之所以引发关注，是因为它刚好踩中了 2026 年 6 月 AI 编程讨论的转折点。Addy Osmani、Boris Cherny 和 Peter Steinberger 几乎在同一周把 AI 编程的新阶段称为 Loop Engineering，而 Stripe 的 Minions 管道已经用类似思路每周合并 1300 多个 AI 生成 Pull Request。

这个数字之所以重要，不是因为 AI 又多写了几行代码，而是因为软件开发的重心正在从「人类告诉模型写什么」，转向「人类设计一个会自己排队、取任务、写代码、检查结果、保存状态并继续运行的系统」。

过去一年，AI 编程工具的叙事大多围绕模型能力：代码补全更准、上下文窗口更长、代理能一次性完成更复杂任务。但 Loop Engineering 讨论的是另一件事：当生成代码本身越来越便宜，工程师真正要设计的，变成一个可持续运转的循环。机器可以不断产出候选方案，人类要决定哪些结果可信、哪些必须挡下、哪些长期成本正在被隐藏。

近日，一位 Anthropic 工程师发布了一份关于「智能体系统的循环工程」的 11 页资料，把 Loop Engineering 放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之后，视为 AI 编程进入下一阶段的关键方法。这篇文章正是以这份资料为切口，结合 Boris Cherny、Addy Osmani 等人的公开讨论，以及 Stripe Minions 每周合并 1300 多个 AI 生成 PR 的案例，解释 Loop Engineering 到底是什么、为什么突然被全网讨论，以及它真正改变的不是写代码，而是软件开发中的验证、调度和判断。

AI 编程从「一次提示」走向「持续循环」

Loop Engineering 被放在 Prompt Engineering、Context Engineering 和 Harness Engineering 之后，作为 AI 工程栈的第四层。

Prompt Engineering 解决的是「怎么问」；Context Engineering 解决的是「给模型看什么」；Harness Engineering 解决的是「如何把一次模型运行接入工具、测试和工作流」。Loop Engineering 往前多走一步：系统不只执行一次任务，而是能在固定时间或触发条件下重新启动，把上一次结果作为下一轮输入。

一个完整循环通常包含五个动作。

第一步是发现工作，例如扫描 CI 失败、开放 Issue、代码提交或待处理任务；第二步是任务交接，把任务整理成模型可以处理的上下文；第三步是独立验证，检查模型产出的代码是否真的运行、是否通过测试、是否引入副作用；第四步是结果持久化，把状态、判断和未完成事项写入文件或系统；第五步是调度循环，让下一轮在合适时间继续运行。

这里最关键的并不是「生成」，而是「验证」。如果一个循环只是不断让模型写代码、再让同一个模型夸自己的结果，它很容易变成「点头循环」：每一轮都看似前进，实际只是把错误包装得更完整。

Osmani 自己的晨间 triage 循环是一个个人版例子：系统每天自动读取前一天的 CI 失败测试、开放 Issue 和最近提交，生成状态文件，把无法处理的事项放进人工收件箱。它的价值不是替工程师做所有决定，而是在工程师醒来之前完成初筛，把注意力留给真正需要判断的部分。

Stripe 的 1300 个 PR：可靠性来自约束，不是模型

Stripe 的 Minions 管道是这轮讨论中最具冲击力的企业案例：每周合并超过 1300 个 AI 生成 Pull Request，且代码本身没有人工逐行编写。

但这并不等于 Stripe 把生产系统交给一个大模型自由发挥。相反，Minions 的关键在于高度受控的流程：确定性编排器先组装上下文，从 Jira、代码搜索和内部工具中提取任务信息；LLM 负责生成代码；之后通过硬编码 linter、提交门控和最终人工审查决定能否合并。

换句话说，可靠性不是来自「模型突然足够聪明」，而是来自一连串约束。模型负责提出候选改动，系统负责限制它能碰什么、必须通过哪些检查，人类负责最后判断是否进入主干。

这也是 Loop Engineering 与普通 AI 编程脚本的差别。普通脚本往往把重点放在「让模型完成任务」；循环系统必须考虑任务从哪里来、失败后如何处理、状态如何保留、预算如何控制、谁来阻止错误进入生产环境。

如果没有这些约束，每周 1300 个 PR 不是效率跃升，而可能是技术债务制造机。

生成器和评估器必须分开

Loop Engineering 的一个核心设计，是把生成器和评估器分开。

生成器负责写代码、改文件、提交候选结果。评估器负责挑错，而且最好默认假设代码有问题。两者不能由同一个「乐观代理」完成，因为模型在自我评分时往往倾向于认可自己的输出，尤其是在任务描述模糊、测试覆盖不足或上下文不完整时。

独立评估器可以更简单、更怀疑，也更容易调优。它不需要创造性地解决问题，只需要验证页面能不能打开、测试能不能通过、边界条件有没有破、代码是否符合既定规则。有些实践会让评估器通过浏览器自动化工具实际点击页面，而不是只读代码后给出判断。

这解释了为什么「验证」是五步循环中最难的一环。代码生成已经越来越便宜，但证明一段代码真的正确，仍然昂贵。尤其是在大型代码库中，错误不一定马上暴露，测试也不一定覆盖真实业务路径。循环跑得越快，未被验证的假设累积得也越快。

隐性成本会互相强化

Loop Engineering 的风险不在于它会不会写错代码，而在于它可能让团队更难发现自己已经失去理解。

第一类成本是验证债务。没有被测试覆盖的错误会在循环中不断累积，直到某次合并或上线才集中爆发。第二类是理解力衰退。代码库持续膨胀，但工程师没有亲手经历关键设计选择，心智地图停留在旧版本。第三类是认知投降。人类开始默认接受机器输出，只做形式上的批准。第四类是 token 消耗爆炸。重试、子代理、长上下文和多轮验证会让账单迅速上升。

这四项成本会彼此喂养：测试不够导致验证债务，验证债务增加后工程师更不愿深入理解，理解下降又让人工审查变成橡皮图章，橡皮图章式审查再推动更多自动重试和更高成本。

因此，同样一套循环组件，在不同工程师手里可能产生完全相反的结果。判断力强、边界清楚的人，可以用循环放大自己对系统的理解，把机器当作不知疲倦的执行层；判断力弱或过度依赖自动化的人，可能在数月后变成自己系统的「守门人」，只会批准或拒绝，却无法解释系统为什么这样运行。

代码变便宜后，贵的是判断

Loop Engineering 把一个长期趋势推到更清楚的位置：代码、计划、PR 和任务拆解正在变得接近免费，但「什么是真正正确」没有变便宜。

对企业来说，这意味着 AI 编程的投资重点可能从购买更强模型，转向设计更稳的流程：任务边界、上下文组装、独立评估、状态持久化、预算上限、人工审查点，以及出现异常时如何停止循环。模型能力仍重要，但它只是系统的一部分。

对工程师来说，角色也在变化。过去的核心劳动是写代码，现在越来越多劳动变成审查机器产出的候选答案：它是否符合需求、是否破坏架构、是否只是看起来合理、是否把复杂性推给未来的维护者。

这并不等于程序员已经被替代。相反，Loop Engineering 更像是一台判断力放大器。它能让一名工程师产出过去小团队才能完成的改动量，也能把懒惰、盲信和缺乏验证的习惯放大成生产事故。

真正的分叉在于，人类是否还保留足够强的判断和否决权。AI 可以不断提交 PR，但能不能合并、该不该上线、长期会不会拖垮系统，仍然取决于人。