Claude Fable 5.5 和 Fable 5.1：升级前怎么测？
升级路径有哪些已知信息？
| 迁移问题 | 现在可以做什么 | 哪些部分必须等待证据？ |
|---|---|---|
| 能否直接更换模型 ID？ | 找出当前路由的配置位置 | 确认精确候选 ID 与受支持的请求契约 |
| 工具与结构化输出行为是否相同？ | 保存 schema、固定样例与验收检查 | 在已验证的候选路由上回放 |
| 现有对话能否正确续接？ | 保存脱敏后的代表性历史 | 测试历史接收与续接行为 |
| 缓存与成本能否沿用？ | 记录当前用量与实际费用 | 核查候选规则与计费，不预设缓存可迁移 |
| 是否需要整体替换？ | 找出确实需要改善的工作负载 | 比较结果，再决定是否迁移 |
下文提出的是迁移评估流程，不意味着 Fable 5.5 已支持某项功能，也不表示已有发布时间安排。
从 Fable 5.1 真实存在的接入限制开始
tool_choice 的 any 和 tool 模式会报错；切回较旧模型或修改先前对话内容时，thinking block 也有保留限制。这些是 5.1 已有的规则，并非新发现的 5.5 变化；是否适用于具体网关路由，还需单独验证。| 现有依赖 | 需要从当前应用保存什么 | 未来迁移要回答什么 |
|---|---|---|
| 工具选择 | 工具 schema、业务必须执行的动作，以及应用如何确认动作确实发生 | 候选是否支持所用控制方式？不依赖不受支持的强制选择，能否完成动作？ |
| 带 thinking 的历史 | 原始顺序的消息、收到的不透明块，以及历史转换版本 | 哪些块在候选与回退模型上仍然有效？ |
| 客户端压缩 | 压缩前后历史、被摘要的轮次、保留下来的后续块 | 转换后的历史能否被接受，并保留用户决定？ |
| 流式响应与解析 | 原始事件样例、工具调用拼接、终止／错误分支和解析器版本 | 原解析器能否重建所需输出，并区分完成与中断？ |
| 用量与缓存 | 不重复的 usage 分类、实际扣费、冷启动与缓存命中运行 | 候选是否保留预期缓存行为？完整会话成本是多少？ |
由此可以区分一个很容易误判的问题：如果应用重写较早轮次之后，5.1 请求就已经被拒绝，这是现有接入的基线问题，不能算到尚未测试的新型号头上。每个样例都先在当前可用路由运行，记录已有失败，再加入候选项。
业务状态与模型推理状态也需要分别恢复。工单 ID 和用户批准的负责人，应保存在应用的持久状态中；thinking block 则属于有模型限制的历史内容，保留下来不等于其他模型一定能读取。回退时可以保留已批准的业务事实，但可能需要换用有文档支持的历史表示方式。
不要在同一次实验中同时更换模型、系统提示词、工具与压缩方案。保存提示词模板、工具定义、有代表性的工具响应和解析器版本，注明哪些输出由软件消费，哪些需要人工审查。先用沙箱或已记录的工具响应回放；发送消息、创建记录或扣费重复执行，都不是比较可以接受的副作用。
建立能发现回归的回放集
同时纳入 Fable 5.1 的成功会话和尚未解决的失败。如果候选模型修好了一个困难任务，却扰乱常见工作流，对你的应用而言未必算升级。应在查看候选输出之前定义预期结果。
| 回放案例 | 检查内容 | 失败条件示例 |
|---|---|---|
| 新请求 | 必须遵守的指令和输出字段 | 必填字段消失或限制条件被忽略 |
| 长对话历史 | 重要状态与用户决定是否保留 | 续接内容违背此前已接受的决定 |
| 工具调用与结果 | 参数、顺序和最终响应是否正确 | 重复调用工具或错误解释工具结果 |
| 结构化输出 | 结构校验与字段含义均正确 | JSON 合法，但标识或数值错误 |
| 中断或失败请求 | 重试与回退后状态一致 | 副作用重复或残留未处理的部分状态 |
| 日常成功任务 | 当前质量与延迟保持可接受 | 原本常见的成功任务失败或超时 |
只测试候选路由文档支持的功能。如果某项功能不支持或尚未验证，应将其标记为依赖该功能的工作流迁移阻碍，而不是悄悄从结果中删去这个案例。
一套可照做的 Fable 5.1 Agent 回放案例
TEST-17 的工具响应，以及用户“更新这张工单，不要另建”的指令。这是用于说明方法的应用场景，不是模型行为实测。以三种形式回放：携带必要状态的新请求、原始对话历史、模拟超时后恢复的会话。第一轮固定工具响应，随后再在独立沙箱测试中加入真实形态的工具错误。
| 验收项 | 应保留的证据 | 失败时如何处理？ |
|---|---|---|
| 更新的是正确工单 | 工具名称、参数与最终沙箱记录 | 错误 ID 或意外创建操作直接判失败 |
| 用户已批准字段保持正确 | 修改前后的记录差异 | 未授权字段变更判失败 |
| 重试不重复已提交的操作 | 应用操作 ID 与工具执行日志 | 停止该案例，检查重试和状态处理 |
| 最终回答与实际结果一致 | 对照回答与已记录的工具结果 | 更新失败却声称成功，判失败 |
| 回退后能安全继续 | 恢复状态与保留路由上的回放 | 恢复未验证前不扩大流量 |
每次尝试保存精简记录：案例 ID、模型路由、客户端和提示词版本、历史转换方式、工具日志、通过或失败原因、费用与人工审查时间。未测试结果留空，不能标为通过。如果新请求通过而历史会话失败，应先排查历史边界，不要全面修改提示词；如果两组都在同一个预期状态检查上失败，先检查请求与工具契约。
这个样例让“升级更好”成为可以证伪的结论：回答再流畅，也不能掩盖重复工单或状态损坏。可把同一模式替换成自己应用中会产生实际后果的操作。
{
"case_id": "ticket-update-17",
"before": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "normal", "status": "open"}
},
"instruction": "Set TEST-17 priority to high. Keep its owner and status. Do not create another ticket.",
"expected_after": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "high", "status": "open"}
},
"allowed_changed_fields": ["ticket.priority"],
"forbidden_operations": ["create_ticket", "close_ticket"]
}指令要求把 TEST-17 的优先级改为 high，保留负责人和状态，不另建工单。新请求组提供当前工单与指令；历史组保留之前的批准、创建响应和更新指令；恢复组则让沙箱完成更新，但隐藏工具响应，模拟“写入已提交，客户端却超时”。应用必须先核对已有记录，再决定是否重做操作；只有工具文档真正支持时，幂等键才有去重作用。
normal，判失败；优先级正确但负责人被改动，也判失败；即使原工单已正确更新，多出第二张工单仍然失败。还要同时检查最终状态和执行日志：一次多余写入可能被之后的补偿修改掩盖。丢失工具响应时，助手不能把尚未核对的更新说成已经确认。把起始状态、实际发送的历史、工具调用参数、最终状态与回答放在同一份记录里。如果两个模型都无法处理“已提交写入但响应丢失”，应先修复应用的恢复机制，再判断是否属于模型能力问题。这套验收样例现在就能用于 Fable 5.1 接入；在出现已验证路由之前，5.5 的结果栏仍应保持未测试。
怎样排查历史续接失败？
如果新请求通过，而对应历史会话失败，应对比实际发送给模型的消息：工具调用与结果是否配对、用户已确认的决定是否保留，以及既有生成内容是否改变了输入。保存原始历史，每次转换单独标记版本，才能定位是哪项变化影响了结果。
不要假设缓存条目、会话引用或供应商特有字段能迁移到另一个模型。先核查文档中的适用范围。如果工作流需要转换历史，应使用相同预期状态测试转换后的内容，并记录哪些信息被删除或摘要化。
分别报告新会话与历史续接的通过、失败和未测试数量，并说明原因。新会话组通过，不代表已有对话也可以迁移。
从回放推进到可回退的放量
EvoLink 可以为模型选择提供共同的网关接入层，但具体模型行为仍需验证。应明确保存当前模型、候选模型和回退配置；不要用猜测的 Fable 5.5 ID 填入候选项。
把回放结果变成明确的放量决定
放量前先写下判定规则，包括谁可以停止，以及哪些状态必须保留。如果平均通过率的提升伴随新的严重错误，仅看平均值不足以支持升级。
| 假设的回放结果 | 决定 | 下一步 |
|---|---|---|
| 候选模型通过更多任务，但重复了一次外部操作 | 不转为默认 | 修复或隔离操作边界，再回放两种配置 |
| 新请求通过，历史会话失败 | 不迁移已有会话 | 排查历史转换，单独评估新会话流量 |
| 质量达标，但延迟超过预先确定的上限 | 不作为所有任务的默认项 | 测试明确识别出的慢任务队列能否接受 |
| 只有一个任务类别在预算内改善 | 可考虑按任务有限放量 | 验证该类别的分流错误与回退 |
| 结果达标，但保留路由无法恢复状态 | 暂停扩量 | 建立可用的恢复路径并测试 |
以上是判定示例，不是 Fable 5.5 实测结果。数值门槛应来自应用要求，不能随意照搬某个成功百分比。根据准备放量的范围，覆盖足够类型的正常与失败流量；小样本仍然存在不确定性。
回滚方案应写明原路由和配置版本，停止给候选模型分配新任务，定位进行中任务，核对已经发生的副作用，再从已知状态恢复。记录触发原因与恢复结果。仅仅写在配置里的 fallback，还没有证明自己能恢复业务。
什么结果才值得升级？
如果候选项没有实质收益，只要 Fable 5.1 路由仍可用且适合任务，保留它就是合理结果。如果只有一个工作流改善，只迁移该工作流可能比更改所有默认项更有依据。这两种选择都不需要把未验证发布当作截止日期。
常见问题
能否把 Fable 5.1 ID 改成猜测的 Fable 5.5 ID？
不能。必须先确认精确候选标识与受支持的请求契约。页面路径不是可用的 API 模型 ID。
Fable 5.5 向后兼容 Fable 5.1 吗？
已核查的来源尚未确立向后兼容。需要对目标精确路由验证请求字段、响应、工具和有状态行为。
能否复用现有对话历史？
可以将其准备为测试材料，但不要预设兼容。分别测试全新会话与历史续接，检查重要状态和决定是否保留。
提示词缓存会迁移到候选模型吗？
不要预设缓存可迁移。核查候选路由的适用范围和计费规则，并将缓存相关费用计入评估。
切换模型时应该一起改提示词吗？
先使用冻结的基线。如果必须针对候选模型调优，应作为独立配置加版本号，并使用未参与调优的任务进行评估。
使用工具的 Agent 做影子测试安全吗？
前提是不会意外重复外部操作，而且发送的数据适合该用途。早期回放可使用已记录响应或沙箱，同时统计重复请求费用。
回滚只需要改回模型设置吗？
不一定。需要验证回退路由，并处理进行中的任务、对话状态与外部副作用。配置回滚不会撤销已经执行的操作。
应该在官宣前迁移吗？
来源与适用范围
- Anthropic 模型概览：核查模型身份与文档。
- Anthropic 新闻：核查发布证据。
- EvoLink Fable 5.1：现有模型的基线参考。
