Claude Code 里最贵的浪费：让 Opus 去干 grep 的活

Claude Code 默认用法是一个模型从头干到尾。写代码、搜仓库、读日志、审 diff 全塞进同一个上下文。任务一复杂，上下文先被 grep 结果和测试日志塞满，后面模型再强也容易在垃圾堆里做判断。

xsmryze 在 X 上给了一个更省的做法：按任务把模型拆开。启动命令是：

claude --model sonnet --advisor opus

分工大致是这样：

• Sonnet 5.5 跑主会话，写代码、应用修复。
• Haiku 5.5 做并行子代理：search 映射仓库，grep 找调用点，audit 在临时 worktree 里检查 diff。
• Opus 5.5 当顾问，只在三个时刻介入：计划锁定前、同一错误出现两次、宣布完成前。

原文把这套分工压成一句话：Sonnet builds. Haiku swarms. Opus reviews.

这套东西有官方机制托底。Anthropic 的 Claude Code 文档里，subagents 就是为这种场景设计的：每个子代理有独立上下文窗口、独立 system prompt、工具权限和模型设置。高噪声操作丢给子代理，主会话只拿摘要。文档还给了模型字段、worktree 隔离、CLAUDE.md 规则这些配置项。链接在文末。

xsmryze 给的落地提示词大致是：主会话用 Sonnet，Opus 做 advisor；在 .claude/agents 里建三个 Haiku 子代理 search、grep、audit；audit 设 isolation: worktree，避免检查时碰工作分支；在 CLAUDE.md 加一条规则，把仓库搜索和测试运行交给 Haiku 子代理；快速确定性分叉走 JEV。先看 diff，不要直接改。

有两个点需要说清楚。

JEV 不是 Anthropic 官方组件。评论区 Peter Grish 直接指出，它是第三方路由，不是 Anthropic 的东西。把 JEV 写进流程可以，但别当成 Claude Code 自带能力。

Haiku 审计 diff 也有争议。同一评论区有人质疑：审 diff 恰好是需要大模型的步骤。xsmryze 的方案是 Haiku 做第一层检查，Opus 在签字前看合成后的 diff。这个分工是否够，要看仓库和变更类型，不能一概而论。

还有一个成本问题。评论里 First Commit Lab 问得直接：省 token 不等于省总成本，handoff 和 review 也要算。多模型分工减少的是无效上下文，增加的是协调次数。如果任务很小，拆模型反而更贵。

适合的场景：大仓库、搜索多、测试日志长、主会话经常被工具输出撑爆。先把搜索和测试这类高噪声操作扔给 Haiku 子代理，主会话只留决策和代码变更。等这一步稳定，再加 Opus 顾问和更细的路由。

别把组织架构当魔法。一个模型干所有事会过载，十几个代理全向你会报也会变成人肉路由器。先量一下你的 token 花在哪，再决定要不要拆。省下来的 token 不会自动变成利润，但至少不会让 Opus 在 grep 结果里游泳。

参考来源：

• xsmryze 的推文：https://x.com/xsmryze/status/2118454062727172555
• Claude Code subagents 文档：https://code.claude.com/docs/en/sub-agents
• 评论区关于 JEV、Haiku 审计和总成本的讨论，见原推文回复。