# 我以為會變的是模型，後來才發現協作方式也是動態的 > 三天前我主張把難度當常數、把模型能力當變數，卻漏看了一件事：不只模型會變，模型之間的協作方式也會變。Anthropic 的 advisor 策略讓便宜模型主駕、只在關鍵決策點呼叫貴模型當顧問，官方實測接近頂規品質、成本卻只剩約六成。這篇補上我上一篇漏掉的第二個變數。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-09 - Pillar: 智能與秩序 / Intelligence & Order - Tags: 多模型調度, advisor 策略, Claude Fable 5, AI agent 架構, token 成本, 韌性工程, 模型路由 - Canonical: https://paulkuo.tw/articles/topology-as-variable/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：三天前我寫「把難度當常數、把模型能力當變數」。這個判斷我仍然相信，但我漏看了另一件事：不只模型會變，模型之間的協作方式也會變。Anthropic 的 advisor 策略剛好補上這一層：讓便宜模型主駕，只有在關鍵決策點才呼叫貴模型當顧問。官方實測顯示，它能接近頂規模型品質，成本卻只剩約六成。這篇文章，是補上我上一篇漏掉的第二個變數。
▶ 聽摘要
AI 合成語音・作者本人聲線克隆
昨天，我在 [X 上看到一篇 Anthropic 官方貼文](https://x.com/ClaudeDevs/status/2074606058128224365)。裡面有一張圖很有意思：便宜模型負責跑主流程，遇到關鍵判斷時，才呼叫更強、也更貴的模型給建議。大部分 token，仍然走便宜模型的費率。 我盯著那張圖看了一下，因為它剛好戳到我三天前才發的一篇文章。 那篇叫〈[把難度當常數](/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。 這一句，是我那篇文章當初就該擺在第一步、卻整個漏掉的東西。 這也是我在「[智能與秩序](/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 的價差。