Anthropic 发布 Claude Opus 5 时，最值得注意的不是它又拿下了多少评测第一，而是它给高端模型换了一种更接近生产环境的定价方式：不再只比较每百万 token 的价格，而是比较完成一项任务到底要花多少钱。官方将它定位为接近 Claude Fable 5 能力、但单项任务成本约为一半的日常高性能模型。这意味着旗舰能力正在从少数高难任务的“升级选项”，变成可以进入常规工作流的候选默认模型。
Opus 5 卖的不是更便宜的 token
Opus 5 的 API 价格维持在每百万输入 token 5 美元、输出 token 25 美元，与上一代 Opus 4.8 相同。真正变化的是同样预算下的任务通过率。Anthropic 公布的结果显示，在 CursorBench 上，Opus 5 的最高表现与 Fable 5 峰值相差不到 0.5%，但单项任务成本约为后者一半；在 Zapier AutomationBench 上，它以相同任务成本获得约为次优模型 1.5 倍的通过率；在 OSWorld 2.0 上，它用略高于 Fable 5 三分之一的成本超过了后者的最佳结果。
这些数字仍然主要来自厂商评测，不能直接替代企业自己的测试。但它们揭示的采购逻辑是成立的：token 单价只是成本的一部分。一个模型如果能少走几轮工具调用、更早发现根因、在交付前主动验证结果，即使账面单价更高，完成一次任务的总成本也可能更低。
“先验证，再交付”开始成为模型能力
Opus 5 的发布材料反复强调自检行为。它会为没有现成数据源的程序建立测试 harness，会在桌面和移动端分别检查页面，也更倾向于修复根因而不是只处理表面症状。多家早期用户报告的共同点不是输出更长，而是工具调用和返工更少、任务波动更低。
这会改变 coding agent、研究 agent 和办公自动化产品的验收方式。过去团队常用“回答是否正确”评价模型；现在更需要检查它是否留下可复现的测试、是否引用了可追溯来源、是否在交付前覆盖关键边界条件。验证动作本身，正在从外部工作流补丁变成模型竞争力的一部分。
模型、训练环境和交付系统正在合并
与 Opus 5 同期出现的几项基础设施进展，也在支撑同一变化。OpenForgeRL 尝试直接训练 Claude Code、Codex 等真实 harness 中的 Agent，而不是把工具轨迹压回单轮问答；NVIDIA ModelExpress 把权重和 JIT 缓存从已有 GPU 直接分发给新副本，压缩大模型扩容时的等待；AMD ROCm.ai 则计划把硬件安装、诊断和性能优化包装成可由 Claude、Cursor、Codex 调用的 Skills。
这些工作说明，模型的有效能力越来越依赖它所在的系统。训练时是否保留真实工具协议，部署时能否快速拉起模型副本，硬件知识是否能被 Agent 直接调用，都会影响最终的任务成功率和成本。单独比较模型分数，正在失去解释力。
团队应该怎样评估 Opus 5
对正在使用 Claude Code 或多模型 Agent 平台的团队，合理做法不是立即全量迁移，而是建立一组真实任务做对照测试。至少应记录五类数据：一次成功任务的总费用、墙钟时间、工具调用次数、人工接管次数，以及最终交付物是否通过独立验证。代码任务还应区分简单修改、跨模块重构和难定位故障，因为新模型的优势往往集中在更长、更模糊的任务上。
我的判断是，Opus 5 的行业意义不在于把“最强模型”榜单再刷新一次，而在于把前沿能力带进了日常任务的成本讨论。真正受影响的会是模型路由、Agent 采购和工程验收：默认模型不再由 token 单价决定，而由单位成功任务成本决定。厂商若想证明模型值得替换，也必须拿出更完整的证据，包括成功率、调用轮数、时间、返工和验证质量，而不只是几张 benchmark 图。
参考来源：Anthropic：Claude Opus 5、OpenForgeRL、NVIDIA ModelExpress、AMD ROCm.ai