Agent 记忆不是聊天记录：什么经验值得留下

给 Agent 增加记忆，最直观的方案是保存历史对话，再在新任务开始时检索相关内容。这能帮助恢复背景，却没有自动解决一个更难的问题：过去说过的话，哪些可以成为今天行动的依据？

聊天里同时存在事实、猜测、失败尝试、临时偏好和最终结论。它们在文本上可能一样流畅，在可信度上却完全不同。如果系统只按相似度召回，模型可能把尚未验证的猜测当成团队规则。

阅读 TencentDB 团队记忆实践和 Agent 自进化资料后，我更愿意把记忆理解为一套经验管理过程，而不是一个容量更大的聊天框。（TencentDB Agent Memory 原文 ↗；Agent 自进化飞轮原文 ↗） 它要回答的，不只是记住什么，还有谁能使用、何时适用，以及错误后如何撤回。

一、先区分三种经常混在一起的信息#

为了讨论清楚，我先做一个简单区分：历史记录、任务状态和可复用经验。

历史记录回答“发生过什么”。它保留原始对话、工具输出和时间顺序。任务状态回答“现在进行到哪里”。它保存当前版本、已完成步骤、待确认事项和验证结果。可复用经验回答“下次遇到类似问题，可以参考什么”。

假设 Agent 正在修复一个接口超时问题。对话中说过“可能是数据库慢”，这是历史中的一个假设；当前正在检查执行计划，这是任务状态；最终确认某类查询在特定索引条件下会退化，并用测试验证了改法，才可能形成经验。

这三者需要连接，但不能相互替代。没有原始记录，经验难以核对；没有任务状态，中断后容易重复行动；没有提炼，下一次任务又要重新读完所有过程。

保存得完整，是保真问题。能恢复任务，是连续性问题。能帮助未来任务，是适用性问题。仅增加存储容量，不会自动解决后两者。

二、相似只是线索，不是复用许可#

记忆系统经常从检索开始。关键词可以找到错误码、文件名和符号；语义检索可以找到表达不同、问题相近的历史任务。但找到了，不代表可以照着做。

例如，两条历史工单都提到“连接超时”。一条来自测试环境的代理配置，另一条来自生产环境的连接池耗尽。它们有相似表象，却可能需要完全不同的行动。即使同一项目，分支、版本和配置变化也会让旧修复失效。

TencentDB 的文章明确区分相关关系与可靠复用关系，并通过真实任务检查项目、时间和原始证据。（原文 ↗） 这个区别比某一种检索算法更值得保留：相关内容可以帮助发现方向，却不应自动获得执行权威。

我会进一步区分三种用途：强证据支持的方法可以进入候选计划；弱证据只用来提示风险；背景材料用于解释历史。三者都可能有价值，但应该以不同标签进入上下文。

这里也不是说传统 RAG 无法处理权限和版本。RAG 同样可以具备这些机制。区别在于讨论任务经验时，不能只停留在“召回到哪段文本”，还要追踪它被怎样使用，以及使用后有没有产生新证据。

三、一条有用的经验，需要带着适用条件#

我不认为每条记忆都需要复杂的数据模型。但如果它会影响行动，至少应让使用者看清五件事：结论、来源、适用范围、验证方式和当前状态。

还是用接口超时的假设场景。只保存“遇到超时就扩大连接池”，很危险。它把一个局部修复抽成了普遍规则，也没有说明当时的资源限制和副作用。

更有用的记录应该解释：在什么项目和版本中，什么现象对应什么证据，排除了哪些原因，最后采取了什么动作，怎样验证改善。还要说明哪些条件变化后必须重新检查。

这样的记录会比一句口号长，但它保留了复用所需的因果关系。下一次 Agent 能先核对前提，再决定是否采用，而不是被一个高置信摘要直接带走。

如果证据不足，状态可以是“待验证”，而不是强行写成最佳实践。如果结论已被新证据推翻，则应明确标记失效。记忆不是只允许成功故事进入的展示区。

失败经验也值得保留，但应保存“为什么失败”和“在哪些条件下失败”。单独一句“这个方法不行”，同样会让未来任务失去必要的判断空间。

四、从轨迹到经验，中间需要一次审核#

原始对话直接进入长期记忆，会把大量试探性表达带进后续任务。反过来，只保存最终答案，又可能丢掉关键前提。我的倾向是分层保存：原始证据保留，候选经验单独提炼，稳定结论再经过审核。

审核不一定都由人完成。能被脚本检查的字段、版本和测试结果，可以自动检查；涉及业务规则、长期偏好或高影响操作的经验，则需要更谨慎的确认。

关键是，模型提炼的摘要不能因为写得清楚就自动升级为事实。摘要应能指回证据，并把推断与观察分开。重复出现也不代表正确：同一错误被多次复制，仍然可能只有一份错误来源。

