第 03 篇说过，模型本身是无状态的，每次调用都要重发完整历史。那 Agent 是怎么「记住」你上周说过的话的？答案是：记忆不在模型里，而在模型之外。
一、上下文不等于记忆
先区分两个概念：
| 上下文 | 记忆 | |
|---|---|---|
| 在哪里 | 本次调用发给模型的内容 | 模型之外的存储：数据库、文件、向量库 |
| 多久 | 只在本次调用有效 | 跨调用、跨会话长期存在 |
| 容量 | 受上下文窗口限制 | 理论上无限 |
| 如何生效 | 模型直接看到 | 必须先取出来放进上下文才生效 |
最后一行是关键：记忆要发挥作用，最终还是要被放进上下文。所以记忆系统要解决的核心问题是：存什么、什么时候取、取哪些。
二、短期记忆
短期记忆就是当前会话的消息列表。会话进行时，它一直在上下文里；会话结束，它就消失了。
短期记忆的管理就是上一篇讲的上下文工程：裁剪、压缩、摘要。一个常见做法是保留最近 N 轮完整对话，更早的部分压缩成摘要。
三、长期记忆
长期记忆让 Agent 能跨会话记住信息。常见的存储形式：
- 结构化存储：数据库表，比如用户偏好、项目配置。查询精确，适合明确的事实。
- 文件：Markdown 或 JSON 文件，按主题组织。简单直观，人也能直接阅读和修改。
- 向量库：把文本转成向量存储，按语义相似度检索。适合内容多、需要模糊匹配的场景。下一篇 RAG 会详细讲。
很多实际系统用的就是最朴素的方式：一个或几个文本文件，Agent 每次启动时读进来。不要一上来就上向量库。
四、写入策略：存什么、谁来存
存什么
值得存的通常是稳定的、会被反复用到的信息：
- 用户的身份、偏好、习惯；
- 项目的背景、约定、已做出的决定；
- 反复被纠正的错误（「别再用某个过时的接口了」）。
不值得存的：一次性的临时信息、模型自己推测的结论、可以随时重新查询到的数据。
谁来存
- 用户显式要求：「记住我喜欢简洁的回答」。最可靠。
- Agent 自主判断：给 Agent 一个「写入记忆」的工具，让它自己决定。灵活，但可能存一堆没用的东西。
- 后台处理：会话结束后，由单独的流程回顾整段对话，提取值得保存的信息。不打断对话，质量也更可控。
五、读取策略：什么时候取、取哪些
- 每次全部注入：记忆量小时最简单，比如一份几百字的用户档案，每次都放进 System Prompt。
- 按需检索：记忆量大时，根据当前问题检索相关的部分。可以是自动检索，也可以给 Agent 一个「查询记忆」工具让它自己决定。
- 索引 + 按需读取：每次注入一个记忆目录（有哪些文件、各自讲什么），Agent 需要时再读具体内容。兼顾了覆盖面和上下文成本。
六、记忆带来的风险
- 过期信息：用户三个月前说「项目用 MySQL」，后来换了，记忆没更新，Agent 继续按旧信息工作。记忆需要能更新和覆盖，最好带上时间。
- 错误信息被固化：一次错误的推断被写进记忆，之后反复被使用。所以写入时最好只存用户明确说过的事实，而不是模型的推测。
- 隐私与安全：密码、身份证号、健康等敏感信息不应该存。用户应该能查看和删除自己的记忆。
- 记忆注入：如果记忆来自不可信的来源，里面可能夹带恶意指令。读出的记忆应被当作数据而不是指令。第 18 篇会讲。
本篇小结
- 记忆在模型之外，要生效必须被放进上下文。
- 短期记忆是当前会话，长期记忆是外部存储。
- 写入：只存稳定、反复用到的事实；可由用户、Agent 或后台流程写入。
- 读取：全部注入、按需检索、索引加按需读取。
- 风险：过期、错误固化、隐私、注入。
思考与练习
- 一个帮你管理服务器的 Agent，应该记住哪些东西？哪些东西不应该记？
- 如果用户说「忘掉我之前说的项目配置」，你的记忆系统要怎么处理？
上一篇：AI Agent原理篇07：上下文工程：给模型看什么、什么时候看
下一篇：AI Agent原理篇09：RAG：检索增强生成原理
返回系列总目录