循环工程：AI协作模式的底层重构
最近硅谷AI技术圈出现了一个全新概念——循环工程（Loop Engineering）。这一趋势标志着程序员与AI协作模式的根本性转变：程序员的核心工作不再是手动编写提示词去调用Coding Agent，而是设计一套能自动驱动Agent运转的循环系统。OpenClaw开发者彼得·斯坦伯格（Peter Steinberger）明确提出，不应再手动提示Coding Agent，而应设计让Agent自动运行的循环。Anthropic旗下Claude Code负责人鲍里斯·切尔尼（Boris Cherny）也证实，自己现在很少直接给Claude写提示词，大部分工作交给后台自动运行的循环完成，其核心职责转变为编写这些循环逻辑。甚至Andrej Karpathy提出的AutoResearch项目，其核心思路也是将人从循环中抽离，让系统自主运行以提升token吞吐量。
"你不应该再去手动提示Coding Agent了，你应该设计让Agent自动运行的循环。"
这种转变的背景在于过去两年间，我们与Coding Agent的协作方式极为直接：用户写提示词、给上下文、等结果，再输入下一段指令。在这种模式下，Agent更像是一个需要全程握持的工具，每一步动作都需要人来触发。然而，随着行业深入，越来越多的从业者认为这种‘人驱动’的模式正在被淘汰，取而代之的是‘系统驱动’的循环模式。这种新范式旨在让人不再成为整个流程的瓶颈，通过自动化调度实现更高效的生产力。
循环工程的定义与早期挑战
循环工程的核心定义是用设计的系统替代人工，完成对Agent的提示和调度。这里的‘循环’可以理解为一个递归的目标设定：用户只需定义最终目的，AI便会反复迭代执行，直到目标达成。目前，Claude Code和OpenAI的Codex这两款主流Coding Agent均已完整具备构成循环系统的五个基本模块能力。尽管方向明确，但该领域仍处于非常早期的阶段，面临两大现实挑战：
- Token成本高昂：不同使用模式下token消耗量差异巨大，预算有限时必须谨慎规划循环运行逻辑。
- 代码质量风险：在无人值守的循环中，AI生成代码质量下滑的问题尤为突出，这是行业普遍担忧的焦点。
"这个方向目前还处在非常早期的阶段，很多问题还没有得到很好的解决。最现实的问题就是token成本，不同的使用模式下token的消耗量差异非常大。"
尽管存在争议，但循环工程被视为未来与Coding Agent协作的雏形。值得注意的是，这一概念并非孤立存在，它与Agent Harness Engineering（为单个Agent搭建运行环境框架）和工厂模型（构建软件的一整套系统）密切相关。循环工程位于Agent Harness Engineering的上一层，相当于一个跑在计时器上的运行环境，能够自主生成辅助用的子Agent并自我驱动持续运转。一年前，实现自动循环需开发者自行编写大量bash脚本且难以迁移，如今这些核心能力已内置于主流Coding Agent产品中，使得不同工具间的底层架构趋于一致，开发者只需设计通用的循环逻辑即可跨工具运行。
模块一：自动化（Automations）与心跳机制
一套稳定运行的循环系统由五个核心功能模块及一个独立记忆载体组成。第一个模块‘自动化（Automations）’是循环的心跳，它通过设定运行周期让系统到点自动触发，无需人工启动，从而将一次性任务转化为真正的循环。
在OpenAI的Codex中，用户可在专门的自动化标签页创建任务，选择项目、提示词、执行频率（本地代码副本或后台工作树），并将结果分类归档。若发现问题则进入收件箱，若无问题则自动归档。内部常用此功能处理每日issue分类、CI失败汇总、提交简报及bug排查。此外，自动化任务可直接调用Skill，简化维护。Claude Code则通过/loop指令、定时任务及钩子（Hook）实现类似功能，甚至可推送到GitHub Actions实现关机后持续运行。
"自动化模块的作用是把潜在的工作任务主动发掘出来，而循环剩下的模块就是用来处理这些任务的。"
除了定时自动化，循环工程更贴近核心的是会话内的持续运行功能。Codex和Claude Code均支持/goal指令，该指令会持续运行直到设定的可验证停止条件成立。关键在于，写代码的Agent与判断是否完成的Agent是分离的：每轮执行后由独立小模型检查目标，用户只需提供如‘保证认证模块所有测试通过且格式无误’的条件，即可让系统自主运行，无需盯着进程。这种设计体现了行业在基础能力上的一致性。
模块二：工作树（Worktrees）与并行隔离
第二个模块‘工作树（Worktrees）’旨在解决多Agent并行运行时的文件冲突问题。当多个Agent同时修改同一文件时，极易导致代码冲突，任务失败。Git的工作树功能通过创建独立的工作目录，在单独分支上运行但共享仓库历史记录，从物理层面隔离不同Agent的修改，避免冲突。
Codex内置了工作树支持，允许多个执行线程同时访问同一代码仓库而互不干扰。Claude Code同样提供原生Git工作树功能，可通过--worktree参数在独立副本中开启会话，或为子Agent设置隔离配置，任务结束后自动清理。然而，工作树仅解决机械层面的文件冲突，真正的瓶颈依然在人。
"工作树解决的只是机械层面的文件冲突，但是整个流程的瓶颈依然是人本身。你一天能认真审核多少份代码产出，才是你实际能运行多少个Agent的上限。"
这一现象被称为‘编排税（Orchestration Tax）’。工具虽能提升执行端效率，但审核和判断的工作量最终仍由人承担。因此，限制Agent并发数量的并非工具线程数，而是人类工程师的审查能力。这一限制提醒开发者，在追求自动化并行效率的同时，必须合理评估自身的人力负荷，避免过载导致的质量失控。
模块三：技能（Skills）与意图债务管理
第三个模块‘技能（Skills）’解决的是每次开启新会话时重复解释项目背景的问题。使用Coding Agent常面临‘意图债务（Intent Debt）’，即Agent每次会话从零开始，若未清晰说明要求，便会基于猜测填补空白，导致偏差。Skills通过标准化格式（文件夹含说明文档、指令、元数据及可选脚本/资源）将项目规则、约定、构建步骤及过往踩坑经验固化下来，供Agent每次运行时读取。
在Codex中，用户可通过符号或指令主动调用Skill，当任务描述与Skill匹配时系统自动触发。因此，Skill的描述需简洁明确，准确匹配优于花哨文案。Claude Code的Skill机制逻辑相同。Skills的深层价值在于避免意图债务的重复消耗，使项目知识不断积累产生复利效应。若无Skills，循环每次运行都需重新理解项目规则，效率极低。
"Skill是内容的编写格式，而插件（Plugins）是内容的分发方式。如果你想把一个Skill共享给多个代码仓库使用，或者把好几个相关的Skill打包到一起，就可以把它们封装成一个插件。"
此外，需厘清Skill与插件的关系：Skill是内容格式，插件是分发方式。将Skill与连接器打包成插件，同事只需安装一次即可使用整套配置，无需记忆搭建步骤。这区分了普通Agent与完整循环：普通Agent仅给出修复建议，而完整循环通过插件和连接器能自动创建合并请求、关联工单、通知团队，真正融入现有工作环境。
模块四：连接器（Connectors）与子Agent（Sub-agents）
第四个模块‘连接器（Connectors）’将Agent接入日常工具链，大多基于MCP协议构建。通过连接器，Agent可读取需求跟踪器、查询数据库、调用测试接口或在即时通讯工具中发消息。由于Codex和Claude Code均支持MCP协议，为一款工具编写的连接器通常可在另一款中直接使用，提升了互操作性。
第五个模块‘子Agent（Sub-agents）’是循环中最具价值的结构设计，其核心逻辑是将写代码的角色与检查代码的角色拆分。让写代码的模型自我评审往往因判断宽松而忽略逻辑漏洞，而拥有不同指令或模型的第二个Agent能发现这些问题。在Codex中，用户可主动生成多个子Agent并行运行并合并结果，通过配置文件定义Agent名称、描述、指令、模型及推理强度（如安全审查用强模型高推理，探索型用轻量模型只读）。Claude Code支持类似机制，可组建Agent团队让任务在角色间流转。
"子Agent也会消耗更多的token，因为每个Agent都要独立完成模型调用和工具使用，所以这项能力不需要到处都用，只在需要二次把关的关键场景开启才划算。"
最常见的分工模式为：一个Agent探索需求，一个实现代码，一个对照规格验证。这种设计在无人值守循环中至关重要，因为只有拥有信得过的验证环节，用户才能放心让系统自主运行。值得注意的是，/goal指令底层即利用此逻辑，由全新模型判断循环是否完成，实现生成与校验的分离。
记忆系统与完整循环场景演示
完整的循环系统还需一个独立的记忆载体，如Markdown文件或项目看板。由于大模型每次运行间不记忆内容，记忆必须存在于单次对话之外，落入持久化存储（如磁盘文件）。Agent会忘记进度，但代码仓库和状态文件不会，这就是外部记忆的价值。它将单次任务执行转化为小型自主工作系统。
以日常场景为例：每天早上，自动化任务在代码仓库运行，调用分类Skill读取CI失败记录、未解issue及最近提交，将问题整理写入状态文件。对值得处理的问题，循环创建隔离工作树，派出子Agent起草修复方案，再派另一子Agent对照规范和测试用例审查草案。随后，连接器自动创建合并请求、更新工单，复杂问题进入收件箱待人工处理。状态文件记录已尝试方案、通过验证及处理中问题，确保次日自动化任务能从断点继续，而非从头开始。
"你会发现，在这套流程里你只需要设计一次循环的规则，之后不需要手动提示任何一个步骤。这就是斯坦伯格那个观点的现实体现。"
这套逻辑在Codex和Claude Code中均可跑通，因底层模块一致。它体现了彼得·斯坦伯格的观点：通过设计循环规则，实现无需手动提示的自动化推进。然而，这并不意味着程序员无事可做，反而带来了新的责任与挑战。
循环工程的三大风险与工程师角色转变
尽管循环工程提升了效率，但它并未将人从工作中剔除，反而凸显了三个日益突出的问题：
- 代码验证责任仍在人：无人值守循环也是无人值守犯错的循环。子Agent的验证仅是参考，‘完成’仅是声明而非严格验证结论。用户仍需交付亲自确认可正常运行的代码，这一核心责任不因自动化而改变。
- 理解债（Comprehension Debt）累积：循环产出代码越快，用户亲手写的代码越少，实际代码与理解内容间的差距越大。运行越顺畅的循环，理解债增长越快。唯一解法是认真阅读循环生成的每一份代码，保持对代码库的掌控力。
- 认知投降（Cognitive Surrender）风险：最舒服的状态往往最危险。当循环自动运行时，人易停止主动思考，直接接受所有结果。设计循环可以是提升效率的解药，也可以是能力退化的加速剂。若为逃避思考而丢给循环，将加速能力退化。
"循环本身分辨不出这两者的区别，但你自己可以。这也是为什么设计循环比写提示词更难，而不是更简单。"
总结：平衡之道与杠杆点转移
循环工程是AI协作演进的方向，但处于早期。完全依赖自动化循环而不做审核，产品质量大概率下滑，甚至陷入越修越多的恶性循环。因此，建议尝试搭建循环，但不否定直接提示Agent的价值，找到两者间的平衡至关重要。
循环最终结果取决于使用者：一人用于深度理解的工作以提升效率，另一人用于逃避理解，结果截然相反。设计循环比写提示词更难，因为工作的杠杆点发生了转移：以前杠杆来自写好提示词，现在来自设计好一套能持续运行的系统。鲍里斯·切尔尼的观点并非说程序员工作变简单，而是杠杆点转移。
"你可以去搭建你的循环，但要以一个工程师的身份去搭建，而不是做一个只会按下启动键的人。"
简而言之，开发者应以工程师思维搭建循环，保持判断力与代码理解，利用自动化处理重复劳动，而非放弃思考。唯有如此，循环工程才能真正成为提升研发效率的有力工具，而非能力退化的温床。