文章
别再盲目 Fan-out：Claude Haiku 5.5 四层调度架构实战
Claude Haiku 5.5 又快又便宜，但把所有任务并行丢给它，只会放大误判、评审偏差与 Supply Chain 风险。本文拆解 Fable 决策、Opus 调度、Sonnet 与 Haiku 实现、CI 验证、Opus 验收的分层架构，以及什么样的任务才值得 Fan-out。
· 6 分钟阅读
Claude Haiku 5.5 于 2026 年 10 月 7 日发布。prompt 在 10 万 tokens 以内时，它的价格仅为 Sonnet 5.5 的二十分之一，延迟也是当前这一代 Claude 中最快的。
又便宜又快，很容易让人产生这种想法：把所有 coding 任务拆开，并行丢给一群 Haiku，跑完就行。
在做 Demo 或原型时，这样或许跑得通。一旦放进生产级工程环境，很快就会撞上三个问题：
- 小模型不适合处理歧义。 Haiku 5.5 的官方定位是分类、抽取、路由和 subagent 这类大吞吐、低延迟的工作。当需求仍带有业务歧义、依赖整个系统的上下文时，它很容易交出看似完整、实则方向猜错的结果。
- 让模型挑答案，会产生评审偏差。 把几十份产出丢给大模型读，它往往倾向于挑选“看起来架构漂亮”的版本，而不是逻辑和执行真正正确的版本。
- 权限会随着 Worker 数量被同步放大。 如果允许并行的 subagent 自动安装依赖包或修改配置，启动 N 个 Worker，就等于多了 N 个可能引入恶意依赖的攻击面。
因此我改用分层调度（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 进行 Code Review。
但问题在于，大模型阅读代码时，极易被排版整洁、类型声明规范的方案吸引，但这绝不意味着它能通过边界用例的考验。因此，候选方案必须先经过机器这道关卡：
- 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 自行安装未受信任的第三方依赖包或擅自修改 Lockfile。随意放开安装权限，无异于直接向代码库敞开大门，任由 Agent 引入来源不明的恶意脚本和依赖。
凭量化指标验收，莫信模型评语#
测试结果、测试覆盖率、内存占用以及响应延迟，才是可复现、可横向对比的硬指标。模型的文本评价可以作为参考，但绝不能作为验收代码质量的最终依据。
便宜的模型，要用在对的刀刃上#
Haiku 5.5 大幅降低了并行调用的成本，但并行本身并不能推导出品质的正确。唯有先将决策、分派、验证与验收各司其职，低成本与高吞吐才能真正转化为工程优势。
这套分层机制，本质上就是我在AI Agent 根本就是一支敏捷团队中所阐述的 Graph：谁先处理、做完交付给谁、出现异常如何向上流转。