Loop Engineering：你不在的时候，谁替你盯着 Agent？
Loop 工程正在取代你亲自当那个给 Agent 下指令的人。你转而去设计一套系统，让系统来替你驱动 Agent。
所谓"loop"，就是一个递归目标——你定一个目的，AI 不断迭代，直到完成。它大概由五个模块组成，Claude Code 和 Codex 现在都把这五个凑齐了。
我觉得这可能是我们以后跟编码 Agent 协作的方向。不过话说回来，现在还早，我持怀疑态度，而且你一定得注意 token 成本（手头 token 多还是少，用起来差别很大）。你还得想办法保证质量不掉链子，对"垃圾产出"的担忧也是实打实的。但不管怎样，咱先搞明白这到底是怎么回事。
OpenClaw小龙虾创始人彼得·斯坦伯格，最近说了句狠话："你不应该再手动提示编码 Agent 了。你应该设计 loop 来替你提示 Agent。"
差不多同样的话，Anthropic Claude Code 负责人鲍里斯·切尔尼也说过："我不再手动提示 Claude 了。我有 loop 在跑，loop 来提示 Claude、来决定该干什么。我的工作是写 loop。"
所以，这些话到底啥意思？
从"人拿工具"到"系统替你拿"
过去大概两年，你让编码 Agent 干活的方式就是：写个好提示，给够上下文，你打一段话，它回一段，你再打一段……Agent 是工具，你全程握着它，一轮接一轮。
这个阶段基本要翻篇了——至少有些人这么认为。
现在你做的是：搭一个小系统，让它自动发现工作、分配工作、检查工作、记录进度，然后决定下一步。你让这个系统去戳 Agent，而不是你自己戳。
我之前写过它的"表亲"——Agent Harness 工程，就是搭建单个 Agent 运行的环境，还有工厂模型，即构建软件的系统。Loop 工程比 harness 再高一层——harness 加上定时器、加上自动生成小帮手、加上自我投喂。
最让我惊讶的是，这已经不纯粹是"工具"层面的事了。一年前你想跑个 loop，得写一大堆 bash 脚本，然后永远维护那坨代码，而且只有你自己能跑。现在这些零件直接内置在产品里了。Steinberger 列出的功能几乎完美对应 Codex，又几乎完美对应 Claude Code。一旦你发现它俩的形状一样，你就不会再纠结选哪个工具了——你只需要设计一个 loop，不管你坐在哪个工具里都能跑。
五个核心组件 + 一个记忆
一个 loop 需要五样东西，再加一个"记住事儿"的地方。先列出来：
-
1. 自动化——定时触发，自己发现和分流工作
-
2. 工作树（Worktree）——多个 Agent 并行干活不互相打架
-
3. 技能（Skills）——把项目知识写下来，别让 Agent 每次都靠猜
-
4. 插件和连接器——把 Agent 接入你已经在用的各种工具
-
5. 子 Agent——一个负责干活，另一个负责检查
然后第六样——记忆。一个 markdown 文件也行，一个 Linear 看板也行，任何存在于单次对话之外、能记录"做了什么、下一步是什么"的东西。听着简单得不值一提，但这恰恰是每个长期运行 Agent 都依赖的老技巧——我在《长期运行 Agent》里写过，模型在两次运行之间会忘掉一切，所以记忆必须在硬盘上，不能只在上下文里。Agent 会忘，仓库不会。
两个产品现在都把这五个组件凑齐了，叫法上有点差异，但能力是一回事。下面逐个展开，因为说实话，细节决定了一个 loop 是严丝合缝还是到处漏风。
一、自动化——Loop 的心跳
自动化是把 loop 变成"真 loop"而不是"你跑了一次就完了"的东西。
Codex 里，你在"自动化"标签页创建一个，选项目、选提示词、选频率，再选是在本地代码上跑还是在后台 worktree 上跑。发现问题了？进分流收件箱。啥也没发现？自动归档，很省心。OpenAI 内部就用这个干那些枯燥活——每天分流 issue、汇总 CI 失败、写 commit 摘要、追查上周有人引入的 bug。而且自动化可以调用技能，所以你把重复性的活做成可维护的——触发 $skill-name 就行，不用往定时任务里粘一大段没人会再更新的指令。
Claude Code 走不同的路到达同一个终点：你可以用 /loop 按间隔跑提示词或命令，可以设置 cron 任务，可以在 Agent 生命周期的特定节点用 hook 触发 shell 命令，或者干脆推到 GitHub Actions 上——关了笔记本它照样跑。思路一模一样：你定义一个自主任务，给它一个节奏，发现的结果自动送到你面前，不用你到处去看。
还有一个会话内的原语值得了解，它更接近本文的核心。/loop 是按节奏重复执行。/goal 则是一直干到某个条件真正满足为止——而且每轮之后，一个独立的小模型来检查"完没完成"，所以写代码的 Agent 不是给自己打分的人。你给它类似"test/auth 里所有测试通过、lint 没问题"的条件，然后就可以走开了。Codex 也有同样的东西，也叫 /goal，跨轮次持续工作直到可验证的停止条件成立，支持暂停、恢复、清除。同样的原语，两个工具都有——这也是整篇文章的基调。
这部分解决的是发现工作。loop 的其余部分负责干活。
二、工作树——并行不吵架
你同时跑两个以上 Agent，文件就开始冲突了。两个 Agent 写同一个文件，跟两个工程师往同一行代码提交、互相没沟通过，是同一模一样的头疼。
Git worktree 解决了这个问题——它是一个独立的工作目录，有自己的分支，但共享同一个仓库历史。一个 Agent 的改动，物理上不可能碰到另一个 Agent 的代码。
Codex 内置了 worktree 支持，多个线程同时操作同一个仓库互不干扰。
Claude Code 也给你同样的隔离——--worktree 标志在独立 checkout 中打开会话，isolation: worktree 设置加在子 Agent 上，让每个帮手拿到一个用完自动清理的独立 checkout。
我在《编排税》里写过人的那一边——worktree 消除了机械冲突，但你还是天花板：你的 review 带宽决定了你实际能同时跑几个，不是工具说了算。
三、技能——别再每次都重新解释你的项目了
技能就是让你不用像金鱼一样，每次会话都重新解释同一个项目。
两个工具用的是同样的格式——一个文件夹，里面有 SKILL.md 放指令和元数据，外加可选的脚本、引用、资源。
Codex 里你用 $ 或 /skills 调用技能，或者当你的任务匹配技能描述时它自动运行——所以一个精确无聊的描述比一个花哨的描述好使。
Claude Code 也是同样的做法。
技能还是"意图不再反复烧钱"的地方。我在《意图债》里说过：Agent 每次会话从零开始，你意图里任何空白它都会自信地瞎猜来填。技能就是把意图写在外面——约定、构建步骤、"我们不这么做是因为那次出过事"——写一次，Agent 每次运行都能读到。没有技能，loop 每轮都从零推导你整个项目；有了技能，它开始有复利效应。
搞清楚一个区别：技能是创作格式，插件是分发方式。你想跨仓库共享技能或打包几个一起发，就包装成插件。Codex 如此，Claude Code 亦然。
四、插件和连接器——让 Loop 碰到你的真实工具
只能看文件系统的 loop 是个很小的 loop。
连接器（基于 MCP 协议）让 Agent 能读你的 issue 追踪器、查数据库、访问 staging API、往 Slack 发消息。Codex 和 Claude Code 都支持 MCP，所以给一个写的连接器通常在另一个里直接能用。插件把连接器和技能打包在一起，你的队友一键安装整套配置，不用凭记忆重新搭。
这就是区别： 一个只会说"这是修复方案"的 Agent，和一个自己打开 PR、关联 Linear 工单、CI 绿了之后自动 ping 频道的 loop 之间，差的就是连接器。连接器是 loop 能在你真实环境里动手干活、而不只是告诉你"如果可以的话我会这样做"的关键。
五、子 Agent——干活的人和检查的人必须分开
loop 里最有用的结构设计，就是把写代码的和检查代码的拆开。
写代码的模型给自己打分太心软了。第二个 Agent，带着不同的指令、有时用不同的模型，能抓住第一个自己把自己忽悠了的那些问题。
Codex 里你要求时才生成子 Agent，同时跑，然后把结果汇成一个答案。你在 .codex/agents/ 里用 TOML 文件定义自己的 Agent——每个有名字、描述、指令，可选模型和推理强度。这样你的安全审查者可以是个强模型开高推理，你的探索者可以是个快速只读模型。
Claude Code 在 .claude/agents/ 里做同样的事，还有 Agent team 在多个 Agent 之间传递工作。常见分工都是一个探索、一个实现、一个验证。
我论证过两次这个观点了——一次是《代码 Agent 管弦乐团》，一次是《对抗性代码审查》。它之所以在 loop 里特别重要，是因为loop 在你不在的时候跑，所以一个你真信得过的验证者是你能走开的唯一理由。
子 Agent 确实更烧 token，因为每个都做自己的模型调用和工具操作，所以把 token 花在值得第二次意见的地方。Claude Code 的 /goal 底层也是这个思路——一个全新的模型来判断 loop 完没完成，干活的那个不管这事儿。创造者和检查者的分工，应用到了停止条件本身。
一个完整的 Loop 长什么样
把这些拼起来，单个线程就变成了一个小控制面板。这是我一直在用的一种形态：
一个自动化每天早上在仓库上运行。它调用一个分流技能，读取昨天的 CI 失败、开放的 issue、最近的 commit，把发现写入 markdown 文件或 Linear 看板。对于每个值得处理的发现，线程打开一个隔离的 worktree，派一个子 Agent 起草修复方案，再派第二个子 Agent 根据项目技能和现有测试来审查那个方案。
连接器让 loop 自己打开 PR、更新工单。Loop 处理不了的进分流收件箱给我。状态文件是整个系统的脊梁——它记住了什么试过了、什么通过了、什么还开着，所以明天早上的运行从今天停下的地方接着来。
看看你实际做了什么——你设计了一次，然后你没有提示其中任何一个步骤。 这就是 Steinberger 说的那番话的活生生体现。同样的 loop，Codex 里能跑，Claude Code 里也能跑，因为零件是一样的。
Loop 仍然替你干不了的事
Loop 改变了工作方式，但没把你从工作中删掉。有三个问题，loop 越强反而越尖锐：
1. 验证还是得你自己来
没人看着跑的 loop，也是没人看着犯错的 loop。你把验证子 Agent 和制造者分开，就是为了让 loop 说"完成了"的时候这句话有点分量。但就算这样，"完成"是个声明，不是证明。 我一直在重复《AI 时代的代码审查》里那句话：你的工作是发布你确认能用的代码。
2. 你的理解力会衰退——如果你不刻意维持的话
Loop 越快地发布你没写过的代码，"代码库里有什么"和"你真正理解什么"之间的差距就越大。这叫理解债务，顺畅的 loop 只会让它增长更快——除非你亲自去读 loop 产出的东西。
3. 越舒服越危险
Loop 自己跑的时候，很容易就不再有自己的判断了，它给什么你就接什么。我管这叫认知投降。带着判断力设计 loop 是解药，为了逃避思考而设计 loop 是毒药——同样的动作，完全相反的结果。
构建 loop。但保持你是工程师。
我觉得这是我们工作方式演变的一个预览。但我要说的是：如果我不亲自审代码，如果完全靠自动化 loop 来修 bug，我的产品质量一定会下滑。 我很可能会掉进下行螺旋，越挖越深。
所以，去搭你的 loop 吧，但别忘了直接提示 Agent 仍然管用。关键是找到平衡。
同样一个 loop，不同人跑出来的结果可能天差地别。两个人搭完全一样的 loop：一个人用它在自己深刻理解的工作上加速；另一个人用它来逃避理解工作本身。Loop 不知道两者的区别。你知道。
这就是为什么 loop 设计比提示工程更难，而不是更容易。Cherny 的意思不是说活儿变轻松了——是杠杆的支点挪了。
构建 loop。但像打算继续当工程师的人那样去构建，而不只是那个按下启动键的人。
以上，觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。
搜索公众号:"知悟之旅"关注我看更多
浙公网安备 33010602011771号