Claude Fable 5 system prompt 解读与效果评估

最近 Fable 5 出来了，社区里有人只给 agent 换了一个 prompt，就可以提升处理任务的能力，遂来学习分析一下。

0. 结论先行

所谓 Claude Fable 5 的 system prompt，最值得关注的不是某句神奇指令，而是一套产品级 Agent 操作系统。它把模型在聊天、搜索、记忆、文件、MCP、Artifacts、安全、版权、长任务和用户偏好里的行为都写成了可执行规则。它能显著提升同一模型的任务完成体感，但提升的主要是编排能力、交付纪律和产品一致性，不是底层智力。

如果把“能力”拆开看，system prompt 对不同层的影响大致如下：

所以，“不换模型，换 prompt 能力就强很多”这句话有一半是真的。对纯智力题，它不可能把弱模型变成 Fable 5；对真实工作流，它可以把“聪明但随意的模型”变成“有工作规程的产品代理”。

1. 资料边界

本报告使用两类材料：

1. Anthropic 官方材料：Claude Fable 5 / Mythos 5 发布页、模型概览、迁移指南、Prompting Claude Fable 5、prompting best practices、以及 2026-06-12 的访问暂停声明。
2. 社区流传样本：GitHub 仓库asgeirtj/system_prompts_leaks中名为claude-fable-5.md的 prompt 文件。该文件不是 Anthropic 官方发布的 system prompt，真实性不可确认，只能作为“社区流传样本”分析。

我没有把社区样本的全文原样归档到本仓库。原因是它疑似为专有产品 prompt 的泄露文本，全文转存会造成版权和来源合规风险。本仓库中保存的是 source manifest：来源链接、抓取时间、文件大小、哈希、结构索引和分析用途说明。见raw/Claude Fable 5 system prompt source manifest.md。

2. 官方能确认什么

截至 2026-06-23 检索到的官方信息里，Claude Fable 5 是 Anthropic 在 2026-06-09 发布的 Mythos-class 模型，定位为当时能力最强的广泛发布模型，主打复杂推理、长周期 agentic work、软件工程、知识工作、视觉和企业工作流。官方还说明，Fable 5 与 Mythos 5 是同一底层模型的不同可用形态，Fable 5 面向广泛可用场景并带有更强 safeguards，Mythos 5 面向受限的 Project Glasswing 访问。

官方文档里与 prompt 分析最相关的是这几类事实：

• Fable 5 支持 1M context window 和 128k max output，定位为长任务模型。
• Fable 5 的 adaptive thinking 是 always on；迁移时不能再按旧模型习惯手动控制 extended thinking budget。
• 它有effort作为智能/延迟/成本控制，官方建议多数任务从high开始，最敏感任务再用xhigh。
• API 可能返回stop_reason: "refusal"，尤其涉及 offensive cybersecurity、biology/life sciences、reasoning extraction 等类别时。
• 官方 prompting guide 特别强调：长任务的进度声明必须基于工具结果；足够信息时要行动；明确边界以避免无关重构；可大量使用 parallel subagents；要构造 memory system；长任务最好有 send-to-user 工具。

这说明 Fable 5 的“强”不是只来自 system prompt。它本体能力确实更强，官方也把它描述为比 Opus 4.8 更擅长长周期、自主、复杂、多线程任务。但官方同时给了很具体的 scaffolding 建议，说明模型越强，越需要重新设计 prompt、工具和 workflow。

3. 社区流传样本的整体形态

社区样本文件的本地抓取版本为：

• 行数：3825
• 词数：25544
• 字节数：187672
• SHA-256：e9af7d784b2c6e6f5027c5cb6290076e8313c5bc88e50dc9dae56d8dfb87f1b2

它不是单段 prompt，而是一个分层协议。大体结构如下：

这套结构的本质是：把 Claude.ai 这个产品的所有隐性行为都显式写进上下文。普通用户看到的是一个聊天模型，system prompt 里实际装的是产品规则、工具协议、合规策略、记忆策略和交付规范。

4. 为什么它看起来强

4.1 它把“会不会做”改成“默认会做”

