Loop Engineering（循环工程）

Loop Engineering（循环工程） Loop Engineering（循环工程） Modified June 9 各类叫法虽略有差异，但核心能力别无二致。我逐一拆解说明，毕竟细节决定整套流程是稳定运转，还是暗中处处出问题。 自动化任务，这是心跳 自动化任务才让流程成为真正的循环，而不是你曾经手动跑过的一次任务。在 Codex app 里，你可以在 Automations 标签页里创建一个自动化任务：选择项目、要运行的提示词、运行频率，以及它是在本地检出目录上运行，还是在后台工作树上运行。检测到异常的任务会归入待处理收件箱，无异常的则自动归档，使用体验十分友好。OpenAI 内部也用它处理各类重复性工作：比如每日 问题分拣、持续集成故障汇总、提交说明撰写、排查近期新增bug等等。 而且自动化任务可以调用技能，让周期性任务更易维护；只需调用对应技能名称，不必把冗长指令粘贴到定时任务中（这类长指令往往无人维护更新）。 Claude Code 实现逻辑一致，只是依托定时任务与钩子完成。你可以用 /loop 按周期执行提示词或命令，配置定时任务，借助钩子在智能体运行的特定阶段调用终端指令；如果想要关闭设备后任务仍然持续运行，还能将其托管至 GitHub Actions。核心思路完全相同：定义自主任务、设定执行节奏，结果自动汇总推送，无需人工逐一巡检。 还有一项会话内基础功能，也是本文的核心内容。/loop 是按周期重复执行，而 /goal 会持续运行，直至满足你设定的终止条件。每一轮执行结束后，会由独立的轻量模型做结果校验，实现编写与核验分离。比如设定条件 “auth 模块所有测试用例通过、代码静态检查无异常”，之后便可交由系统自主运行。Codex 也配备有 /goal 功能，支持多轮执行直至达成可校验的终止状态，同时提供暂停、恢复、清空等操作。两款工具采用同源基础能力，这也是全文反复印证的共性规律。 这一环节负责汇总输出任务结果，而循环的其他模块则针对结果开展后续处理。 工作区：让并行运行不再混乱 一旦同时启动多个智能体，就会出现文件冲突，进而引发故障。多个智能体同时编辑同一个文件，和多名开发人员互不沟通、强行提交代码到同一行代码里的窘境如出一辙。Git 工作区就能解决这个问题：它基于独立分支创建隔离工作目录，同时共享同一代码仓库的历史版本，从根本上杜绝不同智能体的文件操作互相干扰。 Codex 把工作树支持直接内置了，支持多个任务线程同时访问同一代码仓库且互不冲突。Claude Code 则借助 Git 工作区实现同等隔离效果：通过 worktree 参数在独立工作目录中启动会话；也可在子智能体配置里开启 isolation: worktree 选项，让每个辅助智能体都拥有专属工作目录，任务结束后自动清理。我此前在 the orchestration tax 里聊过人为协作层面的问题：工作区能解决机械性的文件冲突，但人的能力上限才是真正瓶颈 —— 你的审核处理能力，决定了可同时运行的智能体数量，而非工具本身。 技能模块：无需反复讲解项目背景 技能的作用，是让你不用每次新建会话都重复介绍项目上下文。两个工具采用统一规范：一个文件夹，里面有 SKILL.md，保存指令和元数据，外加可选的脚本、参考资料和素材。在 Codex 中，你可以通过 $ 指令、/skills 命令主动调用技能，系统也会根据任务描述自动匹配并触发对应技能。这也是为什么一个紧凑准确的描述，远远胜过一个花里胡哨的描述。Claude Code 也是类似方式；我在 agent skills 里写过这个模式。 技能模块还能彻底消除反复传递意图带来的损耗。我在 the intent debt 里说过，智能体每次启动会话都是 “从零开始”，一旦指令意图存在缺失，它就会自行臆测补全。而技能模块相当于把项目规则、构建流程、历史问题对应的特殊要求等内容固化下来，只需编写一次，智能体每次运行都会自动读取。没有技能模块，循环流程每一轮都要重新梳理整个项目；接入技能后，它就有点复利效应。 有一点需要分清：技能是编写格式，插件是分发方式。如果需要在多个代码仓库共用一套技能，或是整合多项技能，就可以将其打包为插件。Codex 是这样，Claude Code 也是这样。 插件与连接器，让循环接触真实工具 仅能访问本地文件系统的循环流程，能力十分有限。基于MCP 协议打造的连接器，可以让智能体对接Bug追踪平台、查询数据库、调用测试环境接口、向 Slack 推送消息。Codex 与 Claude Code 均兼容 MCP 协议，为其中一方开发的连接器，通常可以直接在另一方使用。而插件会把连接器和技能模块整合打包，团队成员只需一键安装配置，无需从零重复搭建整套环境。 这正是两类智能体的核心差距：普通智能体只会给出修复方案，而完善的循环流程能自动创建代码合并请求、关联工单，待持续集成校验通过后，还会主动在群组内通知。连接器让循环能在你的真实环境里行动，而不是只告诉你“如果我能做，我会怎么做”。 子智能体，实现编写与校验分离 在整套循环架构里，最实用的设计就是拆分执行角色：将代码编写方与结果校验方解耦。负责编写代码的模型，很难客观评判自己的产出。搭配指令不同、甚至模型规格各异的第二个智能体，就能找出前者因思维定式忽略的问题。 Codex 仅在手动触发时创建子智能体，多个子任务并行执行后，再将结果汇总整合。你可以在 .codex/agents/ 目录下用 TOML 文件自定义智能体，分别设置名称、描述、指令，还能指定模型与推理强度。比如安全审核选用高算力大模型，信息检索则使用轻量只读模型。Claude Code 在 .claude/agents/ 目录下配置子智能体与智能体团队，实现任务流转。两款工具的主流分工逻辑一致：一个负责信息探查、一个负责代码实现、一个对照规范完成校验。 我已经两次写过这个观点：一次是 the code agent orchestra，一次是 adversarial code review。它在循环里尤其重要，因为循环会在无人值守状态下持续运行；只有配备可信的校验智能体，你才能真正放心托管任务。子智能体的运行会消耗更多token，因为每个智能体都要独立调用模型与工具，建议把资源用在确实需要二次复核的场景。 其实 Claude Code 的 /goal 命令底层也是这套逻辑：由全新的独立模型判断流程是否终止，而非执行任务的本体模型，把 “执行者 + 校验者” 的分离思路，直接应用到了终止条件判断上。 一个循环长什么样 把以上模块组合起来，一个线程就会变成一个小控制面板。下面是我常用的一套流程架构： 每日定时在代码仓库中启动自动化任务，调用问题分拣技能，读取前一日的持续集成报错、未关闭工单与最新代码提交记录，并将分析结果整理为 Markdown 文件或同步至 Linear看板。针对每一项待处理问题，线程都会拉起隔离工作区，派遣两组子智能体：一组编写修复代码，另一组结合项目技能规范与现有测试用例完成代码审核。 依托连接器，循环可以自动创建代码合并请求、更新工单状态；循环无法处理的问题，则统一归入待处理队列由我跟进。状态文件是整套循环的核心，它会记录已尝试的方案、已通过的校验、待解决的问题，次日任务会接着当前进度继续执行。 你会发现：整套架构只需一次性设计完成，后续无需逐一步骤手动输入指令。这就是 Steinberger 那句话真正落地后的样子。无论使用 Codex 还是 Claude Code，核心组件完全相通，因此可以复用同一套循环流程。 循环仍然不会替你做什么 循环改变了工作模式，但不会取代工程师。 而且随着循环变得更好，有三个问题实际上会变得更尖锐，而不是更轻松。 验证仍然在你身上。 一个无人值守运行的循环，也会在无人察觉时产生错误。拆分校验子智能体，是为了让 “任务完成” 这个结论具备参考价值，但即便如此，“完成” 也只是一种状态表述，不等于绝对可靠。我一直重复 code review in the age of AI 里的同一句话：你的工作，是交付你确认能运行的代码。 疏于跟进会丧失业务认知。 循环越快交付你没写过的代码，现有系统和你真正理解的东西之间的差距就越大。这就是认知负债（comprehension debt）；如果不去阅读、理解流程生成的内容，这套高效体系只会加速认知断层的扩大。 依赖自动化容易陷入思维惰性。习惯了流程自动运转后，人很容易放弃独立判断，全盘接收输出结果，我称之为认知躺平。基于思考、审慎地设计流程，它会成为效率工具；单纯为了逃避思考而搭建流程，则会埋下隐患。同样一件事，导向却截然相反。 构建循环，但要始终坚守工程师的本职 我认为这也是未来研发工作的演变趋势。即便如此，如果我完全依赖自动化流程修复代码、放弃人工审核，产品质量必然下滑，最终陷入恶性循环。 当然，你可以放心搭建属于自己的循环流程，但也要记得，直接向智能体下发指令依然是有效工作方式，关键在于找到平衡。 同样一套循环流程，不同使用者会得到截然不同的结果：有人借助它深耕自己熟悉的业务、提升效率；有人却用它彻底逃避理解业务本身。流程本身没有区别，区别在于使用它的人。 这也解释了为何流程架构设计比提示词工程难度更高。切尔尼的观点并非工作变简单了，而是价值发力点发生了转移。 搭建自动化流程吧。但请以一名资深工程师的视角去设计，而非只做一个按下启动键的操作者。 the orchestration tax agent skills the intent debt the code agent orchestra adversarial code review code review in the age of AI 各类叫法虽略有差异，但核心能力别无二致。我逐一拆解说明，毕竟细节决定整套流程是稳定运转，还是暗中处处出问题。 自动化任务，这是心跳 自动化任务才让流程成为真正的循环，而不是你曾经手动跑过的一次任务。在 Codex app 里，你可以在 Automations 标签页里创建一个自动化任务：选择项目、要运行的提示词、运行频率，以及它是在本地检出目录上运行，还是在后台工作树上运行。检测到异常的任务会归入待处理收件箱，无异常的则自动归档，使用体验十分友好。OpenAI 内部也用它处理各类重复性工作：比如每日 问题分拣、持续集成故障汇总、提交说明撰写、排查近期新增bug等等。 而且自动化任务可以调用技能，让周期性任务更易维护；只需调用对应技能名称，不必把冗长指令粘贴到定时任务中（这类长指令往往无人维护更新）。 Claude Code 实现逻辑一致，只是依托定时任务与钩子完成。你可以用 /loop 按周期执行提示词或命令，配置定时任务，借助钩子在智能体运行的特定阶段调用终端指令；如果想要关闭设备后任务仍然持续运行，还能将其托管至 GitHub Actions。核心思路完全相同：定义自主任务、设定执行节奏，结果自动汇总推送，无需人工逐一巡检。 还有一项会话内基础功能，也是本文的核心内容。/loop 是按周期重复执行，而 /goal 会持续运行，直至满足你设定的终止条件。每一轮执行结束后，会由独立的轻量模型做结果校验，实现编写与核验分离。比如设定条件 “auth 模块所有测试用例通过、代码静态检查无异常”，之后便可交由系统自主运行。Codex 也配备有 /goal 功能，支持多轮执行直至达成可校验的终止状态，同时提供暂停、恢复、清空等操作。两款工具采用同源基础能力，这也是全文反复印证的共性规律。 这一环节负责汇总输出任务结果，而循环的其他模块则针对结果开展后续处理。 工作区：让并行运行不再混乱 一旦同时启动多个智能体，就会出现文件冲突，进而引发故障。多个智能体同时编辑同一个文件，和多名开发人员互不沟通、强行提交代码到同一行代码里的窘境如出一辙。Git 工作区就能解决这个问题：它基于独立分支创建隔离工作目录，同时共享同一代码仓库的历史版本，从根本上杜绝不同智能体的文件操作互相干扰。 Codex 把工作树支持直接内置了，支持多个任务线程同时访问同一代码仓库且互不冲突。Claude Code 则借助 Git 工作区实现同等隔离效果：通过 worktree 参数在独立工作目录中启动会话；也可在子智能体配置里开启 isolation: worktree 选项，让每个辅助智能体都拥有专属工作目录，任务结束后自动清理。我此前在 the orchestration tax 里聊过人为协作层面的问题：工作区能解决机械性的文件冲突，但人的能力上限才是真正瓶颈 —— 你的审核处理能力，决定了可同时运行的智能体数量，而非工具本身。 the orchestration tax 技能模块：无需反复讲解项目背景 技能的作用，是让你不用每次新建会话都重复介绍项目上下文。两个工具采用统一规范：一个文件夹，里面有 SKILL.md，保存指令和元数据，外加可选的脚本、参考资料和素材。在 Codex 中，你可以通过 $ 指令、/skills 命令主动调用技能，系统也会根据任务描述自动匹配并触发对应技能。这也是为什么一个紧凑准确的描述，远远胜过一个花里胡哨的描述。Claude Code 也是类似方式；我在 agent skills 里写过这个模式。 agent skills 技能模块还能彻底消除反复传递意图带来的损耗。我在 the intent debt 里说过，智能体每次启动会话都是 “从零开始”，一旦指令意图存在缺失，它就会自行臆测补全。而技能模块相当于把项目规则、构建流程、历史问题对应的特殊要求等内容固化下来，只需编写一次，智能体每次运行都会自动读取。没有技能模块，循环流程每一轮都要重新梳理整个项目；接入技能后，它就有点复利效应。 the intent debt 有一点需要分清：技能是编写格式，插件是分发方式。如果需要在多个代码仓库共用一套技能，或是整合多项技能，就可以将其打包为插件。Codex 是这样，Claude Code 也是这样。 插件与连接器，让循环接触真实工具 仅能访问本地文件系统的循环流程，能力十分有限。基于MCP 协议打造的连接器，可以让智能体对接Bug追踪平台、查询数据库、调用测试环境接口、向 Slack 推送消息。Codex 与 Claude Code 均兼容 MCP 协议，为其中一方开发的连接器，通常可以直接在另一方使用。而插件会把连接器和技能模块整合打包，团队成员只需一键安装配置，无需从零重复搭建整套环境。 这正是两类智能体的核心差距：普通智能体只会给出修复方案，而完善的循环流程能自动创建代码合并请求、关联工单，待持续集成校验通过后，还会主动在群组内通知。连接器让循环能在你的真实环境里行动，而不是只告诉你“如果我能做，我会怎么做”。 子智能体，实现编写与校验分离 在整套循环架构里，最实用的设计就是拆分执行角色：将代码编写方与结果校验方解耦。负责编写代码的模型，很难客观评判自己的产出。搭配指令不同、甚至模型规格各异的第二个智能体，就能找出前者因思维定式忽略的问题。 Codex 仅在手动触发时创建子智能体，多个子任务并行执行后，再将结果汇总整合。你可以在 .codex/agents/ 目录下用 TOML 文件自定义智能体，分别设置名称、描述、指令，还能指定模型与推理强度。比如安全审核选用高算力大模型，信息检索则使用轻量只读模型。Claude Code 在 .claude/agents/ 目录下配置子智能体与智能体团队，实现任务流转。两款工具的主流分工逻辑一致：一个负责信息探查、一个负责代码实现、一个对照规范完成校验。 我已经两次写过这个观点：一次是 the code agent orchestra，一次是 adversarial code review。它在循环里尤其重要，因为循环会在无人值守状态下持续运行；只有配备可信的校验智能体，你才能真正放心托管任务。子智能体的运行会消耗更多token，因为每个智能体都要独立调用模型与工具，建议把资源用在确实需要二次复核的场景。 the code agent orchestra adversarial code review 其实 Claude Code 的 /goal 命令底层也是这套逻辑：由全新的独立模型判断流程是否终止，而非执行任务的本体模型，把 “执行者 + 校验者” 的分离思路，直接应用到了终止条件判断上。 一个循环长什么样 把以上模块组合起来，一个线程就会变成一个小控制面板。下面是我常用的一套流程架构： 每日定时在代码仓库中启动自动化任务，调用问题分拣技能，读取前一日的持续集成报错、未关闭工单与最新代码提交记录，并将分析结果整理为 Markdown 文件或同步至 Linear看板。针对每一项待处理问题，线程都会拉起隔离工作区，派遣两组子智能体：一组编写修复代码，另一组结合项目技能规范与现有测试用例完成代码审核。 依托连接器，循环可以自动创建代码合并请求、更新工单状态；循环无法处理的问题，则统一归入待处理队列由我跟进。状态文件是整套循环的核心，它会记录已尝试的方案、已通过的校验、待解决的问题，次日任务会接着当前进度继续执行。 你会发现：整套架构只需一次性设计完成，后续无需逐一步骤手动输入指令。这就是 Steinberger 那句话真正落地后的样子。无论使用 Codex 还是 Claude Code，核心组件完全相通，因此可以复用同一套循环流程。 循环仍然不会替你做什么 循环改变了工作模式，但不会取代工程师。 而且随着循环变得更好，有三个问题实际上会变得更尖锐，而不是更轻松。 验证仍然在你身上。 一个无人值守运行的循环，也会在无人察觉时产生错误。拆分校验子智能体，是为了让 “任务完成” 这个结论具备参考价值，但即便如此，“完成” 也只是一种状态表述，不等于绝对可靠。我一直重复 code review in the age of AI 里的同一句话：你的工作，是交付你确认能运行的代码。 code review in the age of AI 疏于跟进会丧失业务认知。 循环越快交付你没写过的代码，现有系统和你真正理解的东西之间的差距就越大。这就是认知负债（comprehension debt）；如果不去阅读、理解流程生成的内容，这套高效体系只会加速认知断层的扩大。 依赖自动化容易陷入思维惰性。习惯了流程自动运转后，人很容易放弃独立判断，全盘接收输出结果，我称之为认知躺平。基于思考、审慎地设计流程，它会成为效率工具；单纯为了逃避思考而搭建流程，则会埋下隐患。同样一件事，导向却截然相反。 构建循环，但要始终坚守工程师的本职 我认为这也是未来研发工作的演变趋势。即便如此，如果我完全依赖自动化流程修复代码、放弃人工审核，产品质量必然下滑，最终陷入恶性循环。 当然，你可以放心搭建属于自己的循环流程，但也要记得，直接向智能体下发指令依然是有效工作方式，关键在于找到平衡。 同样一套循环流程，不同使用者会得到截然不同的结果：有人借助它深耕自己熟悉的业务、提升效率；有人却用它彻底逃避理解业务本身。流程本身没有区别，区别在于使用它的人。 这也解释了为何流程架构设计比提示词工程难度更高。切尔尼的观点并非工作变简单了，而是价值发力点发生了转移。 搭建自动化流程吧。但请以一名资深工程师的视角去设计，而非只做一个按下启动键的操作者。 原帖链接：https://x.com/addyosmani/status/2064127981161959567 原帖链接：https://x.com/addyosmani/status/2064127981161959567 循环工程，就是把“亲自给智能体写提示词的你”替换掉。你设计一个系统，让系统去做这件事。 这里的循环可以理解为一种递归目标：你定义目的，AI 持续迭代，直到任务完成。 它大致由五个构件组成，而 Claude Code 和 Codex 现在都已经具备这五个构件。 我认为，这也许会成为我们和编程智能体协作的未来。不过它仍然很早期，我保持怀疑，而且你绝对必须小心 token 成本（如果你 token 很充裕或紧张，使用模式会差异巨大）。你仍然需要某种方式来确保质量不会下滑；对粗制滥造式输出的担忧也是合理的。话虽如此，我们还是来看看它到底是什么。 @steipete 最近说：“你不应该再直接给编程智能体写提示词。你应该设计循环，让循环去提示你的智能体。” 类似地，Anthropic 负责 Claude Code 的 @bcherny 也说过：“我已经不再提示 Claude 了。我有循环在运行，它们会提示 Claude，并判断下一步要做什么。我的工作是写循环。” @steipete 说 @bcherny 说过 好，那这到底是什么意思？ 过去差不多两年里，你要从编程智能体那里得到结果，方式就是写一个好提示词，并提供足够上下文。你输入一件事，阅读返回结果，再输入下一件事。智能体是工具，而你一直握着它，一轮接一轮。这个阶段某种程度上已经结束了，或者至少有些人认为它快结束了。 现在，你构建一个小系统：它发现工作、分发工作、检查工作、记录完成情况，然后决定下一件事；你让这个系统去触发智能体，而不是你亲自触发。我之前分享过同领域的：agent harness engineering，也就是为单个智能体运行的环境做工程化；还有 factory model，也就是构建软件的系统。循环工程位于运行框架（harness）上面一层。它像运行框架，但会按定时器运行，会生成小助手，并且会自我喂养。 agent harness engineering factory model 真正让我意外的是，这已经不太是工具问题了。一年前，如果你想要一个循环，你得写一堆 bash，并永远维护那堆东西；那是你的，也只有你能用。现在，这些部件直接被产品内置了。Steinberger 列出的内容，几乎可以一一映射到 Codex app；同样也几乎可以映射到 Claude Code。一旦你发现底层架构逻辑相通，就不会再纠结具体选用哪种工具，而是开始设计一个循环，无论基于哪种工具环境都能正常运行。 五个构件，以及一些说明 一个循环需要五样东西，再加一个能记住状态的地方。先列出来，再逐一映射。 循环 1. 自动化任务（Automations）：定时触发自动化流程，自主完成信息探查与问题分级处理。 2. 工作树（Worktrees）：依托工作区机制，实现两个智能体并行作业且互不干扰。 3. 技能（Skills）：借助能力组件沉淀项目知识，避免智能体盲目推测。 4. 插件与连接器（Plugins and connectors）：把智能体接入你已经在用的工具。 5. 子智能体（Sub agents）：让一个智能体负责提出想法，另一个负责检查它。 然后是第六样东西：记忆。一个 Markdown 文件，或者一个 Linear 看板，任何活在单次对话之外、能保存“已经做了什么”和“下一步是什么”的东西都可以。听起来太过简单，没啥技术含量。但所有长期运行的智能体都依赖同一个技巧，我在 long running agents 里写过：模型在两次运行之间会忘掉一切，所以记忆必须在磁盘上，而不是留在上下文里。智能体会忘，代码仓库不会。 long running agents 两个产品现在都具备这五个构件。