Boris Cherny的这句话，值得反复品味。
他表示，自己现在几乎不再手动提示Claude了。每天的主要工作是编写循环，让这些循环去提示Claude，并根据需要自动判断下一步的操作，从而完成大部分调度工作。
Boris Cherny是Claude Code的产品负责人，负责开发那个许多人每天都在使用的Coding Agent。
这一现象似乎有些悖论：Anthropic公司的AI工具开发者已经开始使用一套系统来代替他们手动提示AI。他们不再是直接给AI下指令的人，而是设计“如何让系统给AI下指令”的人。
这就是硅谷最近热议的一个概念：循环工程（Loop Engineering）。
不是工具升级，是协作模式的换挡
在深入讨论这个概念之前，先明确它要解决的问题。
过去两年中，与Coding Agent协作的方式相对固定：用户写提示词 → Agent执行任务 → 用户查看结果 → 再次写提示词。每一步都需要人工触发。Agent更像是一个全程由用户掌控的工具，它不会自行启动、判断或收尾。
这种模式的瓶颈在于人本身。
提出循环工程的核心人物之一是OpenClaw的开发者Peter Steinberger。他的观点非常简洁：用户不应该再手动提示Coding Agent，而应该设计让Agent自动运行的循环。
Andrej Karpathy的AutoResearch项目也采用了类似思路：将人从循环中抽离出来，使系统自主运行，尽可能提升token吞吐量，避免人在整个流程中成为瓶颈。
谷歌云AI总监Addy Osmani最近发表了一篇深度分析文章，详细拆解了这套系统的组成模块。
一套完整的循环，由五个模块构成
Claude Code和OpenAI的Codex已经将这五个模块的能力内置到了产品中。一年前，开发者还需要自己编写bash脚本来维护这些功能，而现在则是开箱即用的。
① 自动化（Automations）——循环的心跳
定时任务。为Agent设定一个运行周期，到点自动触发，有结果时主动通知用户，没有发现问题则静默归档。
OpenAI内部使用这套系统进行每日自动分类新提交的issue、汇总CI失败记录、生成代码提交简报以及排查上周引入的bug等重复性工作。
Claude Code对应的指令是/loop和/goal。/goal指令特别有趣——用户给出一个停止条件，例如“让认证模块所有测试通过”，系统会一直运行直到条件满足。判断是否完成的是一个独立的小模型，而不是执行任务的那个模型。执行和验证从一开始就分开了。
② 工作树（Worktrees）——并行不撞车
同时运行多个Agent时，可能会出现两个Agent修改同一个文件的情况。这个问题类似于两个工程师未经沟通修改同一行代码所带来的麻烦。
Git工作树的解决方案是为每个Agent创建独立的工作目录，运行在单独的分支上，但共享同一个代码仓库的历史记录。物理层面隔离，从根本上避免冲突。
Claude Code的参数是--worktree，Codex则直接支持。
这里有一个现实的限制需要注意：工作树仅解决了文件的物理冲突问题。用户一天能审核多少份代码产出，才是实际能运行多少个Agent的上限——这不是工具能决定的。
③ 技能（Skills）——消除意图债务
每次开启新对话时都要重新解释项目结构、规范和构建方式，这是许多使用过Coding Agent的人都深有体会的痛点。
Skills的解决方案是将这些信息写成文档，放在指定目录，Agent每次运行时都能读取，无需用户再次解释。
更深层次的价值在于消除“意图债务（Intent Debt）”。如果Agent不了解项目规则，就只能猜测，而这些猜测往往与实际要求有偏差。Skill可以一次性记录规则、约定甚至过往踩过的坑，使知识在每次运行中复利积累，而不是每次都从零开始。
④ 连接器（Connectors）——让循环真正接入你的工作
基于MCP协议。有了连接器，Agent可以读取需求跟踪器、查询数据库、调用测试接口以及在即时通讯工具中发送消息。
这是普通Agent和完整循环的核心区别——普通Agent只是告诉你“这里有个修复方案”，而完整循环会自己创建合并请求、关联需求工单，并在CI通过后自动通知团队。从建议变成执行。
由于Claude Code和Codex都支持MCP协议，为其中一款编写的连接器通常可以在另一款中直接使用。
⑤ 子Agent（Sub-agents）——让写代码的不负责检查代码
将生成角色和验证角色分开。道理很简单：让写代码的模型审查自己的代码，它倾向于放过自己的逻辑漏洞。换成另一个具有不同指令甚至不同模型的Agent来审查，才能发现第一个Agent回避的问题。
最常见的分工是三个角色：一个探索需求，一个实现代码，一个对照规范进行验证。
这个设计在循环中尤为重要，因为循环很多时候是在无人监督的情况下运行的。只有可靠的验证环节，用户才能放心让它自行运行。
别忘了记忆系统
除了上述五个模块之外，还有一个不起眼但必不可少的部分：外部记忆。
它可以是一个Markdown文件，也可以是项目看板。记录哪些方案试过了、哪些验证通过了、哪些还在处理中。
大模型每次运行之间不记得之前的内容——这是其本质特点，而非bug。状态文件的作用就是解决这个问题：Agent会忘记任务进度，但磁盘上的文件不会。第二天早上的自动化任务可以从昨天停下的地方继续，而不是每次都从头开始。
但有三件事，循环帮不了你
第一，验证的责任还是你的。
一个无人值守运行的循环，同时也是一个无人值守犯错的循环。子Agent给出的“完成”声明并不等于经过严格验证的事实。用户依然需要亲自确认代码的可运行性。这一点不会因为有了循环而改变。
第二，理解债（Comprehension Debt）会悄悄积累。
循环产出代码的速度越快，用户没有亲手写过的代码就积累得越多，对代码库的真实理解会逐渐退化。运行越顺畅的循环，只会让这种债务增长得更快。唯一的解决办法是认真阅读循环生成的每一份代码。没有捷径。
第三，最舒服的状态，往往是最危险的状态。
当循环可以自行运行时，人们很容易开始不思考，直接接受所有结果。这被称为“认知投降”。
两个人搭建完全相同的循环，可能会得到截然不同的结果：一个用它提高工作效率，另一个则用它逃避对工作内容的理解。循环本身无法分辨这两者的区别，但用户自己知道。
最后一句话
Boris Cherny的观点并不是说程序员的工作变得简单了，而是工作的杠杆点发生了转移。
以前，杠杆来自写好提示词。现在，杠杆来自设计一套能够持续运行的系统。
去搭建你的循环——但要以一个工程师的身份去搭建，而不是做一个只会按下启动键的人。