哈喽大家好我是顾北Anthropic 推出 Advisor Tool一行代码让小模型请教大模型成本降低、智能提升你可能也遇到过这个两难用 Sonnet 跑 Agent 任务成本低、速度快但偶尔在关键决策点翻车——架构选错了、任务路径走偏了后面几十步全废掉。换成 Opus 跑全程成本直接上去而且大多数机械性步骤根本用不到那个级别的智能纯属浪费。这个问题我相信很多做 Agent 开发的人都想过也有人自己攒了大模型编排小模型的方案。但大多数实现起来挺麻烦——要维护两个对话流、管理上下文传递、处理轮次路由……Anthropic 在 2026 年 4 月 9 日直接把这件事做成了 API 原生能力叫Advisor Tool。这个设计思路比功能本身更值得关注先说思路因为这才是有意思的地方。Advisor Tool 的核心模式叫顾问策略Advisor Strategy执行者ExecutorSonnet 或 Haiku负责全程跑任务——调工具、读结果、一步步往前走顾问AdvisorOpus只在执行者卡壳、需要决策、或任务快结束时被呼叫读全部上下文给一个计划或纠偏建议然后退场顾问不调用工具不直接输出给用户只给执行者看一段 400-700 token 的建议文字然后执行者继续干活。这和常见的大模型拆解任务、小模型执行完全是反过来的逻辑。通常我们的直觉是用聪明的大模型做规划用便宜的小模型执行。但这样做有个问题——规划和执行是分离的执行过程中冒出来的新信息无法反馈给规划层要么你需要额外的协调逻辑要么大模型根本看不到执行细节。Advisor Strategy 的逻辑反过来让便宜的模型先跑起来积累上下文在真正需要高智能的时刻才触发大模型介入。这样 Opus 看到的是带着大量执行细节的完整上下文给出的建议也更贴合实际情况。顾问见证了整个过程然后给出建议——而不是在开始时盲目规划。这个区别挺本质的。数字说话光说思路不够来看实际效果配置基准测试对比Sonnet Opus 顾问 vs Sonnet 单独SWE-bench Multilingual2.7 个百分点成本降低 11.9%Haiku Opus 顾问 vs Haiku 单独BrowseComp41.2% vs 19.7%得分翻倍Haiku Opus 顾问 vs Sonnet 单独BrowseComp得分低 29%但成本低 85%最后那组数据最有意思如果你的任务对智能要求不是极致Haiku Opus 顾问可以用 Sonnet 15% 的成本跑出七成多的效果——对于高并发、高频次的场景这个算法非常划算。三个真实用户的评价也值得留意Bolt CEO Eric Simmons在复杂任务上做出更好的架构决策而简单任务不增加任何开销。计划和执行轨迹有了天壤之别。Genspark 联创兼CTO Kay Zhu在 agent 轮次、工具调用和整体得分上都有明显提升——比我们自己搭建的规划工具还好。Eve Legal ML工程师 Anuraj Pandey在结构化文档抽取任务上顾问工具让 Haiku 4.5 能按需咨询 Opus 4.6以五分之一的成本达到前沿模型质量。注意 Kay Zhu 说的那句话——比我们自己搭建的规划工具还好。自己搭的方案在功能上可以对标但工程代价完全不同。接入有多简单真的是一行这是 Anthropic 这次做得很克制的一个地方整个 advisor 机制发生在一次/v1/messages请求内部你不需要管理额外的上下文传递或轮次路由。response client.messages.create( modelclaude-sonnet-4-6,# 执行者tools[ {type:advisor_20260301,name:advisor,model:claude-opus-4-6,max_uses:3,# 每次请求最多调用顾问3次},# 你原来的其他工具照常放这里], messages[...] )加入advisor_20260301到 tools 数组完成。Sonnet 会自己决定什么时候叫顾问你不需要写额外的调用逻辑。费用怎么算顾问产生的 token 按 Opus 费率计执行者的 token 按 Sonnet/Haiku 费率计分开统计在usage.iterations里。顾问通常只输出 400-700 token 的建议文字含思考约 1400-1800 token不生成最终输出——最终输出由便宜的执行者完成所以整体成本比全程 Opus 低很多。有几个细节要注意max_uses是成本保险丝。设成 3 意味着这个请求里顾问最多被叫 3 次超了就返回错误执行者继续跑不退出。Prompt caching 建议 3 次以上才开。顾问每次调用都会写一条缓存第二次起才能读到节省。调用次数少的话写缓存本身的成本会超过节省的部分。多轮对话要把advisor_tool_result带回去。这个块不能丢否则下一轮 API 会报 400。适合哪些场景不适合哪些适合用 Advisor Tool 的情况代码 Agent 任务大多数步骤是读文件、跑命令、看结果机械性高但关键的怎么改这个架构需要高智能。典型场景就是 SWE-bench 那类 bug 修复任务。多步研究流水线搜索 → 筛选 → 汇总中间偶尔需要判断这条信息值不值得深挖。Computer Use 类任务大量重复性点击操作偶尔需要判断下一步走哪个路径。不太适合的情况单轮问答没有执行过程积累顾问也没什么可看的每一轮都需要 Opus 级别判断这种情况直接用 Opus 全程跑更合适advisor 的设计假设是大多数步骤机械性强我的判断这个功能目前是 Beta需要加anthropic-beta: advisor-tool-2026-03-01请求头。但即便是 Beta设计思路已经很完整了。我觉得它真正的价值不只是省钱和提分——而是把什么时候需要更高智能这个决策权还给了模型本身。以前我们做 Agent 系统需要在代码层面决定哪些步骤用大模型、哪些用小模型这是一个脆弱的工程决策因为任务的难度分布往往不规律。现在可以让执行者自己感知到我卡了需要帮助然后触发顾问——这更接近人类工作的方式。对于正在做 Agent 系统的开发者我建议先跑一遍你自己的 eval对比Sonnet 单独和Sonnet Opus 顾问的结果。如果你的任务里有明显的关键决策点大概率会看到显著提升。相关文档https://claude.com/blog/the-advisor-strategyhttps://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool你在 Agent 项目里遇到过小模型在关键点翻车的情况吗欢迎评论区聊聊你的解法。我是顾北关注我我们下期再见
