思考块被锁死Fable 5.1 反蒸馏新规与开发者迁移关键词Fable 5.1、Preserved Thinking、反蒸馏、thinking block、Claude API、上下文一致性适读人群直接调用 Claude Messages API、自己维护多轮对话历史的开发者以及想搞清楚「Anthropic 这次改 API 到底在防什么」的人。本文概览9 月 1—2 日美国当地 9 月 1 日国内报道为 9 月 2 日Anthropic 随 Claude Fable 5.1 上线了Preserved Thinking——回传思考块时API 会用签名校验「产生它的上下文有没有被动过」改了就报错或丢弃。这篇先把蒸馏攻击的手法讲清楚不理解攻击就看不懂防御再拆三道校验、两种模式的取舍然后给出会踩雷的写法清单和官方替代方案最后谈三个我保留意见的地方。目录一、9月2日发生了什么Anthropic 给思考块上了锁二、攻击者是怎么套走思考块的先把手法讲清楚三、Preserved Thinking 的三道校验到底验什么四、严格模式还是非严格模式两个参数、两种后果五、哪些常见写法会踩雷官方给了替代方案六、意外收益prefix 稳定之后缓存命中率带来的成本下降七、这套机制防得住吗三个值得保留的疑问给你的迁移清单一、9月2日发生了什么Anthropic 给思考块上了锁先把事实摆清楚。9 月 1—2 日Anthropic 在发布 Claude Fable 5.1与 Mythos 5.1 同一底层权重、两套安全策略的同时给 API 加了一条规则你回传的 thinking block必须和当初产生它的那套上下文严格绑定上下文被动过这段思考就不作数。官方叫它Preserved Thinking。落到 API 行为上是两句话默认严格模式系统提示、工具集或任一历史消息被改动请求直接400 invalid_request_error可选非严格模式不报错但静默丢弃受影响的 thinking block 及其之后的所有思考块模型在「看不到之前推理过程」的状态下继续作答。生效范围很关键目前只对 2026 年 8 月 31 日 00:00 UTC 之后新建的 API 账户强制执行。老账户暂不受影响Claude Code、claude.ai、Cowork 等官方产品的终端用户也不受影响。Anthropic 同时表态这套机制会在未来模型版本中推广到所有账户——现在的豁免是迁移窗口不是永久豁免。这一条规则的信息量比表面大。它既是一次安全动作也顺带改变了长对话 Agent 的成本结构第六节讲。而在讨论「该不该支持」之前得先弄明白它在防什么。这一节的一句话版本Anthropic 把 thinking block 和它的「出生上下文」焊死了改上下文就等于作废这段思考。目前只卡新账户但全面执行只是时间问题。二、攻击者是怎么套走思考块的先把手法讲清楚不理解攻击手法就看不懂这套防御为什么长这样。Claude 这类推理模型在给最终答案前会在内部走一段思维链CoT。API 会把这段过程以thinking block的形式返回给调用方——注意返回的是加密形式正常开发者看不懂内容只是把它原样存着下一轮连同系统提示、工具定义、历史消息一起传回去用来保持上下文连贯。这是官方推荐的标准用法。漏洞恰恰出在这个「回传」动作上。图一蒸馏攻击手法图一正常用法是原样带回攻击者在中间偷偷改写上下文诱导模型解密并复述推理过程批量收集明文 CoT攻击者发现只要在多轮对话中修改 thinking block 之前的系统提示或历史消息模型的上下文就自相矛盾了。在逻辑错乱的状态下它可能把原本加密的推理过程「解密」并打印出来。这类手法在圈内被叫做上下文注入context injection和对话重写conversation rewriting效果类似给模型催眠——不是攻破加密而是让模型自己把答案说出来。拿到明文 CoT 之后能干什么这正是让 Anthropic 紧张的地方能力被复制用成千上万条高质量推理链去训练一个参数小得多的模型它不必重复那套从零开始的算力堆叠靠背下顶尖模型的解题思路就能把 benchmark 刷上去。对齐没被继承这是更要命的一半。Claude 的「能力 安全护栏」是花大量成本做 RLHF 和红蓝对抗才绑在一起的。蒸馏者只提取了高智商的那部分推理能力底层的安全保障根本没法一起复制过去。用 Anthropic 自己的表述这叫能力与安全的脱钩capability-safety decoupling。一个继承了高级逻辑和代码能力、却没有对应护栏的小模型会更乐意响应生成攻击脚本或协助生物武器研发这类请求。这个判断合乎我们对蒸馏机制的理解蒸馏迁移的是行为分布不是训练时那套约束。规模上按原文与多家转述Anthropic 安全团队观测到的不是「一个账号问几个问题」而是数以千计的虚假账户 自动化脚本昼夜不停地薅。这也是它为什么宁可冒着误伤合法开发者的风险也要上强校验。攻击面的准确位置攻击面不在加密本身而在「回传时上下文可篡改」。想堵住它就得让「这段思考是在什么上下文下产生的」这件事变得可验证——这正是 Preserved Thinking 的设计目标。三、Preserved Thinking 的三道校验到底验什么API 收到一个带着 thinking block 的请求时会做三件事。这三道校验来自 Anthropic 官方开发者文档比公众号转述的「原路返回一字不差」要精确得多。图二Preserved Thinking 三道校验图二三道校验分别是模型版本、prefix 逐字节一致、思考链完整任一不过就按预设策略处理校验官方规则工程含义① 模型检查block 由产生它的模型及更新版本可读换到更旧模型则该 block 被丢弃对话升级到更新版思考保留回退到旧模型思考作废② prefix 未变顶层system、tools集合、该 block之前的每条消息逐字节一致这是最容易被日常写法破坏的一条见第五节③ 思考链完整每个 thinking block 记录前一个跨轮次从中间删掉一个其后全部失效可以从头部丢弃旧 block但不能从中间抽两个容易忽略的细节服务端 compaction 会重设起点官方提到若使用了服务端压缩被校验的 prefix 从最近的 compaction block开始算。这意味着官方托管的压缩是合法的不会误伤——但也意味着想省事就必须用官方那条路。被丢弃的 block 不计费非严格模式下被 drop 掉的思考块不计入账单这点在成本敏感的场景里值得知道。我的解读这三道校验的设计思路是把「思考」变成一个有来源、可验证的对象而不是一段可以自由搬运的文本。它不改变模型能力改变的是 API 对历史的态度——从「你说了算」变成「我可以验」。记住这一条就够了三道校验 模型版本 prefix 逐字节 思考链完整。理解「prefix 逐字节一致」这一条就理解了后面所有踩雷写法。四、严格模式还是非严格模式两个参数、两种后果prefix 校验失败时怎么处理由prefix_mismatch_behavior决定位于thinking.block_binding下需要thinking-binding-controls-2026-08-01这个 beta header 才能设置。importanthropic clientanthropic.Anthropic()# 严格模式默认上下文被动过 → 400 报错请求直接失败respclient.messages.create(modelclaude-fable-5-1,max_tokens16000,system你是客服助手。,messageshistory,# history 中带着之前的 thinking blockbetas[thinking-binding-controls-2026-08-01],thinking{type:enabled,block_binding:{prefix_mismatch_behavior:error}},)# 非严格模式不报错静默丢弃受影响的 thinking block 及其之后的所有思考块respclient.messages.create(modelclaude-fable-5-1,max_tokens16000,system你是客服助手。,messageshistory,betas[thinking-binding-controls-2026-08-01],thinking{type:enabled,block_binding:{prefix_mismatch_behavior:drop_block}},)# 被丢弃的 block 会在响应的 input_transformations 数组里列出流式时出现在 message_start 事件上面是依据官方文档描述的写法示意具体字段嵌套以 Anthropic 官方文档为准——beta 参数在 SDK 各版本间可能微调落地前请对着platform.claude.com的 Preserved Thinking 文档核一遍。两种模式怎么选我的判断是看你能不能接受「模型忘掉前面的推理」严格模式error非严格模式drop_block请求结果400 失败成功模型状态—看不到被丢弃的思考过程适用推理链是核心资产、宁可失败也不能错对话不能中断可接受质量下降风险线上直接报错需要兜底静默降级可能悄悄变差而你不自知这里有个工程上的坑值得单独提醒非严格模式是「静默」的。请求照常返回 200你从结果上很难判断这段回答是在有思考还是没思考的状态下产生的。生产环境如果走这条路线我建议必须把input_transformations记录下来做监控否则你会在某次线上效果下滑时完全找不到原因。我的建议强烈建议开发期用严格模式让问题暴露生产期若必须保可用性再切drop_block并配套监控被丢弃的 block 数量。五、哪些常见写法会踩雷官方给了替代方案这一节是本文对开发者最直接有用的部分。官方文档明确列出了一批会破坏 prefix 的常见模式——坦白讲这里面好几条是业内非常普遍的写法包括很多团队正在用的「优化」。图三会踩雷的写法与官方替代方案图三左侧是官方点名会破坏 prefix 的写法右侧是对应的一等公民替代方案× 会破坏 prefix 的写法√ 官方推荐替代每次请求重建 system prompt塞当前时间、token 预算、模式开关mid-conversation system message追加新指令不动前面的裁剪或丢弃旧轮次server-side compaction官方托管压缩客户端总结旧轮次只保留近期官方 compaction 保留最近 block往早期轮次注入提醒下一轮再删掉turn-scoped system message仅本轮生效会话中途增删toolsmid-conversation tool changes整段对话固定同一思考深度per-message effort按轮调整思考深度第一条我要重点说一下因为它太常见了「每次请求重建 system prompt把当前时间塞进去」。这几乎是所有 Agent 框架的标准操作你是助手当前时间 2026-09-05 10:30。在过去这完全无害但在新规下system 每轮都变 → prefix 每轮都变 → 之前所有 thinking block 全部失效。如果你的应用正好这么做升级到受影响账户后会立刻感受到。好在官方给的是一等公民替代而不是「你自己想办法」——mid-conversation system message、turn-scoped system message、per-message effort 都是正式支持的特性覆盖的场景比想象中全。判断口诀只有一句把messages数组当成「只追加」append-only。# × 每轮重建 system时间变化导致 prefix 失效systemf你是客服助手。当前时间{now}# √ system 固定易变信息走 mid-conversation 追加system你是客服助手。messageshistory[{role:user,content:[{type:system,text:f当前时间{now}},# 追加不改动已有前缀{type:text,text:user_input},]}]谁能松一口气用 Claude Code、claude.ai、Claude Managed Agents 或 Claude Agent SDK 的官方 SDK 会帮你维护 prefix 完整不用改代码。需要自查的直接调 Messages API、自己写 agent loop 管历史的团队。三步自查先别改代码测出自己踩没踩雷与其通读代码找可疑点不如直接量。这个流程不需要任何改造十几分钟能跑完抓两轮真实请求的 payload挑一个多轮会话把第 N 轮和第 N1 轮发给 API 的完整请求体system、tools、messages落盘成 JSON。逐字节 diff比对的粒度是「第 N 轮请求体」与「第 N1 轮请求体中、最后一个 thinking block 之前的全部内容」。只要有一个字节不同prefix 就断了。用受影响账户实测一次拿一个 8 月 31 日后新建的账户开严格模式跑同样的会话看是否返回 400若走非严格模式则看响应的input_transformations是否非空。第 2 步可以直接脚本化比人眼可靠importjson,hashlibdefprefix_fingerprint(req:dict)-str:只取「最后一个 thinking block 之前」的内容做指纹msgsreq[messages]cutlen(msgs)foriinrange(len(msgs)-1,-1,-1):blocksmsgs[i].get(content)ifisinstance(blocks,list)andany(b.get(type)thinkingforbinblocks):cuti# 该条消息之前的所有内容都算 prefixbreakpayloadjson.dumps({system:req.get(system),tools:req.get(tools),messages:msgs[:cut]},ensure_asciiFalse,sort_keysTrue,separators(,,:),)returnhashlib.sha256(payload.encode()).hexdigest()[:16]# 同一个 session 的连续两轮指纹必须一致不一致 prefix 已被破坏print(prefix_fingerprint(turn_n),prefix_fingerprint(turn_n_plus_1))指纹不一致就回到第五节那张表找对应的写法。这个方法的好处是能在改造前就定位问题而不是等线上 400 或者静默降质之后倒推。这一节的行动项把messages当 append-only。最隐蔽的雷是「重建 system prompt 塞当前时间」最省事的出路是改用官方的 mid-conversation / turn-scoped 系列特性。六、意外收益prefix 稳定之后缓存命中率带来的成本下降这次规则变更有个官方没怎么宣传、但对合法开发者实打实有利的副作用。提示词缓存prompt caching生效的前提是请求前缀逐字节不变。过去开发者自由改写上下文模型每次收到的都像是一个「新请求」缓存命中率上不去。现在新规反过来强迫所有人保持 prefix 一致——技术上正好创造了近乎完美的缓存命中条件服务器可以缓存之前的对话上下文下一轮请求直接命中。结果是延迟下降、成本下降。这组数字可以和 Fable 5.1 的定价变化对照着看缓存读取价格从每百万 token 1 美元降到0.25 美元降幅 75%输入/输出价格维持每百万 token 10 / 50 美元不变Anthropic 官方测算典型工作负载成本比 Fable 5 低约25%高度 agent 化的负载最高可降约45%。以上定价与测算均为官方口径来自 Anthropic 发布材料。我的看法这两个动作是配套的不是巧合。一边把缓存价格打到原来四分之一一边用规则逼出高缓存命中率——等于用真金白银补偿那些愿意遵守新规的开发者。对长对话 Agent 这种「反复重放同一段上下文」的场景省下来的钱可能比很多人想象的要多。不过别高兴太早这要求你的应用真的能做到 prefix 稳定。如果你因为业务需要频繁改写上下文而走了drop_block那缓存收益会打折同时还要承担静默降级的代价——等于两头不讨好。收益的前提条件缓存降价 75% 与 prefix 强制稳定是组合拳长对话 Agent 受益最明显。前提是你能做到 append-only否则收益打折。七、这套机制防得住吗三个值得保留的疑问原文标题写的是「大模型蒸馏时代结束」。我的判断是这个说法夸张了。以下三点是我认为需要保留意见的地方也是接下来值得观察的指标。疑问一只卡新账户老账户的空子有多大限制只对 8 月 31 日后新建的账户生效。而按原文描述工业级蒸馏者手里是「数以千计的虚假账户」——这类账户池大概率是在新规之前就批量注册好的。真正有组织的攻击者恰恰最可能持有老账户。那么这套机制短期内挡住的是「后来者」还是「正在干的人」这个答案目前没有公开数据支撑值得观察。疑问二堵住的是 CoT 蒸馏不是蒸馏本身。蒸馏不一定要拿推理链。用海量输入-输出对做response distillation输出蒸馏照样能迁移相当一部分能力——只是拿不到那份「高价值、带推理过程」的数据。所以更准确的说法是Anthropic 堵住了质量最高的那条蒸馏路径让蒸馏的成本和门槛都变高了但远没到「时代结束」。疑问三合法开发者的上下文压缩是刚需替代方案够不够用长对话 Agent 不压缩上下文成本就是指数级的。官方给了 server-side compaction 等替代这在方向上是对的但覆盖面需要实测复杂的自定义压缩策略比如按业务语义保留关键轮次能不能被官方方案完整替代如果不能那等于把一部分成本转嫁给了开发者。这一点我不会靠猜建议有长对话场景的团队尽快做一次对照测试。还有一个更根本的问题这到底是安全动作还是商业动作我认为两者兼有而且不必阴谋论。「能力与安全的脱钩」这个理由在技术上站得住蒸馏确实会破坏对齐的完整性同时它也客观保护了 Anthropic 的商业利益。承认两者并存比把它单纯解读成「垄断」或单纯当成「无私的安全举措」都更接近事实。保留意见汇总防住了最高质量的 CoT 蒸馏路径但没有终结蒸馏老账户豁免与压缩刚需是两个尚未闭合的口子。「蒸馏时代结束」是媒体表述不是工程结论。给你的迁移清单按优先级排序可以直接照着做先确认自己受不受影响账户是否创建于 2026-08-31 00:00 UTC 之后是否直接调 Messages API 自己维护messages两个都是「是」才需要处理。用官方 SDK / Claude Code 的可以直接跳过。全局搜一遍 system prompt 的构造位置凡是每轮动态拼接当前时间、预算、模式开关的优先改造成固定 system mid-conversation 追加。这是最隐蔽也最普遍的雷。审计历史裁剪逻辑自己做的 summarize / trim / 注入提醒再删除逐个迁到官方的 server-side compaction、turn-scoped system message、mid-conversation tool changes。开发期开严格模式让prefix_mismatch_behavior: error把问题全暴露出来别一上来就用drop_block把问题藏起来。生产环境若必须用drop_block配套监控input_transformations静默降级是最难排查的故障类型必须有可观测性兜底。顺带把缓存账算一遍如果应用属于「长对话、重复读上下文」型75% 的缓存降价叠加高命中率可能是一笔不小的成本改善值得单独测一次。关注全面执行的时间点Anthropic 已明确未来版本会推广到所有账户现在的窗口期有限别把豁免当成永久状态。#Fable5.1 #PreservedThinking #反蒸馏 #ClaudeAPI #thinkingblock #提示词缓存 思考块被锁死：Fable 5.1 反蒸馏新规与开发者迁移
思考块被锁死Fable 5.1 反蒸馏新规与开发者迁移关键词Fable 5.1、Preserved Thinking、反蒸馏、thinking block、Claude API、上下文一致性适读人群直接调用 Claude Messages API、自己维护多轮对话历史的开发者以及想搞清楚「Anthropic 这次改 API 到底在防什么」的人。本文概览9 月 1—2 日美国当地 9 月 1 日国内报道为 9 月 2 日Anthropic 随 Claude Fable 5.1 上线了Preserved Thinking——回传思考块时API 会用签名校验「产生它的上下文有没有被动过」改了就报错或丢弃。这篇先把蒸馏攻击的手法讲清楚不理解攻击就看不懂防御再拆三道校验、两种模式的取舍然后给出会踩雷的写法清单和官方替代方案最后谈三个我保留意见的地方。目录一、9月2日发生了什么Anthropic 给思考块上了锁二、攻击者是怎么套走思考块的先把手法讲清楚三、Preserved Thinking 的三道校验到底验什么四、严格模式还是非严格模式两个参数、两种后果五、哪些常见写法会踩雷官方给了替代方案六、意外收益prefix 稳定之后缓存命中率带来的成本下降七、这套机制防得住吗三个值得保留的疑问给你的迁移清单一、9月2日发生了什么Anthropic 给思考块上了锁先把事实摆清楚。9 月 1—2 日Anthropic 在发布 Claude Fable 5.1与 Mythos 5.1 同一底层权重、两套安全策略的同时给 API 加了一条规则你回传的 thinking block必须和当初产生它的那套上下文严格绑定上下文被动过这段思考就不作数。官方叫它Preserved Thinking。落到 API 行为上是两句话默认严格模式系统提示、工具集或任一历史消息被改动请求直接400 invalid_request_error可选非严格模式不报错但静默丢弃受影响的 thinking block 及其之后的所有思考块模型在「看不到之前推理过程」的状态下继续作答。生效范围很关键目前只对 2026 年 8 月 31 日 00:00 UTC 之后新建的 API 账户强制执行。老账户暂不受影响Claude Code、claude.ai、Cowork 等官方产品的终端用户也不受影响。Anthropic 同时表态这套机制会在未来模型版本中推广到所有账户——现在的豁免是迁移窗口不是永久豁免。这一条规则的信息量比表面大。它既是一次安全动作也顺带改变了长对话 Agent 的成本结构第六节讲。而在讨论「该不该支持」之前得先弄明白它在防什么。这一节的一句话版本Anthropic 把 thinking block 和它的「出生上下文」焊死了改上下文就等于作废这段思考。目前只卡新账户但全面执行只是时间问题。二、攻击者是怎么套走思考块的先把手法讲清楚不理解攻击手法就看不懂这套防御为什么长这样。Claude 这类推理模型在给最终答案前会在内部走一段思维链CoT。API 会把这段过程以thinking block的形式返回给调用方——注意返回的是加密形式正常开发者看不懂内容只是把它原样存着下一轮连同系统提示、工具定义、历史消息一起传回去用来保持上下文连贯。这是官方推荐的标准用法。漏洞恰恰出在这个「回传」动作上。图一蒸馏攻击手法图一正常用法是原样带回攻击者在中间偷偷改写上下文诱导模型解密并复述推理过程批量收集明文 CoT攻击者发现只要在多轮对话中修改 thinking block 之前的系统提示或历史消息模型的上下文就自相矛盾了。在逻辑错乱的状态下它可能把原本加密的推理过程「解密」并打印出来。这类手法在圈内被叫做上下文注入context injection和对话重写conversation rewriting效果类似给模型催眠——不是攻破加密而是让模型自己把答案说出来。拿到明文 CoT 之后能干什么这正是让 Anthropic 紧张的地方能力被复制用成千上万条高质量推理链去训练一个参数小得多的模型它不必重复那套从零开始的算力堆叠靠背下顶尖模型的解题思路就能把 benchmark 刷上去。对齐没被继承这是更要命的一半。Claude 的「能力 安全护栏」是花大量成本做 RLHF 和红蓝对抗才绑在一起的。蒸馏者只提取了高智商的那部分推理能力底层的安全保障根本没法一起复制过去。用 Anthropic 自己的表述这叫能力与安全的脱钩capability-safety decoupling。一个继承了高级逻辑和代码能力、却没有对应护栏的小模型会更乐意响应生成攻击脚本或协助生物武器研发这类请求。这个判断合乎我们对蒸馏机制的理解蒸馏迁移的是行为分布不是训练时那套约束。规模上按原文与多家转述Anthropic 安全团队观测到的不是「一个账号问几个问题」而是数以千计的虚假账户 自动化脚本昼夜不停地薅。这也是它为什么宁可冒着误伤合法开发者的风险也要上强校验。攻击面的准确位置攻击面不在加密本身而在「回传时上下文可篡改」。想堵住它就得让「这段思考是在什么上下文下产生的」这件事变得可验证——这正是 Preserved Thinking 的设计目标。三、Preserved Thinking 的三道校验到底验什么API 收到一个带着 thinking block 的请求时会做三件事。这三道校验来自 Anthropic 官方开发者文档比公众号转述的「原路返回一字不差」要精确得多。图二Preserved Thinking 三道校验图二三道校验分别是模型版本、prefix 逐字节一致、思考链完整任一不过就按预设策略处理校验官方规则工程含义① 模型检查block 由产生它的模型及更新版本可读换到更旧模型则该 block 被丢弃对话升级到更新版思考保留回退到旧模型思考作废② prefix 未变顶层system、tools集合、该 block之前的每条消息逐字节一致这是最容易被日常写法破坏的一条见第五节③ 思考链完整每个 thinking block 记录前一个跨轮次从中间删掉一个其后全部失效可以从头部丢弃旧 block但不能从中间抽两个容易忽略的细节服务端 compaction 会重设起点官方提到若使用了服务端压缩被校验的 prefix 从最近的 compaction block开始算。这意味着官方托管的压缩是合法的不会误伤——但也意味着想省事就必须用官方那条路。被丢弃的 block 不计费非严格模式下被 drop 掉的思考块不计入账单这点在成本敏感的场景里值得知道。我的解读这三道校验的设计思路是把「思考」变成一个有来源、可验证的对象而不是一段可以自由搬运的文本。它不改变模型能力改变的是 API 对历史的态度——从「你说了算」变成「我可以验」。记住这一条就够了三道校验 模型版本 prefix 逐字节 思考链完整。理解「prefix 逐字节一致」这一条就理解了后面所有踩雷写法。四、严格模式还是非严格模式两个参数、两种后果prefix 校验失败时怎么处理由prefix_mismatch_behavior决定位于thinking.block_binding下需要thinking-binding-controls-2026-08-01这个 beta header 才能设置。importanthropic clientanthropic.Anthropic()# 严格模式默认上下文被动过 → 400 报错请求直接失败respclient.messages.create(modelclaude-fable-5-1,max_tokens16000,system你是客服助手。,messageshistory,# history 中带着之前的 thinking blockbetas[thinking-binding-controls-2026-08-01],thinking{type:enabled,block_binding:{prefix_mismatch_behavior:error}},)# 非严格模式不报错静默丢弃受影响的 thinking block 及其之后的所有思考块respclient.messages.create(modelclaude-fable-5-1,max_tokens16000,system你是客服助手。,messageshistory,betas[thinking-binding-controls-2026-08-01],thinking{type:enabled,block_binding:{prefix_mismatch_behavior:drop_block}},)# 被丢弃的 block 会在响应的 input_transformations 数组里列出流式时出现在 message_start 事件上面是依据官方文档描述的写法示意具体字段嵌套以 Anthropic 官方文档为准——beta 参数在 SDK 各版本间可能微调落地前请对着platform.claude.com的 Preserved Thinking 文档核一遍。两种模式怎么选我的判断是看你能不能接受「模型忘掉前面的推理」严格模式error非严格模式drop_block请求结果400 失败成功模型状态—看不到被丢弃的思考过程适用推理链是核心资产、宁可失败也不能错对话不能中断可接受质量下降风险线上直接报错需要兜底静默降级可能悄悄变差而你不自知这里有个工程上的坑值得单独提醒非严格模式是「静默」的。请求照常返回 200你从结果上很难判断这段回答是在有思考还是没思考的状态下产生的。生产环境如果走这条路线我建议必须把input_transformations记录下来做监控否则你会在某次线上效果下滑时完全找不到原因。我的建议强烈建议开发期用严格模式让问题暴露生产期若必须保可用性再切drop_block并配套监控被丢弃的 block 数量。五、哪些常见写法会踩雷官方给了替代方案这一节是本文对开发者最直接有用的部分。官方文档明确列出了一批会破坏 prefix 的常见模式——坦白讲这里面好几条是业内非常普遍的写法包括很多团队正在用的「优化」。图三会踩雷的写法与官方替代方案图三左侧是官方点名会破坏 prefix 的写法右侧是对应的一等公民替代方案× 会破坏 prefix 的写法√ 官方推荐替代每次请求重建 system prompt塞当前时间、token 预算、模式开关mid-conversation system message追加新指令不动前面的裁剪或丢弃旧轮次server-side compaction官方托管压缩客户端总结旧轮次只保留近期官方 compaction 保留最近 block往早期轮次注入提醒下一轮再删掉turn-scoped system message仅本轮生效会话中途增删toolsmid-conversation tool changes整段对话固定同一思考深度per-message effort按轮调整思考深度第一条我要重点说一下因为它太常见了「每次请求重建 system prompt把当前时间塞进去」。这几乎是所有 Agent 框架的标准操作你是助手当前时间 2026-09-05 10:30。在过去这完全无害但在新规下system 每轮都变 → prefix 每轮都变 → 之前所有 thinking block 全部失效。如果你的应用正好这么做升级到受影响账户后会立刻感受到。好在官方给的是一等公民替代而不是「你自己想办法」——mid-conversation system message、turn-scoped system message、per-message effort 都是正式支持的特性覆盖的场景比想象中全。判断口诀只有一句把messages数组当成「只追加」append-only。# × 每轮重建 system时间变化导致 prefix 失效systemf你是客服助手。当前时间{now}# √ system 固定易变信息走 mid-conversation 追加system你是客服助手。messageshistory[{role:user,content:[{type:system,text:f当前时间{now}},# 追加不改动已有前缀{type:text,text:user_input},]}]谁能松一口气用 Claude Code、claude.ai、Claude Managed Agents 或 Claude Agent SDK 的官方 SDK 会帮你维护 prefix 完整不用改代码。需要自查的直接调 Messages API、自己写 agent loop 管历史的团队。三步自查先别改代码测出自己踩没踩雷与其通读代码找可疑点不如直接量。这个流程不需要任何改造十几分钟能跑完抓两轮真实请求的 payload挑一个多轮会话把第 N 轮和第 N1 轮发给 API 的完整请求体system、tools、messages落盘成 JSON。逐字节 diff比对的粒度是「第 N 轮请求体」与「第 N1 轮请求体中、最后一个 thinking block 之前的全部内容」。只要有一个字节不同prefix 就断了。用受影响账户实测一次拿一个 8 月 31 日后新建的账户开严格模式跑同样的会话看是否返回 400若走非严格模式则看响应的input_transformations是否非空。第 2 步可以直接脚本化比人眼可靠importjson,hashlibdefprefix_fingerprint(req:dict)-str:只取「最后一个 thinking block 之前」的内容做指纹msgsreq[messages]cutlen(msgs)foriinrange(len(msgs)-1,-1,-1):blocksmsgs[i].get(content)ifisinstance(blocks,list)andany(b.get(type)thinkingforbinblocks):cuti# 该条消息之前的所有内容都算 prefixbreakpayloadjson.dumps({system:req.get(system),tools:req.get(tools),messages:msgs[:cut]},ensure_asciiFalse,sort_keysTrue,separators(,,:),)returnhashlib.sha256(payload.encode()).hexdigest()[:16]# 同一个 session 的连续两轮指纹必须一致不一致 prefix 已被破坏print(prefix_fingerprint(turn_n),prefix_fingerprint(turn_n_plus_1))指纹不一致就回到第五节那张表找对应的写法。这个方法的好处是能在改造前就定位问题而不是等线上 400 或者静默降质之后倒推。这一节的行动项把messages当 append-only。最隐蔽的雷是「重建 system prompt 塞当前时间」最省事的出路是改用官方的 mid-conversation / turn-scoped 系列特性。六、意外收益prefix 稳定之后缓存命中率带来的成本下降这次规则变更有个官方没怎么宣传、但对合法开发者实打实有利的副作用。提示词缓存prompt caching生效的前提是请求前缀逐字节不变。过去开发者自由改写上下文模型每次收到的都像是一个「新请求」缓存命中率上不去。现在新规反过来强迫所有人保持 prefix 一致——技术上正好创造了近乎完美的缓存命中条件服务器可以缓存之前的对话上下文下一轮请求直接命中。结果是延迟下降、成本下降。这组数字可以和 Fable 5.1 的定价变化对照着看缓存读取价格从每百万 token 1 美元降到0.25 美元降幅 75%输入/输出价格维持每百万 token 10 / 50 美元不变Anthropic 官方测算典型工作负载成本比 Fable 5 低约25%高度 agent 化的负载最高可降约45%。以上定价与测算均为官方口径来自 Anthropic 发布材料。我的看法这两个动作是配套的不是巧合。一边把缓存价格打到原来四分之一一边用规则逼出高缓存命中率——等于用真金白银补偿那些愿意遵守新规的开发者。对长对话 Agent 这种「反复重放同一段上下文」的场景省下来的钱可能比很多人想象的要多。不过别高兴太早这要求你的应用真的能做到 prefix 稳定。如果你因为业务需要频繁改写上下文而走了drop_block那缓存收益会打折同时还要承担静默降级的代价——等于两头不讨好。收益的前提条件缓存降价 75% 与 prefix 强制稳定是组合拳长对话 Agent 受益最明显。前提是你能做到 append-only否则收益打折。七、这套机制防得住吗三个值得保留的疑问原文标题写的是「大模型蒸馏时代结束」。我的判断是这个说法夸张了。以下三点是我认为需要保留意见的地方也是接下来值得观察的指标。疑问一只卡新账户老账户的空子有多大限制只对 8 月 31 日后新建的账户生效。而按原文描述工业级蒸馏者手里是「数以千计的虚假账户」——这类账户池大概率是在新规之前就批量注册好的。真正有组织的攻击者恰恰最可能持有老账户。那么这套机制短期内挡住的是「后来者」还是「正在干的人」这个答案目前没有公开数据支撑值得观察。疑问二堵住的是 CoT 蒸馏不是蒸馏本身。蒸馏不一定要拿推理链。用海量输入-输出对做response distillation输出蒸馏照样能迁移相当一部分能力——只是拿不到那份「高价值、带推理过程」的数据。所以更准确的说法是Anthropic 堵住了质量最高的那条蒸馏路径让蒸馏的成本和门槛都变高了但远没到「时代结束」。疑问三合法开发者的上下文压缩是刚需替代方案够不够用长对话 Agent 不压缩上下文成本就是指数级的。官方给了 server-side compaction 等替代这在方向上是对的但覆盖面需要实测复杂的自定义压缩策略比如按业务语义保留关键轮次能不能被官方方案完整替代如果不能那等于把一部分成本转嫁给了开发者。这一点我不会靠猜建议有长对话场景的团队尽快做一次对照测试。还有一个更根本的问题这到底是安全动作还是商业动作我认为两者兼有而且不必阴谋论。「能力与安全的脱钩」这个理由在技术上站得住蒸馏确实会破坏对齐的完整性同时它也客观保护了 Anthropic 的商业利益。承认两者并存比把它单纯解读成「垄断」或单纯当成「无私的安全举措」都更接近事实。保留意见汇总防住了最高质量的 CoT 蒸馏路径但没有终结蒸馏老账户豁免与压缩刚需是两个尚未闭合的口子。「蒸馏时代结束」是媒体表述不是工程结论。给你的迁移清单按优先级排序可以直接照着做先确认自己受不受影响账户是否创建于 2026-08-31 00:00 UTC 之后是否直接调 Messages API 自己维护messages两个都是「是」才需要处理。用官方 SDK / Claude Code 的可以直接跳过。全局搜一遍 system prompt 的构造位置凡是每轮动态拼接当前时间、预算、模式开关的优先改造成固定 system mid-conversation 追加。这是最隐蔽也最普遍的雷。审计历史裁剪逻辑自己做的 summarize / trim / 注入提醒再删除逐个迁到官方的 server-side compaction、turn-scoped system message、mid-conversation tool changes。开发期开严格模式让prefix_mismatch_behavior: error把问题全暴露出来别一上来就用drop_block把问题藏起来。生产环境若必须用drop_block配套监控input_transformations静默降级是最难排查的故障类型必须有可观测性兜底。顺带把缓存账算一遍如果应用属于「长对话、重复读上下文」型75% 的缓存降价叠加高命中率可能是一笔不小的成本改善值得单独测一次。关注全面执行的时间点Anthropic 已明确未来版本会推广到所有账户现在的窗口期有限别把豁免当成永久状态。#Fable5.1 #PreservedThinking #反蒸馏 #ClaudeAPI #thinkingblock #提示词缓存