Claude Sonnet 5.5：Agent 编程默认档位变了（速度、成本与 CursorBench）

Anthropic 于 2026-09-28 发布 Claude Sonnet 5.5，这是 Claude 5.5 家族的第二款模型（紧随 Opus 5.5）。对日常写代码、修 Bug、跑多 Agent 循环的开发者来说，真正值得关注的不是又一张榜单，而是：在同等单价下，任务级成本更低、输出更快，且在 CursorBench / Terminal-Bench 等 Agent 编程评测上逼近甚至局部超过更高档位。对 Java / Spring 团队而言，这意味着 Claude Code、Cursor 与 Spring AI 里的「默认模型」档位可能要重新划线。

平台侧的模型 ID 为 claude-sonnet-5-5（Amazon Bedrock 为 anthropic.claude-sonnet-5-5）。本文事实均以 Anthropic 官方公告与模型文档为准。

为什么说「默认档位」变了

Sonnet 5.5 的定位很明确：它是 Opus 5.5 的更快、更省钱的互补。Opus 仍被 Anthropic 强调为复杂、开放式、需要持续判断力的工作更强；Sonnet 5.5 则在边界清晰的日常任务、修 Bug、写文档 / 幻灯片 / 表格，以及设计感与协作体验上更突出。

关键变化可以压成四句话：

• 单价不变，任务更便宜：输入 / 输出仍为 $2 / $10（每百万 token，与 Sonnet 5 相同；缓存读 $0.20），但 Anthropic 称多数工作单任务成本最高可低约 30%（因同任务更少 token）。
• 更快：输出速度相对 Sonnet 5 约快 30%+，是迄今最快的 Sonnet。
• Agent 编程信号大幅上扬：Terminal-Bench 4.0 70.6%（Sonnet 5 仅 10.3%）；CursorBench 4.0 55.5%（Opus 5.5 为 57.8%，差距约两个百分点）。
• 安全与迁移门槛：这是第一款以接近 Opus 档位的网络安全防护上线的 Sonnet；关闭「前置 thinking」需迁到 between_tools，并注意 distillation / preserved-thinking 相关约束。

对「每天都在循环里烧 token」的 Agent 编程场景，这些数字直接对应默认模型该不该换。

Agent 信号：Terminal-Bench、CursorBench 与 FrontierCode

官方对比表（节选，完整表见 公告页）：

评测	Sonnet 5.5	Sonnet 5	Opus 5.5
Terminal-Bench 4.0（Agent 编码）	70.6%	10.3%	66.4%¹
CursorBench 4.0（真实 Cursor 会话任务）	55.5%	34.1%	57.8%
FrontierCode 1.1 Main	46.2% Max / 52.1% Xhigh	42.4%	54.4%

¹ Opus 的 Terminal-Bench 数字按官方脚注为 Xhigh 努力档下的最高分。

如何读这些数：

• Terminal-Bench 4.0 测的是命令行环境中复杂、多步专业任务。Sonnet 5.5 从 10.3% 跳到 70.6%，对 Claude Code 一类「在终端里干活」的 Agent 体验是断档式提升。Anthropic 还强调：在 Medium 努力档（Claude 应用默认），Sonnet 5.5 已远超 Sonnet 5 的最佳成绩，且单任务成本可显著更低。
• CursorBench 4.0 来自真实 Cursor 会话中的模糊、多文件任务。55.5% 仅比 Opus 5.5 的 57.8% 低约 2 分，这是「日常 IDE Agent 默认用谁」的关键信号——很多团队会据此把日常实现与迭代切到 5.5。
• FrontierCode 关注「改动是否可 merge」。注意 Max 与 Xhigh 并不线性：Sonnet 5.5 在 Xhigh 为 52.1%，Max 反而为 46.2%。官方脚注解释，Max 下更容易触发多子 Agent 的代码审查技能，偶发超时或越界编辑导致扣分。调 effort 时不要默认「越高越好」。

努力档（effort）是成本—质量旋钮：Claude Code / 应用默认多为 Medium，Claude Platform / API 默认多为 High。低档更快、更省；高档更长推理、更仔细自检。多 Agent 流水线里，日常实现用 Medium、关键审查再升 High / Xhigh，往往比全程顶格更划算。

价格、速度与多 Agent 成本运营

清单价对照（每百万 token）：

	Sonnet 5.5	Opus 5.5
输入	$2	$4
输出	$10	$20
缓存读	$0.20	$0.20
缓存写（5 分钟档）	$2.50	$5

只看单价，Sonnet 是 Opus 的一半；再叠加「同任务更少 token + 输出更快」，多 Agent 循环（规划 → 实现 → 自审 → 修失败工具调用）的账单差异会放大。早期测试方还提到：工具调用更会批处理、步数更少、失败工具调用更少——这些对「循环次数 × 单次 token」的成本结构同样敏感。

实务建议：

1. 把「默认实现 Agent」和「架构 / 裁决 Agent」拆开计费：前者用 claude-sonnet-5-5 + Medium/High；后者保留 Opus 5.5。
2. 缓存与批处理：长系统提示、仓库摘要、工具 schema 尽量走 prompt cache；离线评测 / 批量任务走 Batch（官方文档称 Batch 对输入输出有折扣）。
3. 按任务设 effort，而不是全局 Max：Cursor / Claude Code 里对小修用低档，对模糊多文件任务再升档；避免在 FrontierCode 类「忌越界」场景盲目 Max。
4. 观测单任务成本，而不是只盯单价：Anthropic 反复强调的是 cost per task；你们自己的 Agent 日志也应按「一次 PR / 一次 Ticket」汇总 token。

