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