编程 Agent 的重点，正从写提示词转向设计可自动迭代的循环系统。
原文标题：从提示词工程到循环工程，聊聊编程 Agent 的范式转变
原文作者：图灵编辑部
冷月清谈：
怜星夜思：
2、文章说循环系统会带来“理解力债”，你觉得开发者该怎么避免自己越来越看不懂项目？
3、子 Agent 做校验听起来很美，但如果两个 Agent 都错了，人类该怎么设置最后一道防线？
4、你会把哪些开发任务交给自动循环，哪些任务仍然坚持手动和 Agent 单轮对话？
原文内容
循环工程（Loop engineering）正在取代由人类直接向 Agent 发送提示词的传统模式。开发者转而负责设计一套系统，由该系统来自动完成这一过程。这里的“循环”本质上是一个递归目标：用户只需定义核心意图，AI 便会不断迭代，直至任务最终完成。该架构大致包含五个核心基石，目前 Claude Code 与 Codex 均已完整具备。
这或许代表了未来人类与编程 Agent 协同工作的核心形态。但由于该技术仍处于早期阶段，我对此持保留态度。此外，Token 成本是不容忽视的关键因素。本文将深度解析循环工程的内涵及其带来的实质影响。
Peter Steinberger 近期指出：“开发者不应再直接向编程 Agent 发送提示词，而应当着手设计那些能够自动调度 Agent 的循环系统。” Anthropic 公司 Claude Code 负责人 Boris Cherny 也表达了类似观点：“我不再直接给 Claude 下达指令，而是运行一系列循环程序，由它们向 Claude 发送提示并决策下一步行动，我的核心工作变成了编写这些循环。”
那么，这究竟意味着什么？
过去两年里，从编程 Agent 中获取产出的典型方式是：撰写高质量的提示词并提供充足的上下文，你输入一行指令，阅读返回的代码，然后再输入下一行。
在这个过程中，Agent 只是一个单纯的工具，而你全程都在紧握着它，一问一答地进行单步交互。如今，这种模式已经走向终结——或者至少在一些人看来，时代已经变了。
现在的做法是构建一个微型系统。由它负责检索任务、下发工作、校验结果、记录进度并决策下一步行动；由这个系统去直接调度 Agent，而无需人类干预。
我此前曾讨论过与之类似的“Agent 架构工程（Agent harness engineering）”以及“工厂模型（Factory model）”——前者侧重于打造单个 Agent 运行的闭环环境，后者则是构建整个软件的系统。循环工程则位于架构工程之上：它相当于一个自带定时器、能够自主孵化子任务并实现自我反哺的升级版架构。
最令我惊讶的是，这已经不再是单纯的工具问题了。一年前，如果你想实现自动化循环，还必须编写并维护一堆繁琐的 Bash 脚本，且这些脚本完全无法通用。而现在，这些核心组件已经直接内置于产品之中。
Steinberger 列出的功能清单几乎完美对应了 Codex 的应用逻辑，而 Claude Code 的设计也与之如出一辙。一旦你意识到两者的底层形态完全一致，就不会再纠结于工具的选择，而是会专注于设计一套无论在哪种环境下都能稳定运转的循环系统。
五大基石与记忆机制
一个完整的循环系统需要具备五个核心组件，以及一个用于存储状态的媒介。
-
自动化调度：基于特定时间周期自动运行，能够自主进行任务探索与优先级排序。
-
工作树：提供独立的工作空间，确保多 Agent 并行开发时互不干扰。
-
技能沉淀：沉淀并记录项目相关的常识与规范，避免 Agent 在开发时盲目猜测。
-
插件与连接器：提供标准接口，将 Agent 无缝接入团队现有的工具链中。
-
子 Agent 机制：实现职能分离，由一个 Agent 负责产出方案，另一个独立 Agent 负责校验。
在此基础之上，便是第六个要素——记忆机制。它可以是一个普通的 Markdown 文件，也可以是一个 Linear 看板，总之必须是独立于单次对话之外、能够持久化记录已完成与待推进事项的载体。
这听起来似乎平淡无奇，但却是所有长周期运行 Agent 赖以生存的核心逻辑。正如我此前在讨论长周期 Agent 时所提到的，大模型在两次运行之间会遗忘之前的所有状态，因此记忆必须沉淀在磁盘上，而不是依赖上下文窗口。模型会遗忘，但代码仓库不会。
目前，这两款产品均已完整内置了上述五大组件。
尽管各家产品在命名上略有出入，但其底层能力如出一辙。下面我将逐一进行拆解，坦白讲只有深入到这些工程细节中，才能真正看清一个循环系统究竟是严丝合缝，还是在暗中漏洞百出。
自动化调度：
循环的核心脉搏
自动化机制是让“循环”真正运转起来的基石，否则它充其量只是单次运行的脚本。
在 Codex 应用中，用户可以在 Automations 标签页中创建一个自动化任务，配置其对应的项目、待执行的提示词、运行周期，并选择在本地代码库还是后台工作树中执行。运行后若有发现，结果会被推送到分流收件箱；若无异常，则会自动归档。
OpenAI 内部正利用该功能处理各种琐碎的日常事务，例如每日 Issue 的分类筛选、持续集成失败原因的自动摘要、Commit 提交说明的编写，以及追溯上周引入的潜在 Bug。此外，自动化任务支持直接调用既有技能——这意味着你只需触发 $skill-name，而无需在调度配置中粘贴一整面没人愿意维护的冗长指令，从而极大地提升了周期性任务的可维护性。
Claude Code 则是通过定时任务与钩子机制来实现相同的效果。用户可以使用 /loop 命令按特定时间间隔运行提示词或脚本，也可以配置 Cron 定时任务，或者利用 Hooks 在 Agent 生命周期的特定节点触发 Shell 命令。如果你希望在合上电脑后任务依然持续运行，还可以将整套流程直接托管至 GitHub Actions。两者的核心逻辑完全一致：定义一个自动化任务，赋予其运行周期，随后只需等待结果上报，而无需人类反复手动检查。
此外，还有一种非常值得关注的会话内原生指令，它更接近本文探讨的核心本质。如果说 /loop 是按固定周期反复执行，那么 /goal 则是持续运转直至触达你设定的终止条件。在每次迭代后，系统会调用一个独立的微型模型来评估任务进度，从而确保编写代码的 Agent 不用兼任“裁判”。
你只需下达类似于“确保 test/auth 下的所有测试均通过且 Lint 检测无误”的指令，便可抽身离开。Codex 同样内置了名为 /goal 的相同功能，它支持跨轮次持续工作，直至验证通过满足停机条件，中途还支持暂停、恢复与清空。同样的原生逻辑，在两款工具中均得到了实现，这也正是本文所要揭示的普适规律。
这一组件的核心作用在于发掘并暴露问题，而循环系统的其余部分，则负责对这些问题展开实际行动。
工作树：
避免并行开发陷入混乱
一旦同时运行多个 Agent，文件冲突就会接踵而至，进而导致任务失败。两个 Agent 同时修改同一个文件，其带来的麻烦与两位工程师在缺乏沟通的情况下强行提交同一行代码如出一辙。而 Git 工作树（Worktree）能够有效解决这一痛点：它在共享同一代码库历史的前提下，为每个分支开辟独立的临时工作目录，从而在物理层面上确保一个 Agent 的修改绝对不会污染另一个 Agent 的工作区。
Codex 直接将工作树支持内置于系统底层，使得多个线程能够同时访问同一个代码库而互不碰撞。Claude Code 同样利用 Git 工作树实现了这种隔离机制：它提供 worktree 标志以便在独立的工作区中启动会话，并支持在子 Agent 上配置 isolation: worktree 参数，确保每个辅助 Agent 都能获得一个独立的、用完即毁的干净工作区。我此前在讨论“编排成本”时曾从人类协作的视角探讨过这个问题：工作树虽然消除了机械层面的代码冲突，但开发者自身依然是效率的瓶颈——决定系统并发上限的不是工具本身，而是你个人的 Code Review 带宽。
技能沉淀：
告别重复交代项目背景
技能机制能够避免你在每次开启会话时，都像金鱼一样不厌其烦地向 Agent 解释相同的项目背景。两款工具在这一点上采用了完全相同的格式：一个包含 SKILL.md 的文件夹，用于存储开发指令与元数据，并可选择性地附带相关脚本、参考资料及资产文件。
在 Codex 中，你可以通过 $ 或 /skills 手动调用技能；或者当当前任务与技能描述相匹配时，系统会自动触发该技能——这也是为什么严谨、务实的描述往往比花哨的措辞更有效。Claude Code 的实现方式如出一辙。
技能也是终止意图成本无限恶性循环的关键所在。Agent 在每次会话开始时都是一块白板，它会用极其自信的猜测去填补你意图表达上的任何空白。而技能正是将这些意图、开发规范、构建步骤以及鉴于以往某次事故，我们绝不采用某种写法的经验，固化在模型外部。你只需编写一次，Agent 在每次运行时都会自动读取。缺乏技能支持的循环系统在每个周期都要从零开始重新推演你的整个项目，而具备技能沉淀的系统则能让项目经验产生复利。
这里需要厘清一个概念：技能是内容的创作格式，而插件则是其分发载体。当你需要跨代码库共享某项技能，或者将多项技能打包在一起时，你需要将其封装为一个插件。在 Codex 中如此，在 Claude Code 中同样如此。
插件与连接器：
让循环真正触达业务工具链
一个只能读取本地文件系统的循环，其应用场景极其有限。基于 MCP（Model Context Protocol）构建的连接器，赋予了 Agent 访问 Issue 追踪器、查询数据库、调用测试环境 API 以及在 Slack 中发送消息的能力。由于 Codex 和 Claude Code 都原生支持 MCP 协议，你在其中一款工具上编写的连接器，通常可以直接无缝迁移到另一款工具中。此外，插件将连接器与技能打包在一起，让团队成员能够一键安装你的配置，而无需完全凭记忆去重新搭建整套流程。
这就是仅提出修复建议的单个 Agent 与能自动开 PR、关联 Linear 工单并在 CI 通过后自动在频道派发通知的循环系统之间的本质区别。连接器正是循环系统得以在真实开发环境中付诸行动、而非仅仅停留在口头建议的核心原因。
子 Agent 机制：
实现执行者与校验者的职能分离
在循环系统中，迄今为止最具实用价值的架构设计，无疑是将代码编写者与结果校验者进行解耦。让编写代码的模型去批改自己的作业，其态度往往过于宽容。而引入一个配置了不同指令的第二 Agent，则能有效捕获第一个 Agent 因思维定势而忽略的漏洞。
Codex 仅在用户明确发出指令时才会孵化子 Agent，让它们并行运行，并将最终结果汇聚合并。用户可以在 .codex/agents/ 目录下通过 TOML 文件自定义专属 Agent，为其配置名称、描述、指令以及可选的模型与推理强度。
通过这种方式，你可以让高推理强度的强模型担任安全审查员，而让轻量快捷的只读模型负责前期的可行性探索。Claude Code 同样具备这一机制，其通过 .claude/agents/ 下的子 Agent 及 Agent 团队实现任务在不同角色间的流转。在这两款工具中，最典型的职能分工通常是：一个 Agent 负责探索，一个 Agent 负责落地实现，另一个 Agent 则对照产品规格说明书进行最终的验证。
而在循环系统内部，这一机制之所以至关重要，是因为循环是在人类视线之外自主运行的。只有引入一个你真正信任的校验者，你才有可能安心抽身离开。当然，子 Agent 机制由于每个实例都需要独立的模型推理与工具调用，必然会消耗更多 Token，因此建议将预算倾注在那些确实需要第二意见的关键节点上。这也是 Claude Code 底层 /goal 指令的运作本质——由一个全新的模型来评判循环是否应当终止，而不是让执行任务的模型自己做主。这种执行与校验的分离，被直接应用在了停机条件本身的判定上。
一个典型循环系统的运作全貌
将上述组件有机结合，原本单一的技术线程便会演变成一个微型的控制面板。以下是我一直在高频使用的一种架构形态。
每天早晨，自动化任务会在代码仓库中定时触发。其提示词会调用一个分流技能，该技能负责读取昨天的持续集成（CI）失败日志、未解决的 Issue 以及近期的 Commit 记录，并将分析结果写入一个 Markdown 文件或 Linear 看板中。针对每一个具备处理价值的问题，该线程会立即开辟一个隔离的 Git 工作树，并指派一个子 Agent 去起草修复方案；随后，第二个子 Agent 会对照项目已沉淀的技能规范和既有测试用例，对该方案展开严格审查。
通过连接器，循环系统能够自动创建 PR 并同步更新工单状态。至于任何系统无法自主解决的异常，则会流转至分流收件箱中等待我人工介入。状态文件构成了整套流程的脊梁——它持久化地记录了哪些方案已被尝试、哪些测试已经通过、哪些事项仍处于开启状态，从而确保隔天早晨系统运行能完美承接前一天的进度。
回看整个流程，人类实际上只做了一件事：将其设计了一次。上述所有步骤都无需你手动去发送任何一条提示词。这正是 Steinberger 观点的真实例证——无论是在 Codex 还是在 Claude Code 中，由于底层组件完全一致，你最终构建出来的都会是这样一套循环系统。
循环系统依然无法为你做的事
循环工程改变了工作形态，但并没有将人类从流程中彻底抹去。事实上，随着循环系统越发完善，以下三个问题不仅没有变得简单，反而会愈发尖锐。
-
最终验证仍取决于人类：一个在无人监督下自主运行的循环，同样会在无人察觉的情况下持续犯错。将验证子 Agent 与执行子 Agent 进行解耦，其核心目的仅仅是让循环系统给出的已完成结论更具参考价值；即便如此，已完成也只是一种声称，而非绝对的证明。正如我谈及 AI 时代的 Code Review时反复强调的那句话：“你的职责是交付那些你亲自确认过可运行的代码。”
-
技术认知依然在加速腐蚀：如果放任不管，你的理解力会逐渐退化。循环系统帮你交付不属于你编写的代码速度越快，既有代码库与你真实掌握的技术之间，鸿沟就会越大。这就是理解力债，而一个运转过于顺畅的循环，只会加速这种债务的堆积——除非你真正去阅读它所产出的每一行代码。
-
安逸的姿态往往最危险：当循环系统实现自我运转时，开发者极易丧失独立思考的能力，从而倾向于盲目接受系统反馈的任何结果。我将这种现象称为认知投降。设计循环系统是一把双刃剑：当你带着审慎的判断力去构建它时，它是解决问题的良药；而当你为了逃避思考而去构建它时，它便成了退化的加速器。同样的举动，导向的却是完全相反的结局。
构建循环，保持审慎
我认为这预示了我们未来工作形态的演变趋向。如果我不亲自走查代码，或者完全依赖自动化循环去修复问题，产品质量必然会滑坡。这非但不能解决问题，反而可能让我陷入恶性循环，在泥潭中越陷越深。
因此，尽可去搭建你的循环系统，但也无需全盘否定直接向 Agent 发送提示词的有效性。其核心在于找到两者之间的最佳平衡点。
此外，循环系统的产出结果完全取决于使用者本身。两个人构建出完全相同的循环，最终的结局可能南辕北辙。前者利用它在自己深耕的领域内加速推进，而后者则试图用它来彻底逃避对业务的理解。循环系统本身无法甄别这种差异，但你心知肚明。
这也正是循环设计比提示词工程更难、而非更简单的原因所在。Cherny 的核心观点并不是说工作变轻松了，而是说效能的杠杆点发生了转移。
去构建循环吧。但请以一个矢志坚守工程底线者的姿态去构建它，而不是做一个仅仅负责按下启动键的旁观者。
原文链接：https://addyo.substack.com/p/loop-engineering
《 图解 Skill 》
宝玉 | 著
百万粉丝 AI 应用专家宝玉作品，85 幅示意图 × 40 张实用表格 × 67 处特别提示，这本书是 Skill 工作流系统化落地经验的一线总结。本书不绑定平台，扣子、Claude Code、OpenClaw 均可使用；也不要求读者具备编程基础，只要你想用 AI 提效，就可以通过本书学会技能，并立刻投入使用。
《Claude Code 橙皮书》
花叔 | 著
一本零基础也能上手的 AI 编程实战佳作，央视新闻、《人民日报》专访达人亲身实践写成的落地手册。本书完整浓缩花叔一线实战经验，全书梳理了海量实操干货。3 个可直接复刻的完整项目、6 套经过验证的最佳实战流程、9 个极易忽略的实操注意事项、16 条踩坑复盘得来的避坑经验、35 条提升效率的核心实操建议。
如果你对手搓自己的专属 AI 智能体感兴趣，推荐你李博杰的「Agent 实战营」。
490+ 同学已加入，好评连连！
Agent 实战营主讲人：李博杰
Pine AI 联合创始人 & 首席科学家｜中科大少年班 + MSRA 联培计算机博士
-
畅销书《图解大模型》《图解 DeepSeek 技术》译者
-
华为首批 " 天才少年 " 项目入选；曾任华为 2012 实验室计算机网络与协议实验室副首席专家
-
顶会硬核履历：SIGCOMM / SOSP / NSDI / USENIX ATC / PLDI 多篇论文，ACM 中国优秀博士论文奖、微软学者奖学金
-
现在在 Pine AI 做的事：让 Agent 能像真人一样接打电话、操作电脑——实时语音 / 快慢思考结合 / RL / 知识系统 / Computer Use 全套工程化都已落地