Claude Fable 5.1 深度拆解：缓存读取降价 75% 的账怎么算、effort 五档怎么选、长程 Agent 怎样才不跑丢

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

一句话结论：Fable 5.1 的基础单价一分没降（每百万 token 输入 10 美元、输出 50 美元），真正变的是缓存读取从 1 美元砍到 0.25 美元，降幅 75%。这个改动只对「重度 Agent、上下文反复复用」的场景有意义，官方给出的口径是普通负载总成本降约 25%，重度 Agent 负载最高降约 45%。同时，8 月 31 日之后新注册的 API 账号，思考块被绑定在产生它的那一次对话上，历史消息必须只追加、不能回头改——这条比降价更容易让你的老代码当场报 400。

上面这段是给只想要结论的人看的。往下是完整拆解：我会把缓存这笔账用具体数字算一遍，讲清楚 effort 五个档位各自适合什么活儿，分析长程任务「跑到一半忘了目标」这件事在这一代被怎么改的，梳理护栏一松一紧之后哪些事能做、哪些事被转走，最后给出在国内环境下落地时必须过的合规关口和一份上手自查清单。

想看完整拆解，往下翻。

一、这次发布真正值得记住的三件事

Anthropic 在 2026 年 9 月 1 日同时放出了 Claude Fable 5.1 和 Claude Mythos 5.1。官方页面上写得很直白：这两个是同一个底层模型，区别只在护栏（safeguards）的松紧程度。Fable 5.1 面向所有人开放，Mythos 5.1 只走受审核的可信访问计划，服务网络安全防御和生命科学两个方向。

发布当天各家媒体的稿子铺天盖地，跑分表贴了一屏又一屏。但我自己把官方公告、定价文档、提示词工程文档翻了一遍之后，觉得对一个真正要拿它干活的人来说，值得记住的其实就三件事。

第一件，价格结构变了，但不是你以为的那种「降价」。

基础定价原封不动，每百万输入 token 10 美元，每百万输出 token 50 美元。变的是缓存读取（cache read）那一项：从原来的 1 美元降到 0.25 美元。这不是普通的打折，而是计费倍率被改了——一般 Claude 模型的缓存命中价是基础输入价的 0.1 倍，而 Fable 5.1 和 Mythos 5.1 被单独调成了 0.025 倍。定价文档里专门加了一条脚注说明这个例外。

这意味着什么？意味着如果你的活儿是「问一句答一句」，这次降价跟你几乎无关。但如果你在跑 Claude Code、跑多轮工具调用、跑长上下文的 Agent，缓存读取本来就占了账单的大头，那这刀就砍在了最肉的地方。

第二件，模型的性格变了，长程稳定性是这一代的主线。

官方原话是 Fable 5.1 会避开那些「让成果质量变差的捷径」，会去修问题的根因。最有说服力的一个例子来自投资机构 Millennium：他们内部系统里有一个大约百万分之一概率才触发的崩溃，团队四五年没找到原因，试过的模型（包括 Fable 5）都没搞定。Fable 5.1 的做法是把第三方厂商的库反汇编，跟核心转储对上，最后把病根定位到那个外部库里。

这类案例的价值不在于「哇好厉害」，而在于它说明了这一代模型的能力形态：不是单点回答变强，而是能在一条很长的排查链路上不掉链子。

第三件，API 层面有一个破坏性变更，很多人会踩。

从 2026 年 8 月 31 日起新建的 API 账号，Fable 5.1 返回的思考块（thinking block）只在产生它的那一次对话里有效。如果你的框架在两次请求之间改动了前缀——系统提示词、工具列表、或者任何更早的消息——再把之前的思考块回放上去，API 会直接返回 400。老账号目前不受影响，但官方明确说了，后续所有新模型都会对全员强制生效。

这三件事，我会在后面分别用一整章展开。先从最容易算错的那笔账开始。

二、把缓存读取这笔账算清楚

