循环工程 (Loop Engineering)
从提示智能体到设计提示它们的系统。
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
循环工程就是用设计好的系统来取代你自己作为提示智能体的人。你设计的系统来完成这项工作。 这里的循环可以理解为一个递归目标——你定义一个目的，AI 迭代直到完成。 它大致由五个构建块组成，Claude Code 和 Codex 现在都已经具备了全部五个。
我认为这可能是我们与编程智能体协作方式的未来。然而，现在还为时尚早，我持怀疑态度，而且你绝对必须注意token 成本（如果你 token 充裕或匮乏，使用模式会差异巨大），所以我想拆解一下它到底是什么以及它意味着什么。
Peter Steinberger 最近说："你不应该再手动提示编程智能体了。你应该设计循环来提示你的智能体。"类似地，Anthropic 的 Claude Code 负责人 Boris Cherny 说："我不再手动提示 Claude 了。我运行着循环来提示 Claude 并弄清楚该做什么。我的工作是写循环。"
那么，这些到底意味着什么？
大约两年来，从编程智能体那里获取成果的方式是写一个好的提示并提供足够的上下文。你输入一条指令，阅读返回的结果，再输入下一条。智能体是一个工具，而你全程都在掌控它，一回合又一回合。那个时代基本结束了，至少有人这么认为。
现在你构建一个小系统来发现工作、分配任务、检查结果、记录完成情况，然后决定下一步做什么，你让这个系统来驱使智能体，而不是你自己。我之前写过与之相关的概念——智能体线束工程，即构建单个智能体运行的环境，以及工厂模型——构建软件的系统。循环工程位于线束的上一层。线束但它是按定时器运行的，会生成小助手，并自我供给。
让我惊讶的是，这已经不再是一个工具层面的问题了。一年前如果你想要一个循环，你要写一堆 bash 脚本，然后永远维护那一堆脚本，它是你的，只属于你。现在这些组件直接内置在产品中。Steinberger 的清单几乎完美地映射到 Codex 应用，然后几乎一模一样地映射到 Claude Code。一旦你注意到结构是相同的，你就不再争论用哪个工具了，你只需设计一个无论你坐在哪个工具里都能工作的循环。
1、五个组件，然后是备注
一个循环需要五样东西，外加一个记忆的地方。让我先列出来再逐一映射。
- 自动化——按计划触发，自行完成发现和分类。
- 工作树（Worktrees）——让两个并行工作的智能体不会互相踩脚。
- 技能（Skills）——把智能体本靠猜测的项目知识写下来。
- 插件和连接器——把智能体接入你已经在使用的工具。
- 子智能体（Sub-agents）——让一个提出想法，另一个检查验证。
然后是第六样东西——记忆。一个 markdown 文件，或一个 Linear 看板，任何存在于单次对话之外、记录已完成和待办事项的东西。听起来太简单而不重要。但这是每个长时间运行的智能体都依赖的同一招，我在长时间运行的智能体中详细讨论过，模型在每次运行之间会忘记一切，所以记忆必须在磁盘上，而不是在上下文中。智能体会忘记，代码仓库不会。
两款产品现在都已具备全部五个组件。
名称在个别地方有所不同，但能力是一样的。让我逐一讲解，因为说实话，细节才是循环能否稳固运行还是悄悄处处泄露的关键。
2、自动化，这是心跳
自动化是把循环变成真正的循环——而不只是你跑过一次的东西。在 Codex 应用中，你在 Automations 标签页创建一个，选择项目、要运行的提示、运行频率，以及是在本地检出还是在后台工作树上运行。发现了结果的运行会进入分类收件箱，没发现任何东西的运行会自动归档，这很好。OpenAI 内部用它们处理无聊的事情，比如每日 issue 分类、汇总 CI 失败、撰写提交简报、追查上周有人引入的 bug。而且自动化可以调用技能，所以你可以保持重复性任务的可维护性——你触发 $skill-name，而不是把一大段说明文字粘贴到一个没人会更新的计划任务中。
Claude Code 通过调度和钩子实现了同样的效果。你可以用 /loop 按间隔运行提示或命令，可以调度 cron 任务，可以用钩子在智能体生命周期的特定节点执行 shell 命令，或者把整个任务推到 GitHub Actions 让它在关上笔记本后继续运行。思路完全一样——你定义一个自主任务，给它一个节奏，结果自动呈现给你，而不是你到处去检查。
还有一个值得了解的会话内原语，它更接近本文的主题。/loop 按节奏重复运行。/goal 持续工作直到你编写的条件真正为真，每回合之后由一个独立的小模型检查你是否完成了，所以编写代码的智能体不是自己给自己打分的那一个。你给它类似"test/auth 下所有测试通过且 lint 干净"的条件，然后离开。Codex 也有同样的东西，也叫 /goal，跨回合持续工作直到一个可验证的停止条件成立，支持暂停、恢复和清除。同样的原语，两款工具，这基本上就是本文的模式。
所以这是呈现工作的部分。循环的其余部分是对其采取行动。
3、工作树，让并行不会变成混乱
你运行超过一个智能体的那一刻，文件就开始冲突了，那就是失败。两个智能体写同一个文件，和两个工程师提交到同一行代码但事先没沟通过一样令人头疼。git worktree 解决了这个问题——它是一个独立的、在自己分支上的工作目录，共享同一个代码仓库历史，所以一个智能体的编辑在物理上不可能触及另一个智能体的检出。
Codex 内置了工作树支持，多个线程同时命中同一个仓库而不会互相碰撞。Claude Code 通过 git worktree、用于在其自己检出中打开会话的 --worktree 标志，以及设置在子智能体上的 isolation: worktree 设置提供同样的隔离，每个助手获得一个全新的检出，用完自动清理。我在编排税中写了这些事情对人类的影响——工作树消除了机械碰撞，但你仍然是上限，你的审查带宽决定了你实际能运行多少个，而不是工具。
4、技能，让你不用每次都解释你的项目
技能就是让你不再像金鱼一样每次会话都重新解释相同的项目上下文。两款工具使用相同的格式——一个包含 SKILL.md 的文件夹，其中存放指令和元数据，以及可选的脚本、参考文件和资源。Codex 在你用 $ 或 /skills 调用时运行技能，或者当你的任务匹配技能描述时自动运行，这就是为什么一个精确无趣的描述胜过一个巧妙的描述。Claude Code 以相同的方式工作，我在智能体技能中详细说明了这个模式。
技能也是意图不再反复消耗你的地方。我在意图债务中论证过，智能体每次会话都从零开始，它会用自信的猜测来填补你意图中的任何空白。技能就是把意图写在外面——约定、构建步骤、"我们不这么做是因为那次事故"，写一次，智能体每次运行都会读取。没有技能，循环每个周期都从零重新推导你的整个项目；有技能，它就像复利一样积累。
有一点要搞清楚——技能是创作格式，插件是分发方式。当你想跨仓库共享技能或将几个技能打包在一起时，你将它们打包为插件。Codex 如此，Claude Code 也如此。
5、插件和连接器，循环触碰你的真实工具
一个只能看到文件系统的循环是微小的循环。基于 MCP 构建的连接器让智能体能读取你的 issue 追踪器、查询数据库、访问 staging API、在 Slack 中发送消息。Codex 和 Claude Code 都支持 MCP，所以你为一个工具编写的连接器通常在另一个中也能工作。插件将连接器和技能打包在一起，让你的队友一次性安装你的配置，而不是凭记忆重建整个东西。
这就是一个说"这是修复"的智能体和一个自动打开 PR、关联 Linear ticket 并在 CI 绿了之后 ping 频道的循环之间的区别。连接器是循环能在你的真实环境中行动、而不是仅仅告诉你如果它能做什么它会做什么的原因。
6、子智能体，让构建者和检查者分开
循环中最有用的结构，毫无疑问，是将编写者和检查者分开。编写代码的模型给自己打分时会过于宽容。一个带有不同指令、有时使用不同模型的第二个智能体能捕获第一个智能体说服自己的那些问题。
Codex 只在你请求时生成子智能体，同时运行它们，然后将结果合并为一个答案。你可以在 .codex/agents/ 中用 TOML 文件定义自己的智能体，每个都有名称、描述、指令和可选的模型及推理力度，所以你的安全审查者可以是一个高力度下的强模型，而你的探索者是一个快速的只读工具。Claude Code 通过 .claude/agents/ 中的子智能体和 agent teams 做同样的事，它们之间传递工作。两者的常见分工是：一个探索，一个实现，一个对照规格验证。
我已经论证过两次，一次是代码智能体交响乐，一次是对抗性代码审查。它在循环中特别重要的原因是循环在你不在时运行，所以一个你真正信任的验证者是你能够离开的唯一理由。子智能体确实消耗更多 token，因为每个都要做自己的模型和工具工作，所以把它们花在值得支付第二次意见的地方。这基本上也是 Claude Code 的 /goal 在底层做的事情——一个全新的模型决定循环是否完成，而不是做工作的那个模型，构建者和检查者的分离应用于停止条件本身。
7、一个循环是什么样的
把它们组合在一起，单个线程变成了一个小控制面板。这是我一直在用的一种模式。
一个自动化每天早上在仓库上运行。它的提示调用一个分类技能，读取昨天的 CI 失败、未解决的 issue、最近的提交，并将发现写入一个 markdown 文件或 Linear 看板。对于每个值得处理的发现，线程打开一个隔离的工作树，派一个子智能体起草修复方案，然后派第二个子智能体对照项目技能和现有测试审查该草案。
连接器让循环能打开 PR 并更新 ticket。循环无法处理的任何事情会落到我的分类收件箱中。状态文件是整个事情的核心——它记录了尝试了什么、通过了什么、什么仍然开放，所以明天的运行会从今天停下的地方继续。
看看你实际上在那里做了什么。你设计了一次。你没有提示任何一个步骤。这就是 Steinberger 的全部观点变成了现实，而且无论在 Codex 还是在 Claude Code 中它都是相同的循环，因为组件就是相同的组件。
8、循环仍然不能为你做的事
循环改变了工作方式，但并没有把你从中删除。实际上有三个问题随着循环变得更好反而变得更尖锐，而不是更容易。
验证仍然是你的事。一个无人值守运行的循环也是一个无人犯错的循环。你将验证子智能体与构建者分开的全部原因是让循环的"完成了"意味着一些东西，即使如此，"完成"是一个声明，而不是证明。我一直重复AI 时代的代码审查中的同一句话——你的工作是交付你确认能工作的代码。
如果你放任不管，你的理解力仍然会退化。循环越快交付你没写的代码，现有代码和你实际理解之间的差距就越大。这就是理解债务，顺畅的循环只会让它增长得更快，除非你阅读循环产出的东西。
而舒适的姿态是危险的姿态。当循环自动运行时，放弃思考、只接受它返回的东西是非常诱人的。我称之为认知投降。带着判断力设计循环是解药，为了逃避思考而设计循环则是催化剂——同样的行为，相反的结果。
9、构建循环。保持工程师的身份。
我认为这是我们工作方式将如何演进的一个预览。不过，如果我不亲自审查代码，或者完全依赖自动化循环来修复，我的产品质量会下降。我很可能陷入一个向下的螺旋，不断把自己挖进更深的坑。
话虽如此，去建立你的循环吧，但别忘了直接提示你的智能体也是有效的。关键在于找到正确的平衡。
循环也会因人而异产生不同的结果。两个人可以构建完全相同的循环，却得到完全相反的结果。一个用它来在自己深刻理解的工作上加速。另一个用它来完全避免理解工作。循环不知道区别。你知道。
这就是为什么循环设计比提示工程更难，而不是更容易。Cherny 的观点不是说工作变容易了。而是说杠杆点转移了。
构建循环。但要像打算继续做工程师的人那样构建它，而不仅仅是做那个按下启动按钮的人。
原文链接: Loop Engineering
汇智网翻译整理，转载请标明出处
