Claude Fable 5.1 将思考块绑定至单一对话 —— 导致智能体丢失推理能力的四种编辑操作 (2026)

三份官方文档对此进行了描述，它们各自阐述了不同的侧面。发布日志宣布了这一消息，What's new in Claude Fable 5.1 页面总结了这一破坏性变更，而专门的 Preserved thinking 页面则包含了完整的规则和迁移清单。第四篇面向消费者的帮助中心文章（在同一天更新）展示了在完全不接触 API 的情况下，该机制是如何运作的。

思考块现在带有模型和签名

该规则具有方向性。用 Anthropic 的话来说：“每个思考块都会记录是哪个模型生成了它，并且它仅单向保留：Claude Fable 5.1 可以读取早期模型的思考块，而早期模型无法读取 Claude Fable 5.1 的思考块。”

因此，向高级模型迁移的对话会保留其推理。向低级模型迁移的对话则会在该轮交互中丢失推理。Fable 5.1 接受来自 Opus 5、Fable 5、Mythos 5 及更早模型的思考块。而这些模型都无法读取 Fable 5.1 的思考块。

当请求携带了目标模型无法读取的思考块时，“API 会在模型看到该块之前将其丢弃。” 丢弃的思考块不予计费。对于调试至关重要的一点是：通过使用 thinking-binding-controls-2026-08-01 Beta 测试版请求头，丢弃情况会在顶层的 input_transformations 数组中报告。根据文档，如果不使用该请求头，“丢弃将是无声无息的。”

在模型检查之上，还有另外两项检查。API 会验证“该块之前的任何内容都没有改变” —— 包括顶层的 system 提示词、tools 中的工具集以及该块之前的每一条消息 —— 并且“早期思考块的链条没有断裂”，因为“跨轮交互中，每个思考块都会记录前一个思考块”。

导致其后所有内容失效的四种编辑操作

发布页面清晰地列出了这些模式。以下操作会使之后的所有思考块失效：

• “编辑、重新排序或删除较早的轮次，同时保留较晚的轮次。”
• “在较早的轮次中注入单次请求文本（如提醒或状态行），并在下一次请求中将其删除。”
• “在同一对话的请求之间重新构建顶层 system 提示词或 tools 数组。”
• “在后续请求中提供不同字节数据的图片或文档 URL（检查针对的是字节数据而非 URL，因此针对同一文件的轮换签名 URL 是没有问题的）。”

“四种”只是官方的简要总结，并非全部情况。Preserved thinking 页面将相同的内容扩展成了一个包含更多行的表格 —— 编辑工具、从历史记录中间删除思考块、重新组织轮次范围内的消息。在断定你的框架没有问题之前，请先阅读该表格。

在强制执行该检查的情况下，重放已失效思考块的请求将返回 400 错误，其错误信息为 The block is bound to a different conversation。

请注意这四种操作中哪一个是陷阱。第二种并不是什么罕见的代码：在较早的消息中注入每轮提醒并在下一次请求中将其剥离，是引导长工具循环的常用技巧，而这会让你付出失去其后所有思考块的代价。

哪些操作依然有效，以及目前对谁强制执行

文档同样明确指出了哪些操作不属于编辑，而且这个列表比人们想象的要宽容得多。在末尾追加消息是没有问题的。从历史记录的开头删除思考块、移动 cache_control 标记以及更改 max_tokens、output_config 或 tool_choice 也是可以的。服务器端压缩和上下文编辑也明确是可行的，因为“检查对比的是你发送的内容，而不是服务器编辑后的副本”。

强制执行是分阶段进行的，日期非常精确：“新账户是指在 2026 年 8 月 31 日 00:00 UTC 或之后创建的账户。” 这些账户从今天起就会受到该检查的限制。对于老账户，不匹配的情况会被记录下来，但只有在请求设置了 prefix_mismatch_behavior 时才会采取行动。需要提前规划的是这句具有前瞻性的话：“后续模型将对所有用户强制执行此检查。”

这引出了整篇文档中最有用的警告，针对的是任何发布供他人运行的工具的开发者：“如果你维护一个供人们使用自己的 API 密钥运行的工具或框架，新账户的用户会比你先遇到这个检查：因为你自己的密钥很可能是在老账户上。”

消费者端：你的记忆可能会改变模型

