Advisor Strategy：一個讓我改變 Agent 架構思維的小模式

Anthropic 最近發布了一篇技術部落格，介紹他們稱為 Advisor Strategy 的 agentic 架構模式。讀完之後我覺得這件事比表面看起來更值得思考——不只是因為數字漂亮，而是因為它在反駁一個我們長期以來幾乎沒在質疑的直覺。

你一直以為的那個直覺

大多數人設計 multi-agent 系統的時候，直覺是這樣的：

聰明的大模型在前面規劃、分解任務、做決策；小模型在後面執行細節。

這是一種自然的類比——就像公司裡的層級架構，CEO 不做 Excel，工程師不定策略。合理。

但 Advisor Strategy 把這個邏輯倒過來了。

核心想法其實很簡單：

讓小模型（Sonnet/Haiku）主導執行全程，只有在遇到真正困難的決策時，才去「請教」大模型（Opus）。

大模型在這裡扮演的是 advisor，而不是 orchestrator。它不調用工具，不產出給使用者看的輸出，只提供一次性的判斷或建議，然後退場。

技術上，這是透過 Messages API 裡一個新的 advisor tool 實現的，單一 /v1/messages request 就能處理整個 handoff，還可以用 max_uses 控制 advisor 最多被諮詢幾次。

Anthropic 給出的 benchmark 結果：

Sonnet + Opus advisor vs. Sonnet alone：SWE-bench Multilingual 提升 2.7 個百分點，成本下降 11.9%
Haiku + Opus advisor vs. Haiku alone：BrowseComp 從 19.7% 跳到 41.2%（翻倍以上），成本比 Sonnet 便宜 85%，但性能仍比 Sonnet 低 29%

這裡最有趣的不是絕對分數，而是「性能上升、成本也下降」同時發生。這在工程上不常見，通常你會在兩者之間 trade-off，不是兩個都贏。

原因是：Sonnet 獨立運作時，遇到難題它還是得硬撐，平均的 token 效率並不理想。有了 advisor 機制，它可以在簡單任務上快速跑、難任務上精準問，整體 token 花費反而更優化。

我第一個聯想是神經科學裡的 dual-process theory（雙歷程理論）：
Kahneman 的 System 1 / System 2 框架。

Advisor Strategy 就是在 AI agent 架構裡實現這個分工：Sonnet/Haiku 跑 System 1，Opus 只在必要時啟動 System 2。

這不是新概念，但 Anthropic 做了一件重要的事：把它標準化成一個 API primitive，而不是讓開發者自己用 prompt engineering 土法煉鋼。標準化代表可測量、可複製、有最佳實踐可依循。

advisor 何時介入的判斷邏輯，是誰決定的？

如果是 executor 自己決定「這個問題我需要去問 advisor」，那它其實需要足夠的 meta-cognition 才能做出這個判斷，這是對 Sonnet/Haiku 的預設前提。如果 executor 在真正複雜的地方沒有意識到自己需要幫助，advisor 就永遠不會被觸發。

這是個有趣的 bootstrap 問題：你需要一定程度的智慧，才能知道自己什麼時候不夠聰明。

另外值得注意的是，max_uses 的設定太低會讓 advisor 沒有發揮空間，太高會讓成本優勢消失。這需要 per-task calibration。

如果你在跑 agentic 任務（coding、web browsing、tool use），這個模式值得試。尤其是：

如果你的任務是幾乎每一步都需要深度推理（比如某些數學或複雜推論鏈），這個模式可能幫助有限，因為 advisor 會頻繁被觸發，成本優勢消失。

Advisor Strategy 讓我重新思考 agentic 架構設計的一個基本問題：

我們真的需要每個決策都用最大的模型嗎？

多數時候，答案是不需要。我們過去的做法是「一刀切用最好的」，因為不確定什麼時候需要，索性都給 token 燒下去。Advisor Strategy 提供了一個更細緻的分層機制，並自動化分配資源。

這是工程上的常識，但在 LLM 領域真正被系統化、benchmark 驗證，並且做成 API primitive。