54 Agent Memory：短期记忆、用户上下文与摘要
Agent Memory：短期记忆、用户上下文与摘要
Memory 的目标是保持任务连续性，不是永久保存所有聊天。记忆要分层、可控、可删除。
[TOC]
1. 先把 Agent 想清楚
很多人一听到 Agent，就会想到“让大模型自己决定下一步”。这个理解只对了一半。
在真实项目里，Agent 更像是一个被工程规则约束住的任务执行器：
模型负责理解自然语言、提出候选动作
代码负责权限校验、状态流转、工具执行
业务接口负责最终事实和写操作
日志审计负责事后追踪
把所有历史对话都塞进 Prompt，会带来隐私、成本和错误继承问题。Agent 需要的是当前任务相关记忆。
所以这一阶段的博客不要写成“模型越来越聪明”。更准确的写法是：我们正在学习如何把模型的灵活性放进一个可控的工作流里。
2. 一个业务场景
用户前面说“就是那个上周买的设备”，后面问“能创建工单吗”。系统需要记住上文里的订单和故障描述，但不应该把无关闲聊永久保存。
这个场景里面最重要的不是模型能不能说出一段好听的话，而是：
它选了哪个工具
为什么能调用这个工具
参数从哪里来
权限在哪里校验
失败后状态怎么变
用户确认前会不会产生真实写入
把这些问题问清楚，Agent 项目才不会变成一个不可解释的聊天黑盒。
这一节要先区分“记忆”和“状态”。
判断顺序可以这样写：
1. 当前任务必须用到的信息放 state，例如订单号、确认状态、工具结果
2. 跨会话可复用的信息才考虑 memory，例如偏好、常用联系方式
3. 记忆写入前要判断是否敏感、是否需要用户同意、是否有过期时间
4. 读取记忆时仍要经过权限和上下文校验，不能覆盖业务事实
5. 最后用旧记忆、过期记忆、错误记忆和权限变化样例验证
它解决的是长期上下文问题：Agent 可以变得更懂用户，但不能把不可靠记忆当成真实业务数据。
3. 核心概念
1. 短期记忆
保存当前任务需要的消息、实体、工具结果和待确认动作。
这一点在项目里要落到具体规则：服务当前任务。
2. 用户上下文
稳定偏好或资料需要来源和过期策略，不能从一次聊天永久推断。
这一点在项目里要落到具体规则：长期记忆要谨慎。
3. 历史问题
历史问题可帮助理解追问，但要按用户和权限隔离。
这一点在项目里要落到具体规则：历史不能串租户。
4. 摘要
上下文太长时做结构化摘要，保留关键事实和待办。
这一点在项目里要落到具体规则：摘要是压缩，不是审计。
4. 整体流程
graph TD;
A["接收新消息"] --> B["加载任务 State"]; B["加载任务 State"] --> C["选择相关历史"];
C["选择相关历史"] --> D["裁剪或摘要"];
D["裁剪或摘要"] --> E["执行 Agent"]; E["执行 Agent"] --> F["保存必要记忆"];
这张图里，模型只是其中一个节点。工具、状态、权限、确认和审计同样重要。
如果一个 Agent 图里只有“用户 -> 模型 -> 答案”，那它还只是 Chat，不是能进入业务系统的 Agent。
5. 落地步骤
1. 划分记忆层级
会话消息、任务状态、长期偏好、业务事实分开存储。
完成后应该能看到：记忆分层表。
2. 设置上下文预算
优先保留系统规则、当前问题、待确认动作和关键工具结果。
完成后应该能看到：上下文预算规则。
3. 避免错误固化
模型提取的长期事实要经用户确认或业务验证。
完成后应该能看到：长期记忆确认流程。
4. 支持删除
用户应能查看、修改或删除持久记忆。
完成后应该能看到：记忆管理接口。
6. 状态、接口或工具字段
| 项目 | 说明 |
|---|---|
| memoryType | 短期、长期、摘要、业务事实 |
| scope | 会话、用户、租户 |
| source | 来源消息或系统 |
| expiresAt | 过期时间 |
| verified | 是否经过确认 |
字段设计要尽量结构化。不要让下游通过一段自然语言去猜“成功了没有”“下一步要干什么”。
7. 示例
摘要模板
- 当前目标：
- 已确认事实：
- 已调用工具及结果：
- 待确认动作：
- 未解决问题：
- 不应继承的临时信息：
- 摘要来源消息范围：
示例里的字段不一定照搬，但思想要保留：输入、状态、输出、错误和审计信息要分开。
8. 哪些事不能交给模型自由发挥
模型不能把猜测直接写成用户长期事实。例如用户说“可能是我爸的订单”，不能永久记成订单归属。
这一节特别重要。Agent 项目最容易踩坑的地方，就是把“理解意图”和“执行业务动作”混成一件事。
模型可以建议动作，但最终执行必须经过代码和业务系统的规则。
9. 测试路径
建议至少准备下面几类测试：
正常路径：输入完整，工具正常返回
缺字段路径：订单号、联系方式、问题描述不完整
权限路径：查询别人的订单、访问无权知识库
失败路径：工具超时、模型输出非法、检索为空
恢复路径：等待确认时服务重启、重复确认、超时确认
Agent 的测试不能只看最终回答。你要检查状态、工具调用、审计日志和是否产生真实副作用。
10. 工程取舍
- 记忆越多，体验越连续，但隐私和成本越高。
- 摘要能省 Token，但可能丢细节。
- 长期记忆要少而准。
取舍讲清楚以后，读者才能知道你为什么这样设计，而不是以为所有问题都要上 Agent。
11. 常见坑
- 把所有聊天永久保存。
- 跨用户检索历史消息。
- 把模型猜测当成事实。
- 摘要覆盖原始审计记录。
这些坑本质上都和一个问题有关：没有把模型输出当成“不可信的候选结果”。
12. 验收清单
- ☐ 记忆按作用域隔离
- ☐ 上下文有预算
- ☐ 长期事实有来源
- ☐ 用户可删除持久记忆
- ☐ 摘要不丢待确认动作
如果这些检查项没过，先不要急着加更多工具。工具越多，边界越乱，排查越难。
13. 落地清单
- ☐ 设计记忆分层表
- ☐ 写摘要模板
- ☐ 模拟一次追问理解
- ☐ 设计记忆删除接口
练习时可以先用 Mock，不要一开始就连真实订单或工单系统。等状态、权限和幂等设计清楚后，再接真实接口。
14. 小结
Memory 不是越多越好。好的记忆系统知道什么该记、记多久、给谁用，以及什么时候忘掉。
Agent 的价值来自灵活性，但安全来自边界。能把这两件事同时讲清楚，才算真正理解 Agent 工程化。