2.1 先搞明白「缓存」在大模型 API 里到底缓存了什么

这个词很容易被望文生义，我第一次接触的时候也理解错了，以为是「问过的问题会记住答案」。不是的。

大模型的 API 是无状态的。你每发一次请求，整个提示词——系统提示、工具定义、历史消息，全部要重新走一遍编码。多轮对话越聊越长，你每一轮都在为前面那一大坨内容重复付钱。

提示词缓存（prompt caching）解决的就是这个。你在某个内容块上打一个标记（cache_control），API 会把这个标记之前的所有内容编码好存下来。下一次请求如果开头那部分一模一样，就直接从缓存里读，不用重算。

这里有个关键点，很多人栽在上面：它是前缀缓存，顺序敏感，逐字节匹配。缓存的匹配范围是「工具定义 → 系统提示 → 消息」这个固定顺序，一直到你打标记的那个块为止。前缀里哪怕差一个 token，缓存直接失效，你按原价付全款。

我自己踩过的坑是在系统提示里塞了一个当前时间戳。看起来无伤大雅，结果每一轮请求的前缀都不一样，缓存命中率是零，账单直接翻了几倍才发现问题。时间戳这类动态内容，要么挪到最后，要么干脆别放。

用一张图把这个结构画出来会更清楚：

flowchart LR
    A["工具定义<br/>tools"] --> B["系统提示<br/>system"]
    B --> C["历史消息<br/>messages"]
    C --> D["本轮新输入"]
    B -.打断点.-> M1["缓存段 1"]
    C -.打断点.-> M2["缓存段 2"]
    D --> E["按原价计费"]
    style M1 fill:#e8f4ea
    style M2 fill:#e8f4ea
    style E fill:#fbe9e7

图里的原则就一条：越稳定的内容放越前面，越动态的内容放越后面。断点最多能打四个，打在稳定内容的末尾。断点之后的所有东西，每次都是新鲜输入，全价计费。

2.2 缓存不是免费的，写入要加价

这是第二个容易忽略的地方。缓存本身有成本：

• 写入缓存（5 分钟有效期）：按基础输入价的 1.25 倍计费
• 写入缓存（1 小时有效期）：按基础输入价的 2 倍计费
• 读取缓存：一般 Claude 模型是 0.1 倍，Fable 5.1 和 Mythos 5.1 是 0.025 倍

有效期这件事也有个细节：每次读取缓存，计时器会重置。所以一段聊得比较密的对话，缓存会一直「热着」，你不需要反复付写入费。但如果两次请求隔了十几分钟，缓存已经过期，你就得重新付一次 1.25 倍的写入费，然后可能还没等到第二次读取就又凉了——这种间歇性负载，开缓存反而是亏的。

用中文把盈亏平衡点写出来（不用数学符号，纯文字表达）：

5 分钟档：
    写入成本 = 1.25 × 基础输入价
    每次读取节省 = 基础输入价 - 缓存读取价
    → 一般模型（0.1 倍）：读满 1 次即回本
    → Fable 5.1（0.025 倍）：读满 1 次即回本，且回本后的每一次都更省

1 小时档：
    写入成本 = 2 × 基础输入价
    → 一般模型：读满 2 次回本
    → 需要连续复用同一前缀，才值得开

2.3 现在来算 Fable 5.1 这笔账

假设一个典型的 Agent 编程场景：系统提示加工具定义加已经读进来的代码文件，稳定前缀大约 10 万 token。这段内容在一次任务里被反复读取，比如 50 轮。

按 Fable 5 的旧价格（缓存读取 1 美元每百万 token）：

写入一次：100000 ÷ 1000000 × 10 × 1.25 = 1.25 美元
读取 50 次：100000 ÷ 1000000 × 1 × 50   = 5.00 美元
前缀部分小计                              = 6.25 美元

按 Fable 5.1 的新价格（缓存读取 0.25 美元每百万 token）：

