把应用迁移到 Opus 5.5，需要确认请求有效、响应能被正确解析，并且工具调用能够完成而不会重复执行外部操作。只替换模型名称，不能证明这些条件都成立。
本文是根据 2026 年 10 月 10 日核对的官方迁移指南整理的测试方案，没有执行付费 API 测试，也不保证特定网关兼容。
第一次调用前检查请求参数
官方指南说明 Opus 5.5 使用始终开启的自适应 thinking，并拒绝旧的显式 thinking 配置。强制工具选择中的 tool_choice 值 any 与 tool 不受支持，可用选项包括 auto 或 none。还需要检查 thinking 内容块是否有效，以及 computer-use 工具版本是否兼容。
应检查实际构造请求的代码，不能只看示例配置。应用省略的字段，可能被封装库、SDK 默认值或网关转换重新加回去。
记录模型 ID、服务商、SDK 版本和相关请求参数，保存测试样本前移除凭证。服务商展示名称带有 Opus，不代表一定映射到这个版本。
分别测试四种行为
HTTP 请求成功只是第一步。只把第一个响应内容块当作文字读取的程序，遇到其他类型就可能出错。工具参数解析成功，也不代表它提出的业务动作合法。
可以按回归评估指南固定初始任务、预期结果和评分规则，比较迁移前后的表现。
保留应用自己的授权检查
从强制指定工具改为自动选择工具后，应用仍应验证参数，检查操作是否在用户授权内，并保留原有确认步骤。
例如，客服助手可能提出调用退款工具，但应用仍需验证订单、金额和用户权限。升级模型不能让一个工具建议直接变成转账授权。
编程 Agent 可以先使用无副作用的工具或测试代码项目。首次迁移试验不应涉及部署、购买、凭证修改和破坏性操作。
添加重试之前确认不会重复执行
没有收到明确响应，不等于之前的外部操作失败。工具可能已经改变状态，之后连接才中断，盲目重放就可能重复操作。
系统支持时保留操作标识，核对真实结果，只重试缺少的步骤。连接恢复与任务恢复需要分别处理，策略取决于应用自身约定，不能只根据模型服务商的状态码决定。
正确执行之后再比较费用
确认任务能安全完成后，再比较整项任务用量与验收质量。Opus 与 Sonnet 对比提供选型标准，API 成本指南帮助统计多次调用。
不要根据单次请求就宣布迁移更省钱。失败、返工都需要计入，也应区分自己测出的结果与服务商宣传。
区分 API 迁移与客户端选模型
在受支持的客户端里选择模型，与维护自己的 API 集成，是不同工作。客户端负责底层请求时，不应要求普通用户自行修改原始参数。
如果希望通过 Agent.Space 使用项目工作流，可以查看开发者 API 指南和当前产品价格。确认实际支持方式后再创建工作区。官方 API 迁移说明不代表第三方环境会开放所有参数。