企业官网建设流程全解析

Anthropic 在 9 月 28 日发布了 Claude Sonnet 5.5。官方给出的卖点很直接：相比 Sonnet 5，新模型快了 30% 以上，多数工作成本最高可降低 30%。这两个数字足够让开发者重新看一遍自己的模型配置，但真正需要注意的并不只是价格表上的变化。

如果应用已经接入 Claude API，或者把 Claude 放进了工具调用、代码 Agent 和长上下文工作流，直接把模型名换成claude-sonnet-5-5并不一定结束迁移。thinking 的设置方式、强制工具调用、thinking blocks 的处理方式，甚至 computer-use 工具的版本，都可能影响原来的请求。

图 1：Anthropic 官方发布帖中的 Claude Sonnet 5.5 速度与成本表述。来源：Anthropic Claude 官方 X。

先把这个模型的基本信息对上

Release Notes 显示，Claude Sonnet 5.5 的模型 ID 是claude-sonnet-5-5，发布日期为 2026 年 9 月 28 日。官方列出的接入方向包括 Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud 和 Microsoft Foundry。这个列表说明产品已经覆盖这些平台，具体能否调用仍要看地区、账户权限和服务目录，不能把平台名称直接等同于所有环境都已同步开放。

模型详情页给出的参数更适合用来做迁移前基线：默认上下文窗口为 1M token，最大输出为 128K token，输入价格为每百万 token 2 美元，输出价格为每百万 token 10 美元。页面还列出了 5 分钟缓存写入、1 小时缓存写入和缓存读取的价格。对长上下文应用来说，缓存字段和输出上限同样会影响预算，不能只盯着输入单价。

图 2：Claude Sonnet 5.5 模型页中的参数和迁移提醒。来源：Claude Sonnet 5.5 模型详情页。

它的定位，是把能力和成本重新组合

Anthropic 对 Sonnet 5.5 的定位不是单纯追求最高能力，而是把它放在速度、智能和成本的交叉位置上。官方介绍页把它称为更快、更低成本的 Sonnet 5 升级，也将它作为 Opus 5.5 的补充。换句话说，它更像是一个适合频繁调用的工作档位，而不是只在最复杂任务上偶尔启用的旗舰档位。

官方展示的评测覆盖了 Agentic coding、Knowledge work、Computer use 和 Visual chart recognition 等任务。比如编程和知识工作数据，说明 Anthropic 希望开发者把它用于持续执行、多步判断和较长上下文的工作流；计算机使用与图表识别数据，则展示了它在工具和视觉输入上的覆盖范围。这些数字是 Anthropic 自己的评测结果，能够说明官方如何定位模型，但不能直接替代某个团队的业务验收。

图 3：Anthropic 官方基准对比，覆盖编程、知识工作、计算机使用和视觉图表识别。来源：Anthropic Claude 官方 X。

另一个容易被忽略的变量是 effort。模型页面默认开启 adaptive thinking，默认 effort 为 high；官方成本图也显示，同一个模型在不同思考深度下，任务得分和单次成本会一起变化。因此，比较模型时不能只看每百万 token 的价格。一个模型单价更低，如果为了完成同一任务消耗了更多输出 token 或更高的思考预算，实际成本未必按比例下降。

图 4：Anthropic 按 effort 展示知识工作得分与成本关系。来源：Anthropic Claude 官方 X。

迁移时，四个 API 细节比模型名更重要

第一是 thinking 设置。Sonnet 5.5 默认使用 adaptive thinking，如果原来的请求显式发送thinking: {"type":"disabled"}，迁移后需要改为thinking: {"type":"between_tools"}，这是该模型支持的最低思考设置。已经用参数控制延迟或输出形态的应用，应该先搜索代码中的 thinking 配置，再重新记录 token 消耗和响应时间。

第二是强制工具调用。官方迁移文档明确说明，tool_choice的any和tool在 Sonnet 5.5 上会返回 400。原来要求模型必须调用某个工具的流程，不能只替换模型 ID；可以按迁移建议使用auto，再结合 strict tool use 或结构化输出约束工具参数，并重新验证模型是否在正确的时机调用工具。

第三是 thinking blocks 与模型、会话的绑定。工具调用之间的文本可能以 thinking block 返回，应用如果把历史消息保存下来重新播放，或者在工具循环中自行筛选消息，就需要检查这些 block 是否被完整保留。只测试一次普通问答，很难发现这种问题。

第四是 computer-use 工具的变化。在 Claude API 和 Google Cloud 上，旧的computer_20251124工具不再接受，需要按对应渠道文档改用新的 toolset。对于已经接入计算机操作的 Agent，这属于请求校验阶段就可能暴露的兼容问题。

这些变化在 What’s new 和 迁移指南 中都有明确说明。它们共同指向一个事实：模型升级的检查重点，不只是一串新的模型 ID。

官方价格之外，还要看实际 API 服务

官方模型页提供的是模型本身的定价基线。真正接入时，还需要确认目标 API 服务展示的模型 SKU、输入和输出价格、缓存计费单位以及当前服务状态。同一个模型通过不同服务调用时，价格字段和可用条件可能并不完全相同。

图 5：OkenAI 模型详情页中的 Claude Sonnet 5.5 服务价格与接入信息。来源：OkenAI

这类核对以前往往要在不同页面之间来回查找：先确认模型是否收录，再对照输入、输出和缓存价格，最后检查当前服务是否有可用状态。OkenAI 的模型详情页把这些字段放在同一处，适合用来完成第一轮筛选和价格核对。页面展示的是当前服务数据，不等于最终业务账单，也不替代真实任务的稳定性和质量验收。

迁移前，先做一轮最小验证

不必一开始就重做整套系统。可以先用同一个固定任务分别调用旧模型和 Sonnet 5.5，记录输入、输出和缓存 token；再分别测试普通回答、thinking、工具调用和流式输出，观察响应结构、错误码和耗时是否发生变化。最后把任务完成情况和实际成本放在一起比较，再决定直接迁移、灰度并行，还是继续观察。

这样看 Claude Sonnet 5.5，它的吸引力确实来自速度、价格和长上下文能力的组合。但要不要迁移，不能只看发布页上的一句“更快”或“更便宜”。先用官方文档确认兼容点，再用 OkenAI 核对目标模型的服务价格和状态，最后拿自己的固定任务复测，模型升级才会变成一次有数据依据的接入决策。