裸模型经常停在解释层：用户要报告，它给大纲；用户要文件，它贴正文；用户要继续上次，它说看不到历史；用户要查当前信息，它凭训练记忆回答。

这份 prompt 会把这些场景路由到实际能力：

• 用户要当前事实，使用 search / web_fetch。
• 用户提到“上次”“我的项目”“我们决定的方案”，使用 conversation_search 或 recent_chats。
• 用户要文件，真正创建文件并放到输出目录。
• 用户要 PPT、Word、PDF、XLSX，先读对应 skill，再生成产物。
• 用户要图表、流程、交互解释，判断是否用 Visualizer 或 Artifact。
• 用户提到第三方服务，先看 MCP connector，而不是随便编一个流程。

这不是模型突然更聪明，而是默认行为从“回答”升级成“执行”。

4.2 它用工具结果约束进度汇报

官方 Fable 5 prompting 文档强调，长任务里每个进度声明都应能指向本轮工具结果。这是 agent 可靠性的核心。

如果没有这个约束，模型很容易产生“状态幻觉”：说已经跑了测试但实际没跑，说已经修复但只是计划，说文件已生成但路径不存在。社区样本和官方指南都在围绕同一个问题：长任务中，用户不是在评估模型的表达，而是在依赖它对现实状态的报告。

这条规则的价值极高。它能降低两类严重失败：

• 虚假完成：模型宣布 done，但没有验证。
• 虚假阻塞：模型过早停下，问一个其实不需要问的问题。

4.3 它把“什么时候停”写清楚了

强模型的常见失败不是不会做，而是过度做：无关重构、过度解释、创建没要求的文件、设计抽象、加兼容层、写防御性备份、把问题扩大成系统工程。

Fable 5 官方提示建议明确边界：用户只是提问或讨论时，交付物是评估，不要动手修；用户要求 bug fix 时，不要顺手重构；可逆且符合原始请求的动作应继续，不要用“你要我继续吗”来阻塞。

这对 coding agent 尤其关键。好的 agent 不只是多做，而是知道什么是不该做的范围蔓延。

4.4 它把记忆变成“自然使用”，而不是“展示使用”

社区样本里的 memory 规则非常细。核心不是“多用记忆”，而是“只在相关时使用记忆，并且不要暴露检索动作”。

它区分了几类情况：

• 用户直接问自己的事实，且 memory 中有答案：直接答事实，不铺垫。
• 用户请求个性化：可以使用相关记忆。
• 普通技术问题：不要突然提用户背景。
• 敏感记忆：除非用户主动提到，否则不要拿出来个性化。
• 历史对话细节：memory 不够时搜索 past chats，而不是假装知道。

这解决了 memory 产品的核心张力：不用记忆会失去连续性，乱用记忆会让人觉得 creepy。

4.5 它把用户偏好做成 relevance gate

很多个人化系统会犯一个错误：只要用户偏好里有“我喜欢 X”，以后所有回答都硬套 X。社区样本明确规定，背景偏好只有在当前任务直接相关时才应用；行为偏好只有在不牺牲安全、正确性和相关性时才应用。

这是一种很成熟的产品判断：用户偏好不是人格投喂材料，而是任务质量优化信号。

4.6 它把安全做成“边界 + 话术 + 不泄露检测机制”

安全模块不是简单的 blacklist。它会规定：

• 哪些类别必须拒绝。
• 哪些类别可以提供高层次、保护性、事实性信息。
• 拒绝时说原则，不说检测细节。
• 高风险上下文下少说比多说更安全。
• 不要为了帮用户而“重写问题使其看起来安全”。

这类设计对产品很重要，但也会带来误拒。官方 Fable 5 文档也提到，Fable 5 的 safeguards 会覆盖 offensive cybersecurity、biology/life sciences 和 reasoning extraction，良性任务也可能触发。

5. 模块级解读

5.1 产品身份与知识截止

这一层告诉模型：你是谁、有哪些产品、哪些产品事实可能变化、什么时候要查官方文档。

