模型路由：
官方方法論 × 我的 harness 實作
orchestrator、advisor、effort——以及它們在 Claude Code 裡怎麼落地
你上次派 subagent 出去，
是什麼模型在跑？
CC 預設 subagent 繼承主模型
意思是：你可能在用最貴的模型翻譯 markdown，也可能在用最便宜的模型做架構判斷
ClaudeDevs 官方 thread · 2026-07-07 · 576 萬 views
官方給的數字
SWE-bench Pro：Sonnet 5 executor + 強模型 advisor vs 強模型單跑
模型怎麼搭，紙面上就是錢跟品質的差
03 / 24
本場地圖
今天的兩條軸線
不講官方產品（API advisor tool / Managed Agents 雲服務）——只講方法論與 harness 落地
04 / 24
官方方法論 一
Orchestrator：由上而下
強模型當腦、便宜模型當手——但 15 倍 token 意味著不是所有任務都值得開編隊
05 / 24
官方方法論 二 · The advisor strategy（claude.com/blog）
Advisor：由下而上
advisor 只出策略、不碰工具、不產出面向使用者的內容；多數 token 燒在便宜那端
官方方法論 三 · Effort docs / Prompting Claude Opus 5
effort 是第三個旋鈕
路由不是一維（換型號），是二維（model × effort）
“use low and medium liberally as your primary control for token cost and response time wherever your evals show quality holds”
“run a fresh effort sweep on your own evals”
Opus 5：code review 在低 effort 精度不掉
Opus 5：多 subagent 協調能力強
骨架對比
誰決定何時借智力
我的定位——orchestrator 為主、advisor 拆成兩層（自動 + 手動）
08 / 24
我的實作 ①
三分類路由
分類軸是任務性質、不是難度——性質穩定、難度模糊；實作類敢用 opus + medium 就是官方那句的直接應用
09 / 24
主視覺
直覺設計 vs 二維設計
我的實作 ①
Main session 只做三件事
orchestrator 不是「什麼都派」，是「知道什麼不該派」
11 / 24→ 現場：派一個 routed-mech
subagent-routing.md SSOT + routed-* 定義檔 + 即時派工
我的實作 ②
座標鋪滿 agent 艦隊
我的實作 ②
座標也鋪到 workflow 層
workflow 每個 stage 寫死 model。實掃結果：
實例：deep-research workflow——Search / Fetch 釘 sonnet、verify 三票對抗投票釘 opus + xhigh
真實教訓：verifier 併發過高炸 429，教訓固化成 throttle 參數寫死在 workflow 裡
座標不只選給「角色」、也選給「流程的每一站」
14 / 24
我的實作 ② · workflow-hardening §8
gate 照不到的地方——workflow 層的 routing 紀律
workflow 的 agent() 不經過派工 gate——這一層沒有機械攔截，「每個 agent() 顯式寫 model」的文字規則就是唯一防線（skill 在寫 script 當下載入，dynamic workflow / ultracode 也吃這套）
機械類在 workflow 內再分兩檔：haiku-OK（純翻譯 / 格式轉換）vs sonnet-required（大 input + 結構化抽取，實證 haiku 不夠強）
降級的帳用「額度」算：token 量 +10%（retry 與更大的 synth 輸入吃掉），但機械活單價從 opus 級換到 sonnet 級（定價差數倍）——整體額度必降
同時解掉 opus 高併發的 429：機械活不再跟驗證搶爆發額度
enforce 有邊界——gate 管即興派工、規範管 workflow 寫作
15 / 24
主視覺
Haiku 個案：一個模型、兩種待遇
haiku 957 / sonnet 122 / opus 22
不是「用不用 Haiku」——是不信任它的判斷、只租它的手速
回收 · Effort docs
座標是掃出來的、不是抄來的
“run a fresh effort sweep on your own evals”
自建 bench 掃 hook 場景甜蜜點
code search 工具實測後才定 routing
判斷類降級用雙派影子對照驗品質
官方給的是方法，座標要自己掃
17 / 24
我的實作 ③
enforce：紀律不能靠自律
規則寫了 ≠ 會被遵守——main session 是 LLM、會忘
沒帶分類標記 → 拒絕 + 提示重派
未指定 model → 直接攔
攔截率 3/64 = 4.7%
抽查偷懶率 ≈ 0%
→ 轉入「保險絲模式」：平時安靜、換模型 / vendor 時接住
團隊版：不用做到 hook 這麼重——把 model 寫死在 agent 定義檔 frontmatter，就是最便宜的 enforce
18 / 24→ 現場：看 gate 攔下一次派工
故意派一個不合規的 → 被拒 → 換 routed-* 通過；tail audit log
我的實作 ④ · advisor 第一層
自動失敗升級
同一問題最多 2 次修正；用盡走四選一：換路 / 升 effort / 外部第二意見 / 問人
原任務全文 + 上輪失敗輸出原樣貼 + 已排除方向
強模型解出的重複模式蒸餾成完整 spec，降回 sonnet 批次套用
反例：換個措辭再派同級 = 燒額度沒升級；第一次修正就跳最強 = 燒配額跳級
20 / 24
我的實作 ④ · advisor 第二層
手動第二意見
官方 advisor 是 executor 自動喊救命；我的主力版本是人類決定何時借智力
自動升級備而少用、手動第二意見天天在用——注意力花在哪，重心就在哪
21 / 24
回收骨架表
第三個答案
三個答案 = 三種成本結構（規劃成本 / token 成本 / 注意力成本）
誠實說：這套維護成本不是零——95% 的時間 gate 是安靜的；偶爾派工的人，agent 定義檔釘 model 那招就夠
22 / 24
帶走
明天就能用的三件事
派工前問一句「這是實作、機械、還是判斷？」
最便宜的 enforce；難題先升 effort，再考慮換模型
定方案前 / 卡關時 / 宣告完成前，花一次注意力叫第二意見，比事後修便宜
延伸閱讀