Claude Sonnet 5.5 发布：70.6% 基准测试得分对阵不变的价格表

Anthropic 发布了 Claude Sonnet 5.5，据称其在 Terminal-Bench 4.0 中取得 70.6% 的分数，同时维持已公布的 Sonnet token 价格不变。

这种组合才是真正的重点。Anthropic 并未要求开发者为这款更新后的日常模型支付更高的单 token 费用。该公司还表示，模型生成输出的速度提升超过 30%，且在许多任务中消耗更少 token。

官方发布公告将这一 70.6% 的结果与 Sonnet 5 的 10.3% 进行比较。公告还显示，在同一基准测试中，Sonnet 5.5 高于该公司公布的 Opus 5.5 的 66.4% 成绩。

这些数字让 Claude Sonnet 5.5 的发布看起来不只是一次常规模型更新。它正在挑战传统的产品划分：一边是快速的默认模型，另一边是仅为高难度工作保留的高端模型。

不过，这个醒目的结果仍需结合背景来理解。基准测试配置、推理力度、智能体脚手架、回退机制和 token 使用量，都可能显著改变得分与运营成本。

独立测试已经呈现出比 Anthropic 发布图表更复杂的情况。Sonnet 5.5 看起来极具竞争力，但其最佳成绩并不必然意味着它是最便宜的生产部署选择。

Claude Sonnet 5.5 的发布改变了默认模型的选择逻辑

Anthropic 将 Sonnet 5.5 定位为团队可默认使用的模型，而非 Opus 的受限替代品。

该模型于 2026 年 9 月 28 日在 Anthropic 的应用和开发者平台上线。Anthropic 还表示，它可通过 Amazon Web Services、Google Cloud 和 Microsoft Azure 使用。

此次发布面向范围明确的编程、修复 bug、文档创建、演示文稿、电子表格及日常智能体工作流。Anthropic 仍将 Opus 5.5 定位于需要持续判断的开放式工作。

这一差异很重要，因为许多业务工作负载更接近 Sonnet 所覆盖的类别。支持回复、代码审查、文档修订或结构化分析，很少需要在每次请求中都启用最高级别的推理能力。

Anthropic 称，Sonnet 5.5 的输出速度比 Sonnet 5 快超过 30%。该公司还表示，尽管公布的 token 价格不变，该模型仍可降低任务总成本。

这一说法取决于任务效率。如果模型使用更少的 token、工具调用或重试次数，即使价格表不变，其每项完成任务的成本也可能更低。

Anthropic 提供了若干早期客户案例来支持这一论点。Slack 报告称，在其离线 Slackbot 评估中，输出 token 数量减少约 14%，且没有更改提示词。

Zendesk 报告称，在其测试中，支持工单的处理速度提升了 20%。Atlassian 表示，其 Rovo 智能体的运行速度最高可比使用 Sonnet 5 时快 30%。

Balyasny Asset Management 在 2,441 项私有金融任务上测试了该模型。该公司称，在分析、提取、预测和检索工作中，模型每个答案的 token 使用量显著低于 Sonnet 5。

这些是公司自行挑选的发布案例，并非覆盖所有工作负载的受控比较。不过，它们说明了 Anthropic 希望买方衡量的内容：完成的工作，而非孤立的 token 价格。

因此，实际变化远不止一项基准测试分数。评估该模型的团队必须同时比较延迟、成功率、重试次数、工具调用和审查时间。

一款能更快且正确完成更多任务的模型，可能改变队列容量和用户体验。它也可能减少人工纠正不完整工作所需的投入。

此次发布包含新的模型标识符 claude-sonnet-5-5。在某些配置下，从 Sonnet 5 迁移的开发者需要更新的不只是这一标识符。

Anthropic 的迁移指南记录了涉及 thinking 设置、强制工具选择、内容块和 computer-use 工具的变化。一些旧有请求模式会返回错误。

例如，当开发者省略相关字段时，thinking 会默认运行。因此，假定首个返回块始终包含普通文本的应用程序可能会失效。

该模型还在支持的 effort 级别中，以 between_tools 设置取代禁用的前置 thinking。对于围绕低延迟响应或可预测推理预算设计的应用，这一行为很重要。

这些兼容性细节使“零成本升级”的说法变得复杂。公布的价格可能保持不变，但迁移工作和评估时间仍会带来运营成本。

这就是为什么团队应将 Sonnet 5.5 视为新的运行时环境，而不只是同一 API 合约背后更好的检查点。

70.6% 的 Terminal-Bench 得分对 Sonnet 之上的产品形成压力