作用不是身份扮演，而是减少 self-knowledge hallucination。LLM 对自身产品、价格、功能、模型 ID 最容易过时，因为这些信息变化快，训练语料永远滞后。把产品信息放进 system prompt，并要求遇到新产品问题先查 docs，是产品级助手的必要设计。

可迁移原则：任何面向真实用户的 AI 产品，都应该把“我是谁、能做什么、不能做什么、当前配置是什么、哪些信息必须查源”写进 runtime context，而不是依赖模型记忆。

5.2 拒绝与安全

安全部分覆盖儿童安全、自伤、心理健康、饮食障碍、武器、毒品、恶意代码、法律金融建议、公共人物创作和政治/伦理争议等。

它的设计重点是稳定性：

• 不因用户换一个说法就改口。
• 不为了显得有帮助而给出边界附近的可操作细节。
• 不把拒绝写成冷冰冰的合规声明。
• 不告诉用户怎么绕过规则。

这会让 Claude 产品更可控，但也会影响高风险专业领域的可用性。对于开发者来说，关键不是照抄安全文本，而是按自己的产品风险定义“可帮助范围”和“拒绝话术”。

5.3 语气与格式

这一层控制输出体验。它要求自然、少过度格式化、简单问题短答、复杂问题才使用结构，不要总是追问，不要在拒绝时用项目符号。

这类指令非常有价值，因为它修正了 LLM 的默认坏习惯：每个回答都写成报告，每个答案都带免责声明，每个澄清都问三五个问题。

可迁移原则：语气 prompt 不应该只写“专业友好”，而要写清楚常见反模式。例如：不要过度列表，不要把用户已决定的事情重新辩论，不要用压缩符号牺牲可读性。

5.4 Memory system

记忆系统是社区样本里最复杂的产品逻辑之一。它既要让 Claude 像一个有上下文的长期协作者，又要避免把用户的历史暴露成“我正在调用你的资料”。

它包含三层规则：

1. 应用规则：什么问题用记忆，什么问题不用。
2. 边界规则：敏感、令人不适、可能鼓励不健康行为的记忆不能主动提。
3. 表达规则：不要说“我看到”“根据我的记忆”“你的资料显示”。

这对任何 agent 产品都很重要。记忆不是越多越好，而是要有 relevance、safety、surprise 三个门槛：相关、不会伤害、用户不会觉得突兀。

5.5 Past chats tools

Past chats 与 memory 不同。Memory 是压缩后的长期画像，past chats 是可检索的原始对话片段。社区样本规定，当用户使用“我的项目”“上次那个方案”“我们讨论过的 bug”这类共享上下文语言时，模型应该搜索历史，而不是让用户重新解释。

这条规则体现了一个非常重要的产品洞察：不必要的搜索成本低，错过历史上下文的成本高。对长期协作型 AI，历史检索是 continuity 的基础设施。

5.6 User preferences

偏好系统的核心是防止过拟合。它明确区分行为偏好和上下文偏好，并要求只有在能实质提高当前回答质量时才使用背景信息。

对用户来说，这会减少“AI 过度记得我”的反感；对产品来说，这能让个性化不破坏任务本身。

5.7 MCP Apps 与工具建议

MCP 相关规则体现了一个平台型产品的约束：当用户要连接外部服务时，模型不能随便选择供应商，尤其是第三方消费类工具。它需要先搜索 connector、建议用户选择、等待 opt-in，只有用户点名或已有稳定偏好时才直接调用。

这说明 system prompt 不只是模型行为指令，还是商业生态规则：不能替用户选择商家，不能制造连接压力，不能用假 UI 模拟真实工具。

5.8 Computer use 与 Skills

这一块是“从聊天到交付”的关键。它规定文件在哪里、上传文件怎么读、新文件怎么写、输出目录怎么交付、何时创建 artifact、何时读 skill。

其中 skill 机制尤其重要。模型在生成 Word、PDF、PPT、XLSX、前端 UI 之前，先读对应 SKILL.md。这相当于把长期经验沉淀成外部操作手册，而不是塞进一个无限增长的主 prompt。

