读见

AINLP文章中文

Claude Sonnet 5.5 发布：干活更快，单价不变

约 10 分钟约 2,290 字

读前速览

5 个要点

Anthropic 发布 Claude Sonnet 5.5，API 单价不变但生成速度提升 30% 以上、单任务成本最多降低 30%，低 effort 档位即可超越上代最高档，同时官方建议重新评估 effort 档位以避免过度推理。

  1. Sonnet 5.5 的核心卖点是低档位效率跃升，而非刷新最高分

    CursorBench 4.0 中 Sonnet 5.5 Low 得分 35.8%、成本 0.50 美元，已略高于 Sonnet 5 Max 的 34.1%、7.17 美元，平均步骤从 140 降到 18；对每天反复读代码、改代码、跑工具的工作流，这种变化比单独刷新最高分更有用。

  2. effort 越高收益递减，跨模型比较中高档位比一路推到 Max 更划算

    Sonnet 5.5 从 Xhigh 到 Max，得分仅从 53.1% 升到 55.5%，费用却从 3.88 美元涨到 9.67 美元；同一张表里 Opus 5.5 High 得分接近 Sonnet 5.5 Max，花费不到后者一半。

  3. 效率提升来自更短的行动链和更常合并的工具调用

    Sonnet 5.5 比 Sonnet 5 更常把可并行获取信息的工具调用合在一起执行，交互链缩短、需携带的历史减少；Base44 的 118 次应用构建测试中，Sonnet 5.5 平均 3.6 轮迭代，Opus 5 用了 7.7 轮，成品评分相当。

  4. 把 effort 拉满可能做过头，反而降低任务完成质量

    FrontierCode 评估代码修改能否不经人工改动就合并并惩罚超范围修改，Sonnet 5.5 Xhigh 得分 52.1%，Max 反而 46.2%；原因是 Max 更常触发 Claude Code 的 code-review skill，把检查拆给多个子 Agent，在 Cognition 检查的两个案例中导致超时或任务范围外的额外修改。

  5. 官方建议重新评估 effort 档位，同名档位不代表与上代相同的推理量

    迁移指南建议较明确的编程和多步工具任务从 Medium 开始，更难或更长的任务再用 High；Claude Code 和应用默认 Medium，Claude API 默认 High。此外原用 thinking: {"type": "disabled"} 关闭推理的请求需改为 between_tools。

完整摘要

Anthropic 发布 Claude 5.5 家族第二款模型 Sonnet 5.5，面向日常编程、修 bug 及文档、幻灯片、表格等工作。官方称输出生成速度提升 30% 以上，多数任务单任务成本最多降低 30%，API 单价维持每百万输入 token 2 美元、输出 token 10 美元不变。文章引用 CursorBench 4.0 数据说明：Sonnet 5.5 在 Low effort 下得分 35.8%、成本 0.50 美元，已略高于 Sonnet 5 Max 的 34.1%、7.17 美元，平均步骤从 140 降到 18；但 Xhigh 到 Max 得分仅从 53.1% 升到 55.5%，成本却从 3.88 美元涨到 9.67 美元，而 Opus 5.5 High 以不到一半花费取得接近 Sonnet 5.5 Max 的得分。文章还分析了效率来源（更常合并工具调用、缩短行动链）、effort 拉满可能做过头（FrontierCode 上 Xhigh 52.1% 反超 Max 46.2%，因 code-review skill 触发子 Agent 导致超时或超范围修改），以及 GDPval-AA 办公设计评测表现和 API 迁移注意事项。

目录 · 5 节

今天凌晨，Anthropic 发布了 Claude Sonnet 5.5。这是 Claude 5.5 家族的第二款模型，接在上周发布的 Opus 5.5 之后，面向日常编程、修复 bug，以及文档、幻灯片和表格等工作。

相较 Sonnet 5，官方称它的输出生成速度提升了 30% 以上，多数工作的单任务成本最多降低 30%。API 单价保持不变：每百万输入 token 2 美元、输出 token 10 美元。节省来自完成任务时用得更少。

这次值得关注的，是低档位能完成的工作明显变多了。Cursor 的编程评测里，Sonnet 5.5 在 Low effort 下，表中得分就超过了 Sonnet 5 的最高档，成本不到后者的十分之一。对每天反复读代码、改代码、跑工具的工作流，这种变化比单独刷新最高分更有用。

先看一项任务花多少钱

CursorBench 4.0 的任务来自真实 Cursor 会话，包含需求不完全明确、需要跨多个文件处理的工作。它的公开榜单同时列出得分、平均成本、token 和步骤数，能看见模型为了交付结果付出了多少。

几组有代表性的结果如下。成本是按输入、缓存读写和输出的公开费率折算出的平均每任务费用：

模型

effort

得分

成本

Sonnet 5

Max

34.1%

$7.17

Sonnet 5.5

Low

35.8%

$0.50

Sonnet 5.5

Medium

39.2%

$0.70

Sonnet 5.5

Xhigh

53.1%

$3.88

Sonnet 5.5

Max

55.5%

$9.67

Opus 5.5

High

56.0%

$3.97

最直观的一组是 Sonnet 5 Max 与 Sonnet 5.5 Low：平均步骤从 140 降到 18，费用从 7.17 美元降到 0.50 美元，表中得分还略高一些。新模型不需要用上一代那么长的行动链，便能达到相近的结果。

