循环工程：别再亲手给智能体写提示词了，去设计那个替你写提示词的系统

所谓循环工程（Loop Engineering），就是把"那个给智能体写提示词的人"——也就是你自己——给替换掉，转而由你去设计一套系统，让它替你干这件事。 这里说的"循环"（loop），可以理解成一个递归式的目标：你定义好一个目的，然后让 AI 不断迭代，直到任务完成。笔者认为，这很可能就是未来人和编程智能体协作的方式。不过话说回来，现在还很早期，笔者自己也持保留态度，而且你必须格外当心 token 成本——你是 token 富裕户还是贫困户，实际花销可能天差地别。所以下面笔者想把这事到底是什么、又意味着什么，掰开揉碎讲清楚。

原文链接：https://addyosmani.com/blog/loop-engineering/

---

Peter Steinberger 前不久说："你不该再去给编程智能体写提示词了，你应该去设计那些替你给智能体写提示词的循环。"无独有偶，Anthropic 旗下 Claude Code 的负责人 Boris Cherny 也说过类似的话：“我现在已经不给 Claude 写提示词了。我有一堆循环在跑，它们替我给 Claude 写提示词、自己琢磨接下来该干嘛。我的工作就是写循环。”

行，这些话到底什么意思？

过去差不多两年里，从编程智能体那儿榨出点东西的方式一直是：你写一个像样的提示词，把足够的上下文喂给它。你敲一段字，看它返回什么，再敲下一段。智能体是个工具，而你得自始至终一直握着它，一来一回。这种模式现在基本算翻篇了——至少有些人觉得它要翻篇了。

如今你要做的，是搭一个小系统：它自己去找活、把活分出去、检查结果、记下哪些做完了，然后决定下一步干啥，最后由这套系统去戳那些智能体，而不是你亲自去戳。笔者之前写过它的一个近亲——智能体框架工程（agent harness engineering），讲的是给单个智能体打造它运行所在的那个环境；也写过工厂模式（factory model），也就是那套用来造软件的系统。循环工程比框架（harness）还要再高一层。说到底它仍然是个框架，只不过这个框架是定时跑的，会自己派生出一堆小帮手，还能自己喂自己。

让笔者意外的是，这事现在已经不太算"工具"层面的事了。放在一年前，你要想搞个循环，得自己写一大坨 bash 脚本，然后永远地维护这坨东西，它是你的、也只是你一个人的。而现在，这些零件直接就内置在产品里了。Steinberger 列的那张清单，几乎能一一对应到 Codex 应用上，然后又几乎原封不动地对应到 Claude Code 上。一旦你发现两边的形态其实是一样的，你就不会再纠结到底该用哪个工具——你只管设计一个在哪个工具里都能跑的循环就行。

五个模块，外加一点说明

一个循环需要五样东西，再加一个用来"记事"的地方。笔者先把它们列出来，再逐个对应着讲。

1. 自动化任务（Automations）：按计划自动触发，自己完成发现问题和分类筛选。
2. 工作树（Worktrees）：让两个并行干活的智能体不会互相踩脚。
3. 技能（Skills）：把那些智能体本来只能靠瞎猜的项目知识写下来。
4. 插件和连接器（Plugins / Connectors）：把智能体接到你本来就在用的那些工具上。
5. 子智能体（Sub-agents）：让一个出主意，另一个来检查。

然后是第六样东西——记忆（memory）。一个 markdown 文件、一块 Linear 看板，什么都行，只要它活在单次对话之外，能记住哪些做完了、接下来该做啥。听上去蠢到不值一提，但这恰恰是每一个长时运行的智能体都依赖的同一个小窍门。笔者在《长时运行的智能体》里专门讲过：模型在两次运行之间会把一切都忘光，所以记忆必须落在磁盘上，而不能待在上下文里。智能体会忘，但代码仓库不会。

这五样东西，两个产品如今都凑齐了。