可迁移原则：system prompt 应该保持为总调度层，具体格式、仓库、领域、工具约束放进可按需加载的 skills。

5.9 文件创建与 Artifacts

社区样本明确区分：

• 聊天内回答：策略、总结、解释、简短代码。
• 文件产物：文章、报告、组件、脚本、PPT、长文、可复用参考。
• Artifact：可渲染、可交互、可复用的独立产物。

这解决一个高频失败：用户要“生成文件”，模型只贴正文。对产品来说，交付不是“内容存在于聊天里”，而是“用户能打开、保存、分享、继续编辑”。

5.10 Search、版权与引用

搜索模块的目标是降低时效性幻觉。它规定当前职位、价格、政策、产品状态、陌生新实体、近期新闻等必须搜索；稳定知识不搜索；复杂问题按复杂度扩大工具调用。

版权模块则规定不要复现长段原文，不要把搜索结果重写成替代原文的摘要，不要引用歌词、诗歌等完整作品。

这两者结合，构成了 web-enabled LLM 的底层纪律：该查时查，查到后用自己的话说，并给出来源。

5.11 Anthropic API in Artifacts

这一模块允许 Artifact 内部调用 Anthropic API、MCP 和 web search，等于支持“AI-powered artifacts”。它还规定了结构化输出、文件输入、MCP result parsing、错误处理、UI 限制等。

这说明 Claude.ai 的 Artifacts 不只是静态 HTML，而是逐渐变成可运行的小型应用平台。system prompt 需要教模型如何在这个平台里正确写应用，而不是只会写网页片段。

6. Prompt 的真实增益来源

可以把增益拆成五类：

6.1 路由增益

模型知道某类请求该走哪个能力路径。比如“总结网页”走 web_fetch，“继续上次方案”走 past chats，“做 PPT”走 pptx skill，“画流程”走 Visualizer。

这是最明显的提升，尤其在工具丰富的产品环境里。

6.2 证据增益

模型不再凭语言自信输出状态，而是把文件、测试、搜索、工具结果作为事实来源。这个增益对 coding agent、研究 agent、数据分析 agent 都很大。

6.3 范围控制增益

强模型容易过度工程。好的 system prompt 会定义 stop condition：何时行动、何时停、何时问、何时不要擅自扩大范围。

6.4 连续性增益

Memory 和 past chats 让用户不用反复重建上下文。长期协作中，这会带来接近“换了一个更懂我的模型”的体感。

6.5 表达增益

少一点模板味、少一点免责声明、少一点无意义列表，最终体验会显著提升。很多时候用户感受到的“聪明”来自表达选择，而不是底层推理差异。

7. Prompt 不能带来的东西

这份 system prompt 再强，也不能替代模型本体能力。

它不能让模型掌握训练中没有、也没有搜索到的信息；不能凭空提升复杂数学证明能力；不能保证弱模型在大型代码库里维持长程一致性；不能在没有工具权限时真的读文件、跑测试、查历史；不能避免所有安全 false positive。

如果把它照搬到一个没有 Claude.ai 工具环境的模型里，很多规则会变成空指令。更严重的是，它会制造工具幻觉：模型以为自己能调用 MCP、Artifacts、past chats 或 memory_user_edits，但宿主环境根本没有这些能力。

8. 如果要复用，应该复用什么

不要照抄 180KB prompt。应该提炼成四层：

1. Root operating contract：身份、目标、证据纪律、暂停条件、交付标准。
2. Tool router：当前环境有哪些工具，各类任务如何路由。
3. Domain skills：文档、代码、数据、前端、研究等专业手册按需加载。
4. Memory and verifier loop：长期经验沉淀、历史检索、独立验证。

一个更适合自己产品/agent 的短版 system contract 可以是：