令人意外的比较并非 Sonnet 5.5 与前代产品之间，而是 Sonnet 5.5 与 Anthropic 的高端 Opus 产品线之间。

Terminal-Bench 评估通过命令行界面工作的智能体。任务要求模型检查环境、使用工具、修改产物，并完成多步骤目标。

4.0 版本包含 66 项由社区贡献者提交、维护者审核的任务。其类别涵盖软件、科学、机器学习、运营、硬件、安全和媒体。

基准测试方法论强调最终产物，而非具有说服力的解释。只有当智能体的工作通过评分器时才会获得积分，而不是其回答听起来似乎合理时。

Anthropic 报告称，Sonnet 5.5 的成绩为 70.6%，Sonnet 5 为 10.3%。该公司称，Opus 5.5 在该模型接受评估的最高 effort 下取得 66.4%。

两代 Sonnet 之间的差距异常之大。这表明，Anthropic 的智能体编程栈中发生的变化不只是语言质量的渐进提升。

这一结果也在这项特定测试中颠覆了预期的产品层级。据称，成本更低的产品系列成员在复杂终端工作中超过了 Anthropic 的高端模型。

这并不意味着 Sonnet 5.5 在所有情况下都优于 Opus 5.5。Anthropic 明确表示，Opus 在需要持续判断的复杂开放式任务中仍然更强。

其他公开评估也支持这一限定。在 CursorBench 4.0 上，Sonnet 5.5 得分为 55.5%，而 Opus 5.5 得分为 57.8%。

在评估职业任务的 GDPval-AA v2.1 上，Sonnet 5.5 和 Opus 5.5 的公布得分分别为 1,844 和 1,846。两款模型在该测试中几乎持平。

FrontierCode 给出了另一项好坏参半的结果。Sonnet 5.5 在一个 effort 设置下达到 52.1%，而 Opus 5.5 得分为 54.4%。

综合来看，这些结果描述的是一种更狭义的反转。当任务具有明确目标、可用工具和可验证的完成条件时，Sonnet 5.5 的表现似乎尤其强劲。

当成功取决于模糊判断、更广泛的规划，或在开放式任务中持续维持质量时，Opus 仍保有优势。

对开发者而言，这种差异鼓励采用模型路由。系统可以将常规实施和边界明确的智能体任务交给 Sonnet，同时为架构设计或困难升级情形保留 Opus。

Anthropic 的发布材料提供了这种分工的一个例子。一位创作者描述了如何使用 Opus 建立游戏架构，再让 Sonnet 5.5 负责实现。

这种模型搭配比单纯的排行榜胜利更重要。它表明，高端推理与高吞吐执行可能会成为同一工作流中彼此独立的阶段。

同样的模式也适用于文档与知识工作。高端模型可以定义分析计划，而 Sonnet 则负责提取、起草、修订和格式化。

已经在构建工程知识库的团队，可以根据代码库文档和审查记录测试这一结构。他们自身已接受的输出比通用排名更重要。

如果 Sonnet 5.5 能持续处理执行阶段，Opus 将面临来自 Anthropic 自身产品家族内部的压力。开发者会问，为何每项看似困难的任务都需要高端模型。

当成本更低的模型响应也更快时，这个问题尤其重要。延迟往往决定用户是否愿意在交互式编程循环中容忍智能体。

基准测试的跃升反映了更好的智能体循环，而不只是更好的回答

Claude Sonnet 5.5 的基准测试结果表明其工具使用效率更高，但 Anthropic 尚未将整体提升归因于某一个单独因素。

智能体基准测试衡量的是一个组合系统。底层模型固然重要，但提示词、工具、推理力度、上下文管理、时间限制和回退行为同样重要。

Anthropic 称，早期测试者观察到更少的步骤和更多批量工具调用。Lovable 报告称，在其内部编程评估中，shell 运行次数约减少一半，工具调用约减少三分之一。

CodeRabbit 也报告称，Sonnet 5.5 使用了更少的输出 token，并在不同复杂度任务中展现出更好的判断力。它指出，与 Sonnet 5 相比，该模型减少了不必要的网页搜索。

这些观察为 Terminal-Bench 的提升提供了一种合理机制。探索更少且更有目标的智能体，能够为改变最终产物的行动保留时间和上下文。

工具效率同样影响可靠性。每一次 shell 命令、浏览器操作或外部请求，都会增加失败、延迟或输出格式错误的机会。

因此，选择更短且有效路径的模型，可以在不显著提升文稿质量的情况下提高完成率。终端工作正是奖励这种纪律性。