零件	在循环里干的活	Codex 应用	Claude Code
自动化任务	按计划做"发现 + 分类"	Automations 标签页：选项目、提示词、节奏、环境；结果落到 Triage（待处理）收件箱；用 /goal 实现"跑到完成为止"	排程任务和 cron、/loop、/goal、钩子（hooks）、GitHub Actions
工作树	隔离并行的功能开发	每个线程内置一个工作树	git worktree、--worktree 标志、给子智能体设 isolation: worktree
技能	把项目知识固化下来	Agent Skills（SKILL.md），用 $name 调用或隐式触发	Agent Skills（SKILL.md）
插件 / 连接器	接上你现有的工具	连接器（MCP），外加用于分发的插件	MCP 服务器，外加插件
子智能体	出主意 + 做验证	子智能体，以 TOML 形式定义在 .codex/agents/ 里	任务子智能体放在 .claude/agents/ 里，还有"智能体团队"
状态	追踪做完了什么	Markdown，或通过连接器接 Linear	Markdown（AGENTS.md、进度文件），或通过 MCP 接 Linear

名字这儿那儿有点不一样，但能力是同一回事。下面笔者一个一个讲，因为说实话，一个循环到底是稳稳立住、还是悄悄到处漏水，全藏在这些细节里。

自动化任务，这是循环的心跳

自动化任务才是让一个循环成为"真·循环"、而不是你只跑过一次就完事的关键。在 Codex 应用里，你在 Automations 标签页里建一个，挑好项目、要跑的提示词、多久跑一次，以及它是跑在你本地的代码副本上，还是跑在后台的一个工作树上。那些有发现的运行会进到一个 Triage（待处理）收件箱，而那些啥也没发现的运行就自己归档掉了，挺省心。OpenAI 内部就拿它干各种枯燥活儿，比如每天的 issue 分类、汇总 CI 失败、写提交简报、揪出上周谁埋下的 bug。而且一个自动化任务可以去调用一个技能，这样你那个反复要跑的东西就能保持可维护——你只要触发 $skill-name 就行，而不是把一大墙指令粘进一个排程里，然后那玩意儿再也没人会去更新。

Claude Code 走的是另一条路，但到的是同一个地方，靠的是排程和钩子（hooks）。你可以用 /loop 让一个提示词或命令按固定间隔反复跑，可以排一个 cron 定时任务，可以用钩子在智能体生命周期的某些节点上触发 shell 命令，或者干脆把整套东西推到 GitHub Actions 上，这样哪怕你合上笔记本它也照跑不误。思路完全一样：你定义一个自主任务，给它定个节奏，然后结果自己送到你面前，省得你到处去查。

还有第二个值得了解的"会话内"能力，而且它跟这整篇文章想说的事更接近。/loop 是按节奏反复跑；/goal 则是一直跑到你写下的某个条件真正满足为止，而且每跑完一轮，会有一个单独的小模型来判断你是不是真完成了——也就是说，写代码的那个智能体，不是给它自己打分的那个。你给它一个类似"test/auth 下所有测试通过、且 lint 干净"的目标，然后就可以走人了。Codex 也有同样的东西，同样叫 /goal，它会跨多轮一直干，直到一个可验证的停止条件成立为止，还支持暂停、恢复和清空。同一个能力，两个工具都有——这差不多就是整篇文章的固定套路了。

所以这部分是负责把活儿"浮"出来的，循环剩下的部分，则是负责对这些活儿动手。

工作树，别让"并行"变成"一锅粥"

你一旦同时跑超过一个智能体，文件就开始打架，这就成了那个会出问题的点。两个智能体改同一个文件，跟两个工程师没打招呼就往同一行代码上提交，是一模一样的头疼事。git worktree（工作树）能解决它：它是一个独立的工作目录，待在自己的分支上，却共享同一个仓库历史，所以一个智能体的改动，物理上根本碰不到另一个的代码副本。

