Anthropic 发布了面向 Claude Fable 5 和 Claude Mythos 5 的提示工程指南。这篇文档的重点不是介绍模型能力本身，而是告诉开发者：如果把旧的 Claude Opus 4.8 工作流迁移到 Fable 5，提示词、Agent harness、超时策略和安全回退都可能需要调整。
Fable 5 的变化可以概括成一句话：它更适合长时间、复杂、端到端的任务，但也更容易在高 effort 下花更多时间规划、检查和扩展上下文。用好它，关键不是把旧提示词原封不动搬过去，而是重新设计任务边界、验证方式和长任务交互。
先把任务难度拉上去测试
Anthropic 建议，不要只用简单任务测试 Fable 5。它的优势更容易出现在过去需要人工花数小时、数天甚至数周完成的工作中，比如大型代码迁移、多阶段分析、复杂 Agent 流程、跨文档研究和高精度视觉理解。
如果只用短问答、简单摘要或一次性小函数来评估，容易低估 Fable 5。更合理的测试方式是拿一类旧模型做起来费劲的任务，让模型完成从理解、计划、执行到验证的完整链路。
适合测试的任务包括：
- 让模型阅读代码库并完成跨模块修改；
- 让模型根据目标规格实现功能、补测试、跑检查；
- 让 Agent 处理多天级别的研究或分析流程；
- 让模型从截图、表格、PDF、图表中提取结构化信息；
- 让多个子 Agent 分工完成独立任务，再由主 Agent 汇总。
effort 是主要控制旋钮
Fable 5 中，effort 是控制智能程度、延迟和成本的主要参数。官方建议，大多数任务可以从 high 开始，最重的能力敏感型任务再用 xhigh，常规任务则可以用 medium 或 low。
一个值得注意的点是，Fable 5 的低 effort 档位也可能强于旧模型的高 effort 档位。也就是说，迁移时不一定要默认把所有任务都拉到最高。更好的策略是：
- 难题和高价值任务优先用
high； - 最关键的复杂推理或长任务用
xhigh； - 常规问答、轻量改写、简单工具调用用
medium或low； - 如果任务能完成但耗时过长，就降低 effort；
- 如果输出验证不足、推理不够深入，再提高 effort。
高 effort 的好处是推理和自检更强，代价是模型可能多做上下文收集、额外解释或不必要的整理。对编码任务，提示词里最好明确限制范围：
|
|
长任务要改超时、流式和进度展示
Fable 5 在困难任务上的单次请求可能运行很多分钟，自主任务甚至可能持续数小时。这是迁移时最容易踩坑的地方。
如果你的应用原来按短请求设计，需要优先检查：
- 客户端和服务端超时时间；
- 是否支持 streaming；
- 用户界面是否能展示进度；
- Agent harness 是否支持异步检查；
- 是否需要用定时任务轮询，而不是一直阻塞等待。
为了避免模型在模糊任务中过度规划，可以加一条简短约束：
|
|
这类提示比写一大段行为清单更有效，因为 Fable 5 的指令遵循能力已经更强。
让进度汇报基于真实证据
长时间 Agent 运行中，一个常见问题是模型可能给出听起来合理、但没有工具结果支撑的状态汇报。Anthropic 建议在提示词中要求模型先审计进度，再向用户汇报。
可以使用类似约束：
|
|
这对代码 Agent、数据处理 Agent 和长时间研究任务都很重要。用户真正需要的不是乐观状态，而是可追踪、可复核的进展。
边界要说清楚
Fable 5 更主动，也更可能在没有明确要求时做额外动作，比如顺手草拟邮件、创建备份分支或扩展任务范围。迁移旧提示词时，需要把“什么时候只给判断，什么时候可以动手”说清楚。
例如：
|
|
这条规则对客服、运维、开发工具和企业知识工作都适用。模型越能干，越需要清楚地定义权限边界。
子 Agent 要更主动地使用
官方文档提到，Fable 5 比旧模型更擅长调度和维持并行子 Agent。对复杂任务，不需要所有步骤都由主 Agent 顺序完成。更好的模式是把独立子任务分出去，主 Agent 继续推进主线，并在子 Agent 偏离目标时介入。
适合分派给子 Agent 的任务包括：
- 在代码库不同模块中查找相关实现；
- 独立验证某个修复是否满足规格；
- 分析不同文档或数据源；
- 对前端实现做视觉对照；
- 对最终输出做 fresh-context 审查。
对于长任务，Anthropic 还建议使用独立验证子 Agent，而不是只让模型自我批判。可以在提示词里要求：
|
|
这能减少“模型自己觉得自己对了”的问题。
记忆系统会提高长期表现
Fable 5 适合有记忆的工作流。官方建议给模型一个可以记录经验的位置，哪怕只是 Markdown 文件。关键是记录可复用的教训，而不是复制聊天记录。
一个简单规则是：
|
|
这对持续维护代码库、长期研究项目、企业知识库和复杂自动化流程尤其有用。Fable 5 不只是一次性执行器，更适合在多次任务之间积累上下文。
不要要求模型复述内部推理
迁移到 Fable 5 时，要检查旧 prompt、skill 和 system 指令里是否有“展示思考过程”“复述推理”“解释内部 reasoning”之类要求。官方文档明确提醒，这类指令可能触发 reasoning_extraction 拒绝类别，从而导致更多请求回退到 Claude Opus 4.8。
如果应用确实需要推理可见性，应该读取结构化的 thinking blocks，而不是要求模型把内部推理作为普通回复文本输出。长任务中需要把进度展示给用户，也更适合创建一个 send_to_user 之类的工具，让 Agent 在不中断执行的情况下发送必须原样展示的信息。
注意安全分类和 fallback
Fable 5 会运行面向高风险领域的安全分类器，重点包括攻击性网络安全技术、生物与生命科学内容，以及提取模型总结思维的请求。即便是正当的网络安全或生命科学任务，也可能触发保护机制。
如果请求被拒绝或分流，API 侧需要配置 server-side 或 client-side fallback 到 Claude Opus 4.8。也就是说，迁移到 Fable 5 不只是换模型名，还要重新检查失败处理、stop_reason: "refusal"、用户提示和计费路径。
给用户的最终回复要更清楚
在长时间工具调用和 Agent 工作流之后，模型可能积累很多内部上下文，最终总结容易变成只有执行者自己看得懂的 shorthand。Anthropic 建议给模型单独约束最终回复风格：先说结果，再说关键支持信息，不要把工作过程中的缩写、箭头链和内部标签直接丢给用户。
可以把最终回复要求写成：
|
|
这条对产品里的 Agent 体验很关键。用户不需要看见模型所有工作痕迹，只需要知道结果、证据、风险和下一步。
迁移时最该先改什么
如果你已经有 Claude Agent 或提示词体系，迁移 Fable 5 时可以按这个顺序检查：
- 把测试任务换成更难、更长、更完整的任务；
- 重新评估
effort，不要所有任务都默认最高； - 调整超时、streaming 和异步任务检查；
- 给长任务加上基于工具结果的进度审计；
- 明确模型什么时候能动手，什么时候只能报告判断；
- 把独立验证交给 fresh-context 子 Agent；
- 增加简单记忆系统，保存跨任务教训；
- 删除要求模型复述内部推理的旧指令；
- 配置 Fable 5 拒绝或分流后的 Opus 4.8 fallback；
- 重写最终总结风格，让用户能快速看懂结果。
Fable 5 的提示工程重点，不是写更长的规则，而是把工作流设计得更适合强模型：任务更难、边界更清楚、验证更真实、交互更异步。旧模型需要很多细碎约束才能稳定完成的事，在 Fable 5 上往往可以用更短的原则来控制；但长任务、权限边界和安全回退，反而更需要在 harness 层面提前设计好。