什么是Advisor Strategy，它与opusplan有何不同

什么是Advisor Strategy

Advisor Strategy是Anthropic正式发布的一种结构。执行由Sonnet或Haiku这类低成本模型承担，只有当该模型自己判断陷入困境的那一刻，才通过API调用Opus获取建议。Opus并非一直待命，而是按需出现。

用组织来打比方更直观。实习生处理日常工作，只有真正卡住时才去请教主管。主管并不一直坐在那里，而是被召唤时才介入，了解情况后给出建议。

从结构上看，执行模型与顾问共享同一个上下文——对话记录和工具历史。顾问给出的建议会被重新写入这个共享上下文，执行模型据此决定下一步动作。整个过程在一次API调用内完成，管理简单；顾问消耗的token会被单独报告，成本因此也能分开追踪。

为什么这次发布很重要

成本差距是真实存在的。Opus每百万输出token 25美元，Haiku只要5美元，相差五倍。如果一项服务每天要处理数千次请求，全部用Opus来运行，成本负担会很重。

但如果一味只用最便宜的模型，性能又会下降。这个策略存在的意义，就是找到既能降低成本又能保持性能，甚至两者同时改善的那个点。

基准测试说明了什么

这是Anthropic自己于2026年4月9日在官方博客文章《The advisor strategy: Give Sonnet an intelligence boost with Opus》中公布的实测结果。在这次发布中，执行模型是Sonnet 4.6和Haiku 4.5，顾问模型是Opus 4.6。

在SWE-bench Multilingual基准测试中，给Sonnet加上Opus顾问后，性能比Sonnet单独运行提升了2.7个百分点，同时单任务成本下降了11.9%。性能上升，成本下降。

在BrowseComp基准测试中，Haiku单独的成绩是19.7%，加上Opus顾问后跃升至41.2%，翻了一倍还多。不过这个组合的分数比Sonnet单独低29个百分点，但单任务成本却便宜85%。下表整理了Anthropic公布的数据。

把四种策略放在一起比较

实际可选的方案大致分为四类：从头到尾只用Opus、刚才说明的Advisor Strategy、Claude Code CLI的opusplan，以及让低成本执行模型在没有顾问的情况下独自工作。

真正区分这四者的不是模型档次，而是判断的主导权在谁手里，以及执行过程中是否存在重新核查的环节。

opusplan与Advisor Strategy有何不同

在Claude Code CLI中应用同样思路的方式是/model opusplan。计划模式下由Opus负责设计，切换到执行模式后自动交给Sonnet接手。

但关键差异在于：Advisor Strategy在执行过程中一旦卡住，随时可以再次调用Opus，每次调用顾问都会重新审视执行模型的工作。opusplan只在计划阶段介入一次，此后直到执行结束，Opus都不会再看一眼。也就是说，复核循环在结构上是缺失的。

因此，当计划本身已经足够周密、执行过程中偏离风险较低时，opusplan已经够用；但如果执行途中判断持续摇摆，这个空白就会实实在在地成为风险。

实际操作中该如何选择

判断标准有两个：这项任务是否在低成本模型能够胜任的难度之内，以及它是一次性任务，还是会不断累积步骤的长期任务。

如果模糊复杂的判断持续出现，让Opus从头到尾掌控更安全。如果是大量、定型化的长期劳动，Advisor Strategy能大幅降低成本。如果只需要一次精确的计划，opusplan就足够了。

但要避免的是，让低成本执行模型在没有顾问的情况下独自面对复杂任务。它无法自行判断何时该停下，试错可能失控，结果总成本反而可能超过单独使用Opus，形成一种悖论。

从AX的角度看，这意味着什么

这个结构其实并非全新技术，而是一种熟悉的组织设计。一线人员卡住时请教上级，上级并不一直待命，只有被召唤时才介入。这是组织沿用多年的授权结构，被原样搬进了AI流水线。

不同之处在于，这种授权的边界和调用规则如今可以写进代码里。可以调用几次、在什么条件下调用、如何追踪每次调用的成本，全都变成可配置的参数。

对于正在评估引入AI的组织而言，问题应该从'该用哪个模型'转变为'该把这个判断放在哪个位置'。比起选模型，角色设计才是如今同时决定成本与质量的关键。