安全与迁移：网络防护、蒸馏防护与 between_tools

网络安全：Sonnet 5.5 的网络相关能力相对 Sonnet 5 提升很大，因此是第一款以接近 Opus 档位的网络安全防护与回退机制上线的 Sonnet。常规软件开发、找 Bug / 修 Bug 仍可用；更高风险的网络安全请求会可见地回退到 Sonnet 5。防御方后续可通过 Cyber Verification Program 申请分级访问。

蒸馏（distillation）与 preserved-thinking：因能力跃升，它也是第一款上线防推理抽取安全分类器的 Sonnet，并扩展了 preserved-thinking——思考内容与创建会话绑定，难以被解耦挪用。多数开发者无感；但若在 Claude Code 等场景中中途换账号、跨账号搬会话，需阅读官方文档中的变更说明。

Thinking 关闭方式变更：若你之前对 Sonnet「关闭 thinking」，升到 5.5 必须改用新的 between_tools（关闭前置 thinking，工具调用之间仍可有简短进度类 thinking 块）。直接传旧的 disabled 会 400。要点：

• 平台默认多为自适应 thinking；要「前置不思考」请显式 thinking: {"type": "between_tools"}。
• between_tools 在 low / medium / high 可用；xhigh / max 下会报错，需改用 adaptive。
• 须把带 signature 的 thinking 块原样回传；会话宜保持 append-only，避免编辑历史后再回放 thinking 块触发绑定校验失败。

完整迁移说明见 Anthropic 的 Sonnet 5.5 Migration Guide（从 模型概览 可进入）。

Java / Spring 读者：何时把 5.5 当日常默认，何时留 Opus

结合公告里的能力边界与 Spring 生态常见用法，可以这样划分：

适合把 Sonnet 5.5 设为日常默认的场景

• Claude Code / Cursor：CRUD、单测、修编译错误、按已有模块风格补接口、小型重构、写 OpenAPI / 配置片段。
• Spring AI：工具调用密集的客服 / 运维 Agent、RAG 问答、工单分类与草稿回复、代码生成脚手架——延迟与单次成本优先。
• 多 Agent 流水线中的「实现者 / 执行者」角色：上游已用 Opus（或人）定好边界与接口契约，下游大批量落地。

建议继续保留 Opus 5.5（或人工）做判断的场景

• 领域建模、限界上下文拆分、事务与一致性方案、跨服务事件设计等架构裁决。
• 安全敏感变更、复杂并发 / 分布式排障、需要长时间权衡利弊的设计评审。
• 「需求本身很糊、要先问清再动手」的开放式任务——Anthropic 明确写：开放式、需持续判断力的工作上，Opus 5.5 仍明显更强。

一个可落地的组合：Opus 定架构与验收标准 → Sonnet 5.5 在 Medium/High 下实现与回归 → 关键路径再回 Opus 抽检。对 Spring AI 多 Agent，把模型 ID 配成可按角色覆盖的 Bean / ChatClient 选项，比全局换一个模型更稳。

和 Spring AI / 多 Agent 落地时的几个细节

在 Spring AI 里换模型通常只是 ChatClient / ChatModel 的 model 名称与 effort 配置。升级到 claude-sonnet-5-5 时建议同步检查三点：

• Thinking 兼容：若自定义了「关闭 thinking」的请求构造，务必将 disabled 改为 between_tools，并确保消息历史里 assistant 的 thinking 块（含 signature）被完整回传，否则会在多轮工具调用中出现 400 或上下文断裂。
• 角色化模型路由：用配置把 architect、implementer、reviewer 映射到不同 model id；实现者默认 Sonnet 5.5，架构与最终 merge 判断走 Opus 5.5。这样账单结构清晰，也方便 A/B。
• 可观测性：记录每次 Agent 回合的 model、effort、input/output tokens、工具调用次数与是否回退（含网络安全回退到 Sonnet 5 的情况）。没有「单任务成本」看板，就很难验证官方宣称的最高约 30% 任务级节省是否在你们仓库复现。

对 Cursor 用户：CursorBench 接近 Opus，并不等于「所有会话都该关掉 Opus」。模糊需求、跨模块重构、需要产品判断的改动，仍可手动升档；把 5.5 设成默认，把 Opus 留给「想清楚再写」的回合，更符合公告里的互补叙事。

小结

Claude Sonnet 5.5（claude-sonnet-5-5）用不变的 $2/$10 单价、最高约 30% 更低的任务成本、30%+ 更快的输出，叠上 Terminal-Bench 4.0 的 70.6% 与逼近 Opus 的 CursorBench 4.0（55.5%），把「Agent 编程默认模型」的性价比中枢往下拉了一档。安全侧首次为 Sonnet 配上接近 Opus 的网络防护，并引入防蒸馏与 preserved-thinking；API 侧关闭前置思考请改用 between_tools。

对 spring4all 读者：日常默认切 5.5 往往合理，但别把架构判断也一并降档。把努力档、角色分工与单任务成本一起管起来，比只换一个 model id 更能吃到这次升级。

主要来源：Introducing Claude Sonnet 5.5（Anthropic，2026-09-28）