同一天，Anthropic 更新了一篇帮助中心文章，解释了为什么 Claude 会在 Fable 5 和 Fable 5.1 的对话中途切换模型。这篇文章是为从未见过 messages 数组的用户写的，但得出的结论是一样的。

Fable 5.1 会在每次请求时运行安全分类器，被拦截的请求会进行回退：“当你的请求回退时，Claude 会在同一对话中，在 Opus 模型上重新运行被拦截的 Claude Fable 5 或 Fable 5.1 请求。” 接着：“切换后，在对话的剩余部分中，模型选择器将保持在 Opus 上。”

这就是聊天窗口中呈现的方向性规则。你的对话刚刚转移到了一个无法读取 Fable 5.1 推理过程的模型上。

该页面上的另外两句话值得深思。被拦截的类别之一是“针对 Fable 5 和 Fable 5.1 的蒸馏攻击，包括试图提取模型总结性思考的尝试” —— 这告诉了你这种绑定关系存在的根本原因。而且，分类器不仅读取你最新发送的消息：“检查还会审查模型读取的所有内容，而不仅仅是你的最新消息 —— 包括记忆、来自连接器的内容、网页搜索结果和文件，因此拦截可能会由你未输入的内容触发。”

仔细阅读这段话。你记忆层中的内容可能会触发模型切换，而模型切换正是导致推理过程被丢弃的原因。

这并没有让 Claude Fable 5.1 的记忆能力变差。这里没有任何内容涉及到持久记忆这一功能，也没有任何内容会缩减这两个模型默认配备的 1M token 上下文窗口。

此外，这并不是一个伪装成政策的削弱。Anthropic 直接说明了原因：签名检查的存在是“为了防止在某一组指令下产生的推理被重放到另一组潜在的对抗性指令下”。将其与消费者端被拦截的蒸馏类别结合来看，你就得到了一个双层防御机制。将其称为退步是对它的误读。

它确实改变的是消息数组的状态。在此之前，messages 是你可以重写的工作记忆：就地总结旧的轮次、修补提醒、在引入新工具时重新构建系统提示词。但在 Fable 5.1 上，该数组更接近于一个带有校验和的仅追加日志。你系统中那些做出其他假设的部分现在需要另寻他处。

它还改变了回退的代价。以前，根据价格或可用性轮换模型的路由机制只是牺牲了一点质量。现在，它还可能会丢弃推理链，而且除非你启用了 input_transformations，否则这种丢弃是在不通知你的情况下默默发生的。

“Fable 5.1 现在会遗忘事情。” 事实并非如此。绑定机制控制的是推理块是否可以被重放到请求中。这与 Claude 在对话之间记住的关于你的信息无关，那是一个拥有独立控制的独立系统。

“所以我应该停止传回思考块。” 这也是错误的，而且代价高昂。Fable 5.1 会读取早期模型的块以及它自己的块；在漫长的智能体交互轮次中重放它们是保持推理链完整的关键。解决办法是停止编辑历史记录，而不是停止发送它。

“这只影响编写原始 API 调用的人。” 大体属实，但有例外。文档指出，Claude Code、claude.ai、Claude Managed Agents 和 Claude Agent SDK 会为你保持前缀完整。如果你是自己构建 messages 数组 —— 包括在包装器、代理或评估框架内部 —— 你就是那个必须进行检查的人。

“400 错误是最坏的情况。” 400 错误其实是好情况，因为你知情了。默默丢弃的情况更糟糕：在没有 Beta 测试版请求头的情况下，由于模型降级导致思考块被丢弃，或者轮换的文档 URL 悄悄提供了不同的字节数据。

“我可以直接关闭检查。” 你可以选择发生不匹配时的处理方式 —— 使用 "drop_block" 代替默认的 "error" —— 但丢弃并不等于保留。API 会“删除该块以及对话中其后的每个思考块”。这是一个合理的生产环境默认设置，而不是一种修复手段。

仅追加规则是对特定事物的一个限制：单个对话的请求体。它并没有规定你项目的持久知识应该存放在哪里。这种区分就是整个解决方案的核心，也是为什么那些已经将约定、决策和偏好保存在对话记录之外的记忆层中的团队，几乎没有受到这次发布的影响。

记忆层的工作方式正是该检查所期望的。较早的轮次中不会重写任何内容，因为事实从未存在于其中。而且由于存储是外部的，同样的知识在回退到刚刚丢弃了你推理链的 Opus 时依然能够存活 —— 并且在之后的模型中也能存活。MemoryLake 采取了三个步骤。

