Agent 记忆策略:从 session 到长期

LLM 没有记忆。每次 API 调用独立 —— 模型对你上次对话零回忆。Agent 产品里的「记忆」是你通过决定每次调用带哪些 context 盖出来的。盖错,agent 感觉很笨(两条消息后就忘了用户名字)或很贵(每次都送整段所有对话历史)。

四层记忆基本涵盖所有真实产品需求。大部分团队过度工程化,在自己 50 行就够的时候去抓记忆库。

四层

Working memory。 当前对话的 message 历史。「我刚告诉你我叫 Alice」。对话内有效。
Session memory。 当前 session 的压缩总结。「这个用户在处理退款。」直到用户关掉聊天有效。
User memory。 跨 session 知道用户的东西。「Alice 是 Pro 方案、住台北、偏好繁中。」永久。
Episodic memory。 用户之后可能引用的特定过去事件。「3 月 3 日 Alice 问了 API rate limit 我们用 X 解决。」可搜索,不一定加载。

它们不是顺序层 —— 是你并行维护的不同抽象。

第 1 层:working memory(简单那个)

就是你每次 API 调用送的 message 数组:

messages = [
  {"role": "system", "content": "You are a helpful assistant."},
  {"role": "user", "content": "My name is Alice"},
  {"role": "assistant", "content": "Nice to meet you, Alice"},
  {"role": "user", "content": "What's my name?"},
]

模型轻松答「Alice」因为答案在 context 里。

working memory 有一个真挑战:context window 会塞满。50 轮对话带大工具输出之后,你可能已经到 context 预算 80%。三个解法:

总结旧轮次。 把前 30 轮换成 200 token 总结,每 N 轮跑一次。
消费过的工具结果丢掉。 第 4 轮的检索结果第 20 轮用不到。
用 prompt caching。 Claude 或 Gemini,system prompt + 对话前段可以 cache,重送便宜。(但还是吃 context。)

第 2 层:session memory(把简单做好)

Session 结束时(用户关聊天、你开新对话),别把整段历史丢掉,压缩它:

session_summary = llm.summarize(
    "用 200 token 总结这段对话。"
    "重点:用户要什么、解决了什么、还有什么待处理。"
    f"\n\n对话:\n{full_transcript}"
)
store_in_db(user_id, session_id, session_summary)

下次用户出现:加载他最近 3 个 session 总结,作为「最近脉络」注入 system prompt。Agent 现在感觉有连续性,你却没送 5 万 token。

这个单一功能 —— session 总结注入下个 session 的 context —— 用 100 行代码给你 80% 的「感觉它记得我」效果。

第 3 层:user memory(团队想太多的地方)

关于用户该永久持续的东西:名字、方案 tier、语言偏好、工作脉络、表述目标、学到的事实(「用户是儿科医生」「用户对花生过敏」)。

两种实作方法:

方法 A:结构化 profile

CREATE TABLE user_profile (
  user_id UUID PRIMARY KEY,
  display_name TEXT,
  preferred_language TEXT,
  occupation TEXT,
  notes TEXT[]  -- 用户提过的自由格式事实
);

用户提到事实时,agent 用 remember(category, fact) 之类的工具加进 profile。Session 开始时把 profile 加载 system prompt。

优点:结构化、可查询、可预测。用户可以看跟编辑他的 profile。

缺点:需要你预测哪些字段重要,抓不到所有东西。

方法 B:自由格式记忆 + 检索

把事实存成 vector store 里的 embedding。每轮检索 top-K 最相关记忆。

relevant_memories = vector_store.search(current_query, top_k=5)
system_prompt += f"\n相关记忆:\n{relevant_memories}"

优点:抓任意事实,规模到每用户几千条记忆。

缺点:检索可能漏相关记忆或浮出无关的。比较难 debug。没遗忘政策的话存储无上限成长。

实务上有效的做法

混合:

重要事实用结构化 profile(方案 tier、语言、名字、3 个主要表述目标)。5-10 字段。
轶事事实用自由笔记表(「偏好简洁答案」、「是儿科医生」)。最多 50 笔最近的,更多就用 embedding 搜索。

出货这个之后撞到真实限制再去抓 Mem0 / Letta / Zep。

第 4 层:episodic memory

最深层。用户可能想回头参考的过去对话:「上个月关于 API rate limit 的问题我们决定怎么处理?」

实作:

每段过去对话(完整或总结)用 metadata(日期、user_id、主题)当文档 index。
Agent 收到 query,对这个 index 跑检索。
找到符合就当 context 浮出:「2026-03-03 你讨论过... [总结]」
可选:让 agent 对特定过去 session 问追问。

大部分产品不需要第 4 层。客服 agent 跟个人助理受益。一般 chatbot 不需要 —— 成本(存储、检索延迟、评测复杂度)比偶尔「你记得那次吗?」时刻多。

2026 框架版图

值得认识的记忆框架:

Mem0。 最热门。自动记忆抽取 + 存储 + 检索。Python 跟 TS SDK,可以塞 LangChain 或独立用。用 LLM 从对话抽事实存起来。
Letta(原 MemGPT)。把记忆当层次操作系统 —— 「主记忆」对「归档记忆」。学术上有趣,设定多。
Zep。 Production 导向,评测跟 dashboard 较强。认真的对外 agent 值得。
LangChain Memory / LlamaIndex Memory。 那些框架的内建模块。

我的看法: 单产品独立团队,自己写。5+ 人团队出多个 agent 产品,用 Mem0 标准化。高风险(法律、医疗、金融建议 agent),跟 Zep 团队评估。

常见错误

存太多。 每个路过评论都进长期记忆。半年后 agent 以为用户真的很在乎猫,因为他提过一次。存储时激进过滤。
忘了忘记。 用户会变,旧事实变错。加时戳跟衰减权重,让用户清记忆。
相信 agent 抽取的事实。 「用户说他 30 岁」可能其实是「用户说我觉得你30 岁」。LLM 抽取会错。把存的记忆给用户看,让他改。
没隐私控制。 2026 年用户期待能看、改、删除自己的记忆。「这个 app 记得我什么?」必须能回答,理想上是 UI。
每轮加载太多。 每轮塞 5000 token 记忆,你每次 API 调用都付钱。要选择性,只载相关记忆。

独立开发者务实 stack

2026 年我自己个人项目在跑、推荐给独立创始人的:

Working memory:就 message 数组,30 轮后总结。
Session memory:每 session 200 token 总结存 postgres。
User memory:5 字段结构化 profile + 50 笔最近自由笔记。
Episodic memory:除非用户明确要,跳过。

大概 200 行代码,涵盖大部分产品「记忆」该做的 90%。撞墙再评估框架。

什么时候不要盖记忆

单轮产品(搜索、无来回的 tool use)。不需要记忆。
无状态 API endpoint。 记忆让输入输出依赖隐藏状态,测试难。
高隐私领域。 用户假设关页面对话就忘了的话,盖记忆创造期待跟风险。默认不记得,让用户 opt in。

下一步

MemGPT: Towards LLMs as Operating Systems(Packer et al, 2023)—— 原始 Letta 论文。
Mem0 文档 —— 实务抽取 pattern。
Generative Agents: Interactive Simulacra of Human Behavior(Park et al, 2023)—— 推红 agent 记忆的斯坦福论文。
查这些词:episodic memory、retrieval-augmented memory、fact extraction、memory consolidation。