没有记忆的 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 才能从一次性问答，升级成能持续工作的系统。