到底什么是 Loop Engineering？不再写提示，而是设计循环
公众号名称：AI 方寸山
作者名称：九皋山人
发布时间：2026-06-10 08:24
原文： Loop Engineering.[1] 作者：@addyosmani
前言： Prompt Engineering、Context Engineering、Agentic Engineering，再到这篇的 Loop Engineering。AI 这几年的四代”工程”串起来看是同一条线：人一步步从干活的回路里往外退，管得越来越靠上，手离具体操作越来越远。
Looping Engineering，就是让你设计的一套系统替你干活，不用你再一句句给智能体写提示。这里的”循环”是一个会自己往下推的目标：你说清楚要什么，AI 就一轮轮迭代，直到做完。 它大概由五个零件组成，Claude Code 和 Codex 现在这五样都齐了。
我觉得以后我们跟编程智能体打交道，多半就是这个样子。不过现在还太早，我自己也存疑，你得盯紧 token 花销（token 管够还是得省着用，用法差得很远）。你还是得想办法别让质量往下掉，那种”代码越写越烂”的担心也不是没道理。话说回来，我们先看看它到底是怎么回事。
@steipete 最近说[1]：“别再手动给编程智能体写提示了，你该设计循环，让循环去给智能体发提示。“巧的是，Anthropic 家 Claude Code 的负责人 @bcherny 也说[2]：“我不再手动给 Claude 写提示了。我跑着几个循环，由它们去给 Claude 发提示、决定做什么。我的活儿是写循环。”
那这话到底什么意思？
这两年来，想让编程智能体给你干出活，办法一直是写一条好提示，把上下文喂够。你打一句话，看它回什么，再打下一句。智能体是个工具，你从头到尾攥在手里，一轮接一轮。这个阶段差不多到头了——至少有些人觉得快到头了。
现在你搭一套小系统，让它自己去找任务、派任务、查任务、记下哪些做完了，再决定下一步干什么——你让这套系统替你去使唤智能体。这个思路有两个”近亲”，我都写过：一个是智能体 harness 工程[3]，给单个智能体搭好运行环境；一个是工厂模式[4]，一套专门造软件的系统。循环工程比 harness 高一层。harness 再加个定时器，能自己派出干活的小智能体，还能自己给自己喂任务。
让我没想到的是，这事现在不再靠你自己搭工具了。一年前你想跑个循环，得写一堆 bash 脚本，然后没完没了地维护，那是你私藏的家当。现在这些零件直接做进产品里了。Steinberger 列的那张清单，几乎能一条条对到 Codex 上，对到 Claude Code 上也差不多。等你看出两边长得一个样，你就懒得再争哪个工具更好了——你只管设计循环，手头不管用的是哪个，它都跑得起来。
六个组件
一个循环工程 Looping Engineering [5]需要六样东西。
自动化：到点自己启动，自己去找活、分活。
工作树：让两个同时干活的智能体互不踩脚。
Skill：把项目里的门道记下来，省得智能体瞎猜。
插件与连接器：把智能体接到你本来就在用的工具上。
Sub Agent：一个出主意，一个挑毛病。
再加第六样，记忆。可以是一个 Markdown 文件，也可以是一块 Linear 看板，总之是独立于单次对话之外、记下哪些做完了、哪些还没做的东西。听着简单到不值一提。可每个长时间运行的智能体，靠的就是这一手，我在长运行智能体[6]里细讲过：模型每跑完一轮就把前面的事忘光，所以记忆得写到磁盘上，不能搁在上下文里。智能体会忘，代码仓库不会。
这六样，Claude Code 和 Codex 这两个工具现在都有了。
各处叫法不太一样，但能干的事是一回事。我一个个拆开说，因为说实话，一个循环是稳稳地跑，还是悄无声息地垮掉，差别全在细节里。
自动化：循环的心跳
有了自动化，循环才真叫循环，而不是你手动跑过一遍就完事的东西。
在 Codex 里，你到”自动化”标签页建一个任务，选好项目、写好它要执行的提示、设好多久跑一次，再选是在本地代码上跑，还是在后台的工作树上跑。跑出结果的，进收件箱等你处理；什么都没跑出来的，自己归档，这点很省心。
OpenAI 内部就拿它干杂活，比如每天分一遍 issue、把 CI 的失败汇个总、写写提交小结、揪出上周谁带进来的 bug。自动化任务能调用技能，这样那些反复要做的事就好维护：你只要打一个 $技能名，而不是把一大段指令塞进定时任务里，搁着烂掉、再没人更新。
Claude Code 靠调度和钩子（hook）做到同一件事。你可以用 /loop 每隔一段时间跑一次提示或命令，可以排 cron 任务，可以用钩子在智能体干活的某个节点触发 shell 命令，也可以把整个任务丢到 GitHub Actions 上，让它在你合上电脑之后接着跑。路子是一样的：定一个能自己跑的任务，设好节奏，有结果就送到你面前，省得你到处亲自去查。
还有一个“目标明确”的命令，更贴近本文要说的核心，那就是/goal。/loop 是按节奏反复跑。/goal 是一直跑，直到你写的某个条件真的成立；而且每跑完一轮，会有一个独立的小模型来判断任务做完没，这样的目的是让写代码的agent 和打分的不是同一个。你给它设个目标，比如”test/auth 下所有测试通过、lint 不报错”，然后人就可以走开。Codex 也有这功能，也叫 /goal，它会一轮轮接着干，直到一个能验证的收尾条件成立，还能暂停、接着跑、清空重来。同一个东西，两个工具都有，这差不多是全文反复出现的规律。
以上是负责找出活儿的部分。循环剩下的部分，负责把这些活儿真正做掉。
工作树：让并行不变成一团乱
只要你同时跑不止一个智能体，文件就会开始打架，活儿也就跟着失败。两个智能体同时写同一个文件，就跟两个工程师事先没打招呼、各改同一行代码一样让人头大。
Git 工作树就是来解决这个的。它是一个单独的工作目录，跑在自己的分支上，跟主仓库共用同一段历史，所以一个智能体改的东西，碰不到另一个智能体那份代码。
Codex 自带工作树，多个线程能同时用一个仓库，互不打扰。Claude Code 用 git worktree 做到同样的隔离：加 --worktree 就能在一份独立代码里开会话，还能给子智能体设 isolation: worktree，让每个帮手拿到一份全新的代码，干完自动清掉。
我在编排税[7]里写过这背后跟人有关的一面，工作树能挡掉机器层面的冲突，但卡脖子的还是你自己：你一次能盯几个智能体，看的是你审代码的精力，不是工具。
Skill：不用每次都把工作流重讲一遍
有了技能 Skill，你就不用像条金鱼一样，每开一个新会话都把项目背景、工作流等从头讲一遍。
Skill 现在的基本格式都一样：一个文件夹，里面放一个 SKILL.md，装着指令和元数据，还可以另带脚本、参考资料和别的文件。
在 Codex 和 CC 里，你用 $ 或 /skills 点名调用技能，它就跑；或者你的任务跟技能的描述对得上，它自己就跑，所以描述写得简短、朴素，反而比写得花哨更管用，我在Agent skill [8]里写过。
技能还能让你不用为同一个意图反复掏腰包。我在意图债务[9]里讲过，Agent 每次开会话都是冷启动，你没说清的地方，它会自信满满地替你猜。
技能就是把这些意图写在外面：团队的约定、构建的步骤、“这事我们不这么干，是因为上次出过事故”，写一次，智能体每次跑都能读到。没有技能，循环每一轮都要把你整个项目从头推一遍；有了技能，它多少能一点点攒起来。
有一点得分清：技能是你写东西的格式，插件是你把东西发出去的方式。想跨仓库共享技能，或者把几个技能打成一包，你就把它们封进插件。Codex 这样，Claude Code 也这样。
插件与连接器：让循环够得着你真正在用的工具
只能看到文件系统的循环，是个小循环。连接器建在 MCP 之上，让智能体能读你的 issue 系统、查数据库、调预发布环境的 API、往 Slack 里发消息。
Codex 和 Claude Code 都支持 MCP，所以你为一个工具写的连接器，通常在另一个工具里直接能用。插件再把连接器和技能打成一包，你的同事点一下就能装上你整套配置，不用照着记忆一件件重搭。
这就是”这儿有个改法”和”循环自己发 PR、挂上对应的 Linear 工单、等 CI 变绿了自动在群里吱一声”两者的差别。正是连接器，让循环能在你真实的环境里动手，而不是光告诉你它想干嘛、却干不了。
Sub Agent：让出活的和挑错的分开
到目前为止，循环里最管用的一招，是把出活的和挑错的分开。
写代码的模型给自己判作业，太容易手下留情。第二个 Agent，拿着另一套指令、有时干脆换个模型，能抓住第一个 Agent 自己说服自己绕过去的那些问题。
Codex 只有在你明确开口时才会派出子 Agent，让它们并行跑，再把结果并成一个答案。你在 .codex/agents/ 里用 TOML 文件定义自己的 Agent，每个有名字、描述、指令，还可以选模型和推理力度，这样你的安全审查员可以用一个推理够狠的强模型，而你的探路者用一个只读、跑得快的小模型就行。Claude Code 也一样，用 .claude/agents/ 里的子 Agent ，加上彼此传任务的智能体小队来做。两边常见的分工都是：一个去探路，一个去实现，一个对照规格说明去验。
这个思路我已经讲过两次，一次在代码智能体乐团[10]，一次在对抗性代码审查[11]。它在循环里格外重要，是因为循环是在你没盯着的时候跑的，所以有个你真信得过的验证者，才是你敢走开的唯一理由。
子 Agent 确实更费 token，因为每个都要自己调模型、自己动工具，所以把它们用在那些值得花钱听第二个意见的地方。说到底，Claude Code 的 /goal 在底下干的就是这件事，让一个全新的模型来判断循环做完没，而不是让干活那个自己说了算，把出活的和挑错的分开这条原则，一路用到了”何时收尾”上。
一个循环长什么样
把这些拼到一块，一个普通的会话就成了一小块控制台。下面是我自己一直在用的一种样子。
每天早上，一个自动化任务在仓库上跑起来。它的提示调用一个分流技能，这个技能去读昨天 CI 的失败、还开着的 issue、最近的提交，再把发现的东西写进一个 Markdown 文件或一块 Linear 看板。每条值得处理的发现，会话都开一个单独的工作树，派一个子智能体去起草改法，再派第二个子智能体，对照项目技能和现有测试，把这个改法审一遍。
连接器让循环能发 PR、能更新工单。循环搞不定的，全落到收件箱里，等我来收拾。那个状态文件是整套系统的脊梁，它记着哪些试过了、哪些过了、哪些还开着，这样明早再跑时，就能从今天停下的地方接着来。
回头看看你到底做了什么。你把设计一次做完了。中间任何一步，你都没再手动写过提示。这就是 Steinberger 那套说法真正落到地上的样子。而这个循环，在 Codex 和 Claude Code 里是一模一样的，因为支撑的组件就是同一套。
循环仍然不能替你做的事
循环改的是你怎么干活，不是把你从活里抹掉。 而且有三件事，会随着循环变强变得更扎手，而不是更省心。
验证还是你自己的事。 一个没人看着跑的循环，也是一个没人看着就出错的循环。你把验证的子智能体从出活的那个里拆出来，图的就是让循环说的”做完了”有点分量——可即便这样，“做完了”也只是一句声明，不是证明。AI 时代的代码审查[12]里那句话我一直在重复：你的活儿，是交出你确认能跑的代码。
你要是放着不管，你对代码的理解会慢慢烂掉。 循环越快地交出你没亲手写过的代码，现有代码和你真正搞懂的那部分之间，缺口就越大。这就是理解债务[13]，循环跑得越顺，这缺口涨得越快——除非你去读循环产出的东西。
是的，那个让你最舒服的姿势，八成就是最危险的。循环自己跑起来之后，你很容易就不再有自己的判断，它给什么你就照单全收。我把这叫认知投降[14]。带着判断去设计循环，它是解药；为了躲开思考去设计，它就是加速器——同一个动作，结果正相反。
打造循环，保持工程师本色
我觉得这是我们干活方式往后变成什么样的一个预告。话虽如此，要是我不亲自审代码，全指望自动化的循环去修，我做出来的东西质量会掉。我多半会陷进一个越转越糟的圈，把自己往更深的坑里挖。
话说回来，循环你尽管搭，但别忘了，直接给智能体写提示这招照样好使。关键是找到那个合适的度。
同一个循环，落到不同人手里，结出的果也不一样。两个人搭出一模一样的循环，结果可能正好相反。一个人用它，在自己摸得很透的活儿上跑得更快。另一个人用它，来躲开”搞懂这活儿”这件事本身。循环分不出这俩有什么区别。你分得出。
所以说，设计循环比写提示更难，而不是更容易。Cherny 想说的不是活儿变轻松了。他真正说的是，能撬动结果的那个点，挪了地方。
去搭你的循环。但要像一个铁了心要保住工程师本色的人那样去搭，而不是只当那个按下启动键的人。
参考链接
-
@steipete 原推：https://x.com/steipete/status/2063697162748260627
-
@bcherny 的说法（via @rohanpaul_ai）：https://x.com/rohanpaul\_ai/status/2063289804708835412
-
智能体 harness 工程：https://addyosmani.com/blog/agent-harness-engineering/
-
一个循环需要的五样东西（@reach_vb）：https://x.com/reach\_vb/status/2063713960495558940
-
对抗性代码审查：https://addyosmani.com/blog/adversarial-code-review/
-
AI 时代的代码审查：https://addyosmani.com/blog/code-review-ai/
#Claude #Codex #CC #Agent #AI #Subagent #LoopEngineering
内容效果不满意？点此反馈