写入一次：100000 ÷ 1000000 × 10 × 1.25   = 1.25 美元
读取 50 次：100000 ÷ 1000000 × 0.25 × 50 = 1.25 美元
前缀部分小计                              = 2.50 美元

同一段前缀，6.25 变 2.50，省了六成。这就是官方说「重度 Agent 负载最高省约 45%」的来源——之所以整体只有 45% 而不是 60%，是因为账单里还有输出 token、还有断点之后的新鲜输入，这两块一分钱没降。

官方公告里给的口径写得很实在：这个 25% 和 45% 是拿 2026 年 8 月连续四周的真实用量、按默认 effort 档测出来的。普通负载覆盖的是 Claude Enterprise、Claude Code 和 API 的整体使用；重度 Agent 负载指的是上下文重、工具重、缓存读取占成本大头的那类活儿。

把三种典型场景的受益程度列个表，方便你对号入座：

2.4 一个反直觉的推论：压缩上下文可能不再划算

这一点是我翻提示词工程文档的时候才注意到的，官方在讲上下文压缩（compaction）的时候顺带提了一句：因为缓存读取变便宜了，「为了省钱而尽早压缩上下文」在 Fable 5.1 上可能已经不是最优的成本与智能权衡了，建议试试把压缩点往后挪。

这个推论挺重要的。过去大家做长程 Agent，一个常规操作就是上下文一到某个长度就赶紧做摘要压缩，因为长上下文太贵。现在缓存读取只要 0.025 倍，保留完整上下文的边际成本大幅下降，而压缩本身是有信息损耗的——摘要总会丢掉细节。所以在新的价格结构下，「留着」的性价比可能高于「压掉」。

莫潇羽这边的实操建议是：如果你已经有一套压缩策略，别急着照搬到新模型上，把压缩阈值往后调一档做个 A/B，用你自己的评测集看质量和成本的曲线，别拍脑袋。

2.5 三个必须提醒的现实问题

第一，缓存写入是尽力而为的。 文档里说得很清楚，API 不保证一次写入在下一次请求时一定可读。实践中命中率很高，但你的成本模型不能假设 100% 命中。

第二，缓存有最小 token 门槛。 内容太短是不会被缓存的，不同规格的模型门槛不一样，小模型的门槛更高。给一个只有几百 token 的系统提示打断点，纯属白打。

第三，价格随时会变。 大模型的定价变动非常快，上面这些数字是我写稿时官方定价页面的口径，请以实时数据为准。另外，境外模型的计费币种是美元，实际支出还要叠加汇率与支付渠道成本，做预算的时候别忘了这一块。

三、effort 五档：比换模型更值得先拧的那个旋钮

3.1 很多人的成本失控，问题不在模型上

我见过不少人吐槽旗舰模型烧钱，仔细一问，全都是把「模型」「effort 档位」「套餐额度」这三件事混成一件了。

这三者是相乘的关系。你把模型换成最强的那个，但 effort 拉到 low，简单问题照样消耗不了多少；反过来，你 effort 拉到 max，问一句「今天几号」，也烧不了几个 token。真正把额度打光的，是三个都往「强」的那一边推的组合。

所以在换模型之前，先把 effort 这个旋钮搞明白，收益比什么都大。

3.2 五个档位分别是什么

Claude 的 effort 参数目前是五档：low、medium、high、xhigh、max。官方文档给的定位大致是这样：

有个概念要先解释清楚：effort 是行为信号，不是严格的 token 预算。文档里专门强调了这一点——在低档位下，遇到足够难的问题模型照样会思考，只是相比高档位思考得少一些。它不是一刀切的「只准想 N 个 token」。

另外还有一个容易搞混的：Claude Code 里的 ultrathink 不是第六个档位，它是在提示词里被匹配到的关键词，效果是把当前这一轮的 effort 往上顶一格，属于临时加档，不是设置项。

3.3 Fable 5.1 上的档位使用建议

这里有两条我觉得很有价值的官方建议，专门针对 5.1：

