从一个 Agent 开发者的视角重新拆解 Agent Memory
这是一个关于 Agent Memory 的系列文章。
第一篇不急着讨论某个框架，也不急着选择数据库。先把一个更基础的问题说清楚：Agent Memory 到底应该是什么？
后续三篇会继续讨论：
- 为什么 Agent Memory 不能只靠向量数据库
- Agent Memory 的数据模型：Event、Evidence、Candidate 与 Memory Fact
- Agent Memory 的安全边界：权限、删除、版本与回执
一、先说结论
我以前也容易把 Agent Memory 理解成两件事：保存聊天记录，或者接入一个向量数据库。
但真正把 Agent 的任务连续性拆开之后，会发现这两种理解都不完整。
Memory 要解决的不是"过去说过什么"，而是：
Agent 在下一次工作时，能不能找回正确的信息，知道这些信息是否仍然有效，并且能够继续完成任务。
比如，用户对助手说：
继续处理我上次的旅行计划。
这句话看起来很简单，但 Agent 至少需要知道：上次计划去哪，出行日期有没有变化，预算是多少，同行人是谁，已经看过哪些方案，哪些偏好是长期的，哪些只是这一次的临时要求，以及上次任务究竟做到哪一步。
如果系统只保存了聊天记录，它也许能找到一大段对话，却不一定能回答这些问题。
所以我现在更愿意这样定义 Agent Memory：
Agent Memory 是一套把历史事件、事实、偏好、任务状态和证据来源组织成可信上下文的能力，让 Agent 在正确范围内记住正确的信息，并在需要时找回来。
二、聊天记录不等于 Memory
聊天记录当然有价值，它是最重要的原始材料之一。但原始材料和可继续使用的记忆不是一回事。
还是用旅行计划举例。
用户先说："这次预算尽量控制在 8000 元以内。"
过了一会儿又说："如果是直飞，预算可以放宽一点。"
第二天用户补充："这次带孩子，航班不要太晚。"
这几句话的性质并不一样：
- 8000 元是这次行程的预算约束
- 直飞优先可能是本次选择，也可能逐渐成为偏好
- 带孩子时不要太晚，是一个有条件的偏好
- 它们都来自对话，但适用范围和有效时间不同
如果系统把所有句子放在一个"聊天记录"里，下一次只能重新让模型阅读和猜测。如果系统把它们整理成带有范围、时间和来源的结构化信息，Agent 才能更可靠地继续工作。
因此，Memory 不是把聊天记录复制到另一个表里，而是对历史信息进行整理、筛选、标注和治理。
三、Memory 也不只是摘要
摘要比原文短，但短不代表可靠。
一个摘要可能写成：
用户喜欢直飞，预算 8000 元，同行有孩子。
这句话看起来很方便，但它丢失了几个关键问题：
- 这是用户长期偏好，还是这次旅行的临时要求？
- 预算是硬性上限，还是大致目标？
- "同行有孩子"适用于哪一次行程？
- 这条信息来自哪次对话？
- 后来用户有没有修改过？
没有来源、范围和版本的摘要，可能比原始对话更危险，因为它看起来更像一个确定事实。
一个可信的 Memory 不只保存"内容"，还要保存内容的上下文：谁说的、什么时候说的、适用于什么事情、是否已经被更新、是否需要用户确认。
四、Memory 和任务状态也不是一回事
用户说"继续上次的旅行计划"，除了需要找回事实和偏好，还需要恢复任务进度。
例如：
- 目的地已经确定
- 航班已经筛选
- 酒店还没有比较
- 付款还没有确认
这些信息描述的是任务当前做到哪一步。它们应该由任务运行状态来管理，而不是藏在一条语义记忆里。
Memory 可以告诉 Agent 用户通常偏好可取消的酒店；任务状态则要明确告诉 Agent 当前这个任务是否已经选定酒店、是否等待用户确认。
这两个概念混在一起，就容易出现两类错误：把一次任务的临时状态误认为长期偏好，或者把长期偏好误当成当前任务已经完成的步骤。
我的判断是：
Memory 提供历史依据和连续性，Task Runtime 负责当前任务怎么继续，权限和回执负责动作是否有资格执行、是否真的成功。
五、一个可信 Memory 要经过哪些步骤
如果把 Memory 看成一条流水线，大致需要经历以下过程。
1. 接收事件
系统先接收发生过的事情，比如用户说了一句话、修改了预算、查看了某个方案，或者外部系统返回了结果。
这一步的重点不是"尽量多收集"，而是明确数据来源和用户授权。系统不能默认读取所有设备、文件和应用。
2. 提取候选
系统从原始事件中提取可能值得记住的内容。
比如从多次选择中发现"用户通常优先直飞"，或者从当前对话中发现"这次不要安排晚于晚上九点的航班"。
这里的结果只能叫 Candidate，也就是候选记忆。模型认为某件事可能成立，不代表它已经是系统可以长期相信的事实。
3. 治理候选
系统需要判断候选的来源、作用范围、有效时间、敏感程度，以及它是否和已有内容冲突。
如果用户以前说过"预算不超过 8000 元"，现在又说"这次预算可以到 10000 元"，系统不能简单地让两条记忆同时生效。
4. 分类保存
原始事件、证据、长期事实、偏好和任务状态应该分开保存。它们的生命周期和读取方式不同。
5. 按条件召回
当用户再次提出请求时，系统先确认用户、任务和范围，再读取当前有效的任务状态和事实，最后用关键词、向量和时间等方式补充相关内容。
6. 更新和纠正
记忆不是写入之后永远不变。用户可以修改、暂停或删除它，新的证据也可能替代旧版本。
这也是为什么 Memory 不应该被设计成一个只进不出的黑盒。
六、工程上至少需要哪些对象
如果要把上面的概念真正实现出来，至少需要区分几类数据。
Event：发生记录
Event 记录系统发生了什么，例如用户修改了预算，或者任务完成了酒店筛选。
Evidence：证据来源
Evidence 记录这条信息来自哪里，可以是某次对话、某个文档、一个表单或外部系统的返回结果。
Candidate：候选记忆
Candidate 是模型或规则提取出的可能记忆。它还没有通过治理，不能直接当成正式事实。
Memory Fact：规范记忆
Memory Fact 是经过判断后，系统允许后续使用的事实或偏好。它需要带来源、作用域、版本和有效时间。
Task State：任务状态
Task State 记录目标、已经完成的内容、缺失项、下一步和阻塞点。
最容易犯的错误，就是把 Candidate 直接写成 Memory Fact。模型说"用户可能喜欢早班机"，不等于系统就应该永久相信这件事。
七、从"继续旅行计划"看完整闭环
用户再次说："继续处理我上次的旅行计划。"
系统应该按这样的顺序工作：
- 找到可能对应的旅行任务；如果有多个相似任务，先澄清。
- 确认当前用户、任务范围和信息权限。
- 找回目的地、日期、预算、同行人和相关证据。
- 区分长期偏好、本次要求和临时例外。
- 恢复任务状态，明确已经完成和仍然缺失的步骤。
- 生成下一步建议，但涉及付款或预订时重新请求确认。
- 执行动作后查询外部系统的真实结果。
- 只有确认成功，才把结果写入已完成状态或新的事实。
这条链路说明，Memory 并不是一个孤立组件。它需要和任务运行、权限控制、动作执行以及结果回执配合起来。
八、应该分几步建设
我倾向于把建设过程分成三步。
第一步：Remember，先记得住
先让系统能够跨会话找回事实、证据和任务状态，重点验证来源、作用域、跨任务隔离和用户纠错。
第二步：Reconcile，再记得准
再处理冲突、过期、版本、长期偏好、临时例外、删除和多来源合并。
第三步：Continue，最后接着做
最后让任务能够跨时间、跨设备和跨应用继续，但关键动作仍然需要当前授权，并以外部系统的真实回执作为完成依据。
这三步不适合颠倒。没有稳定的来源和任务状态，个性化只会放大错误；没有准确的事实和版本，跨设备执行就不可靠。
结尾
Agent Memory 不是让 Agent 记住一切。
它真正要做的是：
在正确范围内记住正确的信息，在需要时把它找回来，并且允许用户理解、纠正和控制它。
后面的三篇文章会继续把这个判断拆开：为什么向量数据库不等于 Memory，这些数据对象如何设计，以及权限、删除、版本和回执应该放在哪些控制点上。