Anthropic 为 Sonnet 5.5 增加了五个 effort 级别。该设置控制模型在操作之前或操作之间进行推理和检查工作的时长。

更高的 effort 可以改善困难任务的表现，但也会消耗更多 token 和时间。Anthropic 建议团队评估多个设置，而不是直接沿用对 Sonnet 5 的旧有假设。

这一建议很容易被忽视。基准测试的最佳结果通常反映了经过刻意选择的配置，而生产系统往往采用默认设置或成本受控设置。

发布图表中的 70.6% 数据是在 Anthropic 的评估框架内得出的。独立评估者在改变测试框架或 effort 级别时，可能获得不同结果。

例如，Artificial Analysis 在其自身的 Terminal-Bench 4.0 测试中报告了 64%。其独立评估将 Sonnet 5.5 列为领先模型之一，但强调其在最高 effort 下的 token 使用量很高。

该机构发现，在其测量过的所有模型中，Sonnet 5.5 在每项 Intelligence Index 任务中消耗的输出 token 最多。这一结果挑战了简单的效率叙事。

两项发现之间并不存在必然矛盾。Sonnet 5.5 可以在较低设置下高效运行，而在被推向其最高测量能力时消耗大量 token。

价格与总消耗量之间的区别至关重要。当模型进行更长时间的推理时，不变的价格表并不保证账单不变。

Anthropic 表示，在多项评估中，低或中等 effort 可以用 Sonnet 5 最佳得分的一小部分已完成任务成本取得更好成绩。独立测试表明，最高 effort 具有不同的特征。

因此，生产环境买方应评估一条曲线，而非单一数据点。有用的比较应绘制任务成功率与延迟、token、重试次数和人工审查之间的关系。

开发团队可以先选取一组具有代表性的代码库任务。这些任务应涵盖 Bug 修复、重构、测试创建、依赖项变更，以及对陌生代码的导航。

每次运行都应使用相同的环境和验收检查。评审人员应记录补丁是否有效、是否保持在范围内，以及是否需要人工修正。

测试还应统计失败的工具调用次数和耗时。这些指标能够揭示更高的榜单分数是否真正转化为更好的开发循环。

团队应在多个努力级别下重复这一练习。如果中等努力即可完成大多数常规工作，最高努力可能会增加成本，却无法带来足够的额外价值。

同一产品内部的最佳配置也可能不同。快速交互式助手所需的设置，与需要进行广泛验证的夜间迁移代理并不相同。

这正是此次发布背后的核心机制。Anthropic 正在让开发者更能控制 Sonnet 投入多少计算资源，同时声称在这一范围内都能获得更好的结果。

这些数字尚未说明的问题

作为已披露的结果，基准测试的亮眼成绩具有可信度，但它本身无法证明生产环境的可靠性或普遍的成本节省。

第一个限制是配置敏感性。Anthropic 的 70.6% 得分和 Artificial Analysis 的 64% 得分都针对 Sonnet 5.5，但它们来自不同的评估设置。

第二个限制是回退行为。一些评估系统可以在预设条件下，将被拒绝或不受支持的请求路由至另一款模型。

Artificial Analysis 在少量任务中观察到了回退。Vals 也将供应商侧回退列为可能影响排行榜解读的因素。

回退本身并非不当行为。它可能代表客户实际获得的产品行为，尤其是在供应商通过路由维持安全性或可用性时。

不过，借助回退获得的结果回答的是与纯模型结果不同的问题。买方应明确自己评估的是模型、供应商网关，还是完整的托管代理。

第三个限制涉及基准饱和。70.6% 的得分仍留下了显著的失败空间，但也削弱了该基准区分未来模型的能力。

当领先系统能够完成大多数任务时，困难的边缘案例就变得更加重要。微小的提示词或测试框架改动，也可能改变排名，却未必会改变普通用户体验。

Terminal-Bench 仍然有价值，因为其任务要求真实操作并生成可验证的产物。尽管如此，没有任何单一基准能代表每种代码库、工具链、安全策略或审批流程。

第四个限制是总资源消耗。Artificial Analysis 发现，Sonnet 5.5 的最高努力配置在每项 Intelligence Index 任务中使用约 193,000 个输出 token。

这一测量并不描述每一个请求。但它说明，团队不应仅根据公开的 token 单价来推断完成任务的成本。

在最高努力级别下，Artificial Analysis 发现 Sonnet 5.5 并不位于其比较中的最高效前沿。其他配置则提供了不同的平衡。