第一条，即使你在 Fable 5 上已经扫过一遍档位，换到 5.1 也要重新扫。 原因是同名档位在不同模型上对应的思考量并不一样。这条很反直觉，但确实如此，别拿老配置直接迁移。

第二条，5.1 的 low 档很值得单独看一眼。 文档说，在 low 档下 Fable 5.1 在「每任务成本」上常常能跟 Opus、Sonnet 系列打得有来有回，而分数更高。翻译成人话就是：那些你原本准备用中小模型跑、还得给它拉高 effort 的活儿，可以把 5.1 的 low 档拉进来一起比一比，结论未必是你想的那样。

在 medium 档，5.1 的效果大致能对上 Fable 5，但成本更低。所以如果你的评测集显示质量够用，往下降一档到 medium 甚至 low 是有明确收益的。

3.4 低档位的一个副作用，得单独说

Fable 5.1 在 low 档有个行为变化：它调用搜索和检索工具的频率比 Fable 5 低，更倾向于凭记忆回答。

这个副作用在做资讯类、时效类任务的时候杀伤力很大。模型对某个名字有个模糊印象，就直接答了，而那个印象可能已经过时半年。

官方给的两个解法：一是把受影响的那几轮临时提到高一档（effort 支持对话中途切换），而不是整段对话都拉高；二是在系统提示里加一句引导，大意是「认得一个名字，不等于知道它现在的状态」，遇到快速变化领域的名词要先搜。

我把这条思路做成了自己的常备提示片段，效果不错：

当问题围绕一个你不能确信认识的名称展开，或者这个名称属于
AI 模型、开发者工具这类几个月就变一轮的领域时，这个名称本身
就是最需要核实的东西：先搜索再回答，并且至少有一条查询要
原样使用用户写的那个名称。哪怕你有一些背景知识也照做——
半吊子的背景知识恰恰是让过时答案听起来很权威的原因。

3.5 高档位的另一个副作用：会把成品先想一遍再写一遍

这是 xhigh 和 max 档上的一个具体问题，官方文档写得很坦白：在这两档下，模型可能会在思考阶段就把整份长成品草拟一遍，然后在回复里再写一遍。结果就是等待时间翻倍、输出 token 翻倍，成品质量却没变好。

处理办法有两个：

一是默认别用高档跑长文档。官方的推荐起点就是 high，只有当你实测出质量增益才往上走。

二是如果确实要在高档跑，把 max_tokens 设大（要给思考和回复都留够空间，因为它是二者之和的硬上限），并且在用户消息末尾加一段说明，告诉模型「思考和回复共用一个额度，把成品写两遍会把这一轮的长度翻倍而不改善结果」。文档里给了完整措辞，实测能显著缩短思考长度。

莫潇羽@源码七号站 的经验是：写长文档这类任务，high 档几乎就是最优解，往上加档纯属交学费。

四、长程任务为什么会「跑丢」，这一代改了什么

4.1 长程 Agent 的三个经典死法

现在的模型早就不怕写代码了。真正难的是让它连续跑几个小时、调几十个工具还不出事。我自己搭 Agent 的时候，反复遇到的是这么三种死法：

第一种，忘了最初的目标。 跑到第三十轮，模型开始围着某个子问题打转，原始需求早就不知道飘哪去了。

第二种，报错之后治标不治本。 测试红了，它去改测试用例，让测试变绿；类型报错，它加一个类型忽略把警告压掉。表面上「完成了」，实际上埋了雷。

第三种，话说到一半就停。 最后一段写着「接下来我会……」，然后回合就结束了，等着你回一句「继续」。人在旁边盯着的时候这不算事，异步跑批的时候这就是纯粹的浪费。

Fable 5.1 在这三点上都有动作，但方式不太一样：有的是模型行为本身变了，有的是给了你提示词层面的抓手。分开说。

4.2 「不走捷径」是这次最实在的行为变化

