长任务 Agent 升级 Opus 5.5，四个会静默翻车的地方

长会话里的 Agent，最怕的不是模型突然变慢，而是那个看起来只有一行的升级，把一个原本能跑十几个小时的任务悄悄掰断。

Anthropic 昨天发布了 Claude Opus 5.5。官方给出的信号很直接，典型按 token 计费的工作负载比 Opus 5 便宜约 40％，输入和输出分别从每百万 tokens 的 5 美元、25 美元降到 4 美元、20 美元，缓存读取则从 0.50 美元降到 0.20 美元。

这对跑长任务的团队当然有吸引力。Agent 一旦开始读仓库、跑测试、反复调用工具，缓存读取常常比新输入更接近账单主体。好家伙，最会烧钱的那一段，刚好砍得最狠。

但这次更新里真正值得上线前开会看一眼的，不是榜单，也不是宣传图上的曲线。是 迁移指南 里那四项破坏性变更。

如果你们只是拿 Claude 写一轮短代码，改完模型名跑个冒烟测试，大概率没什么戏剧性。

如果你们的 Agent 会连续工作很久，会强制工具调用，会把思考过程和进度流给前端，或者还挂着旧版 computer use，这四项会让一次看起来省钱的升级，变成一场很安静的线上排障。

便宜的不是 token，是完成同一件事的总账

图中是 Anthropic 公布的每百万 tokens 定价。输入和输出各降了 20％，缓存读取降了 60％。这张图有个容易被忽略的地方，柱子最高的输出价格不是长任务唯一的主角。

长任务 Agent 常会先吞下项目约定、代码结构、测试日志和工具描述，再在同一个会话里不断回看。这里的缓存读取像是进了一个已经搭好的脚手架，后面的每一步不必再从地面开始算。缓存读取从 0.50 美元降到 0.20 美元，才是这次升级对长会话更有感的部分。

官方还说 Opus 5.5 生成速度比 Opus 5 快 30％以上，并且会用更少 tokens 完成任务。这个判断对容量规划有价值，不过别把它直接换算成生产线一定快 30％。

真实链路里还有检索、工具服务、浏览器、测试集、限流和失败重试。模型少等十分钟，不代表整个任务少等十分钟。你大概也碰到过，模型早就写完了，CI 还在那儿慢吞吞地跑。厉害了，系统最慢的那块永远不肯配合海报。

所以我会把升级决策拆成两句。

如果你们的成本主要来自长上下文与重复回看，Opus 5.5 值得优先进入灰度。

如果你们的瓶颈在工具执行、测试队列或人工验收，先别把降价当成吞吐量承诺。它省的是模型账单，不会替你修那台已经红了半小时的构建机。

第一处变化，思考不能再被关掉

Opus 5.5 的 thinking 是始终开启的。新功能说明 写得很直白，原来依赖关闭思考来压延迟、压输出格式，或者让模型只吐工具参数的调用方，需要重新看一遍自己的请求构造。

这不是一句“能力更强”能盖过去的变化。很多 Agent 会把模型的文本输出和工具参数解析写在同一层，再用一个很窄的规则判断什么时候该继续。过去那条规则如果暗含了“没有思考块就开始执行”，升级后就可能在意料之外的事件上停住。

先别急着把所有分支改复杂。最朴素的检查是，找一条真实的多工具轨迹，确认思考相关事件会被客户端消费、记录或明确忽略，而不是被当成用户可见文本、未知消息或重试条件。

没有这条轨迹，测试通过也只是因为测试里没有真正跑长会话。这个坑很安静，直到某个任务卡在第 37 次工具调用后，才有人在日志深处看见一串没人认识的事件。

第二处变化，强制工具调用会直接报错

Opus 5.5 对强制工具使用的处理也变了。官方文档说明，某些原先可以把模型硬推向工具调用的请求会返回错误。

不少团队会这么做。不是因为喜欢控制模型，而是流程里有一步必须落成结构化结果，不能让模型写一段解释然后拍拍屁股走人。比如让它必须调用一个校验工具、必须写入任务状态，或者必须把结果交给下一段工作流。

问题不在于强制工具调用这件事对不对。问题在于升级时，很多人只会验证模型能不能回答，而不会验证那条最倔的系统指令还能不能被服务端接受。

