Anthropic 发布 Advisor 工具：便宜模型干到一半卡住，一键打电话问更聪明的模型
- Anthropic 为 Claude API 上线测试版 Advisor 工具：更快更便宜的「执行模型」在生成过程中可以临时调用一个更聪明的「顾问模型」，拿到策略建议后继续把任务干完。
- 整个过程发生在同一次 API 请求内：顾问模型不使用任何工具、不做上下文管理，思考过程会被直接丢弃，只有最终建议文本传回给执行模型。
- 顾问模型的能力必须和执行模型相当或更强，例如 Claude Sonnet 5 做执行模型时，只能配 Claude Opus 4.7 或 Claude Opus 4.8 等更强模型当顾问，具体配对关系由官方兼容表严格限定。
- 顾问每次调用通常只输出 400 到 700 个文字 token（含思考共 1400 到 1800 token），比让顾问模型从头到尾重新生成一次任务省得多，这是省钱的关键。
- 对不太主动找顾问的执行模型（尤其 Claude Haiku 4.5），官方测出一个「提醒」技巧：在第二轮插一句「你还没找顾问」，能让任务通过率提升约 7 个百分点，但插入时机早晚会直接影响效果好坏。
干活的和出主意的，分开找模型
Anthropic 最近为 Claude API 上线了一个测试版新工具 Advisor 工具，让更快更便宜的「执行模型」在生成任务的过程中，可以临时调用一个更聪明的「顾问模型」获取策略建议，拿到建议后继续把任务写完。
一个手脚麻利但经验稍浅的模型负责真正把答案写出来，遇到关键决策时敲一下隔壁那位更强模型的门，问几句话就回工位接着写，而不是把整个任务甩给强模型从头重做。
以前只能二选一：要么便宜要么聪明
在需要很多步的 agent 任务里（写代码、操作电脑、多步骤调研），大部分轮次其实是机械操作，只有少数关键节点真正需要顶尖智能。可过去调模型只有两条路，两头都不讨好。
协作模式踩在质量和成本的中间地带：绝大多数 token 由便宜的执行模型在低费率下产出，只有那几次真正需要动脑的关键节点，才花几百 token 请顶尖模型出个主意。
干活干到一半，打个电话问问顾问
顾问工具和普通工具一样挂在 tools 数组里，什么时候调用由执行模型自己决定。一次完整的调用是这样四步走的。
整个来回全部发生在同一次 /v1/messages 请求内，你这边不产生任何额外的网络往返。唯一的例外是顾问还没答完就先打住的情况，需要你把这段对话原样发回去续上。
第一步里，执行模型吐出的是一个 server_tool_use 块，名字叫 advisor，里面的 input 永远是空的：执行模型只负责「决定现在该问」，具体喂给顾问的上下文由服务器自动补全。第二步，服务器在自己那头单独跑一遍顾问模型，顾问用的是 Anthropic 给它的一套系统提示词，看到的是执行模型的完整对话记录，包括你的系统提示词、工具定义、之前所有轮次和工具结果，以及执行模型这一轮到目前为止已经写出的文字。
顾问是个「只出主意、不沾手」的角色：它自己不使用任何工具，也不做上下文管理；它的思考过程在返回前会被直接丢弃，最终只有那段建议文本回到执行模型手里。
执行模型发起的这次调用之所以是「空」的，就像你敲资深同事的门时不用先把整个项目背景复述一遍，公司的共享文档系统已经自动把你手头的进度摆到他面前了，你只管开口问。
如果顾问还没答完：断点续传（pause_turn）
有时候这次请求会在顾问调用还挂着的时候提前结束，响应里带一个 stop_reason: "pause_turn"，只有发起调用的 server_tool_use 块，还没有对应的结果。这时候你把这条 assistant 消息原样追加回 messages（保留那个 server_tool_use 块），带着同样的顾问工具和 beta header 再发一次请求就行，不需要新加用户消息，也不需要补 tool_result 块。
像打电话遇到占线提示「请稍后再拨」，你不挂机、直接重播同一个号码就能接上刚才没说完的话。续上的这一轮如果又打住了，就再重复一次同样的动作。
点开看细节：返回结果里的两种块，和顾问的「加密建议」
成功的调用会在 assistant 内容里先出现一个 server_tool_use 块（发起调用），紧跟一个 advisor_tool_result 块（顾问的回话）。后者的 content 是个联合类型：像 Claude Opus 4.8 这类顾问返回明文 advisor_result（text 字段可读）；而 Claude Fable 5 和 Claude Mythos 5 这两个顾问返回加密的 advisor_redacted_result，你拿到的是一段读不了的 encrypted_content，下一轮由服务器解密后渲染进执行模型的提示词。两种情况都要在后续轮次里把内容原样传回。调用失败时结果块里会带 error_code（如 overloaded、prompt_too_long、max_uses_exceeded），执行模型会看到错误后不带建议继续往下写，整个请求本身不会失败。
谁能给谁当顾问，是有讲究的
顶层 model 字段是执行模型，工具定义里那个 model 字段是顾问模型，两者必须凑成一个合法的配对。规则只有一条硬线：顾问必须是 Claude Sonnet 4.6 或更强，并且能力至少要和执行模型持平。配错了，API 直接返回 400 错误，点名说不支持这个组合。
| 执行模型 | 可选的顾问模型 |
|---|---|
| Claude Haiku 4.5 | Fable 5Mythos 5Opus 4.8Opus 4.7Opus 4.6Sonnet 4.6 |
| Claude Sonnet 4.6 | Fable 5Mythos 5Opus 4.8Opus 4.7Opus 4.6Sonnet 4.6 |
| Claude Sonnet 5 | Fable 5Mythos 5Opus 4.8Opus 4.7 |
| Claude Opus 4.6 | Fable 5Mythos 5Opus 4.8Opus 4.7Opus 4.6 |
| Claude Opus 4.7 | Fable 5Mythos 5Opus 4.8Opus 4.7 |
| Claude Opus 4.8 | Fable 5Mythos 5Opus 4.8Opus 4.7 |
| Claude Fable 5 | Fable 5 |
| Claude Mythos 5 | Mythos 5 |
虚线框 = 能力相当、可以互相当顾问（如 Opus 4.7 与 Opus 4.8）。高亮行 Sonnet 5 是个直观例子：它只能配 Opus 4.7 或 Opus 4.8，连 Opus 4.6 都不在其列。
这条「顾问能力必须≥执行模型」的硬规则背后的道理很直白：如果顾问比执行模型还弱，它给不出真正有价值的建议，那这趟调用就白花了。所以官方把配对关系用一张兼容表锁死，弱顾问配强执行的组合根本不允许提交。
有些模型不爱主动找顾问，官方专门做了个「提醒」
有些执行模型第一轮不会主动去问顾问，尤其是 Claude Haiku 4.5 这类更轻量的模型。官方的办法是：如果它第一轮没调用顾问，就在第二轮之前，另起一条用户消息插一句简短提醒（nudge）。但这句提醒插得早还是晚，会显著改变结果。
提醒本身很有效，问题全在时机：插早了，执行模型还没摸清任务，这次低信息量的调用反而会挤掉一次本该更晚、更有价值的调用；插晚了，又错过了更好的调用窗口。Anthropic 用真实实验数据把这个时机的敏感度摆了出来。
官方给的用法很具体：先测出你的执行模型在没有提醒时、通常第几轮才首次调用顾问（记作第 N 轮），把 NUDGE_TURN 设得比 N 大；如果工作负载里既有简单任务又有复杂任务，可以把 NUDGE_TURN 提到 3，让两轮就能完成的简单任务先跑完，别被提醒硬塞进一次没必要的咨询。
点开看细节：提醒怎么插、和「强制调用」的区别
提醒要作为它自己单独的一条用户消息，接在工具结果之后，而不是塞进同一条消息里当兄弟块。连续两条用户消息是合法的，官方在 Haiku 和 Sonnet 上测下来两种写法效果等同，单独成一条只是让提醒和工具输出区分得更清楚。另外，如果你的系统提示词里已经有「只在真正不确定时才找顾问」这类克制性措辞，就别再加提醒了，两条指令会打架。想在某一次请求上强制咨询，可以把 tool_choice 设成指向 advisor，但强制调用不能和扩展思考同时开，否则 API 报 400。
这顿饭多花的钱，账单怎么算
顾问调用作为一次单独的子推理，按顾问模型自己的费率结算，不会被卷进执行模型的 usage 总数里。想拆清每一段花了多少，得看 usage.iterations 这个数组。
顾问每次典型输出 400 到 700 个文字 token，算上被丢弃前用掉的思考，一共约 1400 到 1800 token。省钱的关键就在这里：顾问不负责生成你最终那一大坨输出，那部分由执行模型在更低的费率下完成。
还有几个只作用于执行模型、不会自动延伸到顾问的细节：顶层 max_tokens 只约束执行输出，管不到顾问的子推理（要单独限制得在工具定义里另设 max_tokens）；顾问的 token 也不吃执行模型那边的 task budget；Priority Tier（优先级承诺）也是各算各的，除非你的组织在顾问模型上也有承诺，否则顾问调用不走优先级。
还能再省一笔：顾问那头也能开缓存
缓存有两层，各自独立。执行侧的 advisor_tool_result 块和普通内容块一样可缓存，这层不用特别操心；真正有讲究的是顾问侧自己的缓存。
顾问模型每次看到的对话记录，都是在上一次的基础上多追加了一段新内容，所以前缀是稳定的。在工具定义里开 caching（形如 {"type":"ephemeral","ttl":"5m"}）后，每次调用写一份缓存，下一次读到那个点、只为新增的那段付费，你会看到第二次及以后的 advisor_message 迭代里 cache_read_input_tokens 变成非零。
就像每次找顾问都要把之前的会议纪要重念一遍，开缓存等于纪要存了档，往后只需要补念新增的那一段。但建这个档本身也要成本，见面次数太少，建档的钱比省下的还多，划不来。
官方还特别提醒两条一致性坑：一是 caching 开关要设一次就全程保持，中途来回切会直接造成缓存失效；二是 clear_thinking 配置不当（keep 值不是 "all"）会让顾问每轮看到的引用记录发生位移，同样打断顾问侧缓存，这只是成本变差、不影响建议质量。
点开看细节：clear_thinking 的默认值为什么会踩坑
当开了扩展思考但没显式配置 clear_thinking 时，API 默认走 keep: {type: "thinking_turns", value: 1}，正好会触发上面说的缓存位移（这是早期 Opus / Sonnet 模型和所有 Haiku 模型的默认行为；而 Opus 4.5+ 和 Sonnet 4.6+ 默认保留所有轮次）。想让顾问侧缓存稳定，把 keep 明确设成 "all"。
什么活儿适合这么干，什么活儿别折腾
官方在「When to use it」里把边界划得很清楚：这套协作只在「大部分轮次可以省、少数轮次必须强」的混合负载里才划算。
长链路 agent 任务：编程 agent、电脑操作、多步骤调研这类流水线，多数轮次是机械执行，只有少数关键节点真正需要顶尖智能。已经在用 Sonnet 处理复杂任务的团队，加个 Opus 顾问，有机会换来质量提升、总成本与直接用 Sonnet 相近甚至更低；已经在用 Haiku 4.5 的团队，加顾问是比直接换更大执行模型更省的智能升级路径。
单轮问答，没什么可规划的；纯粹的「模型选择器」透传场景，用户已经自己在成本和质量之间做了取舍；以及每一步都真正需要顾问模型全部能力的负载。这些情况下，协作模式带不来好处。
官方也把话说在前面：结果因任务而异，请在你自己的工作负载上评估。目前该工具在 Claude API 和 AWS 上的 Claude Platform 提供 beta 版，暂不支持 Amazon Bedrock、Google Cloud 和 Microsoft Foundry，并且符合零数据保留（ZDR）条件。
You get close to advisor-solo quality while the bulk of token generation happens at executor-model rates.（你能逼近顾问模型独立完成的质量，而大部分 token 生成发生在执行模型的费率下。） Claude 开发者文档 · Advisor tool