步骤 1：创建 API 密钥

登录并在你的控制面板中生成一个 API 密钥。这是你的智能体、框架或后端用于读写记忆的凭证，它与对话当前运行在哪个 Claude 模型上无关。这种独立性正是关键所在：从 Fable 5.1 回退到 Opus 改变了能够读取你思考块的模型，但完全不会改变能够读取你记忆的内容。

步骤 2：上传你的第一批记忆

将你原本想注入到较早轮次中的内容放在这里。内部约定、已做出的决策及其背后的原因、名称、定义以及智能体不断重新学习的规则。如果你一直在维护一个冗长的系统提示词，并且每当项目细节发生变化时就重新构建它，那么这种重新构建现在就是四种会导致失效的编辑操作之一 —— 请将其易变的部分移入记忆，而将稳定的部分留在 system 中。

步骤 3：连接你的 AI 和智能体

将你的框架指向该存储，检索就会在轮次的开始阶段发生，而不是通过重写历史记录的后部来实现。实际上，这意味着你的每轮上下文是从外部源组装并追加的，而不是被修补到六轮之前的消息中。这正是签名检查所要求的形式，也是保持提示词缓存处于热状态的形式。

对于漫长的智能体运行，最直接的变化是引导必须移动到对话的末尾。提醒变成了追加的轮次或轮次范围内的系统消息；工具更改通过对话中途的工具更改路径进行，而不是通过重新构建 tools 数组；裁剪则交给服务器端压缩或上下文编辑，该检查在设计上会忽略这些操作。

对于前面设有路由器的任何系统，变化在于你需要可见性。发送 thinking-binding-controls-2026-08-01 Beta 测试版请求头并记录 input_transformations，可以将无声无息的丢弃变成你可以统计的数据行。Anthropic 官方的检测方案是：运行一个正常的、将 prefix_mismatch_behavior 设置为 "drop_block" 的多轮会话，并读取返回的内容。

对于其他所有人 —— 即在浏览器中使用 Claude 的人 —— 实际的变化更小也更奇特。如果安全回退将你的对话转移到了 Opus，编辑你之前的消息是文档中记录的解决办法：“在重试之前编辑你之前的消息通常会有所帮助。” 这与 API 端的建议恰恰相反，但两者都是正确的，因为它们针对的是不同的层级。“不要编辑历史记录”是针对请求体的规则，而不是针对你如何使用聊天窗口的规则。

一个关于成本的提示也指向了相同的方向：导致思考块失效的模式在很大程度上也是导致提示词缓存失效的模式。解决其中一个问题，另一个问题也就迎刃而解了。

• 完全按返回的原样追加 assistant 轮次。 逐字节对应，包括空思考块及其签名。
• 绝不修补较早的轮次。 每轮提醒应放在具有 clear_at: "next_user_message" 的轮次范围内系统消息中，这会保留在 messages 中且不消耗 token，同时保持后续块有效。
• 在对话中途不要动 system 和 tools。 使用对话中途的系统消息以及工具添加和删除路径，而不是重新构建这两个数组。
• 在服务器端进行裁剪。 压缩和上下文编辑不计为编辑。而客户端对较早轮次的总结则算作编辑。
• 通过 ID 引用文件。 检查针对的是字节数据，而不是 URL。
• 在需要之前主动开启可见性。 发送 Beta 测试版请求头并记录 input_transformations，这样被丢弃的块就会成为一个指标，而不是一个谜团。
• 像新账户一样进行测试。 你自己的密钥可能在老账户上，因此请显式设置 prefix_mismatch_behavior。
• 将持久知识保留在 messages 之外。 任何你原本会注入到历史记录中的内容都属于记忆层，而且在处理时，你的智能体实际读取的内容非常值得审计。

Claude Fable 5.1 最瞩目的变化并不是缓存读取的价格。而是你发送的对话已经变成了一个已签名、与模型绑定且仅追加的对象，并且四种普通的编辑习惯现在会让你付出失去模型推理能力的代价 —— 其中一种还是在无声无息中发生的。

这一限制虽然严格，但解决方法都是 Anthropic 随之发布的官方功能。更好的消息是，人们以前塞进消息数组中的大部分内容本来就不属于那里。推理与单个对话绑定是有意为之的。而你项目的知识则完全不需要与任何东西绑定。