我会把写入长期记忆当成一次变更。新经验可能增加知识，也可能与已有规则冲突。系统需要知道它补充了什么、替代了什么，以及谁确认了这次变化。

这一步看起来降低了“自动记忆”的速度，却能避免把每次尝试都传播成组织知识。对多人、多 Agent 场景来说，写入错误的成本可能比少记一条更高。

五、先处理边界，再比较相关性#

团队记忆与个人笔记最大的差异之一，是信息不能默认向所有成员开放。原始轨迹可能包含客户数据、密钥、内部决策和未确认判断。

TencentDB 的方案把身份、项目和访问权限放在候选筛选之前，再进行相关性检索与上下文装配。（原文 ↗） 我认可这个顺序，因为不该访问的材料，不应为了排序而先暴露给模型。

这里需要区分两件事。信息权限决定“能不能看”；适用范围决定“看了能不能用”。有权读取一个旧项目的工单，并不意味着它适合当前分支。把两者都归为过滤，会掩盖它们不同的责任。

固定约束与历史经验也应分开。当前任务明确绑定的规则，不能被相似度更高的旧建议覆盖。历史习惯可以帮助理解偏好，但不能代替本次高影响操作的授权。

对个人记忆而言，原则同样成立。上次用户允许发邮件，不代表这次也允许；曾经偏好的默认参数，不代表每个环境都适用。记住用户，不等于替用户永久授权。

六、上下文装配不是把整包经验倒进去#

经验治理做得再好，如果每次都把大量内容注入上下文，仍然可能让当前任务被历史包围。

我更喜欢渐进式读取：先给经验摘要、适用条件和证据入口；确定相关之后，再读取完整过程。当前规则与任务约束优先，历史方法按需补充，不相关内容不争夺注意力。

但渐进读取也有成本。摘要过短可能隐藏关键限制，文件拆得过细可能增加往返。因此，评价它不能只看节省多少文本，还要看是否漏掉前提、增加多少工具调用，以及任务结果有没有退化。

一次任务还应尽量使用稳定的经验版本。否则上午读取旧规则，下午读取新规则，最后却没有记录变化，验收时就很难解释行动依据。

任务结束后，经验使用情况也应留下记录：用了哪条，为什么用，最终结果怎样。没有这条连接，我就只能看到记忆库在增长，却不知道哪些内容真正有帮助。

七、证明记忆有效，不能只看检索命中#

“找到了相关经验”与“任务做得更好”是两个指标。前者检查读取过程，后者检查实际收益。

TencentDB 的文章报告了前序经验用于后序任务的评测，并展示组合资产对任务完成率、成本和轮次的影响。（原文 ↗） 这些结果值得参考，但它们来自作者报告；缺少完整配置和单类资产对照时，我不会把收益归给某一条记忆，也不会外推到所有项目。

如果自己设计测试，我会保持任务、模型、工具和资源上限可比，再比较有记忆与无记忆的结果。除了成功率，还要看错误经验导致的误操作、额外读取成本和人工纠正次数。

时间顺序也很重要。评测目标任务时，不能使用这个任务发生之后才产生的修复经验，否则系统实际上提前看到了答案。前序经验是否帮助后序任务，必须在时间边界内检查。

还应该放入不适用的相似案例、过期经验和冲突规则。一个只会命中正例的系统，可能在真实任务中非常积极地用错经验。

对需要模型判断的结果，评测者也可能有偏差。可以结合可执行测试、规则检查和人工抽样，而不是让记忆生成者只凭自己的评价宣布记忆有效。

八、删除和撤回，是记忆系统的基本能力#

记忆讨论中，写入与召回经常更受关注。但一条错误经验进入多个摘要、索引和任务后，怎样撤回同样重要。

只删原始文本可能不够。系统应能定位它派生出的结论，更新检索候选，并让后续任务不再把失效内容当成可靠依据。已完成任务的历史证据可以保留，但它与当前有效知识需要区分。

冲突也不能只用“最后写入覆盖”解决。新结论可能只适用新版本，旧结论在旧版本中仍然正确。保留版本范围，比把所有历史压成一条全局规则更合理。

如果刚开始建设，我会先选择一个重复任务明确、验证方法可执行的场景。先做好少量经验的来源、适用范围、读取与撤回，再扩大自动写入。这个顺序比先积累大量无法判断的摘要更容易检查效果。

结语：让下一次任务少走弯路，而不是记住一切#

我不把“任何错误只犯一次”理解为系统承诺。新问题、环境变化和不同根因都可能让类似错误再次发生。记忆能减少可继承部分的重复损耗，不能取消新的验证。

这也是我更看重记忆治理的原因。一个可信系统不仅知道过去发生了什么，还知道哪些结论尚未确认，哪些已经失效，以及当前任务应该重新检查什么。

好的 Agent 记忆，不是让过去永远留在上下文里，而是让经过核对的经验，在合适的边界内进入下一次行动。 存储提供可能性，适用性判断和反馈决定它是否真正有价值。