用 AI 编码助手时最让人纠结的一幕是什么?好模型太贵,便宜模型又会在难题面前卡住。Anthropic 这回正面解决了这个两难。
Claude Code 的 /advisor 命令,其实是执行模型(Sonnet)在作业途中卡住时,自动向上位模型(Opus)请教的机制。大部分 token 都交给便宜模型处理,只有难判断的环节才让贵模型介入,以此把性价比拉到极致。SWE-bench 上 Sonnet 单独跑 72.1%,加上 Opus Advisor 提升到 74.8%,而每次任务的成本反而下降了 11.9%。
这是什么?
/advisor 是 Anthropic 于 2026 年 4 月 9 日在 Claude 平台正式推出的模型配对模式(Model Pairing)。 过去常见的做法是贵模型(Opus)在上面指挥,便宜模型(Sonnet/Haiku)承接下游任务(子智能体/Sub-agent 模式),而 /advisor 把这套完全反了过来。
它的工作方式是这样的:像 Sonnet 4.6 或 Haiku 4.5 这种又快又便宜的模型从头到尾主导整个任务。读文件、写代码、跑测试 —— 全部由执行模型自己完成。一旦遇到自己拿不准的决定,它就会自动向 Opus 4.6 请教。
关键在于:Opus 会先看完整段对话上下文,然后只回一段 400~700 token 左右的简短战略建议。它完全不能直接写代码、改文件或调用外部工具,纯粹扮演"思考者"的角色。
在 Claude Code 里,输入 /advisor 并选中 Opus 4.6 就能立即启用。不需要额外设置或调参,一行就搞定。 通过 API 调用时,也只要在 tools 数组里加上一个 advisor_20260301 类型即可。
最亮眼的一点是,建议会累积进整个会话的上下文。之后再次触发 Advisor 时,它会连同之前的建议一起参考。如果执行模型得到的结果和建议不符,它会明确问出来:"Advisor 说是 X,但测试结果是 Y —— 要不要再咨询一次?"
有什么不同?
来对比一下传统多模型模式和 /advisor 模式的差异。
| 传统子智能体模式 | /advisor 模式 | |
|---|---|---|
| 结构 | 贵模型在上面指挥,便宜模型负责执行 | 便宜模型主导,卡住时才向贵模型咨询 |
| 成本结构 | 大部分费用集中在编排模型上 | 以执行模型费用为主,Advisor 只消耗少量 token |
| 上下文共享 | 开发者自行管理上下文传递 | 服务端自动传递 |
| 编排方式 | 需要 LangGraph、AutoGen 等框架 | 一行 API 配置即可 |
| Advisor 的工具访问 | Worker 可以使用工具 | Advisor 无法访问工具(只做推理) |
| 适用场景 | 每一步都很复杂的任务 | 大部分是机械性步骤,偶尔需要难判断的场景 |
实际的基准测试如何?
用数字来看看。
其中 Haiku 的跳跃格外值得关注。BrowseComp 从 19.7% 提升到 41.2%,不只是简单的改进,而是 Advisor 把 Haiku 在复杂网页研究上本来存在的根本能力差距给补上了。法律文件抽取服务 Eve Legal 就靠 Haiku + Opus Advisor 组合,达到了前沿模型级别的质量,而成本只有 Opus 单独使用时的五分之一。
上手指南
- 在 Claude Code 里直接开用
在终端输入/advisor→ 选中 Opus 4.6 → 就这样。如果你现在把 Sonnet 4.6 当主模型用,现在就可以试试看。 - 通过 API 集成
在 Messages API 请求中加上 beta 头anthropic-beta: advisor-tool-2026-03-01,然后在 tools 数组里放一条{"type": "advisor_20260301", "name": "advisor", "model": "claude-opus-4-6"}就行。 - 做好成本控制
用max_uses参数限制每次请求里 Advisor 的调用次数。编码任务通常 2~3 次就足够覆盖核心决策点。 - 选对模型搭配
性价比之王:Sonnet + Opus Advisor。极致省钱:Haiku + Opus Advisor(适合大批量处理)。如果你主要用 Opus,那就和子智能体流程并行使用更合适。 - 用好提示词技巧
在系统提示中加入"在做 substantive work 之前先向 advisor 确认"或者"完成前和 advisor 再 double check 一次"这类明确指令,可以让 Advisor 的调用时机更精准。
实战提示:Advisor 的调用会在 token 账单上以独立一行显示,你可以按项目追踪 Advisor 是否真的物有所值。而且用 /compact 压缩对话后,Advisor 之前的建议依然会被保留,在长会话里充当"知识沉淀层"。
深入了解
局限也要知道:Advisor 的输出不支持流式,所以子推理期间流会短暂中断。此外,如果主模型过于自信,它可能根本不调用 Advisor —— 这时候就得靠提示词来补。
Advisor 真正的潜力,并不在于它本身是一个功能,而在于它是未来模型策略的底层设施。如果以后出现比 Opus 贵得多的下一代模型(比如 Mythos 之类),把它当主模型用显然代价太高。但要是把它设为 Advisor,就能只在关键决策上调用下一代模型的智力,同时把成本压在可控范围内。
根据 Anthropic 的官方文档,在编码任务中把 Sonnet 设为 medium effort 再接上 Opus Advisor,可以用更低的成本拿到接近 default effort Sonnet 单独使用时的智能水平。如果你需要最强智能,default effort + Advisor 的组合就是最强档。
那么子智能体和 Advisor 到底该用哪一个?主模型是 Sonnet 的话,Advisor 就是答案。主模型是 Opus 的话,子智能体(独立上下文)更合适。因为 Advisor 共享整条对话记录,如果主模型一开始把问题 framing 错了,Advisor 也很容易掉进同一个陷阱。而子智能体是在干净的上下文里起步,反而能给出更新鲜的视角。
