Opus只该审三次：Claude Code多模型分工的省法

Opus 很强，但让它去仓库里找文件，属于用牛刀拍蒜。xsmryze 在推文里拆了一套 Claude Code 的多模型分工：Sonnet 主写，Haiku 并行搜和审，Opus 只当顾问。核心目标很直接，别把最贵的模型和主会话上下文浪费在搬砖上。

Claude Code 是 Anthropic 的终端编码代理，能在仓库里读写文件、跑命令、改代码。模型一多，问题就来了。搜索输出、grep 结果、diff 审计会堆在主会话里，上下文很快变脏。推文作者给的解法是按模型擅长的活分工：

• Sonnet 5.5 跑主会话，写代码、应用修复、协调任务。
• Haiku 5.5 开三个子代理并行干活：search 映射仓库，grep 找调用点，audit 在临时 worktree 里检查 diff。
• Opus 5.5 不常驻，只做 advisor。推文列了三个介入点：计划锁定前、同一个错误出现第二次、宣布完成前。
• 推文作者还提到 JEV，把它当作更底层的分叉路由：选哪个文件、用哪个工具、重试还是停止，这类不需要大模型思考的分叉交给 JEV 毫秒级处理，大模型只处理真正有分歧的。

一句话总结推文里的分工：Sonnet builds. Haiku swarms. Opus reviews. 翻译过来就是，Sonnet 负责建，Haiku 负责群搜，Opus 负责审。

这套东西最值钱的地方不在模型组合，在上下文隔离。有网友追问，Haiku 和 Sonnet 不还是读同一个仓库吗，token 怎么少。关键在搜索结果、grep 调用点、diff 审计各自在自己的上下文里跑，最后只把摘要和判断送回主会话。主会话不再被整屏文件内容塞满，Opus 也不用从找文件开始审。审计还放在 throwaway worktree 里，检查不碰工作分支。具体省多少 token 看仓库和任务，但方向清楚。

推文里给了一条启动命令：claude --model sonnet --advisor opus。这里别急着照抄。有网友 Kuz 在回复里提醒，Opus advisor 模式四月就有，Claude Code 里是 /advisor；Haiku 子代理模型用环境变量 CLAUDE_CODE_SUBAGENT_MODEL 设置，不是命令行 flag。配置前先翻文档。文档链接：http://code.claude.com/docs/en/sub-agents

推文作者还给了一段可直接粘贴的配置提示词，核心是五步。按原意整理成中文：

围绕这套分工重配我的 Claude Code：
1. 主会话跑 Sonnet 5.5，Opus 5.5 做 advisor。
2. 在 .claude/agents 建三个 Haiku 5.5 子代理：search 映射仓库，grep 找调用点，audit 检查 diff。
3. audit 设置 isolation: worktree，检查不碰工作分支。
4. 在 CLAUDE.md 加一条规则：仓库搜索和测试运行都交给 Haiku 5.5 子代理，保持主上下文小。
5. 工具选择、路径选择、重试这类快速确定性分叉走 JEV。
先给我看所有改动的 diff，我说 go 之前不要改。

最后一步挺重要。先看 diff 再让代理动手，能少很多返工。别在主分支上直接开三模型派对，拿一个分支试。小脚本和小仓库未必需要这套排班，大仓库、长会话、搜索密集的任务收益更明显。

原帖：https://x.com/xsmryze/status/2117335920827371778