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

让上线决定可以撤回

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

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

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

先按集成类型决定需要验收什么

只发单次请求、解析最终文本的应用，兼容面小于会切模型、保存签名思考历史、流式显示工具进度的 Agent。换模型 ID 前先分类，才能确定必要测试；这并不保证简单应用输出完全不变。

JSON 合法不等于提取事实正确。Schema 可以要求存在 invoice_total，但金额仍须与原文件核对；参数格式正确的工具调用，也可能指向错误记录。兼容检查说明应用能运行，任务检查才说明结果有用。

平台差异不能省略。目前迁移文档说明 Bedrock 上的 Sonnet 5.5 不支持 structured outputs，包括 strict tool use；旧 Computer Use 工具在不同平台的处理也不同。一个供应商端点的结果不能直接填进另一服务的就绪表，模型 ID 旁边必须记录端点类型。

建立与你的应用对应的最小回归包

生成新答案前先准备夹具：普通请求、接近应用自身限制的长输入、故意缺少信息的输入、拒绝或不支持的请求、工具失败、多轮续接，以及影响最大的历史 Bug。这是覆盖清单，不能声称七个案例就证明生产安全。

每个夹具写清必需行为和失败判据。提取任务可以要求金额、币种、来源位置全部准确，缺数据时编造即失败。编程任务要求回归测试在基线失败、修复后通过，且不能修改验收测试。文档任务要求来源事实出现在指定章节，不允许虚构引用。

解析器夹具同时保存原始响应形状和应用显示结果。检查文本来自正确内容块、thinking 没有被当作最终回答，以及进度文本为空时界面是否看起来卡死。Sonnet 5.5 可能在请求成功的同时改变中间响应结构，所以只看 HTTP 状态码的健康检查会漏掉这类回归。

工具夹具中故意返回一次错误，确认应用正确回传结果、遵守重试上限，并且不会重复执行第一次结果尚不确定的外部动作。破坏性操作使用沙盒替身；目的是验证编排在失败时的处理，而不是靠真实扣款或邮件判断它有没有执行两次。

两套配置都写清楚，包括默认值

配置记录至少包含模型 ID、端点、SDK/客户端版本、thinking 模式、effort、输出上限、系统提示词哈希、工具 Schema 哈希和检索版本。请求中省略字段，也要把生效默认值写入记录。Sonnet 5.5 的 API 默认 high，Claude Code 默认 medium，同一个模型名在两个客户端可能从不同配置开始。

保留不可变的基线 commit 或配置版本。新模型需要新字段时，建立独立 5.5 配置，不要直接覆盖唯一旧请求。只把模型 ID 改回去，却保留不兼容的 5.5 字段，不算可靠回滚。报告不放密钥，非敏感配置与哈希足以标识版本。

官方说明 Sonnet 5 与 5.5 使用相同 tokenizer 和费率，这有助于比较相同输入，但不能决定输出长度和工具循环行为。除非文档要求兼容修改，先沿用原提示词。后续调提示词另存一个配置，不要把全部收益归因于模型升级。

怎样把测试结果变成发布决定

报告分开记录兼容失败、任务失败和运行故障。请求字段被拒绝属于兼容问题；格式正确但金额错误属于任务失败；超时、依赖不可用属于运行问题。三类都可能阻止发布，但处理方式不同，混成一个“准确率”会让下一步不明确。

一个合成门槛示例是：全部关键夹具通过，不允许重复外部操作，常规任务验收率达到团队现有标准，成本和完成时间在预先约定预算内。这不是通用阈值；关键子集是硬条件，即使平均值提高也不能豁免。具体数字要来自产品需求和已有测量，而不是新品公告。

假设二十个任务中，两版都完成十八个，也不能直接说等价：旧版失败的是两篇低风险草稿，新版失败的是财务提取和数据迁移，含义完全不同。逐任务比较失败严重性，而非只看 90% 对 90%。调查新增失败、重复不明确案例，并让决策记录保留小样本限制。

回滚要恢复行为，不只是恢复名称

有限放量时，请求应绑定可追踪配置；除非专门测过，不要在一个正在执行的任务中途切模型。日志必须能区分新旧流量。只读输出可以考虑影子评估，但不能因为同时比较两个模型，就重复执行有副作用的工具调用。

触发回滚后，停止把新任务发给新配置，恢复已验证的适配器，按保存状态处理进行中的任务。重试前先核对结果不确定的外部操作。保留失败响应和 usage 供调查，同时保护敏感内容；生产回退不意味着删除新版本证据。

最终发布记录应列出通过的夹具、未解决问题、验收责任人与方法，以及回退配置。模型或平台权限阻止真实运行时，应标记“已准备，尚未验证”。文档检查和本地请求结构验证是有价值的准备，但不能写成端到端升级成功。

下一步看哪篇

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