Sonnet 5值得升到5.5吗？价格不变，接入和验收仍要重测

Sonnet 5.5 是 Sonnet 5 应用的升级候选，但不能仅凭模型名就当作可直接替换的更新。官方每 token 价格不变，请求字段、effort 行为和响应处理却有变化。应在自己的验收检查通过、且新行为改善目标工作之后，再决定升级。

本文面向已经使用 Sonnet 5 的团队，重点是上线决策，不做通用模型排名。文档核对于 2026 年 9 月 29 日，即 Sonnet 5.5 在 9 月 28 日发布之后。本文不主张所有 Sonnet 5 应用都需要立即迁移生产环境。

哪些可以沿用，哪些要重新验证

来源：Sonnet 5.5模型页面和变化说明。Tokenizer 不变，说明相同输入文本的分词方式一致，不说明两款模型会生成同样多的输出 token。

先写清楚为什么要升级

提出一个具体、可检验的假设。例如：“在保持回归测试通过率的前提下，减少边界明确的 Bug 修复任务中的重试次数。”也可以是“让文档初稿少遗漏必需章节”。这些都需要测试，不能当成发布公告已经证明的改善。

不要同时更改提示词、检索流程、工具和模型，否则即便结果更好，也无法判断原因。保留旧配置，用相同任务集比较。如果必须调整请求字段才能让 Sonnet 5.5 接受请求，应把兼容性修改记录为新配置的一部分。

从真实用途中挑选任务，必要时去除隐私信息。既要有常见请求，也要有少量难题，以及用户在意的失败类型，不要只构造与厂商最佳演示相似的例子。

先验证兼容性，再讨论性能

优先检查思考模式、强制工具调用、思考历史、computer use 与 advisor 兼容性。Sonnet 5.5 不接受 thinking.type: disabled；文档给出的关闭执行前思考的替代方式是 between_tools，effort 不高于 high。强制 tool_choice 值也需要迁移。

具体请求示例和平台限制见 400错误迁移指南，本文不重复整份排错说明。升级清单也应包含成功响应：即便 HTTP 200，进度显示或预期工具调用仍可能缺失。

测试解析器如何处理普通文本、工具调用、思考块和拒绝响应。对话中途切模型时，要确认不兼容块如何处理；编辑早先消息时，要核对绑定行为。单轮“hello”成功，并不能验证生产 Agent 的完整循环。

质量与成本一起记录

验收标准保持不变。编程任务可以要求目标测试和完整回归测试通过，且没有无关修改；数据提取要检查结构与字段事实；文档要检查必需章节，以及每项引用输入数据的陈述。

记录请求数量、计费用量分类、获得合格输出的时间和审核成本。流式输出更快，不一定意味着任务更快完成；单价不变，也不能保证账单不变，因为输出可能更多、工具轮次可能增加。

Artificial Analysis发布报告有助于决定测什么，但它注明了预发布部署问题和计划重跑。不能把其结果当成自己应用的实测升级效果。外部发现与自身结果应分列记录。

让上线决定可以撤回

先在隔离测试环境运行新配置。检查通过后，再选择产品适用、已获准的有限范围上线。记录精确模型、配置和发布时间，区分此后流量与旧版本，不要把两个版本悄悄混在一个性能汇总里。

保留回滚配置，并写清触发条件，例如无效响应超过可接受阈值，或关键任务出现回归。回滚不等于认定模型整体更差，也可能说明当前接入或工作负载需要继续调查。

不要因为有新版本，就认为旧模型立刻退役并删掉配置。生命周期承诺需要单独查询，各服务的访问与弃用安排可能不同。迁移计划应依据实际支持日期和平台行为，而不是标题制造的紧迫感。

下一步看哪篇

费用计算见价格记录指南，配置测试见 effort对照方法。如果真正的问题是要不要换更大模型，应看 Sonnet与Opus，不要把版本升级与模型档位切换混成一次测试。