重磅更新！Anthropic 顧問策略徹底改變了我使用 Claude Code 的方式

하이라이트

• Anthropic 推出的顾问策略（Advisor strategy）让 Claude 3.5 Sonnet 担任主执行者，而仅在复杂决策时咨询 Claude 3 Opus。

• 该策略在 SWE-bench 基准测试中表现优于单一的 Sonnet 模型，且成本显著低于以 Opus 为主智能体的模式。

• 顾问模式下的 Opus 仅负责提供指导和重构建议，从不直接编写代码或执行工具调用。

• 在实际测试中，该策略成功修复了 Sonnet 多次尝试均失败的实时同步逻辑 Bug。

• Sonnet 处理大型任务时采用顺序执行方式，导致 UI 库转换任务耗时达 31 分钟，效率低于具备并行协调能力的 Opus。

• 当主执行者 Sonnet 误判任务复杂度而未主动咨询顾问时，需要人工干预提醒以介入顾问模型。

타임라인

1. 00:00 - 01:30

   模型协调与顾问策略的原理

   单一模型无法兼顾速度、推理能力和成本。由于 Anthropic 降低了速率限制，Opus 的大量 Token 消耗会导致上下文限制迅速耗尽。顾问策略通过减少 Opus 在简单迭代中的参与度，实现了更持久的开发会话。

   • Opus 模型虽然推理能力强，但高昂的 Token 消耗和较低的速率限制缩短了使用窗口。
   • 顾问策略将 Sonnet 设定为处理代码更改和工具调用的执行者，而将 Opus 设定为仅在必要时介入的咨询顾问。
   • 这种双智能体架构在性能和成本效益上均超过了单独运行的 Sonnet。
2. 01:31 - 04:29

   复杂逻辑调试的实战验证

   在处理涉及移动、缩放和删除的实时状态同步时，Sonnet 表现出推理深度不足。Opus 顾问通过回顾对话历史评估全局情况，直接定位了逻辑冲突。这种方法避免了模型因理解力限制而产生的反复试错，提高了调试速度。

   • Sonnet 无法独立解决实时同步功能中删除操作失效的逻辑断裂问题。
   • 启用顾问策略后，Opus 准确识别出同步逻辑的缺陷位置并给出了重构建议。
   • 执行者 Sonnet 在采纳建议后一次性完成了修复，消除了多次往返调试的需求。
3. 04:30 - 07:07

   UI 转换任务中的局限性与并行性能

   虽然顾问策略能保证操作的安全性，但 Sonnet 缺乏将大任务拆分为并行子智能体的能力。在 UI 转换测试中，Sonnet 必须逐一处理组件，这增加了总耗时。这表明在时间效率优先于 Token 成本的大型重构场景中，全 Opus 模式依然具有优势。

   • 顾问策略在将 UI 转换为新库的过程中，成功预判并解决了库版本冲突问题。
   • Sonnet 顺序处理任务的特性导致 31 分钟的转换耗时，显著慢于能并行协调任务的 Opus。
   • 对于涉及整个应用的大规模重构，直接使用 Opus 作为主智能体更为节省时间。
4. 07:08 - 08:52

   功能实现与人工干预的必要性

   在添加新功能页面时，执行者可能会盲目自信地独立执行，从而引入组件边界失效或同步触发机制错误。实验证明，当模型出现逻辑偏差时，需要人类开发者介入并指定使用顾问。Opus 介入后成功解决了点击按钮才更新的延迟问题，实现了即时编辑反馈。

   • Sonnet 在实现新页面功能时常因误判任务难度而跳过咨询顾问，导致组件状态渗漏等 Bug。
   • 人工提示强制模型咨询顾问后，Opus 识别出组件选择错误并修正了流式传输逻辑。
   • 模型对任务复杂度的判断并不总是准确，导致顾问可能无法在第一时间介入。
5. 08:53 - 10:14

   策略应用范围与最终建议

   开发者需要根据项目需求权衡 Token 限制与推理深度。顾问策略在节省资源方面表现卓越，但在面临严苛的下游后果权衡时，Sonnet 即便有指导也可能选错路径。因此，该策略是优化日常开发成本的有力工具，而非万能方案。

   • 顾问策略最适合需要偶尔深度推理但以常规实现为主的中等规模应用。
   • 对于依赖项极其复杂或存在多个潜在故障点的应用，应优先选择全 Opus 架构。
   • 顾问策略能缩小 Sonnet 与 Opus 之间的能力差距，但无法完全替代后者的原生推理深度。