升级到Claude Opus 5.5：模型编号背后的五大重大变化。

一个模型字符串，五重惊喜

想象一下发布公告后的那个星期五。Anthropic已经发布了Claude Opus 5.5（2026年9月22日），其在大多数任务上的表现可媲美Fable版本，每次运行成本大约降低40%，定价为每百万个标记输入费用4美元，输出费用20美元。大家都对这一折扣感到兴奋，而你的生产环境仍然基于Opus 5设计，只差一个模型字符串就能启用新版本。只需将model改为claude-opus-5-5即可。

第一个测试用例看起来也没更聪明。它可能会因为误判而返回HTTP 400错误，或是由于循环在每一步都强制使用某个tool_choice而导致失败。也有可能请求能够通过，工具芯片不断出现，但原本用于展示进度信息的工具间叙述却消失了。没有错误提示，智能体表现也没有提升，操作人员开始怀疑任务是否卡住了。

这只是一个预检环节，并非最终测试总结。在新模型ID背后还有五项需要解决的问题：持续不断的思考、强制使用的工具、与模型绑定的思维限制、一个已被废弃的计算机使用工具，以及一种永远不会引发400错误的流式结构变化。更换字符串很简单，真正困难的是让系统能够应对下一个请求。

测试报告的说法与文档中的描述

媒体报道主要集中在价格上。相关公告及文章强调了Fable级别的性能表现、网络安全防护以及更低的Opus成本。Anthropic提供的数据也支持这一说法：在大多数任务上能达到Fable 5.1级别的性能，单次运行成本大约降低40%，Opus 5的定价为4美元/20美元，而Fable为5美元/25美元，且输出速度快30%以上。0.20美元/次的缓存读取费率仅是价格列表中的一行内容，并非最受关注的点。

文档中的说明虽较少，但十分精确。平台概览中列出了针对已在Opus 5上运行的代码的四个重大变更：思维功能无法关闭、强制使用工具时会出错、思维块会被绑定在特定模型和对话中，此外旧版的computer_20251124工具也不被Claude API或Google Cloud接受。

风险主要存在于自定义的 Messages API 代理循环、多模型路由器，以及那些强制在 Claude API 或 GCP 上使用特定工具和计算型代理的工作流中，因为这些系统仍然会发送 Opus 5 格式的请求。某些配置则更为安全：Claude Managed Agents 只需要新的模型名称，而 Claude Code 与 Agent SDK 会直接在对话中添加内容，从而降低思维绑定带来的风险。声称所有功能都会失效并不准确。尽管如此，这一升级仍值得采用，而对于那些将发布帖子视为正式上线标志的人来说，其带来的损害确实是真实的。随着请求规则的收紧，价格反而下降了，因此这并非简单的字符串替换即可完成。

这五项内容分别是：

1. 自适应思维功能始终处于开启状态。无论是设置 thinking.type.disabled，还是将 enabled 与 budget_tokens 结合使用，都会返回 400 错误码。

强制将 tool_choice 设为 any 或 tool 时会返回 400 错误。

思维块与生成它们的模型绑定，因此即使请求成功，路由器也会丢失无法读取的推理过程。

computer_20251124 在 Claude API 和 GCP 上会被拒绝（Bedrock 仍可接受）。

工具之间的叙述内容会被放入思维块中，而在默认的 display: "omitted" 设置下这些思维块是空的，这种情况不会引发 400 错误。

上述路径中有四种会以 400 错误明显失败，而那些“安静”的流程则不会，这就是为什么进度界面会在 200 状态码下消失。默认的运算强度也发生了变化：Opus 5 使用 high 级别，而 5.5 使用 medium 级别，因此哪怕没有错误，简单的设置更改也会改变行为。那些拒绝使用你所提供配件的廉价 Opus 版本则会导致服务中断并需要发布声明。

第一个问题：思维无法关闭

在 Opus 5 中，当努力程度为“高”或更低时，发送 thinking: {"type": "disabled"} 可以起到作用，手动设置 enabled 并搭配 budget_tokens 也同样有效。而 Opus 5.5 则不再考虑之前的延迟路径设置方式。文档指出，自适应思维始终处于开启状态，深度则通过努力程度参数来控制。

发送 thinking.type.disabled 后，API会返回HTTP 400错误，指出问题出在 thinking.type.adaptive 和 output_config.effort 上。enabled 模式也会以相同方式失败。为降低延迟而优化的聊天路由，以及为节省令牌而关闭思考功能的廉价工具循环，会在切换后的首次调用时就首先出问题。那些期望第一个内容块为 text 格式的代码也会失败，因为默认的 display: "omitted" 设置下，响应开头可能会出现文本为空的 thinking 块。