Codex 把工作树支持直接做进了产品里，于是好几个线程可以同时怼向同一个仓库而互不干扰。Claude Code 给的是同样的隔离：有 git worktree、有一个 --worktree 标志能让一个会话开在自己的副本里、还有一个 isolation: worktree 设置，你把它挂到一个子智能体上，每个小帮手就能拿到一个干净的副本，用完还会自己清理。笔者在《编排税》里写过这事"人"的那一面：工作树消除的是机械层面的碰撞，但你才是那个天花板——你的审查带宽，决定了你实际能跑几个，而不是工具说了算。

技能，让你不用每次都重新解释一遍项目

技能（Skill）就是让你别再像条金鱼一样，每开一次新会话都把同一套项目背景重新讲一遍。两个工具用的是同一种格式：一个文件夹，里面放一个 SKILL.md，装着指令和元数据，然后可以选配脚本、参考资料、各种素材。Codex 在你用 $ 或 /skills 调它的时候会跑这个技能，或者当你的任务匹配上某个技能的描述时它自己就跑起来了——这也正是为什么一段又紧凑又"无聊"的描述，反而比一段花哨的更好用。Claude Code 干法一样，笔者在《智能体技能》里把这套模式写过了。

技能也是"意图"不再让你反复掏钱的地方。笔者在《意图债》里论证过：智能体每开一个新会话都是从零的冷启动，你意图里留的任何窟窿，它都会拿一个自信满满的猜测去填。而技能就是把那份意图写在了外面——那些约定、那些构建步骤、那句"我们不这么干，因为之前出过那次事故"，一次性写在那个智能体每跑一轮都会读到的地方。没有技能，循环每一轮都要把你整个项目从零重新推导一遍；有了技能，它就开始有点"复利"的味道了。

有一点要分清楚：技能是"创作"的格式，而插件是"分发"它的方式。当你想把一个技能跨多个仓库共享、或者把几个打包到一起时，你就把它们打包成一个插件。Codex 是这样，Claude Code 也是这样。

插件和连接器，让循环能碰到你真实的工具

一个只能看到文件系统的循环，是个很小的循环。连接器（Connectors，底层建在 MCP 之上）让智能体能读你的 issue 跟踪系统、查数据库、戳一下预发布环境的 api、往 Slack 里丢条消息。Codex 和 Claude Code 都讲 MCP 这套"普通话"，所以你给其中一个写的连接器，通常在另一个里直接就能用。而插件把连接器和技能捆在一起，于是你的队友一次就能装好你的整套配置，而不用凭记忆把它从头搭一遍。

这就是"一个只会说’这是修复方案’的智能体"和"一个会自己开 PR、关联 Linear 工单、等 CI 一变绿就往频道里发个通知的循环"之间的区别。连接器，正是让循环能在你真实环境里动手的原因，而不是只能告诉你它要是能动手会做点啥。

子智能体，让"干活的"离"检查的"远一点

一个循环里最有用的结构性安排，没有之一，就是把"写代码的那个"和"检查代码的那个"分开。写代码的模型给自己改作业的时候，实在是太宽容了。换一个带着不同指令、有时甚至用不同模型的第二个智能体，能逮住第一个把自己说服了的那些问题。

Codex 只在你开口要的时候才派生子智能体，让它们同时跑，然后再把结果折回成一个答案。你把自己的智能体定义成 .codex/agents/ 目录里的 TOML 文件，每个都有名字、描述、指令，以及可选的模型和推理强度（reasoning effort），于是你的安全审查员可以是一个高强度运行的强模型，而你的探路者则是某个只读的、跑得飞快的小家伙。Claude Code 干法一样，子智能体放在 .claude/agents/ 里，还有能在彼此之间传递工作的"智能体团队"。两个工具里常见的分工都是：一个探索，一个实现，一个对着规格说明做验证。

