重新理解智能体系统：Claude Fable 5 提醒我们的两件事

最近读到一条关于 Claude Fable 5 的长帖，里面没有继续重复“模型又变聪明了多少”这种叙事，而是把问题往前推了一步：当模型能力继续上升之后，我们使用模型的方式，也必须跟着变。

这件事真正值得关注的地方，不是 Fable 5 又在某个榜单上多拿了几分，而是它让智能体系统的设计逻辑变得更清楚了。

过去我们很容易把注意力放在提示词上：提示词怎么写得更清楚，约束怎么加得更完整，背景信息怎么一次性塞进上下文。但对更强的智能体模型来说，真正能释放能力的，可能不是一条更长的 prompt，而是一个能反馈、能验证、能沉淀经验的运行系统。

如果用两个关键词概括，就是：循环和记忆。

第一个变化：重点从“写提示词”转向“设计循环”

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

他把有效使用记忆拆成了五个阶段：失败、调查、验证、提炼、查阅。

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

这里的关键不是“记了多少”，而是记忆有没有改变下一次行动。

如果记忆只是堆积材料，那它很快会变成噪音。真正有价值的记忆，是能把失败转化为规则，把一次任务里的验证结果变成下一次任务的默认判断。

智能体系统真正要设计的是什么

读完这条线索后，一个更清楚的判断是：未来智能体系统的重点，可能不是不断追求一个更完美的单次提示词，而是设计一个更好的运行机制。

这个机制至少有两层。

第一层是内层循环。它负责当前任务，让模型围绕目标、测试、日志和评分标准不断修正结果。

第二层是外层记忆。它负责跨任务积累经验，把失败、验证和规则沉淀下来，在后续任务中复用。

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

这也会改变我们看待“提示工程”的方式。提示词仍然重要，但它不再是唯一变量。更重要的问题变成了：

• 有没有给模型一个明确、可检查的目标？
• 有没有让模型看到真实反馈，而不是只靠自我感觉？
• 有没有使用独立验证器，避免模型自评偏差？
• 有没有把本次任务中的经验沉淀到下一次任务？
• 有没有把一次性对话，升级成可持续运行的系统？

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

总结

Claude Fable 5 带来的启发，可以压缩成两句话。

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

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

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