Claude Opus 5.5降价却破坏四个Agent依赖项

Anthropic 于周二发布的 Claude Opus 5.5 比前代产品更便宜了：每百万输入 token 的价格从 5 美元降至 4 美元，每百万输出 token 的价格从 25 美元降至 20 美元。100 万 token 的上下文窗口和 12.8 万 token 的最大输出保持不变。

从纸面数据看，升级是一个很容易做的决定。但在实践中，换一个模型 ID 可能并没有那么简单。

Anthropic 的迁移指南标注了四个破坏性变更，这些变更会导致原本为 Opus 5 构建的请求在切换到 Opus 5.5 后返回 400 错误。还有一些其他变更不会触发错误，但仍然可能改变现有 agent 的行为。

Anthropic 的迁移指南标注了四个破坏性变更，这些变更会导致原本为 Opus 5 构建的请求在切换到 Opus 5.5 后返回 400 错误。

Thinking 始终开启

第一个变更涉及 thinking 控件。Opus 5.5 在请求将 thinking 设置为 disabled 或使用 enabled 且同时设置 budget_tokens 时会返回 400 错误，effort 成为控制模型推理量的唯一方式。之前为了节省时间和 token 而对简单步骤关闭 thinking 的 agent，现在需要给那些步骤分配一个更低的 effort 级别。由于 thinking 现在始终开启，响应以 thinking 块开头，所以假设第一个 content 块是文本的代码也需要修改。

默认的 effort 级别也从 Opus 5 的 high 降到了 Opus 5.5 的 medium，所以省略该参数的请求将悄无声息地以更低的设置运行。Anthropic 建议显式设置 effort 并重新运行 effort 评估，因为每个步骤的合适级别可能已经随着成本和延迟的变化而改变。

不再支持强制工具调用

强制工具调用也不再可用：将 tool_choice 设置为 any 或 tool 会返回 400 错误，包括在 token 计数端点上——基于这些设置的成本估算将连同它们本应定价的请求一起失败。许多 agent 循环会在某个步骤必须查询数据库、运行代码或访问其他服务时强制调用，而 Anthropic 的替代方案是将 auto 与 strict 工具使用或结构化输出结合，并在提示词中说明该工具的适用时机。

路由与会话历史

Thinking 块现在与产生它的模型和会话绑定。在 Claude API 上，Fable 5.1 和 Mythos 5.1 是唯一能读取 Opus 5.5 thinking 块的其他模型，因此路由器或降级方案将对话交给任何其他模型时，这些轮次将在没有先前推理的情况下运行，而不是返回错误。

对于那些已经在监控 agent 调用是否被悄悄路由到旧模型的团队来说，这增加了一层复杂性。Opus 5.5 可以读取 Opus 5 以及更早的 Opus、Sonnet 和 Haiku 模型的 thinking 块，但无法读取 Fable 或 Mythos 的 thinking 块。

对于这些块保持有效，会话也必须保持仅追加模式。修剪旧消息、更改工具定义、在客户端汇总早期上下文，或在会话中途重写系统提示词，都会使现有的 thinking 块失效——对于在 2026 年 8 月 31 日 UTC 零点或之后创建的账户，在其中一种编辑后重放 thinking 块会默认返回 400 错误。旧账户不会收到错误，但无效的块仍然会发送给模型，Anthropic 表示未来的模型将对所有账户强制执行此检查。不编辑早期轮次的集成无需代码变更，Anthropic 表示 Claude Code、claude.ai、Claude Managed Agents 和 Claude Agent SDK 已经以这种方式工作，而自行压缩上下文的 agent 应遵循该公司关于保留 thinking 的文档。

第四个变更影响 Claude API 和 Google Cloud 上的 computer-use agent，Opus 5.5 拒绝 computer_20251124 工具，只接受通过 computer_toolset_20260801 工具集进行的 computer use。请求本身变得更简单，因为 beta header 被移除，工具集条目不需要名称或显示尺寸，但 agent 循环需要更多改动。每个操作现在作为自己的 tool_use 块到达，通过块的 name 而不是 input.action 来标识，单个轮次可以包含多个这样的块，且每个结果都必须回显 toolset_name。旧工具在 Amazon Bedrock 上仍然可用，Anthropic 引导其他平台的开发者参阅 computer use 工具的兼容性文档。

……路由器或降级方案将对话交给任何其他模型时，这些轮次将在没有先前推理的情况下运行，而不是返回错误。

不会抛出错误的变更

最容易被忽视的变更根本不会产生错误。在 Opus 5 上，Claude 在工具调用之间写入的文本作为 text 块返回，但在 Opus 5.5 上，那些叙述作为 progress-update thinking 块到达，而在 thinking.display 的默认省略设置下，这些块是空的。

任何将这些叙述流式传输给用户的 agent 界面都将在工具调用之间变得沉默，直到开发者将 display 设置为 updates——一个在隐藏推理的同时返回进度更新的 beta 选项——或设置为 summarized，后者同时返回两者，然后在其前面的工具调用之前渲染每个非空的 thinking 块。

Opus 5.5 还附带更广泛的安全分类器。它可以返回 refusal 的 stop_reason，其中 stop_details 类别现在除了 cyber 还包括 bio 和 reasoning_extraction，而 Anthropic 的服务端降级方案不会重试因 reasoning_extraction 而被拒绝的请求，而是将拒绝交还给应用程序。

不处理拒绝的 agent 将在任务中途停止，这是一个开发者已经在 OpenAI 的安全系统切断 API 响应时遇到过的问题。

最容易被忽视的变更根本不会产生错误。

从旧模型升级

从 Opus 4.8 升级的团队需要先完成 Opus 5 迁移，这涉及 thinking 默认开启及随之而来的响应格式变更，然后再应用 Opus 5.5 的变更。使用 Opus 4.7 或更早版本的团队有更多工作要做，而使用比 Opus 4.7 更旧的模型的团队还面临 rejected sampling 参数、被拒绝的手动 extended thinking、被移除的 prefill 以及更新的 tokenizer。

Claude Managed Agents 用户只需更改模型名称。在 Claude Code 中工作的开发者可以运行 /claude-api migrate 来应用模型 ID 替换、参数变更、prefill 替换和整个代码库的 effort 校准，然后手动审查清单上的各项进行验证。

Anthropic 建议在切换生产流量之前在开发环境中测试迁移。维护自己集成的开发者也需要测试模型周围的各个部分。工具调用、模型交接、会话历史和面向用户的进度更新在切换后都可能表现不同，因为 agent 故障通常起源于模型本身之外。