Agent Orchestration 選模型：先看節點角色，不是先看模型強弱

Agent Architecture / Model Routing

Agent 管線選模型，不能只問「哪個模型最強」

Threads 提到 Columbia / AgentOptimizer 的 AgentOpt 技術報告：在 HotpotQA planner–solver 管線中，便宜的 Ministral 3 8B 當 Planner、Opus 當 Solver 可達 74.27%；反而 Opus 放在 Planner 位置時，部分組合會直接回答、不委派下游 Solver，導致流程被破壞。這不是弱模型勝利，而是「節點角色」比單點模型能力更重要。

與既有 KB 的關係：Allen KB 先前已收錄 AgentOpt 的 client-side optimization 觀點；這篇補的是更貼近 PM / orchestration 設計的實務問題：Planner、Solver、Advisor 這些節點該用什麼模型，以及為什麼直覺選強模型可能反而錯。

反直覺結果

AgentOpt 報告指出，在 HotpotQA 多跳問答的 planner–solver 流程裡，Opus 作為獨立能力很強，卻可能不是好 Planner。它會用自己的知識直接回答，繞過原本應該呼叫工具與 Solver 的流程。

不是「弱模型比較好」

弱模型在 Planner 位置看起來比較好，是因為它更傾向遵守流程、拆解任務、委派下游。這是 role-fit，不是能力排行。換到 GPQA 這類需要單模型深度科學推理的任務，Opus 獨立回答反而更有優勢。

Advisor Pattern

Anthropic 的 Advisor Tool 也反映類似思路：讓較快、較便宜的 executor 跑主流程，遇到策略瓶頸時再向高智慧 advisor model 請教。強模型不是不用，而是改變它出現的位置與時機。

節點角色	真正需要的能力	強模型可能的副作用	適合的評估方式
Planner	拆解、遵守邊界、委派工具或下游節點。	太會直接回答，破壞原本的 pipeline contract。	看是否正確呼叫 Solver / tools，而不只看 final answer。
Solver / Executor	完成高難度推理、搜尋、工具使用或程式碼產出。	若沒有邊界，可能過度擴張任務範圍。	看答案品質、工具軌跡、成本、延遲與可驗證性。
Critic / Reviewer	找錯、驗證、拒絕低品質輸出。	過度保守或 hallucinate 缺陷。	看 false positive / false negative，而不是單純語氣自信。
Advisor	在關鍵瓶頸提供策略、方向修正、架構判斷。	若一直在線，成本會失控，也可能干擾主流程。	看何時呼叫、呼叫後是否改善結果與成本比。

設計 Agent Orchestration 前，先問這些問題：

這個節點的價值是「回答」還是「拆解與委派」？
它需要遵守邊界，還是需要突破邊界做高階推理？
失敗型態是答案錯、工具沒叫、叫錯工具、成本爆掉，還是延遲太高？
輸出品質使用者是否直接感受得到？若感受不到，是否值得用最貴模型？
有沒有小型 evaluation set 可以測 pipeline 組合，而不是靠直覺或請另一個 LLM 猜？
是否需要把高階模型移到 advisor / escalation 位置，而不是讓它掌控主流程？

PM 視角的重點：模型選擇的上游是場景辨識。若不知道節點在管線中的責任，就算知道哪個模型最強，也很可能把能力放錯地方。