这个观点笔者已经讲过两遍了，一次叫《代码智能体交响乐团》，一次叫《对抗式代码审查》。它在循环里之所以格外重要，是因为循环是在你没盯着的时候跑的，所以一个你是真信得过的验证者，是你能放心走开的唯一理由。子智能体确实更费 token，因为每一个都要做自己那份模型和工具的活儿，所以把它们花在"第二意见值这个钱"的地方。这其实也基本就是 Claude Code 的 /goal 在底层干的事：由一个全新的模型来判断循环是不是完成了，而不是那个干了活的模型——这就是把"干活的和检查的分开"这套思路，直接套到了停止条件本身上。

一个循环长什么样

把这些拼到一起，一个单独的线程就变成了一个小小的控制台。下面是笔者反复在用的一种形态。

一个自动化任务每天早上在仓库上跑。它的提示词去调一个分类（triage）技能，这个技能读昨天的 CI 失败、未关闭的 issue、最近的提交，然后把发现的东西写进一个 markdown 文件或一块 Linear 看板。对于每一条值得做的发现，这个线程会开一个隔离的工作树，派一个子智能体去起草修复方案，再派第二个子智能体对着项目技能和现有测试去审查这份草稿。

连接器让循环能开 PR、能更新工单。循环搞不定的任何东西，都落到那个待处理收件箱里，等笔者来处理。而那个状态文件，是整件事的脊梁骨，它记着试过什么、什么过了、什么还开着，于是明天早上那轮运行，会从今天停下的地方接着干。

然后回头看看你刚才实际做了啥。你只设计了它一次。上面那些步骤，你一个都没去亲手写提示词。这就是 Steinberger 那整个观点变成了现实，而且不管在 Codex 里还是在 Claude Code 里，跑的都是同一个循环，因为零件就是那同一批零件。

循环依然替你搞不定的那些事

循环改变的是工作的方式，它并没有把你从这件事里删掉。而且有三个问题，是随着循环变得越来越好，反而变得更尖锐、而不是更轻松的。

验证这件事，仍然在你头上。一个无人值守跑着的循环，同时也是一个无人值守犯着错的循环。你之所以要把验证者子智能体从干活的那个里分出来，就是为了让循环说的那句"它做完了"能有点分量——可即便如此，"做完了"也只是一句声明，不是一份证明。笔者一直在重复《AI 时代的代码审查》里的同一句话：你的工作，是交付你亲自确认过能跑的代码。

你对代码的理解，只要你放任，它就会烂掉。循环越快地交付出你没亲手写的代码，"真实存在的东西"和"你实际搞懂的东西"之间的鸿沟就越大。这就是理解债（comprehension debt），而一个顺滑的循环只会让它涨得更快——除非你去读循环造出来的东西。

还有，那个最舒服的姿势，恰恰是最危险的那个。当循环自己跑起来的时候，你会非常想干脆别再有什么主见了，它给回来啥就收下啥。笔者把这个叫做认知投降（cognitive surrender）。设计循环这件事，当你带着判断力去做时，它是解药；当你做它是为了逃避思考时，它就是助燃剂——同一个动作，相反的结果。

把循环搭起来，但你得继续当那个工程师

笔者认为，这是未来这一行的工作方式将要如何演变的一个预演。话虽如此，如果笔者自己不去审查代码，或者完全靠自动化循环来修问题，那笔者产品的质量就会下滑。笔者多半会陷进一个向下的螺旋里，不停地把自己往一个越来越深的坑里挖。

所以呢，尽管去把你的循环搭起来，但别忘了，直接给你的智能体写提示词同样有效。关键是找到那个对的平衡点。

循环也会因人而异，给出截然不同的结果。两个人搭出一模一样的循环，可能得到完全相反的结果。一个人用它在自己理解得很深的工作上跑得更快；另一个人用它来彻底逃避去理解这份工作。循环本身分不出这两者的区别。但你分得出。

这正是为什么设计循环比提示词工程更难，而不是更简单。Cherny 的意思，不是工作变容易了，而是那个"杠杆的支点"挪了位置。

把循环搭起来。但要像一个打算继续当工程师的人那样去搭它，而不是像一个只负责按下"开始"键的人。

---