把这类请求单独拉出来。对每个 tool_choice、每种 beta header 和每条中途追加工具的路径，跑一轮最小请求。不要只看 HTTP 是否是 200，也别把错误包装层吞掉。你需要知道，是模型拒绝了、网关拒绝了，还是 SDK 在本地先把参数挡住了。

这一层不做，灰度期间最容易出现一种很烦的现象。普通对话全绿，真正负责收口的那个动作全红。人一看仪表盘，还以为模型今天心情不好。

第三处变化，思考块和对话绑定得更紧

Opus 5.5 的 thinking blocks 会绑定模型和对话。对做会话持久化、断点续跑、跨模型路由的团队，这比表面上更要紧。

一个常见的长任务设计是，主模型推进到某个节点后，把上下文存下来，失败时换模型接手，或者把昂贵步骤交给更强的模型。以前能工作的序列化和回放逻辑，升级后不一定还能原样吃回去。

这不等于不能路由。恰恰相反，路由仍然是控制成本和可靠性的好办法。只是要把会话里的内容分成两类。

用户消息、工具结果、可重建的任务状态是一类。

模型特定的 thinking blocks 是另一类。

后一类不要再当作通用历史包袱，随手塞给下一个模型。该丢就丢，该从业务状态重建就重建。想省一次上下文拼装，反倒把整个恢复流程堵死，真就得不偿失。

上图不是模型能力图，而是这次升级更该盯住的工程关系。模型 ID、工具调用、流式事件和会话恢复，任何一张卡片没有同步更新，长任务都会在最难复现的时候出问题。

顺带再看一眼流式输出。Opus 5.5 在工具调用间写的进度短句，会以 progress-update thinking block 的形式出现。若客户端按默认的 display: "omitted" 处理，用户界面在工具调用之间可能安静下来，但不代表任务挂了。

这里最容易出两种误判。用户看见页面没动，手动取消任务。或者监控只盯普通文本事件，把仍在工作的 Agent 判成无响应。

解决方式不浪漫，也不复杂。把“模型正在执行工具”做成独立状态，把时间戳、工具名和最近一次进度事件打进日志。别用有没有自然语言输出，来判断一个 Agent 有没有活着。

第四处变化，旧 computer use 工具不能继续混用

如果你们还在 Claude API 或 Google Cloud 上使用早期的 computer_20251124 computer use 工具，这次需要替换。Opus 5.5 不再接受它。

这类变更最容易被忽略，因为不少团队把 computer use 封在一层适配器后面，日常业务根本看不到版本字符串。可一旦生产流量真的走到浏览器或桌面自动化，那层老适配器就会把请求送到门口，再被服务端原样退回来。

迁移前把版本字符串全局搜一遍，比凭记忆靠谱。配置文件、环境变量、测试夹具、模板请求和历史任务恢复代码都算。别只搜业务仓库，部署脚本和示例项目里也常藏着一份旧定义。

这里还有一个边界。官方的新模型资料里提到，部分安全相关任务会被透明地路由到其他模型。对普通的修 bug、读代码和常规工程任务，这不妨碍使用。可如果你们对模型名、工具能力或执行轨迹做了严格断言，就要把这类回退当成正常分支来设计，而不是当成一次神秘故障。

真正值得放进发布单的，是这五行

我会把这次升级的发布单压成下面五行。没有实测数据也别假装有，先把能验证的链路走实。

1. 用真实的长任务回放 claude-opus-5-5，确认 thinking 事件不会卡住解析器。
2. 为每条强制工具调用请求做最小测试，记录 API、SDK 和网关各自的错误表现。
3. 禁止把 Opus 5 的 thinking blocks 原样喂给 Opus 5.5 或其他模型，用业务状态重建恢复点。
4. 全局清理 computer_20251124，并在浏览器自动化任务上跑一条端到端冒烟测试。
5. 为工具调用间的静默补上运行态和心跳，别只靠文本流判断任务是否还活着。

五行不酷，甚至有点像发布前那张总被嫌麻烦的检查表。

可长任务 Agent 这东西，最贵的从来不是把模型名替换掉。最贵的是它跑了六个小时后，你才发现上一轮的思考块不能恢复，下一轮的工具调用也没被真正执行。

Opus 5.5 的降价和效率值得试，尤其是缓存占比高的工作流。只是升级的正确姿势不是今天全量切过去，而是先让一条完整任务穿过这四道门，再谈把流量放大。

你们的 Agent 升级里，最容易漏测的是工具调用、会话恢复，还是用户界面的静默时刻？