Anthropic 的 Advisor Strategy（顾问策略）概念我们之前聊过一层：Opus 做大脑、Sonnet 做手脚的工程哲学。这篇不谈哲学，谈落地——advisor 工具在 Messages API 里怎么声明、成本怎么控、pause_turn 恢复和 result variants 这些坑、以及什么时候根本不该用。
它解决的是哪个具体问题
跑长流程 agent 时你通常有两个选择：全程用最强模型，稳但贵；用中档模型跑，便宜，但任务里总有那么一两个判断点需要更强推理，而等你发现时，executor 已经基于错误的判断继续走了很多步。
自己写 escalation 是常规做法：检测难 case → 打包上下文 → 调一个更大的模型 → 把回答拼回去。这套方案麻烦在上下文管理——你传给大模型的上下文跟 executor 手里的是不是一致、拼接后格式会不会坏，都要自己兜底。
Advisor tool 把这段流程做成了平台原生的 server-side tool：executor 自己决定什么时候求助，一次 /v1/messages 请求内完成全部模型交接，你这边不需要额外的 round-trip。
核心机制
把 advisor_20260301 加到 tools 数组，加 beta header anthropic-beta: advisor-tool-2026-03-01：
{
"model": "claude-sonnet-4-5",
"max_tokens": 8000,
"tools": [
{"name": "advisor_20260301", "type": "server_tool", "max_uses": 3},
{"name": "bash", "type": "bash_20250124"}
],
"messages": []
}
流程是这样：
- executor 发出
server_tool_use块，name: "advisor"，input为空——时机由它决定，上下文由服务端提供。 - 服务端在 advisor 模型上单独跑一次推理。advisor 读到的是完整会话转录：你的 system prompt、工具定义、之前所有轮次和工具结果、以及本轮 executor 已经生成的文本。
- advisor 的返回作为
advisor_tool_result回到 executor。 - executor 带着建议继续生成。
关键约束：
- advisor 不调用任何工具、不产出用户可见输出，只给 plan / correction / stop signal。
- advisor 的 thinking block 在返回前被丢弃，只有建议文本到达 executor。
- advisor 模型不能弱于 executor，非法配对在创建时就 400 报错，而不是运行时才炸。
成本：钱花在哪、怎么封顶
钱是分层的。executor 的 token 按 executor 模型费率算，advisor 的 token 按 advisor 模型费率算——而 advisor 通常只产出 400–700 个文本 token（一份短 plan），大头输出全部在便宜档完成。所以整体成本远低于用 advisor 模型全程跑。
官方给了个参考数据：BrowseComp 上 Haiku 单独跑 19.7%，配上 Opus advisor 到 41.2%；比单独 Sonnet 低 29% 的分，但每任务成本低 85%。注意这个收益会随 executor 能力逼近 advisor 而缩小——能力差距越大越划算。
成本控制上两个抓手：
max_uses：给 advisor 的调用次数设上限，防止它被过度求助。- usage 块里 advisor token 单独统计，方便按 tier 追踪开销。
我建议在代码里把 advisor 的调用次数和 token 单独记日志，压测时看「每次 advisor 调用平均省了多少 executor token」，这个比值才是这个模式对你值不值得的硬指标。
两个容易踩的坑
1. pause_turn 恢复
一次响应可能以 stop_reason: "pause_turn" 结尾，同时 advisor 调用还 pending——响应里带着 advisor 的 server_tool_use 块但没有对应的 advisor_tool_result。要恢复：把这段 assistant message 原样 append 到 messages（保留 server_tool_use 块），带着同样的 advisor 工具和 beta header 重新发请求，不用加 user message 或 tool_result。如果恢复请求里漏了 advisor 工具，会返回 400 invalid_request_error，因为 pending 的 server_tool_use 块没有工具可跑。
2. result variants
新一点的 advisor 模型返回的 advisor_tool_result.content 可能是加密的 advisor_redacted_result 变体，服务端在下一轮解密并渲染进 executor 的 prompt。这要求你原样回传 advisor_tool_result 块——别在中间做任何清洗或重写。
什么时候不该用
不是所有任务都值得。官方文档点名的弱适用场景：
- 单轮问答：没有可 plan 的东西，advisor 帮不上忙。
- 纯 pass-through 的模型选择器：用户已经自己选了成本/质量档位。
- 每一轮都需要 advisor 全量能力的工作——这种情况直接把任务跑在 advisor 模型上更简单。
我自己加一条判断：如果 executor 90% 的轮次都靠自身能力就够，只有少数决策点需要更高推理，这个模式收益最大。 如果 executor 动不动就求助，说明模型配对选错了，先换更强的 executor，而不是加 advisor 调用预算。
配对的实践要点
- 咨询策略（什么时候去问）是写在 system prompt 里的，工具本身不带参数。
- 建议在写实质代码前、commit 前、构建下一步之前调用 advisor——先有 plan，再让 plan 流进你的 todo/planner 工具，而不是让 executor 闷头写完一大段再让 advisor 来纠偏。
- Managed Agents 里也有等价的写法：在
multiagent.agents里放{"type": "advisor", "model": ...}，占用保留名anthropic.advisor，一个 roster 最多一个；advisor 咨询线程不占 25 线程的并发上限，咨询失败也不会让 agent 那一轮挂掉（只会收到一条通用失败通知继续跑）。
需要你自行验证的部分
模型具体型号名、advisor_20260301 和 beta header 的生效版本、以及费率，都在快速迭代，写代码前以官方文档为准。上面 BrowseComp 的数据来自官方博客，我在自己的负载里跑出来的收益曲线跟它不一定一致——你的任务形态决定一切，先跑一轮 eval 对比「Sonnet 单独 / Sonnet+Opus advisor / Opus 单独」再定方案。