修复方案：

• 省略 thinking，或发送 {"type": "adaptive"}。
• 通过 output_config.effort 设置深度，记住默认值为 medium。若之前已关闭思考功能，则选择 low。

按type选择内容块，并在工具循环中将思考过程原样返回。

在max_tokens中留出足够空间用于无法关闭的思考过程。

全天候运行并不意味着产出量必然增加，因为控制因素在于投入力度。仅在Claude API上提供快速模式（速度约为常规模式的2.5倍，费用分别为8美元/40美元），适用于延迟才是真正限制因素的场景，Bedrock和GCP则不支持该模式。thinking: disabled不仅已过时，还会导致400错误。

第二项变革：不再强制使用工具

Opus 5.5 不支持强制使用工具，这是一种行为上的变更，而非渐进式废弃。当 tool_choice 的值为 {"type": "any"} 或 {"type": "tool", "name": "..."} 时，系统会返回 400 错误，表明该模型不支持对应的 tool 及 any 类型。auto（默认值）和 none 仍然可用。

那些每轮都强制使用特定工具的机制，比如天气查询、数据库调用或“始终调用search_codebase”规则，都会在此处出问题；依赖工具命名的架构强制规则同样会失效。那些通过强制选择将请求发送到令牌计数端点的CI预检也会失败，因此甚至在发起Messages调用之前，计费计算就已经出错了。从外部看，这次故障似乎只是“我们修改了模型”，但堆栈跟踪却显示仍在发送Opus 5控制平面消息。

修复方案：

• 使用tool_choice: {"type": "auto"}。
• 为工具添加strict: true参数，或使用结构化输出。
• 在提示中明确说明何时应使用每个工具，例如“在……时调用get_X工具”，这种方式比现在被API拒绝的强制选择更有效。

如果每次 count_tokens 调用仍然通过 any 或 tool 的检验，则需再次执行该调用。

这种情况会在模型运行之前就导致失败，且没有让系统优先调用工具的灵活替代方案。这种“始终调用搜索”策略反而成了部署的障碍。

问题三：与模型相关的思考模块

每个思考模块都会标注生成它的模型，一个模型能够理解自己生成的模块以及来自其他模型的有限数量模块。Opus 5.5 可以处理 Opus 5 及更早版本、Sonnet 和 Haiku 版本生成的思考内容，而 Fable 和 Mythos 生成的内容则不在该范围内。反过来，只有 Fable 5.1 和 Mythos 5.1（在 Claude API 上）能够理解 Opus 5.5 生成的内容。

如果路由器或备用系统将对话从 claude-opus-5-5 发送至 Sonnet、GPT 或其他模型，API 会丢弃目标模型无法读取的块。请求仍会成功，且被丢弃的块不会产生费用。其结果是质量悄然下降，不会出现 400 错误，推理能力变弱，但控制面板仍显示正常状态。

在对话进行到一半时修改 system、tools 或之前的设置也可能会使某些块失效。2026 年 8 月 31 日（协调世界时 00:00）之后创建的账户，在对前缀进行修改后重新播放思考块时默认会返回 400 错误。而测试版 thinking-binding-controls-2026-08-01 允许使用 prefix_mismatch_behavior: "drop_block" 作为替代方案。Claude Code、claude.ai、Managed Agents 以及 Agent SDK 均采用仅追加块的方式，从而降低了相关风险。

修复内容：

• 保持对话为只读追加模式。
• 应通过对话中的系统消息来更改指令，而非重写前缀部分。
• 除非文档另有说明，否则模型切换应视为推理过程的重新开始。
• 需原样返回思考过程内容，且不能假设每个 Claude 模型在交接后都能遵循 5.5 版的推理方式。

即使某种备用方案“成功”了，也仍可能丢弃让该轮对话得以进行的推理内容。

第四条规则：旧式的计算机工具

Opus 5需要同时使用computer_toolset_20260801，在测试版中还需使用computer_20251124。在Claude API和Google Cloud上，Opus 5.5仅需要工具集，而若声明使用computer_20251124则会返回400错误，提示claude-opus-5-5不支持该工具类型。Amazon Bedrock仍可接受该配置，因此这方面没有变化。由于模型系列相同只是平台矩阵不同，仅支持Bedrock的团队成员无需进行不必要的重写。

在 Claude API 或 GCP 上，那些仍使用旧类型并发送 computer-use-2025-11-24 测试版标头的桌面端及浏览器端代理，在首次声明工具时会失败。仅更改类型并不足以解决问题，因为读取 input.action 的循环也会中断。通过 tool_use 成员块可将操作放入该块的 name 中，一次轮次可包含多个工具使用操作，且每个结果都需要返回 toolset_name: "computer"。

