成本暴降50%双监督Agent时代新的分工方式

成本暴降50%双监督Agent时代新的分工方式

Claude 从 4 月就开始讲 advisor 这个工作模式，最近又被反复提起：让一个便宜的模型当执行者，让一个更贵的模型在关键节点当顾问。从这里得到的魔王双护灵感，一个便宜的执行模型，配合两个强力模型，让任务能够稳稳”接住”。

我现在跑了两周的配置是这样：DeepSeek V4 Flash 当执行者，GPT 5.6 sol 当 Advisor，Claude Opus 5 当 Delivery。整体效果挺 nice 的，体感上又便宜又快，跑偏也少了。

Claude 从 4 月讲到现在的东西

Anthropic 在 4 月 9 日发了篇博客，标题就叫 The advisor strategy。思路是：Sonnet 或 Haiku 作为执行者跑完整任务，Opus 作为顾问，在执行者遇到自己搞不定的决策点时介入，给出计划、纠正或者停手信号。顾问不碰工具，不产出用户可见的内容，只对执行者说话。

官方给了两组数据：

后来他们把它做成了产品功能。API 里声明一个 advisor 工具，指定哪个模型当顾问，再用 max_uses 限制调用次数，模型在需要的时候自己决定调用。Claude Code 里也有对应的 /advisor 命令，配好模型就能用。

在 Claude Code 使用 需要配置 export CLAUDE_CODE_ENABLE_EXPERIMENTAL_ADVISOR_TOOL=1

注意 Claude 订阅/API用户才能使用。

7 月 ClaudeDevs 又发了一轮，这次是 Fable 5 当顾问：Sonnet 5 执行，Fable 5 只在需要时被调用，官方给的数字是 SWE-bench Pro 上拿到 Fable 5 单跑约 92% 的分数，价格只要约 63%，每个任务通常只调用一次顾问。最近这个词又热起来的原因很直接：任务越来越长，模型越来越贵，全程跑最强模型不划算。advisor 把”最强模型的推理”从全程摊派改成按需租用，需要的时候才叫它出来，把完整对话交给它。省钱的逻辑是稀疏调用，不是模型变便宜。

两种 advisor 设计：模型自选时机 vs 每轮 hook

Claude 官方和 omp 对 advisor 有一个根本分歧：什么时候咨询。

Claude 的设计是模型自选。主模型在决策点、反复出错、宣告完成前自己决定调用顾问，官方文档的说法是 Claude decides when to call。顾问每次收到完整对话，返回计划或纠正，主模型自己判断是否采纳。

omp 的设计是 hook 触发。advisor 固定在执行者的轮次边界上，每轮结束都会收到增量记录，触发不依赖执行者的任何判断。

Claude 的优点是无需自建 advisor 运行时，接入成本较低，咨询时机灵活，顾问收到完整 conversation，减少手工挑选上下文造成的遗漏，稀疏调用省钱。缺点在触发时机依赖模型自我评估：模型得知道自己什么时候会搞砸，而这恰恰是最需要监督的模型最缺的能力。便宜模型往往该问的时候不问，不该问的时候乱问。

omp 的优点是触发确定，每轮都有审查机会，不会漏掉轮次触发；治理完整，去重、冷却、静默、打断降级都有；还能配置多个 advisor 从不同角度盯。缺点是没有稀疏调用，每轮都有推理成本；要自己维护顾问的上下文（压缩、升级、清空重来）；实现复杂度高。

我选 omp 的原因就一句话：让模型自己选择 advisor 时机，太考验模型的能力了。我要监督的恰恰是那个能力不够的执行者，它的元认知最不可靠。hook 方案把”什么时候监督”从模型判断变成工程规则，每轮都看，监督不依赖执行者自觉。多花的每轮推理成本并不算高有缓存命中以及GPT经常重置和bug 很多中转的GPT倍率都在 0.05 左右，成本换来的是监督的确定性。

Advisor：过程监督

omp 的实现里，advisor 是一个独立的只读 Agent，默认只给 Read、Grep、Glob 三个工具。它每轮结束收到这一轮的增量记录，然后判断：干得对不对，有没有偏离用户的要求。

它有一个唯一的发言通道叫 advise，按严重程度分三级：