官方对 5.1 的核心描述是：避开那些让成果质量变差的捷径，去修根因。前面提过的 Millennium 那个百万分之一崩溃的案例，就是这条的极端证明——它没有停在「加个 try catch 把崩溃吞掉」，而是一路追到第三方库的反汇编。

早期合作方的反馈里，还有几条描述值得注意。有做基础设施的团队提到，涉及三个代码库、八个以上服务的一次改动，模型能把从入口调用一路到具体函数、再到数据库表和行的完整链路都梳理出来，而且一路都是准确的。也有做事故排查的团队说，在用真实生产事故做根因分析的评测里，它的推理强度超过了上一代旗舰。

这类反馈的共同点是：能力体现在链路长度和追踪深度上，而不是单点回答的漂亮程度。

4.3 但「跑完整件事」还是需要你明确要求

这里有个反直觉的事实：模型能力强了，不代表它默认会一口气跑完。官方文档里专门有一节叫「完成整个任务」，讲的就是模型有时候会描述下一步而不是去做，或者为一个原始需求早就覆盖了的步骤停下来问许可。

官方给的解法是往系统提示里加两段话，第一段的开头一句是关键：明确告诉模型「你在自主运行，用户不在实时盯着，问『要不要我……』会直接卡住工作」。文档说这一句承担了大部分效果，建议原样保留。

我把这段思路整理成中文版，放在自己的 Agent 里用：

你正在自主运行。用户不会实时查看，也无法在任务中途回答问题，
所以「要不要我……」「我是否应该……」这类提问会直接阻塞工作。

对于源自原始需求、且可回退的操作，直接执行，不要询问。
只有破坏性操作，或者需要用户拍板的真实范围变更，才停下来。
任务完成后再提出后续建议是可以的；动手之前先要许可，不行。

结束这一轮之前，检查你的最后一段。如果它是一个计划、一段分析、
一个问题、一串后续步骤，或者一句关于尚未完成工作的承诺
（「我接下来会……」「完成后告诉我……」），那就现在用工具去做掉。
这包括出错后自己重试、缺信息自己去找。不要因为上下文很长就停下。

例外：当用户是在描述问题、提问或者出声思考，而不是在要求改动时，
交付物就是你的判断本身。给出结论然后停下，不要擅自动手修。

最后那个例外条款很有必要。不加的话，你随口说一句「这段代码好像有点慢」，它可能直接开始重构。

4.4 顺手改一堆东西，也得管一管

5.1 还有一个倾向：交付的东西比你要的多。顺手修了旁边的 bug，扩展了任务没提的行为，或者提交了远超改动规模的测试文件。

官方给的抑制指令核心意思是：跑的过程中发现的既有 bug、性能问题、任务没提到的行为，除非不修就实现不了需求，否则不要动，写进总结当作后续项报告；验证过程可以随便写脚本，但临时检查不要变成永久测试文件；测试只在任务要求或者仓库本来就有这个惯例时才提交，规模跟旁边的测试文件对齐。

文档里给的实测结论是：加了这段之后，多余的添加和提交的测试代码显著减少，任务成功率没有可测量的变化。这是个白拿的优化。

4.5 工具调用批处理：一个容易被忽略的提速点

5.1 在大多数情况下会正常并行调用工具。但有一类例外：在编程和计算机使用的循环里，当「下一步该调哪几个工具」是任务隐含的、而不是你明说的时候，它可能一轮只发一个调用。

答案质量不受影响，但每多一轮就多一次往返、多一份 token、多一段等待时间。官方给的解法是在请求末尾加一句很短的引导，大意是「先在心里列出接下来需要什么，然后把所有不依赖别人结果的项目，在这一次回复里一起请求」。

这一句怎么放，有讲究——这就要接到下一章那个最容易踩的坑了。

4.6 上下文压缩要保住哪些东西

如果你是在客户端自己做上下文压缩（而不是用服务端的 compaction），摘要写什么直接决定了新窗口能不能接得上。

