TL;DR：三天前我写「把难度当常数、把模型能力当变数」。这个判断我仍然相信，但我漏看了另一件事：不只模型会变，模型之间的协作方式也会变。Anthropic 的 advisor 策略刚好补上这一层：让便宜模型主驾，只有在关键决策点才呼叫贵模型当顾问。官方实测显示，它能接近顶规模型质量，成本却只剩约六成。这篇文章，是补上我上一篇漏掉的第二个变数。

昨天，我在 X 上看到一篇 Anthropic 官方帖子。里面有一张图很有意思：便宜模型负责跑主流程，遇到关键判断时，才呼叫更强、也更贵的模型给建议。大部分 token，仍然走便宜模型的费率。

我盯着那张图看了一下，因为它刚好戳到我三天前才发的一篇文章。

那篇叫〈把难度当常数〉。我在里面主张，模型分派器不该把模型名字写死进规则，因为模型能力是整套系统里最会变的东西。把难度分类当稳定层，把「哪个角色用哪个模型」抽成一张带日期的绑定表，模型改版时只改那张表。

这个主张我到现在还是信。

但那张图让我发现：我在上一篇文章里，其实也犯了同一个错。只是错不在模型那一层，而在更上面的协作方式。

advisor 策略是什么：让便宜模型开车，贵模型只在路口出手

先讲那张图背后的东西。

Anthropic 四月上线了一个叫 advisor tool 的功能，最近把 Fable 5 也纳进来当顾问。做法是这样：一个便宜、快的模型，也就是 Sonnet 或 Haiku，当 executor，从头到尾把任务跑完。它负责呼叫工具、读结果、一步步逼近答案。

当 executor 碰到自己吃不下的决策，才去咨询更强的 advisor。

advisor 看得到完整脉络，但不接手任务。它只回一段计划、一个修正，或一个「停」的信号。接下来，executor 继续往下跑。

换句话说，advisor 不碰工具，也不直接产出给用户看的答案。它只在关键时刻给方向。

省钱的关键在一个细节：顾问每次只吐大概 400 到 700 个 token 的建议，整个任务大概只被叫一次，其余全部在便宜的 executor 费率上跑。

算下来，多数 token 走的是便宜费率，真正昂贵的判断力只在关键点出现。

Executor（Sonnet 5）在主循环里每一轮都跑，通过 tool call 呼叫 on-demand 的 Advisor（Fable 5）取得建议，advisor 回一段短计划后 executor 继续，多数 token 以较低的 executor 费率计费。

我漏掉的第二种协作方式：拆解，还是请教？

这里有个我当时没看到的分岔。

分岔不在于用哪个模型，而在于任务到底该「往下拆」，还是「往上问」。

我那篇〈把难度当常数〉在讲模型分派时，脑袋里只有一种协作方式：一个总协调把大任务拆成小块，按难度分派给不同的模型，最后验收、整合。

这是由上而下的 orchestrator-workers。Anthropic 在 agent 设计指南里写得很清楚，我还引了它当佐证。

advisor 策略是反过来的。

Anthropic 自己的说法是，它「反转了常见的 sub-agent 模式：一个较大的 orchestrator 拆解工作、分派给较小的 worker」。在 advisor 这一种里，是一个便宜的模型在开车，在需要时往上请教更强的模型。

它不必先拆解，也没有 worker pool 或调度逻辑。

orchestrator 让贵模型坐在上面指挥；advisor 则让便宜模型自己跑，顶级脑力留到需要时才借进来。

两种都对，差别在任务的形状。

有些任务能切块、能并行，各块难度也不一样，最后需要一个强脑把结果收拢。这种适合由上而下拆解。

也有些任务是一条长流程，多数步骤都很例行，只有少数决策点会决定成败。这种就适合让便宜模型一路主驾，需要时再向上请教强模型。

我原本把「多模型分派」讲得好像只等于前面那一种。

多模型分派的两种协作方式对照：左边 orchestrator-workers 由上而下拆解，最强最贵的模型坐在上面每一轮都跑、往下派工给便宜模型；右边 executor-advisor 由下而上请教，最便宜的模型在下面每一轮主驾，只在关键决策点呼叫上面的强模型顾问。

官方数据：第二意见为什么能同时省钱又加分

