升级模型，改变的不只是模型名

Anthropic 于 9 月 28 日发布 Claude Sonnet 5.5，主打速度与任务效率的提升。对于自己构造 Messages API 请求的团队，迁移指南与性能主张同样值得注意：它涉及请求参数和会话处理的变化。使用 Claude Managed Agents 的用户，官方则说明只需更新模型名。以下分析面向自行集成 API 的应用。 [1] [2]

单轮冒烟测试可能漏掉两类不同的问题：一种请求立即报错，另一种请求成功，但实际使用的上下文变了。这两种结果需要分别验收。HTTP 成功只说明服务回了消息，不能证明应用仍按原来的流程工作。迁移计划应从这一区别出发。

Sonnet 5 接受 thinking: {"type": "disabled"}；Sonnet 5.5 对它返回 400。新模型最低的思考设置是 between_tools，只接受 low、medium、high 努力级别；xhigh 和 max 会被拒绝。这是请求契约的变化，不只是参数调优。过去靠关闭思考控制延迟的团队，应明确选择新设置，并重新测量实际流程，而不能指望旧请求原样奏效。 [2]

between_tools 关闭的是开始回答前的扩展思考，工具调用之间的进度说明仍可能以 thinking block 返回。工具循环要把这些区块连同整条 assistant 消息原样传回。若客户端认定第一个内容区块必然是正文，或只用正文与工具调用重建历史，都需要复查。解析时按区块类型读取；续接时保留 API 返回的完整 assistant 消息。 [2] [6]

Sonnet 5.5 会拒绝 tool_choice 中强制调用的 tool 和 any。Anthropic 建议在支持的平台改用 auto，并为工具启用严格输入格式。严格格式能约束已经发生的工具调用；auto 仍允许模型直接作答。Amazon Bedrock 在该模型上不提供严格工具调用，应用还须自行校验工具输入。 [2] [4]

这一区别会影响业务结果。假如流程要求先读取最新记录，再给出答复，一段格式正确的回答不能证明读取已经发生。应用应在收到并验证指定工具结果后，才认定这一步完成；验收时既测正常调用，也测模型直接回答但未调用工具的情况。这是根据文档提出的架构建议，并非断言 Sonnet 5.5 会以某种频率漏调工具。

Sonnet 5.5 产生的 thinking block，只能由产生它的账号或关联账号继续使用。如果无关联的另一个账号把它送回 API，区块会在推理前被丢弃，请求依然成功；不加相应诊断标头时，这件事不会显式报告。切换到无法读取该区块的模型，也可能发生丢弃。因此，路由器拿到成功响应，不代表模型看到了先前的推理内容。 [3]

另有一项前缀约束：重放已签名的 thinking block 时，之前的 system 指令、工具列表和消息必须保持一致。2026 年 8 月 31 日及之后创建的账号默认执行该检查；更早账号的默认执行方式不同，不能用一把密钥上的“没报错”替所有用户作保证。迁移测试应保持历史只追加，并覆盖保存后恢复、工具变化、客户端裁剪旧消息以及切换路由的场景；在支持时查看 input_transformations，识别被丢弃的区块。 [3]

迁移指南还要求处理拒绝结果。拒绝应该进入产品的提示与审阅流程；把它当作网络故障反复重发，会混淆政策结果和服务故障。Anthropic 只在 Claude API 的特定条件下，说明了针对部分拒绝类别的可选服务端回退；这不代表所有拒绝都可重试，也不代表所有托管平台都有同样行为。 [5]

验收时，应记录实际的停止原因、是否触发官方配置的回退，以及用户最终看到什么。这样才能观察安全处理的结果，也避免用底层重试绕过拒绝。仅统计 HTTP 成功率的看板，看不出用户获得的回答是否已经改变。

我们建议一组迁移样本覆盖五条路径：旧的关闭思考请求、过去强制调用的工具、多轮工具交换并重放 thinking block、通过真实账号和路由恢复保存的会话，以及产品对拒绝的处理。逐项检查 HTTP 状态、内容区块类型、工具是否执行且通过校验、可获得的会话诊断信息，以及用户最终看到的结果。还应纳入长会话与一次路由切换，因为单轮冒烟测试暴露不了历史问题。

完成契约验收后，再按明确的努力级别比较任务通过率、完整耗时和每个通过验收任务的成本。Anthropic 的速度与成本主张，可以帮助形成实验假设，不能代替自己工作负载上的结果。更普遍的教训是：模型属于应用、工具、历史和用户之间的一套协议。只有这套协议仍能交付预期结果，升级才算完成。 [1]