# Claude Fable 5.1 为何要求新 API 账号的思考历史只能追加？ **Summary:** Claude Fable 5.1 将保存的思考绑定到生成它的原始上下文。新 API 账号首当其冲，智能体框架应利用这段宽限期进行测试，以免未来模型全面推行该规则时出现集成故障。 - Canonical: https://markhuang.ai/zh/news/claude-fable-51-thinking-history-append-only - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-01 - Section: News - Tags: Claude Fable 5.1, Claude API, AI 智能体, API 兼容性, AI 安全 - Source: [Anthropic](https://www.anthropic.com/claude-fable-and-mythos-5-1) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一串发光的玻璃推理模块被固定在琥珀色晶格中，新的模块正靠近开放的一端](https://cdn.markhuang.ai/news/claude-fable-51-thinking-history-append-only/hero.webp) *Fable 5.1 将保存的思考视为不可变对话前缀的一部分。新轮次可以加入链条，但修改之前的内容可能会导致链条断裂。* [Anthropic 推出 Claude Fable 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1) 时重点宣传了基准测试成绩和定价。页面深处还藏着一项可能让智能体循环出问题的 API 变更：2026 年 8 月 31 日 00:00 UTC 及之后创建的新 API 账号，Messages API 会检查保存的思考块之前的消息、工具和系统提示有没有被动过。不匹配就直接返回 400 错误。 我觉得这项安全控制合情合理，但迁移风险同样值得重视。智能体框架在会话中压缩历史、重建系统提示、更换工具，这些都是常规操作。Fable 5.1 的问题在于，开发者做这些事时不能再改动产生过模型思考的那段前缀。 目前这条规则只管新账号，而且只针对通过 API 和支持的云平台使用 Fable 5.1 的情况。Anthropic 说现有账号暂时不受影响，但未来模型会对所有用户强制执行思考块绑定。趁现在还有宽限期，赶紧测试，别等下次切模型时老集成突然挂掉。 ## 模型发布还改变了对话契约 Fable 5.1 亮点不少。Terminal-Bench 4.0 得分 55.8%，比 Fable 5 的 42.0% 涨了一大截；缓存读取降到每百万 Token 0.25 美元。模型已在 Claude API、Amazon Web Services、Google Cloud 和 Microsoft Azure 上线，模型名 `claude-fable-5-1`。 但真正该上集成检查清单的，是防蒸馏这块改动。Anthropic 的[保存思考说明](https://support.claude.com/en/articles/16761192-preserved-thinking-changing-how-the-messages-api-handles-thinking-blocks-to-protect-against-distillation)写得很清楚：API 会校验返回的思考块是否和当初生成它时的系统提示、工具、消息完全匹配。前缀对不上，开发者只有两条路——要么拒绝请求，要么选择丢弃受影响的思考块，让模型在更少上下文下继续。 丢掉思考块后请求能继续走，但模型看到的上下文变少了。HTTP 调用可能照样成功，集成行为却已经不一样了。Anthropic 说响应里会报哪些块被丢弃了，这个信息一定要记进日志和评估结果里。 ```mermaid flowchart LR A[保存的思考块] --> B{之前的上下文变过？} B -->|没变| C[保留思考继续] B -->|变了，严格模式| D[返回 400 错误] B -->|变了，丢弃模式| E[丢弃受影响的思考] E --> F[带着更少上下文继续] ``` ## 为何要绑定思考模块？ Anthropic 把这项限制定性为防蒸馏措施。担心的是，有人把加密的推理块搬到改过的对话里，诱导模型把隐藏推理以明文吐出来。这样一来，大规模收集推理轨迹去训练别的模型就容易多了。 2026 年 8 月的一篇论文[《Stealing Reasoning Traces from Proprietary LLM APIs》](https://arxiv.org/abs/2608.09867)就描述了这种跨会话、跨用户、跨模型搬运加密推理块的攻击方式。作者在 Anthropic、OpenAI、Google 上都做了演示。负责任披露之后，他们提出了密码学和系统层面的缓解方案。论文很新，我不觉得它能代表所有生产系统的最终结论，但它确实印证了把思考块绑回原始上下文这个威胁模型。 我觉得这个防御思路没问题。一套工具下产生的推理块，不该在另一套可能带有恶意的指令下不经校验就重放。真正的问题是：API 能不能挡住这种攻击，同时不把日常的上下文管理搞得过于脆弱。 ## 普通框架行为现在可能被视为篡改 Anthropic 的[开发者文档](https://platform.claude.com/docs/en/build-with-claude/preserved-thinking)把兼容性边界讲得很实在。直接调 API 的话，消息数组只能追加。裁掉旧轮次、用客户端摘要替换、注入然后再移除提醒、用当前时间重建系统提示、改工具列表——这些操作都可能让后面的思考块失效。 平台也给了官方替代方案。服务端压缩可以缩短工作上下文，新的消息类型可以带更新的指令和工具变更，不用去动前面的字节。这样对话看起来更像事件日志：新状态往后追加，而不是悄悄改掉产生当前状态的那段记录。 > **Info:** > > 如果你的框架直接调 Messages API，只要涉及压缩上下文、换工具、加提醒、轮换动态系统文本、或者把对话切到别的模型，我都建议过一遍。 发布过程还有个尴尬的细节。Anthropic 提醒框架维护者：用了新 API key 的用户可能比维护者自己更早撞上强制校验，因为维护者的账号往往注册更早。这会搞出最头疼的那种兼容性 bug——客户报上来了，开发者用同样的代码和模型却复现不了。 ## 我会在 CI 里让未来的规则直接报错 老账号不用等自动强制执行。文档说请求可以加 `thinking-binding-controls-2026-08-01` beta header，配合 `prefix_mismatch_behavior` 设置主动开启绑定校验。我会拿有代表性的多轮会话跑这条路径，CI 里直接选报错模式。硬性报错能把第一个被改过的前缀揪出来。 测试集要覆盖那些 demo 里经常跳过的状态切换：跨压缩边界、换工具、刷新动态系统值、触发模型回退，还要跑够长让提醒重复出现。请求体要按共享前缀做对比。生产环境如果用丢弃模式，`input_transformations` 字段必须记录并统计——HTTP 响应照样 200，不代表模型没丢掉之前的思考。 测试还得模拟一个新客户组织。当前规则覆盖新注册的 Claude Platform 组织和 Amazon Bedrock 账号，以及截止日期之后新建的 Google Cloud Vertex AI 和 Microsoft Azure Foundry 项目。Claude Code、Claude Cowork、Claude.ai、第三方产品，以及 Fable 5.1 以外的模型，都不在这次强制执行范围内。 ## 安全修复要当 API 迁移来对待 早期[公开讨论](https://www.reddit.com/r/ClaudeAI/comments/1w4juj2/introducing_claude_fable_51_and_claude_mythos_51/)大多集中在跑分提升、缓存降价、订阅用户能不能跟着省钱这些话题上。问题本身没问题。但对维护智能体循环的团队来说，保存思考更可能把升级变成集成事故。 Anthropic 不让推理块在改写过的对话之间随意搬运，理由很充分。新 API 也给了迁移方案，没有一刀切禁止长对话。但这项控制确实改变了"什么才算一次合法对话"的定义，开发者应该把它当成 API 契约变更来看。 Fable 5.1 对新账号直接上规则，对老账号给警告。我的做法很直接：能追加就追加，动态状态走官方支持的消息类型，趁老账号还能选的时候把拒绝路径测一遍。迟早会有模型把这条规则推到所有人头上。