没有记忆的 Agent，只是一次性问答。真正能干活的 Agent，必须记得上下文、任务进度和长期偏好。

一、为什么需要记忆？

前面讲了规划。规划解决“下一步做什么”。记忆解决“之前发生过什么”。

没有记忆，Agent 每次都像第一次启动。用户刚说过的信息会丢，工具刚查过的结果会丢，任务做到哪一步也会丢。

所以，记忆不是高级功能。它是 Agent 从“聊天机器人”走向“任务系统”的必备能力。

二、记忆到底是什么？

记忆不是把所有历史都塞进 Prompt。那样会越来越慢、越来越贵，也更容易让模型分心。

更合理的做法，是把信息分层：最近对话放 Session，任务进度放 State，长期事实放 Memory，需要时再检索出来。

• Session：当前会话历史，解决“刚才聊了什么”。

• State：当前任务状态，解决“任务做到哪一步”。

• Long-term Memory：跨会话长期记忆，解决“这个用户/系统长期有什么信息”。

• Retrieval：按需召回，解决“这次问题真正需要哪些历史”。

三、核心流程：先读，再答，最后更新

一个带记忆的 Agent，每次运行至少有三步。

• 运行前：读取会话、读取状态、检索长期记忆。

• 运行中：模型推理，必要时调用工具，工具结果进入状态。

• 运行后：追加事件、更新状态，把值得保留的信息写入长期记忆。

关键点在于“按需”。不是所有历史都要进上下文。只把与当前任务相关的信息交给模型。

四、三层记忆怎么分？

很多 Agent 项目失败，不是因为没有记忆，而是因为把记忆做乱了。

临时信息存进长期库，会造成脏数据。长期偏好只放在当前 Prompt，又会在下一次对话丢失。

• 短期记忆适合保存最近对话和上下文。长了就摘要，不要无限堆。

• State 适合保存任务进度、工具结果、当前步骤。它更像运行时变量。

• 长期记忆适合保存稳定事实、用户偏好、历史结论和可复用经验。

• RAG 可以作为长期知识的一种实现，但 RAG 不等于全部记忆。

五、源码级逻辑：MemoryManager 应该放在 Agent 前后

工程上不要把记忆逻辑散落在每个 Prompt 里。更好的方式，是抽一个 MemoryManager。

它在 Agent 运行前负责读取和压缩上下文；在 Agent 运行后负责写事件、更新状态、沉淀长期记忆。

这也是主流框架的方向。LangGraph 把短期记忆放在 agent state 中，并通过 checkpointer 让线程可以恢复；长期记忆则通过 store 按 namespace 和 key 保存。OpenAI Agents SDK 的 Session 会在每次运行前自动读取会话历史，在运行后保存新消息。Google ADK 则把 Session、State、MemoryService 拆成清晰组件。

六、案例：售后客服 Agent

用户说：“上次那个退款还没到账，再帮我看一下。”

如果没有记忆，Agent 只能追问：哪个订单？什么时候申请的？之前怎么处理的？

如果有记忆，流程就不一样。

• 从 Session 里知道用户上一轮问过退款到账时间。

• 从 State 里拿到当前退款工单 ID。

• 从 Long-term Memory 里知道用户偏好短信通知。

• 调用退款系统查询状态。

• 返回明确结果，并按偏好补发通知。

这才是用户真正需要的体验：不用重复解释，系统能接着上次继续处理。

七、不要把记忆做成风险源

记忆越强，风险越大。因为它会保存历史，也可能保存错误、过期或敏感信息。

最重要的一条：不要什么都记。

密码、身份证号、银行卡号、敏感健康信息、未经确认的推测，都不应该随意进入长期记忆。

生产环境必须支持查看、删除、过期和审计。记忆不是黑盒，用户和系统都要能管。

八、什么时候该上 Memory？

• 只做单轮问答：可以不做 Memory。

• 需要多轮对话：至少要做 Session。

• 需要多步骤任务：必须做 State。

• 需要个性化、跨会话延续：必须做 Long-term Memory。

• 涉及隐私、财务、医疗、交易：必须加权限、审计和删除能力。

九、总结

Memory 不是让 Agent “什么都记住”。

Memory 的核心，是把有用信息放到正确位置，并在正确时间拿出来。

Session 保连贯。State 保进度。Long-term Memory 保长期能力。

做到这一步，Agent 才能从一次性问答，升级成能持续工作的系统。