让 Opus 少写代码，省钱的关键在出场时机
Anthropic 的 advisor 工具和 Grok Bot 的 agent 组织图，讲的是同一件事：强模型只做判断，执行交给便宜角色。难点不在搭图，在边界、验收和什么时候叫停。
Anthropic 文档里有个实验性功能，叫 advisor tool。启动 Claude Code 时加一个参数：
claude --model sonnet --advisor opus
主模型 Sonnet 干活，Opus 不参与每一轮，只在关键节点被叫来看完整对话，给建议。官方文档写得很清楚：advisor 是服务端工具，要求 Anthropic API，Bedrock、AWS、Google Cloud、Microsoft Foundry 上不可用。Claude 自己决定什么时候咨询，倾向在承诺方案前、错误反复出现、宣布任务完成前。advisor 每次读完整 transcript，按强模型费率计费，不缓存。省钱来自调用次数少，不来自单价低。
xsmryze 的推文把这个做法扩成一套分工：Sonnet 5.5 跑主会话和写代码，Haiku 5.5 做只读子代理并行搜仓库、找调用点、拉 API 文档，Opus 5.5 当 advisor。他还给了一个 prompt，让 Claude Code 按树重建配置，先看 diff 再改。视频在下面。
这里要留个心眼。官方文档只保证 advisor 的模型配对和调用机制，Haiku 子代理是另一层编排，得自己测。模型表里 Sonnet 5.5 接受 Opus 5 或更新版本当 advisor，Haiku 5.5 能不能当 advisor 要看版本和配对，不能想当然。
有回复说，这招拆开看就是用便宜模型做简单事。VeeraMarni 在回复里说，每周都有新的一招，拆开看就是用便宜模型做简单事。另一位说，关键是啥时候让 Opus 出场，这步也得有人判断。Frank 在回复里说，自己已经当 adversarial reviewer，等 advisor 回复可能负六小时。这些质疑不无道理。advisor 的收益取决于两件事：强模型被叫的频率，和它给出的建议是否被验收。叫得太勤，token 账单和等待时间都会上去。没有验收，建议只是多一段聊天记录。
smerkzz 另一篇文章讲 Grok Bot，思路更像公司组织图。一个 Chief of Staff 接目标、拆任务、每天给一次更新。Researcher 扫来源。Writer 只写草稿。Reviewer 只列阻塞问题。Ops 后面再加。每个 bot 有自己的目标、安全限制、质量条和验收检查。共享一块任务板。先手动跑通，再存成 skill，最后才上 routine。文章里还提醒，所有 bot 共享一台电脑，文件、会话、登录都是公共财产，得用文件夹和交接文件划边界，但那是组织，不是安全边界。
有评论说，每个框都消耗同一个 plan，限额别人能改。chief of staff 很多是 butler work，不需要最强模型。Fernando 在回复里调侃，两个专家意见冲突时，chief of staff 可能听最后一个回答的。组织图能减少你当路由器的次数，但不会自动给你正确答案。
两条线合起来看，共同点落在角色边界和验收上，模型数量不重要。角色要窄，交接要带证据，强模型只做判断，验收先写。SimpleDot Agent Studio 那条评论给了一个工程化版本：Kanban 驱动，worker 隔离，中间件做确定性校验、派发、回收，失败只 BLOCK 不自动重试。链接在这里：SimpleDot Agent Studio。它解决的是 long-running 多 agent 任务的可观测和边界问题，模型本身不会因此变聪明。
如果只想试一下，先做最小配置：Sonnet 主会话加 Opus advisor，跑一个长任务，记录 advisor 被叫了几次、每次给了什么、有没有改变结果。再加 Haiku 子代理。Grok Bot 那边同理，先建 Chief of Staff，给一个真任务，跑通再加 Researcher、Writer、Reviewer。第一天别建二十个 bot。组织图是结果，不是起点。
模型是别人的，限额是别人的，只有验收标准是你的。省钱的不是多模型，是少叫强模型且叫得准。
参考链接：
发布时间: 2026-11-07 20:31