一個 Agent 不該做完所有事：Claude 新顧問模式讓高價模型只在關鍵時刻出手
Claude Code 的顧問模式、Managed Agents 與官方 cookbook 放在一起看，真正重點不是模型排名，而是怎麼把昂貴判斷和低成本執行拆成一套可治理的 Agent 工作流。
本篇內容由倉鼠特報員 AI 協助產出。
倉鼠碎碎念：
這次重讀官方說明後，我覺得這篇真正值得留意的地方更清楚了：Fable 5 和 Sonnet 5 的強弱比較只是入口，後面其實是一套 Agent 成本管理的工程分工。Advisor tool 解決的是何時請高階模型做判斷，Managed Agents 解決的是多個工作者如何隔離上下文、工具與技能，cookbook 則直接把成本帳攤開，說明高階 coordinator 不碰原始網頁、便宜工作者模型 負責大量閱讀。這三份材料合在一起，重點就很明白：未來用模型不能只選最強，還要設計誰判斷、誰搬磚、誰驗收。
解讀來源：
https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool
https://platform.claude.com/docs/en/managed-agents/multi-agent
================= 廣告時間 ================
在進入這次的主題之前，想先跟你分享一個最近讓我覺得「原來如此」的東西。
我認識 VK 好幾年了。她是《VK 科技閱讀時間》Podcast 主持人，每週要消化大量科技資訊做節目，至今累積了超過 350 篇研究、跟 AI 來回協作超過 60 萬字，也曾受邀到 Google I/O 跟 NotebookLM 團隊交流。我一直知道她產量高、寫得快，每週都能穩定交出東西，但她到底怎麼做到的，我以前一直沒真的搞懂。
直到她把整套流程拆開給我看，我才知道那個「穩定」是怎麼來的。
她的方法不是偶然跑出來的，是在真實的大量產出壓力下，一步一步磨出來的。我本來以為她教的是寫作者的事，跟我沒太大關係。但我讀完整個體驗包才發現不是。她給了三套工作流，分別對應內容創作、產業研究、學術研究。只要你的工作需要「快速把陌生資料變成可以用的判斷」，這套流程就對你有用。
真正的卡點在哪裡
行銷在做市場調查是這樣，PM 要整理競品策略是這樣，業務見新客戶前要惡補產業知識也是這樣。卡的不是「做不到」，是「把一堆陌生資料讀懂、整理出全貌」這一段太耗，耗到很多人還沒開始就先放棄了。這才是真正的卡點。
VK 的流程是這樣走的：先用 NotebookLM 的 Deep Research 掃大量來源建資料庫，再手動補它抓不到的（官方檔案、法說會簡報、Podcast 逐字稿）。然後做一張術語表，她說掌握 20% 的關鍵字，就能讀懂 80% 的內容。接著做「全景總覽」，先把地圖看完，刻意不急著問問題。這一步是在對抗一個很常見的陷阱：你一開口就只能問到你以為你知道的答案，確認偏誤就這樣長出來了。
最打動我的是兩個設計。第一個是「驗證提示詞」：你用自己的話把重點整理一遍，再把答案貼回去讓 AI 檢查，它會直接告訴你哪裡其實沒搞懂、哪裡把猜測當成事實。「看過」跟「真的懂了」之間有一條縫，這招是去踩那條縫的。第二個是反幻覺設計：她的提示詞要求 AI 每個論點都附上原文摘句，資料不足的地方標「來源未涵蓋」，不准憑空填答。
這不是把工作外包給 AI。你的判斷、觀點、取捨，還是你自己來。AI 把最耗時的前置整理好，讓你把腦力留給真正該你出手的地方。「能用 30 秒講給朋友聽」是她驗收「你真的理解了」的標準，我覺得這條線設得很對。
先試試這段提示詞
我讀完之後，第一件事是把這套「先把資料整理成全貌、再回頭驗證自己到底懂沒懂」的思路，整理進我自己的工作流裡。底下這段是入門版。先在 NotebookLM 用 Deep Research 匯入資料、勾選你要參考的來源，再把這段貼進去跑（工具免費，手機也能跑）：
請只根據我匯入的來源整理，不要用你自己的背景知識補充，全部用條列、每點簡短好讀：
先給我 3 到 5 句的整體判斷，讓我一眼抓到這批資料的重點。接著再分四塊：
一、發展脈絡：這個主題怎麼一路走到現在，有哪些關鍵節點。
二、主要立場或做法：有哪幾種，各自的核心論點是什麼。
三、還沒定論的爭點：哪些地方目前還沒有共識。
四、下一步該補什麼：列出我最該再找的 2 到 3 類資料，並說明少了它們，我的判斷會有什麼盲點。
三個規則：
1. 每一點都用括號標出來自哪一份來源，如果來源裡有原句，附一句短摘錄。
2. 資料不足以回答的，直接寫「來源未涵蓋」，不要自己編。
3. 不要寫「很重要」「值得關注」這種空話，只給具體內容。
試完之後，你會感覺到「有結構地問」跟「隨便問」差在哪裡。
VK 的完整課程
這段提示詞只是入門。VK 課程的完整版本，是針對寫作、產業研究、學術研究不同情境，一步扣一步的連續流程，告訴你什麼時候建資料庫、什麼時候回頭驗證理解、什麼時候把資料收斂成判斷。兩者的定位本來就不同。
如果你只是想叫 AI 直接幫你生一篇出來，這堂課可能不是你要的。但如果你的工作就是要讀大量資料、整理出自己的判斷，這套會很有感。你卡住的可能不是能力，而是還沒有一套把混亂陌生資料變成清晰全貌的方法。這堂課在解決的，就是這件事。
課程還在集資期，想試的話這陣子入手會比較好。VK 另外還有產業研究、學術研究兩套，這次集資三堂合購會更划算。
折扣碼 CIRCLEGHOST 是給知識倉鼠讀者的專屬福利，結帳折 $80，連結在這：https://pse.is/98dseq
好，這個先分享到這。我們回到這週的正題。
=============== 廣告時間結束 ==============
正文開始
做 Agent 工作流最痛的地方，很多時候已經不是模型不夠聰明。真正讓人卡住的，是成本很快失控。
一個長任務跑下來，主 Agent 讀資料、查來源、修改內容、跑工具、整理結果，所有東西都塞進同一條上下文。你想用最強模型保穩定，帳單會一路往上跳；你想換便宜模型省錢，又怕它在關鍵判斷上走錯方向。很多團隊最後卡在同一個兩難：便宜的模型不夠穩，穩的模型又太貴。
ClaudeDevs 這串貼文值得看的地方，就在這個痛點上。Fable 5 和 Sonnet 5 的搭配只是入口；把原 PO 附的顧問工具（Advisor tool）、受管 Agent（Managed Agents）和實作範例庫（cookbook）一起讀完後，會看到一套更完整的 Agent 成本管理方法：高階模型負責判斷、規劃與驗收，便宜模型負責大量閱讀、搜尋與執行。
這篇會拆兩個模式：顧問模式（advisor pattern）和協調者與工作者模式（orchestrator-worker pattern）。
前者解決「什麼時候請高階模型進來判斷」，後者解決「大量工作怎麼拆給不同工作者（worker）」。
兩者合起來，其實是在回答同一個問題：
Agent 系統要怎麼像一個團隊那樣分工，避免讓單一模型從頭燒到尾。
顧問工具：讓高階模型在關鍵時刻做判斷校正
顧問工具官方說明的第一句就很關鍵：它讓一個更快、成本更低的執行模型，在生成中途諮詢更高智慧的顧問模型（advisor model）。顧問模型會讀取完整對話，產生計畫或方向校正，然後執行模型繼續把任務做完。
這裡有兩個容易被忽略的細節。
第一，顧問模型並不會自己使用工具。官方說明寫得很清楚：顧問模型本身沒有工具（tools），也沒有自己的上下文管理（context management）。它收到的是執行模型的完整紀錄（transcript），包括系統提示（system prompt）、工具定義、先前回合、工具結果，以及執行模型在這一輪已經生成的文字。它的工作是提供建議，任務仍由執行模型推進。
第二，Advisor call 發生在同一個 /v1/messages 請求（request）裡，使用者端不需要額外開一輪對話。執行模型決定何時呼叫顧問模型，伺服器端跑一次顧問子推理（advisor sub-inference），再把顧問結果餵回執行模型。這就像工程師平常自己寫，遇到架構風險或方向不確定時，找資深 reviewer 看完整上下文給意見，最後仍由原本的工程師繼續動手。
這也解釋了為什麼貼文第一個模式叫 advisor。這裡的 advisor 可以理解成「顧問」，不是另一個共同工作者。Fable 5 不負責搬磚，它在關鍵點上幫 Sonnet 5 避免走錯路。
如果讀者想自己開：API、Claude Code、一般 Claude app 要分開看
這裡最容易讓讀者誤會，所以要先拆清楚。原貼文和 API 說明講的「顧問模式」，底層是 Anthropic 的 server-side advisor tool；Claude Code 說明則把它包成 /advisor、advisorModel 和 --advisor。兩者是同一條顧問工具能力的不同入口，但不等於 Claude Code sub-agent，也不等於一般 Claude app 聊天頁面裡的一個開關。
如果你是直接用 Anthropic API，官方入口是 Claude API 的 Advisor tool 說明。它目前是 beta 功能，請求裡要帶 advisor-tool-2026-03-01，並在 tools 陣列加入 advisor_20260301：
response = client.beta.messages.create(
model="claude-sonnet-4-6", # 執行模型：負責主要工作
max_tokens=4096,
betas=["advisor-tool-2026-03-01"],
tools=[{
"type": "advisor_20260301",
"name": "advisor",
"model": "claude-opus-4-8", # 顧問模型：只在需要時進場
"max_uses": 2,
"max_tokens": 2048,
}],
messages=[{"role": "user", "content": "你的長任務需求"}],
)如果你是用 Claude Code，官方入口是 Claude Code 的顧問工具說明。CLI 裡有三種開法：第一種是在 session 裡輸入 /advisor 開選擇器；第二種是直接指定顧問模型，例如 /advisor opus；第三種是啟動單次 session 時用 claude --advisor opus。如果想把它變成持久預設值，可以在 Claude Code 設定裡寫入：
{
"advisorModel": "opus"
}這裡的計費也要講精準。Claude Code 說明寫得很清楚：advisor 是在 Anthropic 基礎設施上執行的 server tool，可供「訂閱」和「API 計費帳戶」使用。若你用的是訂閱方案，顧問使用會計入該方案的使用限制；若你用的是 API billing，顧問 token 會按顧問模型的輸入與輸出費率計費。也就是說，Claude Code CLI 能開顧問，但不代表一定是另外走 API 扣款，帳務取決於你當下的 Claude Code 帳戶與計費方式。
還有一個常見混淆：Claude Code sub-agent 不是這裡的 advisor tool。Sub-agent 是把整個子任務委派給另一個 Agent；advisor tool 則是在同一個任務流程裡，由 Claude 在決策點請更強模型讀完整對話並給指導。Claude Code 說明也把兩者分開比較：顧問是在任務中途的決策點介入，sub-agent 則是針對整個被委派的子任務運作。
至於一般 Claude app / claude.ai 聊天介面，這份 Claude Code 說明沒有提供一個讓一般聊天手動開 advisor_20260301 的按鈕或設定。比較嚴謹的說法是：目前可確認的入口是 Anthropic API 與 Claude Code；Claude Code on the Web 若沿用 Claude Code 功能，則要看介面是否提供 /advisor 或對應設定。不要把一般 Claude 聊天視為已經能手動開啟這個顧問工具。
開啟後，使用者也不是手動每次呼叫顧問模型。Claude 會自己判斷何時需要 advisor，例如提交方案前、遇到重複錯誤時、或宣佈任務完成前。你可以在提示裡要求「繼續前先 consult the advisor」，但官方說明也說，沒有一個設定可以硬性限制或強制每次都呼叫顧問。
貼文給的數字很有意思。在 SWE-bench Pro 上，Sonnet 5 + Fable 5 顧問模式可以達到 Fable 5 單獨執行約 92% 的分數，但價格約 63%。
配圖裡的資料大概是：
Sonnet 5 單獨執行約每題 0.75 美元、準確率約 75.5%；
Sonnet 5 + Fable 顧問模型約每題 1.43 美元、準確率約 84%；
Fable 5 單獨執行約每題 2.24 美元、準確率約 91%。
這組數字背後的真正意思是：高階判斷很貴，但高階判斷不需要每一步都發生。coding agent、computer use、多步研究這類長程任務（long-horizon workloads）裡，大量回合（turn）其實偏機械，真正值錢的是少數計畫、校正與驗收時刻。
官方說明也特別提醒，顧問模式弱在三種情境：單輪問答、純粹讓使用者自己選成本品質的模型選擇器（model picker），以及每一步都真的需要顧問模型完整能力的工作。
換句話說，每一步都請高階模型看，顧問模式（advisor pattern）就失去意義，成本也會回到全程使用昂貴模型的狀態。
顧問模式成本帳本，官方已經拆開給你看
顧問工具說明（Advisor docs）裡，最值得做 Agent 執行環境（runtime）的人注意的，是用量與計費（usage and billing）那一段。
Advisor call（顧問呼叫）會作為獨立子推理（sub-inference）計費，出現在 usage.iterations[] 裡。Executor 的 token 會記在 message iteration；Advisor 的 token 會記在 advisor_message iteration。Top-level usage 不會把 Advisor token 全部混進去，因為它們按不同模型費率計價。
這個設計很重要。它等於提醒 Agent 系統不要只看總 token（模型處理文字的計費單位），而要看「誰在什麼角色上花 token」。如果一個任務很貴，你要知道貴在執行模型反覆生成、顧問模型輸出太長、工具結果太肥，還是工作者模型在讀大量資料。
官方還給了幾個成本控制手段：
設定值
max_uses可以限制單次請求（request）裡，advisor 被呼叫幾次。設定值
max_tokens可以限制 advisor 每次輸出的 token，官方測試建議可從 2048 開始。顧問端快取（advisor-side caching）適合預期三次以上顧問呼叫的長 Agent loop（Agent 迴圈），兩次以下通常不划算。
對話層級上限（conversation-level cap）要由 客戶端（client-side）自己計數，達到上限後要移除 顧問工具（advisor tool），並清理歷史紀錄裡的 顧問結果區塊（advisor result blocks），避免後續 400 error。
這些細節讓顧問模式（advisor pattern）從「直覺上省錢」變成「可以被成本看板追蹤」。如果要把這套方法放進自己的 Agent 系統，不能只實作一個 ask_advisor()，還要記錄顧問呼叫次數、顧問輸出長度、執行模型呼叫長度，以及顧問模型是否真的減少後續工具呼叫與返工。
受管 Agent：多 Agent 的關鍵是隔離
第二個官方來源是 Managed Agents 的多 Agent 分工 session（multi-agent sessions）。這份說明補上了原貼文第三到第五則的底層機制。
官方說法是：多 Agent 編排（multi-agent orchestration）讓一個 Agent 協調其他 Agents 完成複雜工作。這些 Agents 可以平行行動，而且各自有隔離上下文（isolated context），這能提升輸出品質，也可能縮短完成時間。
這裡最重要的是「隔離」兩個字。
在 Managed Agents 裡，所有 Agents 共享同一個沙盒（sandbox）、共享儲存空間（filesystem）和 vault 憑證（vault credentials），但每個 Agent 都跑在自己的獨立 session 裡。
每個 session 都有自己的對話歷史，形成隔離上下文的事件流（context-isolated event stream）。協調者看到的是主 session 裡的活動摘要；當它委派工作時，執行環境會建立額外 sessions。
官方還補了一個非常實務的細節：Threads 是持續存在的（persistent）。協調者可以對之前叫過的 Agent 送後續追問（follow-up），而那個 Agent 會保留先前回合（turns）的上下文。這代表 Sub-agent 不會只是一次性函式呼叫，更像一個保有前文記憶的工作者。
每個 Agent 也有自己的設定（configuration）：模型、系統提示、工具、MCP 伺服器與技能（skills）。
官方明確寫到：tools、MCP servers 和上下文不共享。這點對安全與成本都很重要。你不應該把所有工具都塞給主 Agent，也不應該把所有資料都塞回主對話。
比較好的做法，是讓協調者知道如何派工，讓不同工作者帶著最少必要工具與上下文去做事。
官方也直接列出多 Agent 適合委派的三種模式：
平行化（Parallelization），把獨立子任務同時分派出去（fan out），例如搜尋多個來源、分析不同資料，最後由協調者（coordinator）合成結果。
專門化（Specialization），把任務交給有特定系統提示與工具的 Agents，例如安全 Agent 或說明資料 Agent，避免讓單一 Agent 載入所有能力。
升級處理（Escalation），把一部分複雜子任務交給更強的 Agent 或模型。
這三個詞剛好對應原貼文的兩種做法。顧問模式（advisor pattern）是升級處理的輕量版本，協調者與工作者模式則是平行化加專門化的完整版本。
實作範例庫把成本結構講得最直接：大模型不要碰原始網頁
第三個官方來源是 Anthropic 實作範例庫（cookbook）的 CMA_plan_big_execute_small.ipynb。
這份筆記本（notebook）的標題很直接：
大模型負責規劃，小模型負責執行。
它一開始就說，大部分 Agent 工作負載（workload）裡其實有兩種完全不同的工作：少量規劃與判斷（planning and judgment），以及大量機械式閱讀與執行（mechanical reading and doing）。
網頁研究（web research）是最極端的例子，因為驗證二十個事實可能要讀進數十萬 token 的網頁；如果全部用前沿模型（frontier model）處理，真正支配帳單的，往往是前面那一大段閱讀成本。
Cookbook 的做法是把兩種工作拆開：前沿協調者模型負責規劃研究與整合答案，但不直接碰原始網頁（raw web page）；便宜工作者模型在自己的平行上下文裡讀網頁，再回傳蒸餾後的發現。
官方 notebook 也給了實測結果：在作者的測試紀錄裡，整個模型團隊大約便宜 2.5 倍、快 3 倍，而且 84% 到 98% 的輸入 token 是以工作者費率（worker rate）計價。
它還特別說，這個成本邏輯不只適用網頁研究，也適用資料審查、日誌分析和程式碼庫掃描。
這句話對 Agent 系統很關鍵。只要任務裡有大量「讀」的動作，就應該先問：這些原始材料（raw material）有必要進入最高階模型的上下文嗎？很多時候答案是否定的。高階模型需要的是濃縮後的證據、分歧、風險與結論，原始資料可以先留在工作者的上下文裡消化。
ClaudeDevs 在 BrowseComp 上給出的結果正好補上這個觀點：全 Sonnet 5 是 77.8%，每題 16.01 美元；Fable 5 主導模型 + Sonnet 5 工作者模型是 86.8%，每題 18.53 美元；全 Fable 5 是 90.8%，每題 40.56 美元。
這組結果不需要被解讀成「混合方案永遠最好」。它真正提供的是一個很有價值的成本位置：Fable 5 主導模型 + Sonnet 5 工作者模型只比全 Sonnet 貴一點，但準確率大幅拉高；距離全 Fable 只差 4 個百分點左右，成本卻少了一大截。
把三份官方來源合起來看，方法論其實很清楚
如果把原貼文、顧問工具說明、多 Agent 說明和實作範例庫放在一起，會得到一套比「多模型省錢」更完整的方法論。
第一，先分清楚任務裡哪一段是在判斷，哪一段是在搬磚。規劃、架構判斷、風險審查、最終整合是判斷層；搜尋、閱讀、抽取、編輯、跑測試、掃日誌是勞動層。不要讓最貴模型全程做兩種工作。
第二，少量高價判斷用顧問模式。如果主執行模型大多能完成任務，只是需要在早期方向、卡關時刻、完成前驗收取得高階建議，就用顧問模式。官方最佳實務也提到，程式任務（coding tasks）裡常見的好時機是：做完初步方向盤點後、進入實質工作前，以及完成後、宣告完成前。
第三，大量可拆工作用協調者與工作者模式。如果任務可以分成多個來源、多份材料、多個假設、多個候選解，協調者就該分派任務（fan out）。工作者（Worker）的價值在於它們能在隔離 session 裡平行消化大量資料，再把主對話需要的資訊濃縮回來。
第四，工具與技能要跟著角色切開。多 Agent 說明明確說 tools、MCP servers、上下文不共享。這其實是 Agent 產品設計的重點：不要把所有工具都給主 Agent，也不要把所有能力塞進同一個系統提示。安全 Agent、說明資料 Agent、研究工作者、程式碼審查者（code reviewer）應該有不同工具與不同提示。
第五，成本追蹤要按角色拆帳。顧問工具說明裡的 usage.iterations[]、實作範例庫裡按 session 拆分的用量（per-thread usage）、Managed Agents 的事件流（event stream），都指向同一件事：Agent 執行環境（runtime）不能只記總成本。它要能回答是哪個角色燒 token，哪個工作者讀了最多資料，哪次顧問呼叫是否真的減少後續返工。
對我們自己的 Agent 工作流有什麼啟發
這篇對 Hermes / OpenClaw 這類 Agent 系統很有啟發，因為我們本來就會遇到類似問題：主 Agent 上下文越來越肥，工具結果、子任務過程、錯誤日誌、圖片 QA、Notion 回傳全部塞進同一條對話。最後成本變高，雜訊變多，主 Agent 也更容易被歷史細節拖慢。
Anthropic 這套官方方法其實在提醒我們，不要把 Agent 當成一個超大聊天框，而要把它當成一個有分工的工作組織。
主 Agent 應該像協調者（coordinator），負責判斷哪些任務要自己做、哪些要委派、哪些需要高階 review、哪些只是機械處理。Sub-agent 應該帶著清楚任務、必要工具、隔離上下文去處理拆分後的子任務。顧問模型則適合在方向不確定、風險高、完成前驗收時進場。
這也會改變我們對「模型選擇」的想像。未來模型選擇器（model picker）不能只問你要 Fable 5 還是 Sonnet 5，還要問你要哪種執行策略：單模型快速處理、執行模型 + 顧問模型、協調者 + 工作者、專家團隊（specialist team），或升級模式（escalation mode）。
接下來更值得問的問題會變成：「哪個角色需要哪種模型？」
最後記住一句話
這串貼文和官方說明合在一起，給出一個 Agent 成本管理框架：
高價模型負責判斷，低價模型負責勞動，執行環境負責隔離上下文、工具與帳本。
如果只看到 Fable 5 顧問模式或 Sonnet 5 工作者模型，會覺得這只是 Anthropic 的新功能展示。但如果把顧問工具說明、多 Agent 分工 session 和實作範例庫一起讀，就會看到更大的變化：
AI 系統正在從「呼叫一個模型」變成「管理一組有角色、有存取邊界、有成本結構的模型團隊」。