循环工程？大多数开发者不需要！
大多数开发者暂时还不需要将他们的编程智能体放入循环中，即使这个技术在本月火了。
循环工程是构建一个按计划提示智能体的系统，而不是你自己逐条输入每个提示。
Peter Steinberger 在 6 月 7 日用一句话引发了这一轮热议：停止提示编程智能体，开始设计循环来提示它们。
它在四个条件下才有回报：任务会重复、验证是自动化的、你的 token 预算能承受浪费、智能体已经拥有高级工程师会使用的工具。缺少任何一个，循环的成本就大于收益。
1、循环实际上做什么
循环发现工作、交给智能体、检查结果、记录发生了什么，然后决定下一步。
Addy Osmani 在同一周发表了一篇关于此实践的长文，他简单明了地定义了它：循环工程就是用设计好的系统来取代你自己作为提示智能体的人。
Boris Cherny，Anthropic 的 Claude Code 负责人，在 Osmani 的文章中被引用了同样的话："我不再手动提示 Claude 了。我运行着循环来提示 Claude 并弄清楚该做什么。我的工作是写循环。"
Osmani 将循环分为六个部分：按计划运行的自动化、隔离并行工作的工作树、存储项目知识的技能、连接你工具的连接器、分离编写和检查的子智能体，以及跨运行持续存在的状态文件。
智能体每次运行都会忘记。文件不会。
2、想法并不新，新的在于可获得性
Anthropic 在 2024 年 12 月就描述了这些模式。
它的工程文章《构建有效的智能体》命名了评估者-优化者循环（一个模型生成，另一个批评，重复）和编排者-工作者模式（一个模型委托给其他模型），并将智能体定义为"通常只是 LLM 在循环中基于环境反馈使用工具。"
2026 年走红的术语在十八个月前就已经被记录了。
两件事发生了变化。
能力：Anthropic 报告称，模型能可靠完成的任务长度大约每四个月翻一番，比之前的七个月有所缩短，其顶级模型现在能处理大约需要人类十二小时的工作。
Anthropic 合并到自身代码库中超过 80% 的代码现在由 Claude 编写。
分发方式也变了。
Osmani 的说法是，一年前循环意味着写一堆 bash 脚本并永远维护它，而现在这些组件内置在工具中。
现在运行它只需要一个配置文件，而不是一个定制装置。
3、那你真的需要吗？
循环在四个条件下才赚回成本。构建之前先跑一下测试。
任务会重复。
循环将设置成本分摊到多次运行中。对于一次性任务，一个好的提示更快更便宜。如果工作不是每周重复的，你拥有的不是一个循环，而是一个你只运行过一次的脚本。
验证是自动化的。
循环需要能在你不在场时否定工作的东西：测试套件、类型检查器、linter、构建。没有自动化检查意味着你又回到了椅子上去阅读每个 diff，这正是循环本应消除的工作。
你的 token 预算能承受浪费。
循环会重新读取上下文、重试和探索。无论运行是否产出任何东西，这都会消耗 token。这种技术与预算成比例扩展，这就是为什么对实际上拥有免费 token 的人来说它显而易见，而对按量计费的人来则显得鲁莽。
智能体已经拥有高级工程师的工具。
日志、一个复现环境、运行其编写的代码并看到什么出错的能力。没有这些，循环就是盲目迭代。
四个都回答"是"的话，循环值得构建。缺少任何一个，你就是在自动化一个还没准备好被自动化的过程。
4、30 秒循环检查
在调度任何事情之前，检查五个条件：
- 任务至少每周发生一次。
- 测试、类型检查、构建或 linter 能否定坏的输出。
- 智能体能运行它修改的代码。
- 循环有硬性停止条件：token 预算、迭代次数或时间限制。
- 人类在合并、部署或依赖变更之前进行审查。
好的第一个循环：CI 失败分类、依赖升级 PR 草稿、lint-修复遍历、不稳定测试复现、在具有强测试的代码上进行 issue 到 PR 的草稿。
不好的第一个循环：架构重写、认证或支付代码、生产部署、模糊的产品工作、任何"完成"是一个判断性决定的事情。
缺少一个条件就保持为手动提示。
5、谁会输
生成从来不是瓶颈，循环让这一点变得显而易见。
Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍，Anthropic 自己称这个数字"几乎肯定夸大了真正的生产力提升。"
墙是审查，不是编写。
无人值守运行的循环会拉大第二个差距。
Osmani 称之为理解债务：循环越快交付你没写的代码，代码仓库中包含的内容和你理解的内容之间的距离就越大。
他将它与认知投降配对——那种停止形成观点、接受循环返回任何东西的倾向。
真正伤害的账单不是 token 账单。而是你必须调试一个团队中没人读过的系统的那一天。
token 账单也是真实的。
循环偏向于能花钱的人，大多数使用消费者套餐的开发者无法运行重型验证循环而不触及限制或收到意外账单。
6、什么区分了有效循环和昂贵循环
循环最难的部分不是循环本身。而是往里面放一个能说"不"的东西。
没有真正检查的循环就是智能体在重复赞同自己。
Osmani 的说法是，编写代码的模型用自己的话说是"给自己打分时过于宽容"，所以最高价值的结构性改变是将编写者和检查者分开。
这就是 Anthropic 2024 年文章中评估者-优化者模式的新名称。
检查必须能客观地失败：一个测试、一个类型错误、一个失败的构建。一个被告知"审查这个"但没有真正信号的第二个智能体只是增加了第二个乐观主义者。
失败模式有一个名字。
工程师 Geoffrey Huntley 记录了"Ralph Wiggum 循环"——一个本应在完成时才发出完成 token 的智能体提前发出了，然后循环在一个半成品的工作上退出了。
没有硬性关卡，循环会悄无声息地失败并继续消耗。
证据也不支持大规模扩展。
2025 年一项涵盖 26 个领域 306 名从业者的调查（《在生产环境中衡量智能体》研究）发现，68% 的生产环境智能体在人类介入前只运行十个步骤或更少。
有效的系统是小而受监督的，不是自主的群体。
2026 年一项关于异步编程智能体的研究，其收益（论文复现额外增加 26.7%，库任务额外增加 14.3%）来自于将每个智能体隔离在自己的 git worktree 中并验证，而不是来自于增加智能体。
Anthropic 自己对智能体的首要原则读起来也是一样的：保持简洁。
7、安全代价
无人值守运行的循环就是无人值守运行的攻击面。
佐治亚理工学院的 Vibe Security Radar 截至 2026 年中已追踪到超过 70 个确认的 CVE 与 AI 编程工具相关，该计数被称为不完整的，涵盖命令注入、服务端请求伪造和跨站脚本攻击。
智能体优化的是能工作的代码，而不是安全的代码，循环比人类阅读速度更快地交付这些代码。
智能体自身的配置也是一个目标。
2026 年对 17,022 个智能体技能的审计发现其中 520 个在泄露凭据，约 74% 的泄露归因于调试日志记录。
技能描述同时充当提示注入向量，因为智能体将它们读取为指令。
一个自动安装技能的循环会在没有人类事先审查的情况下继承每一个漏洞。
8、谁受益
获益的团队是那些拥有重复性、机器可检查的工作以及运行预算的团队：持续测试分类、依赖升级、lint-修复遍历、在具有强测试覆盖率的代码库上进行 issue 到 PR 的草稿。
如果初级工程师可以从检查清单完成任务，而测试套件能捕获错误，那么循环就适合。
应该跳过的开发者是：使用消费者套餐的独立开发者、任何在没有自动化验证的代码上工作的人、以及真正约束是审查能力而非输入速度的团队。
对于一次性任务、探索性工作，或任何"完成"是一个判断性决定的事情，一个精心瞄准的提示仍然胜出。
9、如果你要做：最小可行循环
如果你通过了四条件测试，在搞花哨的东西之前，先构建能工作的最小循环。
四个部分，不要搞群体。
一个自动化。 一个计划运行——Claude Code 中的 */loop* 或 Codex 中的 automation，按节奏触发并在明确条件下停止。两款工具也提供 */goal*，在陈述的条件为真之前持续运行。
一个技能。 一个单独的 SKILL.md，存储项目上下文——否则智能体每次运行都会从零重新推导。
一个状态文件。 一个 markdown 文件或 Linear 看板，记录已完成和待办事项，使明天的运行从中断处恢复而不是重新开始。Osmani 的规则：智能体会忘记，代码仓库不会。
一个关卡。 能自动否定坏工作的测试、类型检查或构建。这是决定循环是有帮助还是只是在消耗的部分。
顺序很重要：先让一次手动运行可靠，然后转化为技能，包装成循环，再调度它。
一个智能体每次运行都重新阅读的高层规格文档——VISION.md 或 AGENTS.md——可以防止长循环偏离目标。
衡量每个被接受的变更的成本，而不是消耗的 token 或尝试的任务数量。
10、我们的观点
循环工程是一种有真正天花板的真正实践，而大部分炒作跳过了这个天花板。
经济学并非普遍适用。 说它显而易见的人通常有不计量的 token。在 $20 的消费者套餐上，一个无界循环很快就会烧穿速率限制或产生大量使用费用，却没有什么成果，而且目前没有公开的、可验证的案例研究证明独立开发者的回报。
验证仍然是你的事。 这里的每个可靠来源，包括 Osmani 和 Anthropic，都得出同一个观点：循环自动化的是输入，而不是判断。代码审查已经是瓶颈，循环使这个队列更长，而不是更短。
新颖性被过度宣传了。 Anthropic 在 2024 年 12 月发布了这些模式。Gary Marcus 称最近的自我改进框架是一个"诱导和替换"，认为实际上展示的是人类控制下的更快编码，而不是一个自我改进的系统。在这点上，他是对的。
所以最好的建议是：如果你是使用计量套餐的独立开发者，等待；如果你的团队有自动化测试和能承受浪费的 token 预算，从小处开始。
对于重复性、可验证的工作，收益是真实的。对于其他一切，它是一个烧钱坑。
原文链接: Most Developers Do Not Need Agent Loops Yet
汇智网翻译整理，转载请标明出处