官方给的摘要指令列了六项必须保住的内容，我把它整理成一张表：

还有一条权重规则值得单独拎出来：用户说过的话要贴近原话保留，模型自己的解释和推理可以大幅压缩，只留结论和产物。这个不对称的权重设计很聪明——用户的意图是不可再生资源，模型的推理是可再生的。

五、上下文只追加：反蒸馏机制会怎么影响你的代码

5.1 先说清楚「蒸馏」是怎么回事

蒸馏（distillation）本来是个中性的技术词：用一个能力强的大模型产出大量高质量的问答数据，拿去训练一个小模型，让小模型学到大模型的行为方式。学界和工业界都在用，本身没什么问题。

问题出在规模化的滥用上。官方公告里的说法是，这类操作经常以工业化规模进行，动用成千上万个虚假账号。而 Anthropic 把它定性为安全风险的理由是：被蒸馏出来的能力，可能会在没有相应护栏的情况下被发布出去。也就是说，你辛苦训练的对齐和安全机制，被人绕过一层皮直接拿走了。

5.2 被堵上的是哪个口子

被堵的是一个已经公开记录在案的手法：在多轮对话里手动编辑 Claude 之前的上下文，同时保留 Claude 之前的思考过程记录。通过反复改写前文、观察思考块的变化，就能把模型的思维链一点点掏出来。

Fable 5.1 的做法是在 API 层面加了一道校验：思考块只在产生它的那一次对话里有效。

具体规则是这样的：

条件：2026 年 8 月 31 日（含）之后创建的 API 账号

行为：如果一次请求回放了某个思考块，
      而这个思考块的前缀（系统提示 / 工具列表 / 任何更早的消息）
      跟当初产生它的时候不一致

结果：默认返回 400 错误
      或者，如果你显式设置了 drop_block 行为，
      则把受影响的思考块整个丢掉

老账号目前不受影响，但官方已经把话说明白了：未来的所有新模型，这条校验会对全员强制生效。所以这不是「要不要适配」的问题，是「早适配还是晚适配」的问题。

5.3 哪些操作会踩线

这里有个特别有意思的巧合：会触发这道校验的历史编辑操作，跟会让提示词缓存失效的操作，是同一批。

文档里点名的几种：

• 每一轮往历史里注入一段提醒，下一轮再把它删掉
• 就地把较早的几轮对话改写成摘要
• 会话中途修改系统提示或者工具定义

这三种在实际的 Agent 框架里都很常见。第一种尤其常见——很多人为了让模型别忘记某条规则，会在每轮的历史里塞一份提醒，用完就删。这个模式在 5.1 上是直接违规的。

把它画成图对比一下：

flowchart TB
    subgraph BAD["会踩线的写法"]
        direction TB
        B1["第 1 轮历史"] --> B2["注入提醒"]
        B2 --> B3["第 2 轮：删掉旧提醒<br/>再注入新提醒"]
        B3 --> B4["前缀已变<br/>缓存失效 + 思考块校验失败"]
    end
    subgraph GOOD["推荐写法"]
        direction TB
        G1["第 1 轮历史"] --> G2["追加回合级系统消息"]
        G2 --> G3["第 2 轮：旧的原样留着<br/>再追加一份新的"]
        G3 --> G4["前缀字节不变<br/>缓存保住 + 校验通过"]
    end
    style B4 fill:#fbe9e7
    style G4 fill:#e8f4ea

5.4 正确的姿势：回合级系统消息

官方给的替代方案叫回合级系统消息（turn-scoped system message）：在 messages 数组里放一条 role 为 system 的条目，带上 clear_at 为 next_user_message。

它的巧妙之处在于：一旦出现了更晚的用户消息，API 会自动清掉之前的那些副本，模型只读得到最新的一份，而被清掉的那些不占输入 token。但它们在数组里的字节没有被你改动过，所以缓存前缀是连续的，思考块的校验也过得去。