advisor 默认沉默。执行者在正确轨道上，它什么都不说；一旦发现方向选错、验证太薄、用户的要求被悄悄改掉，它才开口。系统提示词里写得明白：为用户的利益辩护，只对具体的技术风险说话，泛泛的不安保持沉默。

它还有一套防骚扰机制。同一条建议去重，内容空洞的短语直接丢弃，刚打断过一次之后几轮内同类问题降级处理。这些机制都是教训换来的，早期版本里 advisor 会疯狂重复”Stop.”、“Done.”这种废话，一晚上刷几百条。

advisor 每轮都看，但大多数轮次不说话。成本是每轮推理一次：增量渲染省的是主 transcript 重复格式化的开销，请求侧是全量重放还是增量续接，取决于 provider 的缓存和状态链机制，实际计费需看 usage。这是”过程监督”和”按需咨询”的本质区别：它不省调用次数，省的是重复注入。

Delivery：解放双手的 “继续” Agent

delivery 的设计初衷特别朴素：Agent 干完一轮之后，怎么知道它真的干完了？

我自己的 harness 里挂了个 delivery 扩展，监听执行者的 session_stop 事件。执行者每结束一轮，它就触发一次验收。它的立场从一开始就是：我不相信执行者自报的结果，除非有证据。

验收流程分三步：

1. 把这一轮的消息按 turn 分组。执行者说了什么（主张）、调了哪些工具、工具返回了什么（证据），摆在一起
2. 对比主张和证据。执行者说”文件写好了”，证据里却没有对应的写文件记录；执行者说”43 个测试全过”，测试输出里找不到这个数字。主张和证据对不上就是存疑，但证据有截断，缺失记录只是弱证据，先只读抽查或者让执行者补证，再下结论
3. 给执行者一个三态裁决：complete（完成）、continue（继续干）、needs_user（需要人）

关键在 continue。delivery 判定”没完成或者还有下一步”时，会自己生成一条新消息发给执行者，内容是具体下一步干什么。执行者收到就继续干活，干完又触发一次 delivery，如此循环，直到 complete 或者达到 follow-up 上限。

所以 delivery 的工作逻辑是：审阅执行者留下的执行记录，把真实跑过的命令、退出码、输出当成证据，对照它的完成声明。审查模型自己不执行任何测试命令，只有 Read、Grep、Glob 三个只读工具，验证不是它的活：证据不足时先只读抽查一下工作区，再发 continue 让执行者自己去跑验证、把结果带回来，没完成就发新需求，让它持续工作，直到证据过关。每轮验收还会重新起一个干净的进程，防止上一轮的上下文污染判断；用户输入会随时取消当前的验收链，人永远是最高优先级。

为什么便宜执行加贵监督能成立

跑双护之前，我一直在两种选择里纠结。全程用 Fable，效果最好，但费用高，长任务烧得肉疼。换 Sonnet，很多小任务、CRUD 任务它确实能做到，可长链路执行容易出问题，最后还是要人盯。

双护模式把关系理顺了：

执行用最便宜的模型，让它快；监督用最强的模型，让它准。

架构上便宜模型承担了大部分输出 token，这是省钱的来源，但 advisor 每轮都在推理，delivery 每轮都要重建一份审查证据，超出 20K 的预算部分直接截断降级，这两块是持续开销。从我只有两周的使用体感，降低了二次返工的频率，时间和成本整体降低。

实测配置与两周感受

我现在的配置：

两个监督角色各自独立配置，想用 Opus 当 Advisor、GPT 当 Delivery，改两处配置就行，架构上没有任何耦合。但是 omp 里面接入 Claude 会封号，我就是封号之后将 Delivery 从 OMP 的内部调用改为了调用外部 claude -p 来调用 Opus。 (以上是在OMP里进行使用，如果你需要在 Claude 或 Codex 进行使用需要自己处理 Hook 调用 codex -p and claude -p)

两周跑下来，感受比较直接：

总结

双监督就是两个老师在监督学生写作业，一个小老师(Advisor)持续监督学生写作业，有问题及时纠正，作业全部完成之后，交给大老师(Delivery)检查，检查整个作业完成情况，发现问题就继续做。

参考资料：

• The advisor strategy - Anthropic
• Escalate hard decisions with the advisor tool - Claude Code Docs
• Fable 5 as advisor - ClaudeDevs