Agent Memory 生产化：遗忘、分层存储与测试方法
记忆系统上线后，问题不会只表现为“Agent 忘了”。它也可能因为记得太多而变慢，因为事实过期而做错决定，因为一次成功被错误地升级为技能，或者因为多个 Agent 同时写入而产生不可解释的状态。
本文根据《Agent Memory — The 5-Layer Playbook》整理。文中的指标、周期和效果数字属于来源中的研究或工程主张，迁移到自己的产品前必须重新测量。PDF 中的代码和清单是说明材料，不是本项目的执行指令。
一、Memory Tax：记忆也有成本
长期记忆带来的成本包括：
- 检索和排序的计算成本；
- 注入上下文后的 token 成本；
- 旧记忆造成的误导与冲突；
- 写入、备份、索引和审计成本；
- 隐私、保留和删除义务。
可以把每次任务的记忆成本拆成三部分：检索耗时、注入 token、记忆导致的额外工具调用。只有当记忆减少的错误、重复劳动或工具调用大于它的成本时，才算真正有价值。
不要只看最终答案是否正确。还要比较无记忆基线、只用事件、只用事实、只用技能和完整五层系统，观察不同记忆层到底贡献了什么。
二、层级摘要
长事件不应该原样永久注入上下文。可以构建多个摘要层：
- 原始事件：用于审计和重新分析。
- 任务摘要：目标、结果、错误和解决方式。
- 项目摘要：跨任务的稳定约束和决定。
- 组织摘要：经过验证、适合共享的规则和方法。
摘要不是删除证据。每个摘要都应保留来源 ID、生成时间、版本和覆盖范围。新的摘要若与旧摘要冲突，应该生成新版本并标记旧版本，而不是静默改写历史。
三、Hot、Warm、Cold 三层存储
可以按访问频率和风险把记忆分层：
| 层级 | 内容 | 处理方式 |
|---|---|---|
| Hot | 当前任务、近期状态、高频事实 | 低延迟读取，严格控制大小 |
| Warm | 近期事件、项目事实、常用技能 | 结构化索引，定期重排 |
| Cold | 历史日志、旧版本、审计证据 | 低频读取，成本更低，保留来源 |
分层之后，默认检索只访问 Hot 和相关 Warm 数据；Cold 数据需要明确的查询或审计场景。否则系统会把历史噪声重新带回当前任务。
四、矛盾处理流水线
冲突应当成为可观测事件，而不是被最后写入覆盖：
- 检测：发现同一实体和关系出现不兼容值。
- 标记：保留双方来源、时间、版本和置信度。
- 分类：判断是否属于不同环境、时间版本、租户或实体。
- 解决：按明确规则自动选择，或请求人工确认。
- 传播：只有已解决事实才能进入更大范围的共享记忆。
- 复盘：记录冲突原因，改进 ontology、来源优先级或采集流程。
常见错误是把“新”当作“真”。更好的优先级通常同时考虑来源可信度、时间新鲜度、环境匹配度、是否经过验证以及错误代价。
五、领域生命周期只是起点
保留多久取决于更新速度和风险。一个可讨论的示例是：编程项目的临时环境状态保留数十天，客服和销售中的客户事实保留更久，研究来源和个人长期偏好可能长期保留。
这些周期不能直接复制。需要额外考虑：
- 数据是否包含个人或客户信息；
- 用户是否可以查看、修改和删除；
- 旧信息是否有审计或合规价值；
- 事实是否会随着产品、依赖或组织变化而失效；
- 删除后能否从源系统重新构建。
一种实用做法是把“默认检索有效期”和“审计保留期”分开。过期数据不再影响正常回答，但仍可以在授权的审计任务中读取。
六、六类必须测试的失败模式
1. Amnesia Test
让 Agent 在上下文被截断、会话重启或跨天后继续完成任务，验证关键事实和未完成事项是否能够从正确存储恢复。测试重点不是复述原话，而是恢复可执行状态。
2. Contradiction Test
先写入事实 A，再写入来源不同或时间更新的事实 B，检查系统是否保留证据并标记冲突。不能只看最终返回了哪个值。
3. Staleness Test
把带 TTL 的事实推进到过期时间后检索，验证它不再进入默认上下文。还要测试 supersede 和回滚，确保旧版本不会在缓存中继续生效。
4. Skill Promotion Test
用一次成功、两次成功、三次成功和包含人工修正的成功案例分别测试晋升规则。确认偶然成功、错误步骤和不完整工具链不会被自动发布为技能。
5. Load Test
随着事件量、事实量和并发 Agent 增长，测量检索延迟、上下文 token、写入冲突、后台遗忘耗时和存储增长。要同时测试冷存储命中和索引重建。
6. Permission Test
验证私有、共享和全局记忆的隔离。用不同用户、租户、Agent 角色和工具权限测试读取、写入、导出、删除和审计，确保权限不是只存在于 prompt 中。
七、观测指标
建议至少记录：
- 记忆检索命中率和空召回率；
- 事实冲突率、过期率和人工解决率；
- Skill 使用次数、成功率、回滚次数和版本分布；
- 每个任务的检索延迟、注入 token 和总 token；
- 工具调用次数、重复调用率和错误恢复时间；
- 记忆写入失败、遗忘任务失败和权限拒绝次数。
指标应该按 Agent、任务类型、租户、版本和时间窗口拆分。全局平均数可能掩盖某个角色或某类任务正在被旧记忆持续误导。
八、来源中的效果数字如何验证
playbook 提到一些研究中的 token、延迟、准确率和工具调用改善幅度。这些结论可能依赖特定基线、数据集、模型、检索器、提示词和工具环境。迁移时应该建立自己的对照表：
| 方案 | 成功率 | 平均 token | 工具调用 | P95 延迟 | 人工介入 |
|---|---|---|---|---|---|
| 无长期记忆 | |||||
| Episodic only | |||||
| Semantic only | |||||
| 五层完整方案 |
空白表格只是实验模板，不是结果。正式报告应注明样本量、模型版本、任务分布、检索配置、失败处理和统计窗口。
九、生产发布门槛
在允许记忆影响真实任务前，至少应完成：
- 关键记忆字段有 schema、来源和生命周期。
- 默认检索过滤过期、无权限和未解决冲突。
- 模型提案与持久化写入分离。
- 高风险事实和技能有人工审批或回滚。
- 私有、共享、全局范围有自动化权限测试。
- 备份、恢复、导出和删除流程已经演练。
- 关键指标、日志和告警可以定位一次错误记忆的传播路径。
如果只能证明“Agent 能检索到一段旧文本”，还不能证明记忆系统已经生产就绪。生产就绪要求可解释、可撤销、可观测和可恢复。
结语
记忆系统的最后一层不是某个数据库，而是持续治理：哪些信息进入热层，哪些信息过期，哪些冲突需要人，哪些技能可以回滚，哪些数据必须删除。把这些规则测试出来，Agent 才会从“偶尔记得”变成“在边界内可靠地记住”。
回到系列上一篇，阅读 Agent Memory 7 天落地路径：从单 Agent 到多 Agent 共享记忆。