文章
別再盲目 Fan-out：Claude Haiku 5.5 四層調度架構實戰
Claude Haiku 5.5 又快又平，但將所有任務平行交給它，只會放大誤判、評審偏誤與 Supply Chain 風險。這篇拆解 Fable 判斷、Opus 調度、Sonnet 與 Haiku 實作、CI 驗證、Opus 驗收的分層架構，以及甚麼任務才值得 Fan-out。
· 5 分鐘閱讀
Claude Haiku 5.5 在 2026 年 10 月 7 日推出。prompt 在 10 萬 tokens 以內時，它的價格是 Sonnet 5.5 的二十分之一，延遲也是目前這一代 Claude 之中最快的。
又平又快，好容易令人想這樣做：將所有 coding 任務拆開，平行交給一群 Haiku，做完就算。
做 prototype 時，這樣或者行得通。放進正式的工程環境，好快會撞到三個問題：
- 小模型不適合處理歧義。 Haiku 5.5 的官方定位是分類、抽取、路由與 subagent 這類大量、低延遲的工作。需求還帶著業務歧義、需要整個系統的脈絡時，它好容易交出看似完整、其實猜錯方向的結果。
- 由模型挑選答案，會有評審偏誤。 將幾十份產出交給大模型讀，它容易挑「看似架構漂亮」的版本，而不是邏輯與執行真正正確的版本。
- 權限會隨著 Worker 數量放大。 如果允許平行的 subagent 自動安裝 package 或修改設定，開 N 個 Worker，就多了 N 個可能引入惡意 package 的入口。
所以我改用分層調度（Hierarchical Orchestration）：每一層只做自己擅長的事，Haiku 的平行能力只用在真正需要的地方。
先講結論：Fable 負責想清楚，Opus 負責分派與驗收，Sonnet 負責主要實作，Haiku 只做機械任務和能自動驗證的搜尋型任務。候選方案先過 CI，再交給模型看。
四層架構：判斷、調度、驗證、驗收#
需求輸入
│
▼
【判斷層】Fable：架構決策、任務拆分、驗收標準
│
▼
【調度層】Opus Main Session：只分派，不重新拆解
├─► 路徑 A：複雜但邊界清楚 ──► Sonnet 實作
├─► 路徑 B：機械任務 ──► 單一 Haiku
├─► 路徑 C：搜尋型、多解法 ──► 多個 Haiku，各自一個 Git Worktree
│
▼
【驗證層】Build、Type Check、Test、Benchmark（路徑 C 只留前 2–3 名）
│
▼
【驗收層】Opus 依驗收標準收斂
失敗就升級：Haiku 修正 2 次仍失敗 ➔ Sonnet ➔ 退回 Opus
每個模型放在哪一層，是按官方定位和價格決定的。下面是 2026 年 10 月 8 日 Anthropic 官方文件上的數字，價格單位是每百萬 tokens 的美元：
| 模型 |
官方定位 |
延遲 |
Input / Output 價格 |
| Claude Fable 5.1 |
高難度推理與長時間的 agentic 工作 |
較慢 |
$10 / $50 |
| Claude Opus 5.5 |
長時間的 agentic coding 與知識工作 |
中等 |
$4 / $20 |
| Claude Sonnet 5.5 |
速度與能力的最佳組合 |
快 |
$2 / $10 |
| Claude Haiku 5.5 |
大量、低延遲的分類、抽取、路由與 subagent 任務 |
最快 |
$0.10 / $0.50 起 |
Haiku 5.5 的價格分兩段：prompt 超過 10 萬 tokens 時，變成 $0.50 / $2.50。
判斷層：Fable 負責架構決策與驗收標準#
不是每個需求都需要 Fable。它是最貴亦最慢的一層，我只在需求有歧義、牽涉跨系統整合，或者要做核心架構決策時才用。
Fable 要交出三樣東西：
- 解決方案設計
- 任務拆分
- 每個子任務可以用測試驗證的驗收標準（Acceptance Criteria）
推理與拆解要由同一層完成。能將系統盲點想清楚的那一層，才切得出邊界乾淨的子任務；架構交給 A、拆分交給 B，介面定義通常會變得模糊。
資訊安全任務是例外。目前這一代 Claude 模型都有安全分類器，請求被阻擋時會回傳 stop_reason: "refusal"，正當的資安工作亦可能被誤擋。Fable 5.1 的分類器涵蓋大部分資安內容，官方說明它並非為資安領域設計；Opus 5.5 則允許在原始碼裏找漏洞。所以資安弱點修復這類需求，前段分析我直接交給 Opus。
調度層：Opus 只分派，不重新拆解#
Opus 是 Main Session，負責路由與派工。這一層不重新推翻架構，亦不做第二次拆解。
- 路徑 A，複雜但邊界清楚：邏輯複雜、但介面邊界已經定義清楚的任務，交給 Sonnet。它是實作的主力。
- 路徑 B，單純的機械任務：樣板程式碼（Boilerplate）、變數重新命名、補單純的單元測試、補文檔，交給一個 Haiku 處理。
- 路徑 C，搜尋型與優化任務：效能調校、複雜 SQL 或 Regex 的多種寫法、排查 Flaky Test，才啟動 Fan-out：派出多個 Haiku，各自在獨立的 Git Worktree 裏嘗試不同解法。
無論走哪條路徑，產出都要進驗證層。
驗證層：先機器，後模型#
很常見的做法，是將平行產出的程式碼全部交給 Opus 或 Sonnet，請它用 prompt 審查。
問題是，模型讀程式碼時，容易被排版整齊、型別宣告完整的答案吸引，但那不代表它通過了邊界測試。所以候選方案要先過機器這一關：
- Build 與 Type Check：能編譯，型別正確
- Unit / Integration Tests：單元測試與整合測試通過
- Benchmark / Profiling：量度效能與記憶體
沒通過自動化測試的直接淘汰。路徑 C 的候選方案，Opus 只看通過檢查、指標最好的前 2–3 個，亦省下 context window 和 token。
驗收層：Opus 收斂，失敗就往上升級#
最後由 Opus 依照判斷層定義的驗收標準收斂結果。Worker 卡住時，依序往上升級（Escalation Path）：
- Haiku 失敗，自動修正 2 次仍未通過，就停止重試。
- 改由 Sonnet 接手修復。
- Sonnet 亦無法通過驗收，通常代表任務拆解或前提假設有矛盾。任務退回 Opus，由 Opus 判斷要不要送回 Fable 重新拆解。
放進正式環境前的三條規則#
不要盲目 Fan-out#
簡單任務不需要多個 Worker，高度歧義的任務小模型又解不開。只有「解法空間大」而且「能用自動化測試快速驗證」的搜尋型任務，才值得讓多個 Haiku 平行跑。
隔離環境，鎖住 Lockfile#
Git Worktree 隔離的是程式碼變更，讓平行的 Worker 不會互相覆蓋檔案；它不限制網絡，亦不限制程式能存取的範圍。要防 Supply Chain Attack，還需要 sandbox，並禁止 Worker 自行安裝未審查的 package 或修改 Lockfile。隨意放開安裝權限，等於讓 Agent 將來歷不明的 package 和 script 帶進程式庫。
用量度數據驗收，不用模型評語#
測試結果、覆蓋率、記憶體用量和延遲，才是可以重現、可以比較的依據。模型的文字評價可以參考，但不能拿來驗收程式碼質素。
便宜的模型，要用在對的地方#
Haiku 5.5 讓平行變得便宜，但平行本身不會讓結果變正確。先把判斷、分派、驗證、驗收分開，平同快才會變成真正的優勢。
這套分層，其實就是我在AI Agent 根本就是一支敏捷團隊裏說的 Graph：誰先做、做完交給誰、出問題轉給誰。