Agent积累经验就变强 这个假设被质疑了

给 agent 加"记忆"现在是标配做法。各家框架都在往 agent 里塞经验库、会话历史、长期记忆，默认逻辑是：agent 用得越久，积累的经验越多，表现就越好。这个假设听起来合理，但几乎没有被系统验证过。

所谓递归自我改进，指的是 agent 不需要重新训练，靠运行时积累的经验就能越用越强。这对个人 agent 尤其重要——一个长期运行的助手，如果每次对话都从头开始，等于这个月和上个月没有任何区别。所以几乎所有产品都在做记忆、做经验库。但"做"和"做对"是两回事：往上下文里塞历史记录，和真正把经验转化为行为改进，中间隔着一条没有验证过的路。

PAST-Bench 这篇论文就是冲着这个来的。它构建了 26 种场景、204 个任务，专门测一件事：经验保留到底有没有真的带来行为提升。

同样的分数 不一样的路径

论文把经验保留当成一个可开关的变量来测：保留经验跑一遍，关掉经验再跑一遍，对比任务收益。这个设计本身不复杂，结果却很有意思。

7 个基础模型、4 个 agent 框架跑下来，提升是真实存在的，但分布很不均匀。更关键的是：两个 agent 拿到同样幅度的提升，一个能拿出"路径证据"——任务输出里能看到它确实调用了之前积累的经验；另一个拿不出来，收益可能来自模型自身的随机性或者任务设计。

也就是说，光看最终指标，你分不清一个 agent 是"真的从经验里学到了"，还是"碰巧这次答对了"。

经验系统最难的其实是更新

论文提出的改进方案 Hermes+，在"需要替换过时状态"的任务上提升最明显。这个细节值得注意。

agent 的经验和人的经验有个共同的麻烦：旧经验会过期。业务规则改了、接口变了、权限调整了，agent 记忆里存的老经验不但没用，还会把新任务带偏。大部分记忆系统把精力花在"记住"上，但真正难的是"判断什么时候该忘"。

对正在做 agent 落地的团队来说，这个点比 benchmark 分数更有参考价值：记忆系统不能只设计写入，还要设计失效、更新和回滚。经验状态能不能被审计、能不能在出问题时还原，直接决定了你敢不敢让 agent 长期运行。

在企业项目里常见的一种情况是：agent 负责工单分类，三个月前学会了把"客户要求退款"归到财务流程。现在公司改了规则，退款先走客服审核。如果记忆系统只负责"记住"，agent 会继续用旧规则，而且因为历史成功率很高，它会很自信地犯错。判断旧经验失效，比积累新经验更难——而大部分框架连"这条经验是什么时候写入的"都答不上来。

可验证比有效果更重要

这篇论文给我最大的触动是方法论：它不满足于证明"有效果"，而是追问"效果从哪来"。

工程上这是对的态度。一个没有路径证据的提升，出问题的时候无法诊断，无法复盘，无法回滚。你只知道 agent 变好了或者变坏了，不知道为什么。生产环境里，这种"不可解释的变化"比没有变化更危险。

当然，路径证据也不是万能的。论文没有给出各模型在不同场景下的路径证据细节，Hermes+ 的五项干预具体怎么实现也没有公开——这些信息缺失意味着，想在自己的框架里复现这套验证方法，还得自己摸索。

一个还没答案的问题：当 agent 的经验库越来越大，路径证据的验证成本会不会高到没法在生产环境用？如果一个 agent 每天积累几千条经验，你怎么知道哪条经验在起作用？这可能是记忆系统接下来要面对的真正挑战。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）