# 我以为会变的是模型，后来才发现协作方式也是动态的 > 三天前我主张把难度当常数、把模型能力当变数，却漏看了一件事：不只模型会变，模型之间的协作方式也会变。Anthropic 的 advisor 策略让便宜模型主驾、只在关键决策点呼叫贵模型当顾问，官方实测接近顶规质量、成本却只剩约六成。这篇补上我上一篇漏掉的第二个变数。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-09 - Pillar: 智能与秩序 / Intelligence & Order - Tags: 多模型调度, advisor 策略, Claude Fable 5, AI agent 架构, token 成本, 韧性工程, 模型路由 - Canonical: https://paulkuo.tw/zh-cn/articles/topology-as-variable/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/topology-as-variable.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：三天前我写「把难度当常数、把模型能力当变数」。这个判断我仍然相信，但我漏看了另一件事：不只模型会变，模型之间的协作方式也会变。Anthropic 的 advisor 策略刚好补上这一层：让便宜模型主驾，只有在关键决策点才呼叫贵模型当顾问。官方实测显示，它能接近顶规模型质量，成本却只剩约六成。这篇文章，是补上我上一篇漏掉的第二个变数。
▶ 听摘要
AI 合成语音・作者本人声线克隆
昨天，我在 [X 上看到一篇 Anthropic 官方帖子](https://x.com/ClaudeDevs/status/2074606058128224365)。里面有一张图很有意思：便宜模型负责跑主流程，遇到关键判断时，才呼叫更强、也更贵的模型给建议。大部分 token，仍然走便宜模型的费率。 我盯着那张图看了一下，因为它刚好戳到我三天前才发的一篇文章。 那篇叫〈[把难度当常数](/zh-cn/articles/difficulty-as-constant/)〉。我在里面主张，模型分派器不该把模型名字写死进规则，因为模型能力是整套系统里最会变的东西。把难度分类当稳定层，把「哪个角色用哪个模型」抽成一张带日期的绑定表，模型改版时只改那张表。 这个主张我到现在还是信。 但那张图让我发现：我在上一篇文章里，其实也犯了同一个错。只是错不在模型那一层，而在更上面的协作方式。 ## advisor 策略是什么：让便宜模型开车，贵模型只在路口出手 先讲那张图背后的东西。 Anthropic 四月上线了一个叫 [advisor tool](https://claude.com/blog/the-advisor-strategy) 的功能，最近把 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 费率计费。](/images/articles/topology-as-variable-advisor.svg) ## 我漏掉的第二种协作方式：拆解，还是请教？ 这里有个我当时没看到的分岔。 分岔不在于用哪个模型，而在于任务到底该「往下拆」，还是「往上问」。 我那篇〈把难度当常数〉在讲模型分派时，脑袋里只有一种协作方式：一个总协调把大任务拆成小块，按难度分派给不同的模型，最后验收、整合。 这是由上而下的 orchestrator-workers。Anthropic 在 [agent 设计指南](https://www.anthropic.com/engineering/building-effective-agents)里写得很清楚，我还引了它当佐证。 advisor 策略是反过来的。 Anthropic 自己的说法是，它「反转了常见的 sub-agent 模式：一个较大的 orchestrator 拆解工作、分派给较小的 worker」。在 advisor 这一种里，是一个便宜的模型在开车，在需要时往上请教更强的模型。 它不必先拆解，也没有 worker pool 或调度逻辑。 orchestrator 让贵模型坐在上面指挥；advisor 则让便宜模型自己跑，顶级脑力留到需要时才借进来。 两种都对，差别在任务的形状。 有些任务能切块、能并行，各块难度也不一样，最后需要一个强脑把结果收拢。这种适合由上而下拆解。 也有些任务是一条长流程，多数步骤都很例行，只有少数决策点会决定成败。这种就适合让便宜模型一路主驾，需要时再向上请教强模型。 我原本把「多模型分派」讲得好像只等于前面那一种。 ![多模型分派的两种协作方式对照：左边 orchestrator-workers 由上而下拆解，最强最贵的模型坐在上面每一轮都跑、往下派工给便宜模型；右边 executor-advisor 由下而上请教，最便宜的模型在下面每一轮主驾，只在关键决策点呼叫上面的强模型顾问。](/images/articles/topology-as-variable-comparison.svg) ## 官方数据：第二意见为什么能同时省钱又加分 一般人的直觉是，多找一个更强的模型来看，一定更贵。 但在某些任务形状里，数字刚好相反。 > **📊 关键数据** > > - **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。 这一句，是我那篇文章当初就该摆在第一步、却整个漏掉的东西。 这也是我在「[智能与秩序](/zh-cn/topics/ai/)」这条线一直在绕的同一个问题：能力快速变动的时候，怎么还设计得出撑得住的秩序。 我在〈把难度当常数〉的结尾写过一句话：盖房子的时候，顺手把逃生门也盖了。 三天后我才发现，真正该检查的不是模型表，而是我对协作方式的预设。 我把难度当成常数，却忘了问：还有哪些东西，只是被我暂时误认成常数？ ## 出处 本文提到的机制与数据，出自 Anthropic 官方资料： - Anthropic Developers（[X 帖子](https://x.com/ClaudeDevs/status/2074606058128224365)）：促成本文的那张 advisor 策略示意图，本文开头提及的原始帖子。 - Anthropic，[The advisor strategy](https://claude.com/blog/the-advisor-strategy)：advisor 策略的定义、「反转 orchestrator-workers」的原话、Sonnet 配 Opus 顾问的 SWE-bench Multilingual 与 BrowseComp 实测数字。 - Anthropic，[Advisor tool（Claude Platform Docs）](https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool) 与 [Claude Code Docs](https://code.claude.com/docs/en/advisor)：advisor tool 的运作、模型配对规则、版本与平台限制。 - Anthropic，[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)：orchestrator-workers 这个由上而下拆解的 workflow pattern。 - Anthropic，[Claude Fable 5](https://www.anthropic.com/claude/fable) 与 [Platform 定价](https://platform.claude.com/docs/en/about-claude/pricing)：Fable 5 的定位与相对 Opus 的价差。