往上加 effort，质量仍有收益，但成本也会迅速增加。Sonnet 5.5 从 Xhigh 到 Max，得分从 53.1% 到 55.5%，费用却从 3.88 美元到 9.67 美元。同一张表里，Opus 5.5 High 得分接近 Sonnet 5.5 Max，花费不到后者的一半。

这些是 Cursor 这套任务和运行环境中的结果，小分差未必具有统计意义。它们提供了一个很实际的选择：需要更多推理时，也值得比较另一款模型的中高档位，而不只是把当前模型一路推到 Max。

CursorBench 4.0 成本曲线：纵轴是得分，横轴是每任务成本，使用对数刻度。

CursorBench 4.0 成本曲线：纵轴是得分，横轴是每任务成本，使用对数刻度。

这也解释了 Sonnet 与 Opus 在新一代里的分工。日常任务已经能在较低 effort 下完成，Sonnet 的效率优势更容易兑现；任务越开放、越依赖持续判断，Opus 仍有它的位置。

少走步骤，怎样变成效率

Agent 的一次任务，可能要经历搜索代码、读文件、修改、运行测试，再继续检查结果。每次工具调用都要等待返回，在保留完整历史的工作流里，新的结果和此前的对话还要进入下一次模型请求。一步一步串行执行，消耗的不只有输出 token。

Anthropic 收到的早期使用反馈中，有一个具体变化：Sonnet 5.5 比 Sonnet 5 更常把工具调用合在一起执行。可以同时获得的信息不必拆成多轮，交互链缩短，后续需要携带的历史也随之减少。哪些步骤能合并仍取决于任务依赖；例如测试必须等代码修改完成，便不能提前运行。

这类效率也体现在实际产品方的观察里。Base44 测试覆盖了 118 次应用构建：Sonnet 5.5 平均用了 3.6 轮迭代，Opus 5 用了 7.7 轮，成品评分相当。这是 Base44 的早期测试记录，对照的是 Opus 5，展示的是应用构建过程中的收益。

更快的输出生成，加上更短的行动链，能够减少等待。Cursor 表里的步骤数则补充了另一个视角：模型到达结果的路径也变短了。

把 effort 拉满，也可能做过头

Sonnet 5.5 的能力确实提高了。官方 Terminal-Bench 4.0 对照中，它从 Sonnet 5 的 10.3% 提升到 70.6%；这项评测要求 Agent 在命令行环境中完成复杂的多步骤任务。

但一项任务的好结果，还包括遵守范围。FrontierCode 评估代码修改能否不经人工改动就合并，会惩罚超出需求的修改。在这项评测里，Sonnet 5.5 的 Xhigh 得分为 52.1%，Max 反而是 46.2%。

Claude 给出了一个具体过程：Max 档位更常触发 Claude Code 的 code-review skill，把检查拆给多个子 Agent。在 Cognition 检查的两个案例里，这导致了超时，或者带来了任务范围之外的额外修改。

多做检查原本是为了提高质量，可检查链条本身也要服从当前任务。修一个明确的 bug，和重新审视整个模块，完成标准并不相同。这两个案例说明了最高档位分数下降的一条路径，并没有给所有任务规定同一个最佳档位。

官方迁移指南因此建议重新评估 effort：较明确的编程和多步工具任务，可以从 Medium 开始，更难或更长的任务再用 High。各档位已经重新校准，同名档位不代表与 Sonnet 5 投入相同的推理量。Claude Code 和应用默认是 Medium，Claude API 默认是 High。

办公和设计也有进步

在面向不同职业任务的 GDPval-AA 评测里，Sonnet 5.5 的评分是 1844，Opus 5.5 是 1846，两者接近。它的用途也扩展到需要整理资料、理解图表、遵循版式并交付完整文件的工作。

官方演示里，还有一个很容易看懂的小作品：让模型用单个 HTML 文件，做出由 24 个小钟组成的大钟。下面是 Sonnet 5.5 的演示成品截图；页面上的时间和 token 是这一次演示的记录。

单文件页面演示：24 个小钟的指针组合成数字时钟。

单文件页面演示：24 个小钟的指针组合成数字时钟。

这类工作往往要来回调整布局、内容和交互。生成速度快，意味着修改后能更快看到下一版；模型能按要求做出较完整的成品，则减少了人接手补齐的工作。对日常协作，两种改进都直接影响使用体验。

Sonnet 5.5 已可通过 Claude API 使用，模型 ID 是 claude-sonnet-5-5，也已接入 AWS、Google Cloud 和 Microsoft Azure。它支持 1M token 上下文、标准最大输出 128K token，缓存读取价格为每百万 token 0.20 美元。

已有 API 工作流需要留意一个变化：原先用 thinking: {"type": "disabled"} 关闭推理的请求，在 Sonnet 5.5 上要改成 between_tools。这个模式关闭请求开头的推理，工具间仍可保留过程更新，支持 High 及以下 effort。其他接口迁移细节放在文末指南里。

参考链接

值得记下

需要更多推理时，也值得比较另一款模型的中高档位，而不只是把当前模型一路推到 Max。
新模型不需要用上一代那么长的行动链，便能达到相近的结果。
多做检查原本是为了提高质量，可检查链条本身也要服从当前任务。
各档位已经重新校准，同名档位不代表与 Sonnet 5 投入相同的推理量。
在 AINLP 查看原文