Agent监控工具排行榜：Loop Engineering深度测评
Loop 工程正在剥夺你作为 Agent 指令下达者的角色。你的核心任务已从“编写提示词”转变为“设计一套系统，由系统自动生成提示词并驱动 Agent”。
那么，Loop 究竟指什么？它是一种递归机制：设定一个目标，AI 持续迭代直至达成。该机制通常由五个模块构成，巧合的是，Claude Code 和 Codex 目前已完整具备这五个模块。
从演进方向看，这可能是未来与编码 Agent 协作的标准化模式。但仍需保持审慎——你需要评估 Token 消耗是否可控、成本是否可承受，同时必须设计质量保障机制，防止产出沦为“能跑但毫无价值的垃圾”。在深入理解其原理之前，先别急着投入生产。
OpenClaw 创始人彼得·斯坦伯格最近放出狠话：“你不应再手动提示编码 Agent。你应该设计 loop，让 loop 替你完成提示工作。”
Anthropic 旗下 Claude Code 负责人鲍里斯·切尔尼也表达了几乎完全一致的看法：“我早已不再手动提示 Claude。我运行 loop，由 loop 负责提示 Claude、决定下一步行动。我的工作就是编写 loop。”
这些言论背后到底在传达什么信息？
从“人操作工具”到“系统代替你操作”
过去两年，与编码 Agent 的协作模式大致如下：精心编写提示词，提供充分上下文，你来我往地对话——Agent 是工具，你全程把持，一轮接一轮地交互。
至少在某些人眼中，这个阶段已经终结。
最新的范式是：搭建一个微型系统，让它自动发现任务、分配任务、检查任务、记录进度，然后决定后续步骤。你让系统去驱动 Agent，而非亲自下场。
我之前写过它的“近亲”——Agent Harness 工程（构建单 Agent 运行环境），以及工厂模型（构建软件的系统）。Loop 工程比 Harness 高出整整一个层级——它融合了 Harness、定时器、自动化辅助工具和自投喂机制。
最令人意外的是，这已不再是纯粹的“工具层面”实验。一年前要实现 loop，你得编写大量 bash 脚本，然后永久维护那堆无人理解的代码，且只有你能运行。如今这些组件直接内置在产品里了。斯坦伯格列出的功能与 Codex 高度吻合，又与 Claude Code 高度一致。一旦发现两个工具的形状完全一致，你便无需纠结工具选择——只需设计一个 loop，无论你坐在哪个工具里，它都能运转。
五个核心组件 + 一个记忆单元
一个 loop 需要五样东西，外加一个“持久化存储”空间。逐项列出：
- 自动化——定时触发，自动发现并分流工作
- 工作树（Worktree）——多个 Agent 并行操作，互不冲突
- 技能（Skills）——将项目知识固化下来，避免 Agent 每次靠猜测
- 插件与连接器——将 Agent 接入你已有的工具生态
- 子 Agent——一个负责执行，另一个负责校验
然后第六项——记忆。可以是一个 markdown 文件，也可以是一个 Linear 看板，任何存在于单次对话之外、能记录“已完成什么、下一步是什么”的载体。听起来简单得不可思议，但这恰恰是每个长期运行 Agent 赖以生存的老方法。正如我在《长期运行 Agent》中所写，模型在两次运行之间会遗忘一切，所以记忆必须存储在硬盘上，而不能仅存在于上下文窗口中。Agent 会遗忘，但仓库不会。
Codex 和 Claude Code 现在都完整具备这五个组件，命名上可能略有差异，但能力完全一致。下面逐一拆解——因为细节决定了 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 写入同一个文件，就像两个工程师同时向同一行代码提 PR 且未沟通一样令人头疼。
Git worktree 解决了这个问题——它是一个独立的工作目录，拥有自己的分支，但共享同一个仓库历史。一个 Agent 的改动物理上无法触碰到另一个 Agent 的代码。
Codex 内置了 worktree 支持，允许多个线程同时操作同一个仓库，互不干扰。
Claude Code 也提供同样的隔离——--worktree 标志在独立 checkout 中打开会话，isolation: worktree 设置加在子 Agent 上，让每个帮手获得一个用完即自动清理的独立 checkout。
我在《编排税》中写过人的那一面——worktree 消除了机械冲突，但你仍然是瓶颈：你的 review 带宽决定了实际能同时跑几个 loop，而非工具说了算。
三、技能——别再每次重新解释项目
技能让你不再像金鱼一样，每次会话都要重新解释同一个项目。
两个工具采用相同的格式——一个文件夹，内含 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，携带不同的指令（有时使用不同的模型），能够抓住第一个 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 处理不了的，进入分流收件箱给我。状态文件是整个系统的脊梁——它记住了什么试过了、什么通过了、什么还开着，因此第二天早上的运行，会从今天停下的地方接着来。
看看你实际做了什么——你设计了一次，之后未再手动提示任何一个步骤。这就是斯坦伯格那番话的活生生体现。同样的 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 设计比提示工程更难，而不是更容易。切尔尼的意思不是说活儿变轻松了——是杠杆的支点挪了。
构建 loop。但像打算继续当工程师的人那样去构建，而不只是那个按下启动键的人。