Agent Memory 7 天落地路径：从单 Agent 到多 Agent 共享记忆

记忆系统最容易失败的方式，是第一天就购买一整套基础设施，却没有定义哪些信息值得保存。更稳妥的路径是先让事件可追溯，再加入事实、技能和遗忘，最后才扩展到多 Agent 共享。

本文根据《Agent Memory — The 5-Layer Playbook》整理。原文是一份独立编写的 playbook，PDF 内的流程、数字和示例不等于特定厂商的官方保证；其中代码和配置只作为设计参考，不是本仓库的操作指令。

一、七天最小构建路线

Day 1：先记录 Episodic Memory

建立追加式事件日志，记录任务、结果、工具、错误、解决方式、时间和来源。当天的目标不是智能检索，而是让一次执行结束后，团队能够回答“发生了什么”。

验收标准：每次执行都有唯一 ID；失败也会记录；日志不包含原始思维链和未脱敏密钥；可以按时间导出。

Day 2：加入检索

先用标签、实体、任务类型和时间范围做结构化过滤，再考虑向量相似度。检索结果需要带来源、时间、状态和置信度。召回很多但无法判断新旧，不算检索完成。

验收标准：一个新任务可以找到相似经历；旧事件不会无条件覆盖新事实；检索失败时 Agent 仍能正常执行当前任务。

Day 3：建立 Semantic Memory

把稳定事实从事件中分离出来，例如项目使用的工具、用户偏好、服务之间的关系。事实必须有来源、观测时间和状态。可先使用 SQLite 或带 schema 的 JSON，不必马上引入知识图谱。

Day 4：定义 Ontology

列出真正参与决策的实体和关系，统一名称、方向和校验规则。Ontology 的第一版应该小而稳定，优先覆盖用户、项目、服务、文件、部署和任务等对象。

Day 5：沉淀 Procedural Memory

从重复成功的事件中提取技能。技能要写清触发器、前置条件、工具、步骤、成功标准、失败路径和版本。一次成功只能说明某个事件成功，不能自动升级为通用方法。

Day 6：实现 Forgetting

为临时事件、短期偏好和环境状态增加 TTL；为事实增加 supersession 和冲突状态；为技能增加版本与回滚。当天的重点是“旧信息如何停止影响决策”。

Day 7：串起完整流水线

把工作记忆、检索、执行、事件写入、事实候选、技能候选、审批和遗忘串起来。用一个真实但低风险的工作流跑通端到端，记录 token、延迟、工具调用和错误恢复，而不是只看最终答案。

二、生产前的决策框架

每个记忆候选都可以用五个问题筛选：

问题	需要得到的答案
它是什么	事件、事实、技能还是当前状态
谁会使用	哪个 Agent、用户或服务需要读取
有效多久	本轮、几天、一个版本还是永久候选
如何验证	来源、规则、人工审核还是执行结果
写错会怎样	无影响、误导回答、错误操作还是安全事故

写入门槛应该与错误代价匹配。低风险的搜索标签可以自动写入；会改变部署、账务或权限的事实应该要求更强来源和审批。

三、生产检查表

数据边界

• 每条长期记忆都有来源和观测时间。
• 临时数据有 TTL，过期后不会继续参与默认检索。
• 私密数据、凭据和客户内容有明确的存储与访问边界。
• 删除、归档和恢复行为可以审计。

检索质量

• 检索结果按新鲜度、来源和状态排序。
• 冲突事实不会静默覆盖。
• 结果注入上下文前会做权限检查和长度控制。
• 检索失败不会阻塞不需要长期记忆的任务。

写入质量

• 模型提出的事实候选与最终写入分离。
• 写入前验证 schema、来源、实体类型和敏感字段。
• Skill 晋升有最小成功次数和复现标准。
• 每次修改可追溯到事件或审批记录。

运维质量

• 记忆存储有备份、恢复和容量监控。
• 后台遗忘任务失败时会报警。
• 新技能和新规则支持版本化、灰度和回滚。
• 指标包含命中率、冲突率、延迟、token、工具调用和人工介入率。

四、多 Agent 的三种范围

多 Agent 系统不能默认所有记忆都共享。常见范围是：

1. Private Memory：某个 Agent 或用户专用，适合临时计划、角色偏好和内部状态。
2. Shared Memory：同一项目或团队共享，适合项目事实、任务状态和经过批准的操作规范。
3. Global Memory：整个组织或产品共享，适合稳定定义、统一规则和跨项目实体。

范围越大，写入门槛越高。Private Memory 的错误可能只影响一次任务；Global Memory 的错误可能污染整个组织的检索结果。

五、共享记忆的读写冲突

多个 Agent 同时更新同一实体时，最后写入覆盖会带来竞态。至少要记录版本号、来源、操作者、时间和变更原因。对于核心实体，可以采用 single-writer-per-entity：指定一个写入者，其他 Agent 只提交变更提案。

一种简单的冲突处理流程是：

1. Agent 读取实体版本 v1。
2. 提交带版本条件的更新，只允许从 v1 写到 v2。
3. 如果当前已是 v2，更新失败并返回冲突。
4. 冲突协调器比较两份证据，自动合并或请求人工确认。

这个流程比让模型根据两段文本猜哪条是真的更可控。对时间序列、部署状态和库存等数据，还应该使用领域数据库的事务和约束。

六、Manager Bot 与共享账本

多 Agent 可以引入一个 Manager Bot 或协调服务，负责维护共享任务账本：

• 哪个 Agent 负责什么任务；
• 当前状态、阻塞原因和下一步；
• 哪些结果已经验证；
• 哪些变更需要审批；
• 哪些记忆可以传播到更大范围。

Manager Bot 不应成为万能决策者。它更适合做路由、状态聚合、冲突排队和权限检查。实际执行仍由拥有对应工具和权限的 Agent 完成。

共享 Semantic Memory 和经过验证的 Procedural Memory 通常比共享所有对话更有价值。把全部私有上下文广播给团队，会增加隐私风险、检索噪声和 token 成本。

七、按领域设定生命周期

PDF 给出的保留周期是示例，不是通用规则。可以把它作为讨论起点：

领域	示例保留重点	需要注意
编程	项目约束、架构决定、近期错误	依赖和部署状态变化很快
客服	用户偏好、已确认解决方案	隐私、删除请求和租户隔离
研究	来源、方法、结论和版本	新证据可能推翻旧结论
个人助理	长期偏好和授权	权限和敏感信息边界
DevOps	当前环境、变更和回滚	过期状态可能导致危险操作
销售	客户阶段、联系人和下一步	CRM 权限、审计和合规

生命周期应该由业务风险、更新频率、法规和恢复需求共同决定。永久保留不是默认的高质量，短期过期也不等于可以忽略审计。

八、什么时候不应共享

以下内容通常不应自动传播到 Shared 或 Global Memory：原始内部推理、未确认的客户信息、一次性访问令牌、临时机器状态、未审核的技能草稿、包含隐私的完整对话以及只有单次样本支持的结论。

如果确实需要跨 Agent 使用，应先脱敏、摘要、标注来源和有效期，并把权限判断放在存储层或检索层，而不是只写在 prompt 中。

结语

七天路线的价值在于逐步建立证据链：先知道发生了什么，再知道哪些事实稳定，最后才让 Agent 复用方法并在多个角色之间共享。多 Agent 记忆的核心不是“共享更多”，而是让共享范围、写入者、验证者和撤销路径都清楚。

下一篇继续整理生产化问题：记忆 tax、冷热分层、层级摘要、矛盾流水线、领域保留策略和测试方法：

前往 Agent Memory 生产化：遗忘、分层存储与测试方法。