你是一个交付型研究与工程代理。先判断用户是在提问、讨论、请求修改、请求产物、请求搜索、请求历史上下文，还是请求运行代码。 当信息足够时直接行动，不要重复分析已经确定的事实。只有在破坏性操作、真实范围变化、或缺少只有用户能提供的信息时暂停询问。 所有进度和完成声明必须能对应本轮工具结果。没有验证就说未验证；测试失败就给失败输出；跳过步骤就明确说明。 用户请求文件或可复用产物时，必须创建实际文件。用户请求当前事实、价格、政策、职位、版本或陌生实体时，必须先查源。 不要做任务外的重构、抽象、功能扩展、兼容层或清理。优先完成用户原始目标。 最终回复先给结果，再给关键证据、文件位置、验证情况和剩余风险。

如果用于 coding agent，再加：

修改代码前先读相关文件和现有测试。优先遵循仓库既有模式。实现后运行最小充分验证。不要回滚用户已有改动。遇到无关脏工作区时只改自己的文件。

如果用于研究 agent，再加：

区分官方来源、二手报道、社区样本和推断。对当前信息优先查官方/一手来源。结论必须标注可信度和适用边界。

这些短规则通常能拿到 70% 以上的行为收益，且不会浪费巨大上下文。

9. 建议的 A/B 评估方法

如果想直观看到“同模型换 prompt”的效果，可以做一个小评测。

9.1 实验组

• A 组：裸 system prompt，只写身份和安全基本要求。
• B 组：加入 Fable-style operating contract，约 1-2k tokens。
• C 组：加入更完整的 tool router + memory + verifier + output rules，约 4-8k tokens。

9.2 任务集

9.3 指标

• 任务成功率：是否完成用户原始目标。
• 工具调用准确率：该用工具时用了，不该用时没乱用。
• 虚假完成率：声称完成但没有证据的比例。
• 不必要暂停率：本可继续却问用户的比例。
• 范围蔓延率：做了用户没要求的重构/扩展。
• 产物可用率：文件是否存在、格式是否可打开。
• 用户可读性：最终答复是否结果先行、简洁、可操作。

9.4 预期结果

最明显的差距会出现在文件产物、长任务、代码修复、当前事实和历史上下文任务上。纯知识问答或短数学题的差距会小得多。这个结果能清楚说明：system prompt 提升的是 agent workflow，而不是模型智力本体。

11. 风险与反面教材

直接复制社区流传 prompt 有几个问题：

1. 来源风险：社区样本不是官方发布，真实性不可验证。
2. 合规风险：疑似专有 system prompt，全文转存和复用可能不合适。
3. 工具错配：里面有 Claude.ai 专属工具，别的环境不存在。
4. 上下文浪费：180KB 规则会吞掉大量 prompt budget。
5. 过度约束：某些规则服务 consumer Claude，不一定适合 coding agent 或研究 agent。
6. 时效风险：产品信息、价格、模型 ID、工具接口会变化。
7. 冲突风险：复制进已有 agent 可能与本地开发者指令、仓库规则冲突。

更好的做法是抽象行为原则，然后用自己的运行环境重新实现。

12. 最终判断

Claude Fable 5 system prompt 的核心价值不是“提示词秘方”，而是一个成熟 AI 产品如何把模型能力包装成可靠工作流的样本。它强在三点：

第一，它把工具、记忆、搜索、文件和安全都纳入同一个行为协议。
第二，它把长任务中的虚假进度、过度暂停和范围蔓延当作一等问题处理。
第三，它把用户体验细节写得足够具体，从而减少 AI 默认的模板化、啰嗦和不落地。

如果要用一句话概括：Fable-style system prompt 不会让模型更会思考，但会让模型更像一个知道如何工作的代理。

参考来源

• Anthropic: Claude Fable 5 and Claude Mythos 5, https://www.anthropic.com/news/claude-fable-5-mythos-5
• Anthropic: Statement on the US government directive to suspend access to Fable 5 and Mythos 5, https://www.anthropic.com/news/fable-mythos-access
• Claude API Docs: Models overview, https://platform.claude.com/docs/en/about-claude/models/overview
• Claude API Docs: Migration guide, https://platform.claude.com/docs/en/about-claude/models/migration-guide
• Claude API Docs: Prompting Claude Fable 5, https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
• Claude API Docs: Prompting best practices, https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Community sample manifest saved in this repository:raw/Claude Fable 5 system prompt source manifest.md