Anthropic 最近重新发布了 Fable 5 和 Mythos 5，随之配套更新了官方的提示指南。这篇笔记是对为 Claude Fable 5 编写提示 这篇文档的阅读整理，主要关注从 Opus 4.8 迁移过来要注意哪些行为变化，以及在 agentic 场景下如何配置 prompt 和 scaffold

背景与能力定位

Fable 5 的定位不太一样。文档一开始就说，取得最佳成果的团队会把它用在「最棘手的未解决问题」上，而不是在简单工作负载上测试它——因为那样往往会低估它的能力范围。

和 Opus 4.8 相比，几个方向有明显改进：

• 长周期自主性：能连续跑多日的目标导向任务，在长期运行中保持指令记忆能力
• 首次正确率：以往需要数天迭代的系统，有团队报告说现在可以一次性实现
• 视觉能力：解读密集技术图像、截图的准确度显著提高，还经过训练可以用 bash 和裁剪工具处理翻转、模糊或含噪声的图像
• 代码审查：跨代码库和仓库历史的缺陷发现召回率高于 Opus 4.8
• 应对模糊性：收到复杂多线程请求时能自行界定范围、提出澄清问题并执行
• 并行子 agent 调度：比之前的模型更可靠，能稳定管理与子 agent 之间的持续通信

不过有个限制需要注意：Fable 5 不适用于攻击性网络安全或生物/生命科学工作，它对此类敏感任务有严格的防护墙，这类请求会返回stop_reason: "refusal"，配置回退到 Opus 4.8。
挺搞笑的，在 X 上见到有人查 Claude Code 后台日志，发现了一个系统标签：TOO_DUMB_TO_NEED_FABLE，被工程师嘲讽：说实话，我压根没想到你们真的会去翻日志😹

行为变化与迁移要点

文档里最核心的一部分，是讲从 Opus 4.8 迁移过来会遇到的几个行为差异。

回合时长变长了。在较高 effort 设置下，单个请求可能运行数分钟，自主运行可能持续数小时。文档说这是团队适应 Fable 5 时遇到的最大转变之一。迁移前需要调整客户端超时、流式传输和进度指示器，并考虑把测试框架改成异步方式检查运行状态（比如定时任务），而不是阻塞等待。

effort 控制是主要杠杆。Fable 5 引入了high/xhigh/medium/low几个 effort 级别。文档建议大多数任务用high作为默认值，能力最密集的工作负载用xhigh，日常工作用medium或low。有个有意思的描述：Fable 5 上较低的 effort 设置通常超过先前模型xhigh的性能——也就是说，没必要无脑拉满。

再往下看，会发现在较高 effort 下它会做一些「超出任务所需」的事情：对没有问的选项进行比较、冗长地解释根本原因、写很重的 PR 描述，或给下一行代码写注释。文档说只需要一条简短的简洁性指令就能管住这些行为，不需要逐一列举。

长时间运行场景的几个要点

这部分对 agentic workflow 的设计影响较大

核实进度声明。文档特别提到，在长时间自主运行中，要指示 Fable 5 根据实际工具结果审核进度。Anthropic 自己测试的结论是：这样做能几乎完全消除虚假状态报告，哪怕是专门设计用于诱发这类问题的任务也能规避。

明确边界。Fable 5 偶尔会做未经请求的操作——比如在没被要求时起草 email、创建防御性的 git 分支备份。需要在 prompt 里明确定义它应该做什么和不应该做什么。

并行子 agent 调度。文档建议频繁使用子 agent，提供清晰的委派指导，并优先采用编排器与子 agent 之间的异步通信（而不是阻塞等待每个返回）。长期存活的子 agent 能在各子任务之间保留上下文，可以通过缓存读取节省时间，同时避免因最慢的子 agent 而出现瓶颈。

记忆系统。文档说「当 Fable 5 能够记录先前运行的经验教训并加以参考时，其表现尤为出色」。建议提供一个记录笔记的位置，简单到一个 Markdown 文件就够了。还可以让它回顾过去的会话来引导记忆系统。

两个比较少见但需要知道的情况

罕见的提前停止。在长会话的深入阶段，Fable 5 偶尔会用纯文本的意图声明（「我现在将运行 X」）结束回合而不发出工具调用，或者在已有足够信息继续时暂停请求许可。这时候回复「继续」或「直接端到端完成」就可以了。对于自主 pipeline，文档建议加一条系统提醒处理这种情况。

罕见的上下文预算担忧。在非常长的会话里，Fable 5 偶尔会建议开启新会话、提议总结并交接，或削减自己的工作。这种情况最常在测试框架向模型显示剩余 token 倒计时时触发。文档建议尽可能避免显示明确的上下文预算计数。

可读性与沟通

在扩展对话或 agent 式对话中，Fable 5 可能会生成难以理解的文本：密集的箭头链式简写、深入的实现细节、引用用户从未看到的思考内容，或过于技术化的措辞。添加沟通风格补充说明可以缓解这个问题～

迁移时的几个注意点

文档最后整理了几条建议，值得关注的：

从难度范围的顶端开始测试。选一个比分配给先前模型更难的任务，让 Fable 5 界定范围、提出澄清问题并执行。

重构现有的 prompt 和 skill。为之前模型开发的 skill 对 Fable 5 而言往往过于规定性，可能会降低输出质量。如果默认性能更好，应该审查并考虑移除旧指令。Fable 5 也擅长根据从当前任务学到的内容即时更新 skill。

个人觉得现在的模型能力越来越强，那些要求边界越明显的 skill 会消灭模型探索的能力，这要求我们编写 skill 要适当规范化和更加的通用化，不应因为过多边界而限制了模型的发挥。

不要指示 Claude 在响应中复现其推理。告诉模型将内部推理回显、转录或解释的 prompt 指令，可能会在 Fable 5 上触发reasoning_extraction拒绝类别，导致更频繁回退到 Opus 4.8。迁移时需要审核现有 skill 和系统提示中的「展示思考过程」类指令。如果应用程序需要推理可见性，应该改为读取 adaptive thinking 中的结构化thinking块。

总结

从这份文档来看，Fable 5 的核心转变是从「单次对话中的强大模型」变成了「能跑几天的自主 agent」。相应地，使用方式也需要从「逐条指令」转向「给目标、给边界、异步检查」。之前为 Opus 4.8 写的很多 prompt 技巧可能不再必要，甚至适得其反——这倒是给了一个机会重新审视并精简现有的框架。