模型升级不是换一个 ID，而是重签一次 Agent 运行契约

把长程 Agent 的模型从 A 换到 B，最危险的误解是：这只是把一个 model ID 换成另一个。

Anthropic 在 9 月 1 日发布的 Claude Fable 5.1 文档里，给了一个很具体的反例。新模型不接受强制工具调用的旧用法；它的思维块只能被同代或更新模型继续读取；如果更改历史中较早的一轮，之后的思维块会失效。它还引入了可显示的工具调用进度事件，并调整了缓存读取的价格。单看每一项都像 API 细节，合在一起却指向同一件事：模型是一个正在执行的系统的一部分，不是一段可随时替换的文本配置。

一次升级，实际改动了四条边界#

对一个会调用工具、保留工作历史、向用户汇报进度的 Agent 而言，模型版本至少和四类东西绑在一起。

边界	Fable 5.1 的官方变化	产品上真正要问的问题
工具	tool_choice: any 和强制指定工具的方式会返回 400	旧的编排器能否继续下发任务？失败时是否会被误判为模型不可用？
状态	思维块并非通用历史；修改较早消息也会令其后内容无效	用户继续一项昨天的任务时，应迁移、丢弃推理状态，还是留在旧版本完成？
事件	可以在工具调用之间输出面向用户的进度更新	前端、审核日志和超时提示能否理解新的事件节奏？
经济性	缓存读取价格和 effort 控制方式变化	同一任务的成本、等待时间与完成率，是否仍在可接受范围？

这张表不是在说 Fable 5.1 “不兼容”。它说明了一个更普遍的工程事实：一旦 Agent 有持久任务，续跑和新开一轮就是两种不同的发布对象。

新会话只需验证“新模型能不能完成任务”；续跑会话还要验证“旧状态能不能被新模型正确解释”。把两者混成一个上线开关，往往会让一小部分最有价值、也最复杂的长任务在升级当天出错。

把 model ID 升级，改成运行契约升级#

我会把一次可运营的 Agent 升级描述成一份运行契约，而不是一个版本号。每个正在执行的任务至少记录这些字段：

run_id
model_snapshot
history_hash
tool_schema_hash
thinking_policy
effort_policy
event_protocol_version

它们的价值不在于“存更多元数据”，而在于把恢复策略说清楚：

• model_snapshot 让任务知道自己从哪个模型开始，而不是盲目追随默认模型。
• history_hash 和 thinking_policy 用来判断已有状态能否安全续用；不满足条件时，明确执行重放、摘要重建或留在旧版本完成，而非把 400 丢给用户。
• tool_schema_hash 把工具 JSON Schema 的变动和模型升级一起验收。模型端不再接受的工具选择策略，要有新的编排分支。
• event_protocol_version 则保护用户体验：后端新增“正在检索”“正在调用工具”并不意味着旧前端能正确显示它。

这里的字段是我根据文档归纳的运行设计，不是 Anthropic 的规定格式。重点是把“状态是否可读、工具是否可叫、进度是否可见”从隐含假设，变成可测试的接口。

上线前至少跑一张迁移矩阵#

常规离线评测只回答“模型输出是否更好”。在升级 Agent 前，还应补一张迁移矩阵：

场景	通过标准	失败时的动作
新建任务	成功率、成本和时延达到目标	暂停新版本流量
旧任务直接续跑	状态可读取，工具调用符合新约束	固定到旧模型或重建任务状态
用户回退并编辑早期消息	不复用已失效的推理块	重新生成后续链路，并提示用户
工具被要求必调	不出现未分类的 400	改走严格工具使用或结构化输出路径
长工具调用	进度事件顺序、文案和超时状态一致	回退为旧事件协议或静默模式
高缓存任务	单任务成本没有意外飙升	降低 effort、限制上下文或停止灰度

这张矩阵应该按任务生命周期切分，而不是只按 prompt 类型切分。尤其是“编辑历史后继续”“跨天恢复”“工具执行到一半断开”这三类场景，最能暴露运行时契约没有被记录的问题。

灰度顺序：先新会话，再迁移旧会话#

一个稳妥的顺序通常是：

1. 用生产脱敏样本回放，比较新旧模型在工具调用、完成率、成本和事件序列上的差异。
2. 只给新建会话放量；旧会话继续按创建时的 model_snapshot 执行。
3. 为明确可迁移的状态建立转换器，并对每次转换留下可审计记录。
4. 最后才处理长任务的续跑迁移；一旦命中不兼容条件，优先重建或留旧，不要静默混接。

这看起来比“全量切模型”慢，但它让回滚有了明确对象：回滚的是新会话流量、某个状态转换器或某版工具协议，而不是整套 Agent。对用户而言，最重要的不是知道后台换了什么模型，而是昨天开始的工作今天还能可靠地继续。

进度事件不是装饰，成本也不是附注#

Fable 5.1 将用户可见进度更新放进工具调用之间，默认长回合会较少更新。这一点值得产品团队单独验收。Agent 的“正在做什么”会影响用户是否等待、是否重复点击、何时接管任务；同一份事件也常被用于客服排查和执行审计。模型升级时，事件字段、频率和中断语义都应有兼容测试。

成本同样要纳入发布门槛。官方资料列出 Fable 5.1 支持最高 100 万 token 上下文和 12.8 万 token 输出，并对缓存读取与 effort 做了新的定价和控制说明。更长的上下文、更多的推理 effort，可能提高一项任务的完成率，也可能让一次“看似相同”的用户请求进入完全不同的成本区间。这里没有通用最佳档位；应以自己的评测集选择 effort。

因此，发布看板至少应同时看四个数：成功率、端到端时延、单任务成本、人工接管率。只看第一个，很容易把“更聪明但不可运营”的版本推向全部用户。

边界与下一步#

本文以 Anthropic 发布于 2026 年 9 月 1 日的 Fable 5.1 官方平台文档为依据，讨论的是长程 Agent 的版本迁移方法，不是在比较不同厂商模型的能力高低。文档中的价格、上下文窗口、Beta 功能和数据保留条件都可能变化；正式接入前应以当日的官方定价、区域可用性和账户权限为准。

接下来最值得补的不是又一轮通用 benchmark，而是一组真实恢复任务：带工具历史的续跑、早期消息编辑后的重建、跨版本回滚，以及用户可见进度的前后端兼容。能稳定通过这几关，模型升级才真正成为一次可控发布。

来源与证据边界#

• Anthropic Claude Platform Documentation，2026-09-01 更新：Claude Fable 5.1 概览。用于核对模型定位、上下文和输出上限、工具与思维块兼容约束、进度更新、缓存读取和模型可用性。页面未标注个人作者。

上面的运行契约字段、迁移矩阵和灰度顺序是基于这些一手资料的工程推导，不是官方性能结论，也没有声称会在所有 Agent 架构中产生同样效果。上线前仍需在自己的工具、数据保留要求和真实任务分布中验证。