修复方案：

• 移除测试版标头。
• 在声明中发送 tools=[{"type": "computer_toolset_20260801"}]，省略 name 及显示尺寸信息。
• 更新代理循环，使其使用成员名称及 toolset_name。

功能得到了提升（该公司在OSWorld 2.0测试中获得的得分为81.8%，被标记为部分达标），同时集成功能也随之出现。

第五个突破：流程不再有噪音

text块的形式呈现，因此用户界面可以显示类似“正在检查迁移……”这样的文字，操作人员也能保持冷静。Opus 5.5采用了与Fable 5.1相同的结构，此时这些对话会以进度更新thinking块的形式出现，每次工具调用前最多显示一个。由于thinking.display的默认值为"omitted"，因此thinking字段会为空。文档中警告称，如果用户界面以这种方式显示进度信息，那么在工具调用之间就会陷入沉默，直到选择能够显示文字的display值为止。

没有请求失败，状态均为200。工具芯片仍然显示，但它们之间的对话内容已消失，用户认为代理程序挂掉了。

修复措施：

• 若只需显示进度文本而不需展示推理过程，可选择display: "updates"（需要beta版本thinking-display-updates-2026-08-18）；若需同时显示两者，则选择"summarized"，并在后续的tool_use操作之前渲染所有非空的推理内容。手势块则保持不变。

四种严重的错误会返回400状态码，而这种情况却从未出现，正因如此，看似正常的测试环境中进度界面就会出问题。最恶劣的迁移错误就是那些返回200状态码的情况。

是否可上线检查清单

应将此次测试视为一种预警机制，而非周五的常规配置调整。在claude-opus-5-5开始处理请求之前：

• 将模型ID更新为claude-opus-5-5，在Bedrock、GCP或Azure上使用对应平台的特定ID。
• 移除thinking: disabled和enabled以及budget_tokens，然后明确设置output_config.effort，其默认值为medium。
• 将tool_choice的值为any或tool替换为auto，同时设置严格的工具要求、结构化输出以及提示词指令。
• 在Claude API或GCP上使用计算机功能时，需切换到computer_toolset_20260801并更新代理循环；Bedrock可能仍保留computer_20251124。
• 在路由器模式下，离开5.5版本时思考过程可能会丢失，不过Claude API上的Fable或Mythos 5.1版本除外。
• 通过type筛选内容，并原样保留thinking块的内容不变。

对于正在处理的用户界面，将display设置为"updates"或"summarized"。

保持对话内容的只追加特性，若前缀被修改则遵循保留思考过程的指导原则，尤其是针对2026年8月31日后创建的账户。

根据实际期望的工作量重新设定成本和延迟指标，并在正式投入生产流量之前在开发环境中进行测试。

可选地，运行Claude Code的/claude-api migrate功能。

只有 Claude Managed Agents 才能仅通过名称进行切换，文档中也仅说明模型名称需要更新。Custom Messages API 的相关工具并不属于这一类别，它们会保持 Opus 5 的请求格式，直到相关列表显示为绿色状态。migrate skill 可以在切换前检测到过时的请求格式，但路由器和进度界面仍需自行测试，因为它并不能替代金丝雀版本。默认的工作量从 Opus 5 的 高 级降到了 5.5 版的 中 级，因此不要将旧的高工作量假设应用到默认的中等级别上。

有计划地进行升级

Opus 5.5确实值得特意采用，对于Fable级任务而言，每次运行成本大约可降低40%，且输出速度更快。选择它是因为模型性能更优，而非因为发布消息听起来像某种启动机制。现在重要的是请求格式，而四处已记录的故障点加上静默流构成了这种限制条件。官方说明并未将这些问题与价格下降同时列出。

严重的400错误会发出明显声响，而路由器连接中断和display: "omitted"情况则较为隐蔽，因此需要对这两种情况都进行监测，否则只能发现那些表现明显的故障。不同平台也存在差异：Bedrock仍支持computer_20251124，而Claude API和GCP则不支持。托管型Agent需要更改名称，而自定义的Messages API则无法享受此类便利。由于原有机制已被取代，成本和延迟都需要重新设定基准，不能默认原有的成本计算方式依然适用。

更改字符串无需任何成本，而迁移则需要费用。此次升级是真实的，所谓直接替换的说法纯属虚构。请按清单逐步操作，重新评估工作量，之后再将流量引导至 claude-opus-5-5。