一般人的直觉是，多找一个更强的模型来看，一定更贵。

但在某些任务形状里，数字刚好相反。

📊 关键数据

  • Sonnet 配 Opus 顾问：SWE-bench Multilingual 比 Sonnet 单飞高 2.7 分，每题成本反而降 11.9%。
  • Sonnet 5 配 Fable 5 顾问：拿到 Fable 单飞约 92% 的分数，只花约 63% 的钱。
  • Haiku 配 Opus 顾问：BrowseComp 从 19.7% 跳到 41.2%，几乎翻了一倍。

为什么会同时赢成本又赢分数？

因为多一个放对位置的第二意见，就能挡掉便宜模型钻牛角尖的浪费。走错路线，或者同一个错误反复重试，都会把工具呼叫烧在死路上。质量和 token 就这样一起赔进去。

省下来的是双份。

所以 Anthropic 的建议很务实：拿你自己的评测集跑三组。便宜模型单飞、便宜模型配顾问、顶级模型单飞。量出你这类工作真正的边界，不要靠感觉选。

真正的错：我把「协作方式」也当成了不会变的常数

回到我自己。

我那篇文章的核心纪律是一句话：不要把会变的东西，焊进不常更新的规则里。

我把模型名字抽出来，关进带日期的绑定表。这一步是对的。

但我在更高一层，做了一模一样的事：我把「协作方式」也默认成不会变的常数。

模型能力我认真当成变数处理了；协作方式却被我默默写死，而且它其实比模型更上游。

整篇文章从头到尾假设「多模型分派等于一个贵脑袋由上而下指挥」，然后才在这个假设底下，去谈哪个角色绑哪个模型。

我在绑定层把这套逻辑想得很仔细；但到了协作方式这一层，却疏忽了。因为真实的情况是，不同问题本来就会需要不同的协作方式。

这个盲点还让我在 v1 的绑定表里，埋了一个成本地雷。

我把当时最贵的 Fable 5，放在「总协调」这个每一轮都会被呼叫的位置上。如果你信的是「贵模型坐上面指挥」，这样绑很自然。

可是一旦看见 advisor 那种协作方式，这就是最烧钱的摆法。

最贵的模型，不该被放在出现频率最高的位置。

后来我把它改掉。Fable 5 从常驻的总指挥，降成关键点才被叫一次的顾问。

我原本以为要防的是模型变强。真正没防到的，是协作方式会多出一种。

不只检查模型，也要检查协作方式

在〈把难度当常数〉里，我花最多心思设计的是一个定期检查机制：新模型一出，就拿一组代表任务重跑一遍，看看某个角色能不能下放给更便宜的模型。

这个机制检查的是「模型有没有变」。但现在看来，还少了一个问题：协作方式有没有变？

原本的检查机制只盯着一件事：这个角色现在该绑哪个模型。

但它不会问另一个更上游的问题：我假设的协作方式，还是唯一的一种吗？

模型变强会在评测集上留下痕迹，你抓得到；但一种更省的做事方式，不会自动出现在绑定表里。你只能自己去看。

advisor 策略四月就上线了，我七月才因为一张图发现它。中间那三个月，我的分派器没有绑错任何模型。

它只是少想了一种协作方式，而我毫无警觉。

所以我现在把检查机制拆成两层。

底下那层还是老样子：新模型出来，就重校绑定。

上面多一层，定期问一次：有没有出现一种新的协作方式，让我原本的分派前提整个要重画？

真正该写进规则的，不是某个模型名字，而是这句话：

先选协作方式，再选模型。

可以拆、可以并行、难度不均的，适合 orchestrator-workers；单线长、决策点少而关键的，适合 executor-advisor。

这一句，是我那篇文章当初就该摆在第一步、却整个漏掉的东西。

这也是我在「智能与秩序」这条线一直在绕的同一个问题：能力快速变动的时候，怎么还设计得出撑得住的秩序。

我在〈把难度当常数〉的结尾写过一句话：盖房子的时候，顺手把逃生门也盖了。

三天后我才发现，真正该检查的不是模型表，而是我对协作方式的预设。

我把难度当成常数，却忘了问：还有哪些东西，只是被我暂时误认成常数？

出处

本文提到的机制与数据，出自 Anthropic 官方资料：