第五个限制涉及安全行为。Anthropic 表示，Sonnet 5.5 是其首个发布时便配备与最强模型类似网络安全防护措施的 Sonnet 模型。

高风险网络安全请求可能会回退至 Sonnet 5。该模型还包含旨在阻止提取其推理过程尝试的分类器。

这些防护措施是对更强能力的回应，但也可能带来新的拒答模式。合法的安全工作流在迁移后可能表现不同。

因此，网络安全防护措施既是一项安全措施，也是一个运营变量。安全团队需要覆盖获授权防御性工作的评估案例。

第六个限制是发布合作伙伴的选择。Anthropic 的客户证言提供了具体数据，但该公司选择了在公告中展示哪些案例。

Slack、Zendesk、Box、Lovable、Atlassian 及其他合作伙伴测试了对其重要的工作负载。这些结果并不能证明无关应用也能获得同样的收益。

金融检索系统、编码代理和客户支持工作流对模型提出的要求不同。它们对可接受错误的标准也不同。

团队应使用自己的数据和评分器复现这些声称的改进。如果一个模型节省了 token，却增加了评审时间，那么整体工作流并未得到改善。

反过来也可能成立。若一个模型消耗更多 token，却能避免失败、减少重试，或完成此前必须升级处理的工作，它仍可能具备经济性。

因此，最有力的解读仍然是有条件的。Sonnet 5.5 似乎推动了能力与成本之间的边界，尤其是在边界明确的代理工作中。

此次发布并未消除对 Opus、自定义评估或人工审查的需求。它让何时使用每一种方案的决策变得更加重要。

三个信号将显示 Sonnet 5.5 是否改变市场

下一项检验是，开发者是否能在常规努力级别下复现 Anthropic 的结果，并将真实工作负载从高端模型迁移出去。

第一个信号是独立基准复现。评估方应公布努力设置、测试框架细节、回退次数、token 消耗和任务级失败情况。

若复现结果接近 Anthropic 的得分，将加强 Sonnet 5.5 代表重大代理能力提升的说法。若差异很大，配置将成为更重要的故事。

70.6% 与 64% 的差距已经说明了披露为何重要。这两个分数都表明性能强劲，但它们暗示了与竞争系统不同的比较结果。

第二个信号是生产路由。关注编码工具和企业平台是否会将 Sonnet 5.5 作为常规代理的默认模型。

默认位置比可选可用性更重要。它揭示供应商是否信任该模型的延迟、可靠性、拒答行为和完成任务的经济性。

如果实施工作从 Opus 转向 Sonnet，将支持 Anthropic 的产品战略。有限的采用则意味着高端推理仍提供关键可靠性。

早期客户证言表明，更可能发生的是路由调整，而非全面替换。CodeRabbit 计划先迁移较简单和中等难度的评审，再根据结果扩大范围。

这种做法是合理的。它将模型选择视为一项运营策略，而非品牌偏好。

第三个信号是不同努力级别下的完成任务成本。买方应关注包括输出 token、工具调用、重试、延迟和评审人员介入在内的测量结果。

如果中等努力保留了大部分基准增益，Sonnet 5.5 将更有理由成为高吞吐量场景的默认选择。如果日常都需要最高努力，其经济优势就会变窄。

开发者还必须监控迁移错误。新的思考行为、工具选择规则、安全回退和内容块处理方式都可能影响现有集成。

Anthropic 的文档建议团队重新运行努力级别测试，并重新建立成本基线。这项指引比未变化的价目表更重要。

Claude Sonnet 5.5 的发布最终挑战了一个熟悉的假设：对于严肃的代理工作，高端模型始终是更安全的选择。

Anthropic 自身的结果显示，Sonnet 在一项重要的终端基准上领先于 Opus。其他测试仍更倾向于 Opus，尤其是在需要持续判断的场景中。

这形成了更清晰的分工。Sonnet 5.5 可以处理快速、边界明确的执行任务，而 Opus 仍是处理模糊决策时的升级路径。

市场影响将取决于这种分工能否经受真实代码库、文档、支持队列和安全控制的检验。

评估 Claude Sonnet 5.5 的团队应从完成的任务开始，而不是孤立的提示词。建立固定测试集，运行多个努力级别，并记录每一次重试。

将该模型与 Sonnet 5 及生产环境中已使用的高端替代方案进行比较。纳入迁移工作、评审时间、拒答和失败的工具调用。

然后提出真正重要的问题：Claude Sonnet 5.5 能否以足够的可靠性完成足够多的真实工作，从而成为你的新默认选择？