最近读到 Lance Martin 关于 Claude Fable 5 的一条长帖，里面没有把重点放在"模型又变聪明了多少"这种常见叙事上，而是讲了一个更值得开发者关注的问题：当模型能力继续提升之后，我们使用模型的方式也要跟着变化。

读完之后，我最大的感受是，Claude Fable 5 带来的改变不只是单点能力增强，而是推动我们重新理解智能体系统的设计方式。过去我们习惯把注意力放在提示词上：怎么写得更清楚，怎么加更多约束，怎么让模型一次性给出更好的答案。但 Fable 5 这类模型更适合被放进一个能反馈、能修正、能记忆的系统里运行。

我把这篇内容整理成两个关键词：循环和记忆。

第一个改变：从写提示词，到设计循环

以前使用 AI 工具时，很容易把问题归因到提示词上。模型回答不好，就继续改提示词；结果不稳定，就继续加规则；任务复杂一点，就试图把更多背景一次性塞进上下文里。

但现在对于更强的智能体模型来说，关键不一定是把提示词写到极致，而是给模型设计一个可以自我修正的环境。

所谓循环，简单说就是让模型先行动，再根据环境反馈修正自己的行动。这个反馈可以来自测试、评分标准、日志、运行结果，也可以来自一个独立的验证器。Claude Code 里的 /goal，以及 Claude Managed Agent 里的 Outcomes，本质上都在做类似的事情：给模型一个目标或评分标准，让它不断尝试、观察反馈、调整策略，直到满足条件。

这和我们写程序很像。一个工程师不会只靠脑内推理完成所有工作，他会写代码、运行测试、看报错、改实现、再运行测试。循环让模型也进入类似的工程流程，而不是只停留在"一次性生成答案"。

Lance Martin 提到的 Parameter Golf 实验让我印象很深。这个挑战要求智能体修改一个训练脚本，启动训练，查看日志和分数，然后决定下一轮实验方向。也就是说，它考验的不是模型能不能回答一个问题，而是能不能持续做实验。

在这个任务里，Fable 5 相比 Opus 4.7 对训练流水线的改进大约高出 6 倍。更有意思的是，两者探索方式不同：Opus 4.7 更像是在已有方案上调整常量，看到小收益后继续沿着同一个模板微调；Fable 5 更愿意做结构性改动，比如尝试架构级变化，并且在遇到短期回退时仍然能继续推进。

所以我在想，或许现在对于模型的强弱定义已经不只是"更会回答"，而是"更会探索"。如果我们只把它当成一个问答接口，就很容易浪费它的能力。真正能释放它潜力的，是一个允许它尝试、失败、验证、再尝试的循环系统。

第二个改变：从临时上下文，到跨会话记忆

第二个让我有感触的点是记忆。

很多时候，我们说 AI 有记忆，其实只是把之前的内容重新塞回上下文，或者从向量库里检索一些片段。但 Lance 这里讲的记忆更像是一个跨会话的外层循环：模型在一次任务中记录经验，在下一次任务中读取这些经验，并逐渐把错误、验证和规则沉淀下来。

这和我平时学习新技术的过程很像。第一次踩坑时，我可能只会记一句"这里容易错"；第二次遇到类似问题，我会回头分析为什么错；再往后，我会把它总结成一条通用规则，之后遇到类似场景就不再重新推导。

Lance 用 Continual Learning Bench 里的一个任务比较了 Sonnet 4.6、Opus 4.7 和 Fable 5。这个任务要求智能体在访问 SQL 数据库的情况下，连续回答一组问题。每个问题都是独立会话，但可以共享记忆。

他把有效使用记忆拆成了五个阶段：

  • 失败：答错后把错误记录下来

  • 调查：在继续之前弄清楚为什么错

  • 验证：把猜测变成经过检查的事实

  • 提炼：把事实总结成可复用规则

  • 查阅：后续任务直接读取规则，而不是重新推导

不同模型大致停在不同阶段。Sonnet 4.6 往往停在第一步，记下一堆失败笔记和开放猜测，但很少真正回头使用。Opus 4.7 能进一步整理 schema 参考，也会标记不确定性，但验证覆盖率不高。Fable 5 在表现好的运行中，可以把验证覆盖率提升到 73%，并把学到的内容提炼成后续任务可用的通用规则。

这让我意识到，记忆不是简单的"存下来"，而是一个持续学习流程。真正有用的记忆应该能从失败中提炼规律，并在未来任务中改变模型行为。

我对智能体设计的重新理解

读完这篇内容后，我对智能体系统有了一个更清晰的判断：未来的重点可能不是不断追求一个更完美的单次提示词，而是设计一个更好的运行机制。

这个机制至少包含两层：

  • 内层是自我修正循环，让模型可以根据目标、测试和评分标准不断改进当前任务结果。

  • 外层是记忆循环，让模型可以跨会话积累经验，把失败转化为规则，并在后续任务中复用。

也就是说，我们不只是把模型当作生成器，而是在为它搭建一个可以学习和改进的工作环境。

这也改变了我看待"提示工程"的方式。提示词当然仍然重要，但它不再是全部。对于 Fable 5 这样的模型，更重要的问题变成了：

  • 我有没有给模型明确、可检查的目标？

  • 我有没有让模型看到真实反馈，而不是只靠自我感觉？

  • 我有没有使用独立验证器来避免模型自评偏差？

  • 我有没有让模型把本次任务中的经验沉淀到下一次任务？

  • 我有没有把一次性对话，升级成可持续运行的系统？

这些问题比单纯纠结一句提示词怎么写更接近工程本质。

总结

Claude Fable 5 带来的两大改变，在我看来可以概括为：

第一，工作方式从"提示模型"转向"设计循环"。我们需要给模型目标、反馈和验证机制，让它能在任务中自我修正。

第二，上下文管理从"临时塞材料"转向"跨会话记忆"。我们需要让模型把失败、验证和规则沉淀下来，在后续任务中真正复用。

这篇内容让我意识到，越强的模型越不应该只被当成一次性问答工具。它更像是一个需要运行环境的工程组件。模型能力提升之后，真正拉开差距的，可能不是谁的提示词更长，而是谁能设计出更好的循环、更可靠的验证，以及更有效的记忆。