用一句话总结这个模式：每一轮追加一份新的，旧的原封不动留在原地，让 API 去负责清理。

对应的迁移动作我列成一张对照表：

最后那条尤其干净利落。既然不回放思考块，就不存在校验失败的问题，模型在压缩后的上下文上重新思考一遍。代价是丢掉了之前的思考连续性，好处是绝对不会出错。

5.5 怎么知道自己的框架有没有踩线

有两个办法，我都试过：

第一个，用诊断模式跑一遍。 把 prefix_mismatch_behavior 设成 drop_block，跑一个正常会话，把返回里的 input_transformations 记下来。有任何被丢掉的块，就说明你的框架在改历史。

第二个，更土但更靠谱：抓包对比。 把连续几轮请求原样录下来，逐字节比对——正确的情况下，后一次请求应该跟前一次请求在追加部分之前完全一致。有任何一个字节对不上，就是有编辑行为。

我个人推荐两个都做。第一个能告诉你「有问题」，第二个能告诉你「问题在哪一行」。

5.6 我对这件事的态度

平心而论，这个改动对绝大多数开发者是没有实质损失的。只追加的历史管理本来就是更干净的工程实践，被逼着做一次也不算坏事，顺带还把缓存命中率救回来了。

真正受影响的是少数做了复杂上下文编辑的自定义集成。官方也说了会分阶段推进，帮助中心有专门的文章讲开发者该做哪些调整。

但从行业角度看，这件事的信号意义比技术意义大：头部厂商开始在 API 层面给能力扩散上锁了。以前大家默认「顶级模型的能力会通过各种途径快速外溢」，这条路正在被系统性地收窄。这对国产模型的追赶节奏会有什么影响，现在下结论还早，值得持续观察。

六、护栏的一松一紧：现在能做什么，不能做什么

6.1 松的那一半：误报大幅下降

过去有个很尴尬的场景：程序员拿模型审自己家的代码，结果被安全分类器当成攻击者拦下来。这类误报（false positive）在实际工作里非常伤，因为它打断的是完全正当的防御性工作。

这次官方给的数据是：网络安全方向最新护栏拦下的误报比之前少了 60%，Claude Code 用户平均每个会话遇到的护栏干预大约下降六成。生物学方向的动作更大——针对基础生物学和医学问题这类无害请求，护栏的触发频率相比 Fable 5 刚上线时下降了 85%。

误报下降的一部分原因是能力边界本身放开了：Fable 5.1 现在允许被用于发现软件漏洞。

6.2 紧的那一半：边界画在哪里

这里要把话说准确。官方的原文表述是：允许用于发现软件漏洞，但不允许用于为这些漏洞开发利用程序。

具体被转走（redirect 到管束更严的 Opus 系列模型）的是几类双重用途任务：

Mythos 5.1 拿到的是更宽松的护栏，但访问方式是白名单：走网络安全验证计划（CVP）和生命科学验证计划（LSVP）两个可信访问项目，而且目前只面向美国的一批机构开放，正在协调扩大范围。官方对 Mythos 5.1 的定性是「我们发布过的模型里网络安全能力最强的」，同时说明它仍处在自家前沿合规框架的较低风险档位。

6.3 国内开发者必须补上的那一课

上面这些是模型厂商的护栏，跟你在国内的法律义务是两码事。这里必须把话说清楚：

模型允许你做，不等于法律允许你做。

在国内做安全相关的工作，绕不开《中华人民共和国网络安全法》和《网络产品安全漏洞管理规定》。核心的几条常识：

• 未经授权对他人的网络、系统、应用进行扫描、测试、渗透，是违法行为，跟你用什么工具没关系
• 发现漏洞后，有按规定报送和不得擅自公开的义务，不能自行披露细节
• 不得向他人提供专门用于侵入网络、干扰网络正常功能的程序、工具

所以正确的用法是：只在你自己拥有或者已获得书面授权的代码和系统上做安全分析。这一条不是模型的护栏，是你自己的红线。

另外，