---
title: "別再無腦 Fan-out：Claude Haiku 5.5 四層調度架構實戰"
description: "Claude Haiku 5.5 又快又便宜，但把所有任務平行丟給它，只會放大誤判、評審偏誤與 Supply Chain 風險。這篇拆解 Fable 判斷、Opus 調度、Sonnet 與 Haiku 實作、CI 驗證、Opus 驗收的分層架構，以及什麼任務才值得 Fan-out。"
url: https://stephen.taipei/articles/claude-haiku-fan-out-orchestration
author: "Stephen Chuang"
date: 2026-10-08T14:05:34+08:00
tags: [ai-agents, software-architecture]
lang: zh-TW
---

# 別再無腦 Fan-out：Claude Haiku 5.5 四層調度架構實戰

Claude Haiku 5.5 在 2026 年 10 月 7 日推出。prompt 在 10 萬 tokens 以內時，它的價格是 Sonnet 5.5 的二十分之一，延遲也是目前這一代 Claude 裡最快的。

又便宜又快，很容易讓人想這樣做：把所有 coding 任務拆開，平行丟給一群 Haiku，做完就好。

做原型時，這樣也許跑得動。放進正式的工程環境，很快會撞到三個問題：

1. **小模型不適合處理歧義。** Haiku 5.5 的官方定位是分類、抽取、路由與 subagent 這類大量、低延遲的工作。需求還帶著業務歧義、需要整個系統的脈絡時，它很容易交出看起來完整、其實猜錯方向的結果。
2. **讓模型挑答案，會有評審偏誤。** 把幾十份產出丟給大模型讀，它容易挑「看起來架構漂亮」的版本，而不是邏輯和執行真的正確的版本。
3. **權限會跟著 Worker 數量放大。** 如果允許平行的 subagent 自動安裝套件或修改設定，開 N 個 Worker，就多了 N 個可能引入惡意套件的入口。

所以我改用**分層調度（Hierarchical Orchestration）**：每一層只做自己擅長的事，Haiku 的平行能力只用在真的需要的地方。

先講結論：**Fable 負責想清楚，Opus 負責分派與驗收，Sonnet 負責主要實作，Haiku 只做機械任務和能自動驗證的搜尋型任務。候選方案先過 CI，再交給模型看。**

## 四層架構：判斷、調度、驗證、驗收

```text
需求輸入
  │
  ▼
【判斷層】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 審查。

問題是，模型讀程式碼時，容易被排版整齊、型別宣告完整的答案吸引，但那不代表它通過了邊界測試。所以候選方案要先過機器這一關：

1. Build 與 Type Check：能編譯，型別正確
2. Unit / Integration Tests：單元測試與整合測試通過
3. Benchmark / Profiling：量測效能與記憶體

沒通過自動化測試的直接淘汰。路徑 C 的候選方案，Opus 只看通過檢查、指標最好的前 2–3 個，也省下 context window 和 token。

## 驗收層：Opus 收斂，失敗就往上升級

最後由 Opus 依照判斷層定義的驗收標準收斂結果。Worker 卡住時，依序往上升級（Escalation Path）：

1. Haiku 失敗，自動修正 2 次仍未通過，就停止重試。
2. 改由 Sonnet 接手修復。
3. Sonnet 也無法通過驗收，通常代表任務拆解或前提假設有矛盾。任務退回 Opus，由 Opus 判斷要不要送回 Fable 重新拆解。

## 放進正式環境前的三條規則

### 不要盲目 Fan-out

簡單任務不需要多個 Worker，高度歧義的任務小模型又解不開。只有「解法空間大」而且「能用自動化測試快速驗證」的搜尋型任務，才值得讓多個 Haiku 平行跑。

### 隔離環境，鎖住 Lockfile

Git Worktree 隔離的是程式碼變更，讓平行的 Worker 不會互相覆蓋檔案；它不限制網路，也不限制程式能存取的範圍。要防 Supply Chain Attack，還需要 sandbox，並禁止 Worker 自行安裝未審查的套件或修改 Lockfile。隨意放開安裝權限，等於讓 Agent 把來路不明的套件和腳本帶進程式庫。

### 用量測數據驗收，不用模型評語

測試結果、覆蓋率、記憶體用量和延遲，才是可以重現、可以比較的依據。模型的文字評價可以參考，但不能拿來驗收程式碼品質。

## 便宜的模型，要用在對的地方

Haiku 5.5 讓平行變得便宜，但平行本身不會讓結果變正確。先把判斷、分派、驗證、驗收分開，便宜和快才會變成真正的優勢。

這套分層，其實就是我在[AI Agent 根本就是一支敏捷團隊](/articles/ai-agent-agile-team)裡說的 Graph：誰先做、做完交給誰、出問題轉給誰。