Opus 5 vs Sonnet 5：什么时候值得多花 5 倍
Claude Opus 5 比 Sonnet 5 贵 5 倍。三个真实场景正面对比，讲清楚什么时候值得加钱，什么时候纯浪费。
先说结论 — Opus 5 和 Sonnet 5 都是 1M 上下文，Opus 贵 5 倍。值得加钱的场景：深度架构级代码审查、需要产出新洞察的多文档综合分析、超过 15 步的复杂推理链。日常 agent 循环、常规写代码、标准问答——Sonnet 5 以五分之一的价格给出相同甚至更好的性价比。
同一家出的，同样的上下文窗口，同样的 API 格式，价格差 5 倍。问题不是「哪个更好」——Opus 5 客观上更强。问题是：对你的具体工作负载，那点能力差距值不值 5 倍的价？
大多数团队多花了冤枉钱。什么都走 Opus「求个保险」。这篇给三个真实场景的正面对决，然后给可执行的路由规则——按任务类型分流，别凭习惯分流。
数字对比
| 规格 | Opus 5 | Sonnet 5 |
|---|---|---|
| 上下文窗口 | 1,000,000 tokens | 1,000,000 tokens |
| Input 价格（每百万 token） | ~$15 | ~$3 |
| Output 价格（每百万 token） | ~$75 | ~$15 |
| 首 token 延迟（10K prompt） | ~2.1s | ~1.2s |
| 首 token 延迟（500K prompt） | ~22s | ~11s |
| 工具调用准确率 | ~97% | ~93% |
| SWE-bench 得分 | ~71% | ~64% |
| 多步推理（>15 步）准确率 | 94% | 79% |
差距真实存在但多数任务上不大。它专门在高难度推理问题上拉开。
场景一：代码审查（200 文件 PR）
设置： agent 审查一个跨微服务代码库的 200 文件 PR。要找 bug、架构违规、安全问题、改进建议。
Opus 5 表现：
- 命中 94% 的埋点 bug（包括分布式锁里一个微妙的竞态条件）
- 识别出架构漂移（某服务绕过消息队列「为了性能」）
- 标记动态拼接查询中的 SQL 注入
- 给出具体重构方案并附实现草图
- 成本：~$3.20/次 | 耗时：~45 秒
Sonnet 5 表现：
- 命中 81% 的 bug（漏掉竞态条件和一个时区边界情况）
- 注意到架构问题但没说清长期危害
- 抓到了 SQL 注入
- 给重构建议但停留在高层，没有实现细节
- 成本：~$0.64/次 | 耗时：~22 秒
结论： 关键 PR（生产部署、安全敏感代码）用 Opus 5 值得——一个漏网的竞态条件到了线上损失远超省的那点钱。日常 PR（文档更新、简单功能、测试修改）用 Sonnet 5 花 $0.64 就够了。
路由规则： PR 涉及并发、安全或核心架构 → Opus 5。其余 → Sonnet 5。
场景二：多文档分析（法律合同审阅）
设置： agent 分析 15 份合同（共 400K token），找冲突条款、缺失标准条款、跨合同风险。
Opus 5 表现：
- 找到全部 8 个埋点冲突，包括两份合同对「重大违约」定义不同导致补救措施矛盾
- 生成交叉引用的风险矩阵
- 产出原创洞察：两份合同组合起来构成了无意的循环责任
- 成本：~$8.50 | 耗时：~65 秒
Sonnet 5 表现：
- 找到 8 个冲突中的 6 个（漏掉循环责任和一个定义不一致）
- 总结合理但交叉引用不够全
- 没抓到合同交互产生的新风险
- 成本：~$1.70 | 耗时：~32 秒
结论： 高风险、需要从多文档交互中综合出洞察（不是找单个文档里的问题）的任务，Opus 5 的推理深度产出质变级别的不同输出。答案不在任何单一文档中而是从它们的交互中涌现时，差距最大。
路由规则： 多文档综合 + 需要涌现洞察 → Opus 5。单文档分析或答案在文本中明确存在 → Sonnet 5。
场景三：日常 Agent 循环（客服 Agent）
设置： 客服 agent 每天处理 500 工单。每个工单要理解问题、搜内部文档、生成回复。
Opus 5 表现：
- 用户满意度：4.6/5
- 解决准确率：96%
- 回复质量：措辞略精致
- 日成本：500 × ~$0.30 = $150/天
Sonnet 5 表现：
- 用户满意度：4.5/5
- 解决准确率：94%
- 回复质量：清晰准确，略少润色
- 日成本：500 × ~$0.06 = $30/天
结论： 0.1 分的满意度差距不值得每天多花 $120（一年 $43,800）。日常 agent 工作，用户几乎分不出 Opus 5 和 Sonnet 5 的区别。
路由规则： 高频、日常、单次调用质量差异微小的 agent 循环 → Sonnet 5 完胜。
决策框架
| 任务特征 | 路由到 |
|---|---|
| 推理步骤 <10 | Sonnet 5 |
| 推理步骤 10-15 | Sonnet 5（失败时重试） |
| 推理步骤 >15 | Opus 5 |
| 单文档分析 | Sonnet 5 |
| 多文档综合 | Opus 5 |
| 需要原创洞察 | Opus 5 |
| 事实抽取 | Sonnet 5 |
| 高频循环（>100 次调用/任务） | Sonnet 5 |
| 安全关键代码审查 | Opus 5 |
| 日常代码审查 | Sonnet 5 |
| Agent 编排 | Sonnet 5 |
| 最终质量关卡 | Opus 5 |
最简心智模型：Sonnet 5 是你的主力，Opus 5 是你的专家顾问。 不是每个问题都请顾问——只在风险高或问题超出主力能力边界时请。
级联架构
最好的架构两个都用：
Agent 任务 → Sonnet 5（尝试）
→ 高置信 → 直接输出
→ 低置信或复杂 → Opus 5（验证/重做）实际运行中 80-90% 的工作走 Sonnet 5，只有 10-20% 的困难部分升级到 Opus 5。综合成本大约是纯 Sonnet 5 的 1.5-2 倍，而不是 5 倍。
SandBase 原生支持这种模式——设置 Sonnet 5 响应的置信度阈值，平台自动在需要时升级到 Opus 5。
两个都不该选的情况
- 速度最优先 — 用 Haiku 或 GPT-5.6 Terra 拿 <200ms 响应
- 成本压倒一切 — 用 Kimi K3，价格是 Sonnet 5 的一半
- 上下文超 1M — 不管选谁都要分块策略
Opus 5 完整能力拆解看 Claude Opus 5 深度分析。Sonnet 5 的 agent 主力定位看 Claude Sonnet 5 用于 Agent 和编码。
常见问题
只能选一个的话选哪个？
Sonnet 5。它以五分之一的价格处理 80-90% 的任务到接近 Opus 的质量。Opus 5 明显更好的场景（深度多文档推理、15+ 步链）在大多数生产工作负载里是少数。先用 Sonnet 5，测哪些地方翻车，再把那些路由选择性升级到 Opus 5。
5 倍价差在规模上是不是更痛？
更痛。规模上两边都能谈量价折扣，但绝对金额差距在增大。每天处理 1000 万 token：Sonnet 5 约 $180/天，Opus 5 约 $900/天。一年差 $262K。能力差距得值这个具体数字你的生意才划算。
能用 Opus 5 当 Sonnet 5 输出的判官吗？
可以，效果不错。Sonnet 5 生成，Opus 5 评估。评估调用很短（只有输出 + 评估标准），所以便宜。约 1.3 倍 Sonnet 5 的成本就能拿到 Opus 级别的质量保证，而不是 5 倍。
Sonnet 是不是每代都在追近 Opus？
历史上是的。每代 Sonnet 都在缩小和上一代 Opus 的差距。但每代新 Opus 也在推高天花板。差距不会消失——只是转移到更难的问题上。决策框架不变：按任务复杂度匹配模型。
对延迟敏感的场景呢？
Sonnet 5 在所有上下文长度上都比 Opus 5 快近 2 倍。面向用户或有时间限制的 agent 循环，Sonnet 5 的速度优势在多次调用中累积。20 次调用的 agent 循环：Sonnet 5 约 24 秒，Opus 5 约 42 秒。
