夜雨聆风你的 AI 助手,为什么总在"失忆"?
一文讲透 Agent 记忆管理的全部套路 —— 短期记忆、长期记忆、Session、State、MemoryService,一次说清。
你有没有过这种经历 —— 昨天跟 AI 聊了半小时的减肥计划,今天打开它,它礼貌地问:"请问您想了解什么?"
那一刻你感觉它根本不是你的助手,就是个陌生人。
聊过的偏好、说过的心愿、立下的 flag —— 全部归零。你以为它在敷衍你,但其实不是。它只是 —— 没有记忆。
答案其实就 6 个字:让 AI 有记忆。
听起来像废话。但你往下看,会发现大厂的 Agent 框架(Google ADK、LangGraph、CrewAI)在这件事上,做了非常优雅的工程抽象。今天我们就用一篇的篇幅,把这件事彻底讲透。
失忆的 AI,是设计出来就这样
Stateless by design.
大模型的本质是一个"无状态函数":你喂它一段提示词,它吐一段文字。上一秒说过什么,下一秒它根本不知道。
这不是 Bug,是 Feature。大模型的训练数据是截止到某一天的,它不可能天然知道你昨天说了什么。
但当它被装进一个"Agent"的外壳,被赋予了"持续服务"的责任 —— 记不住事儿的助手,再聪明也没用。
Agent 失忆,不是模型不行,是工程没做。
而"记忆管理"这个设计模式,就是用来补齐这一课的。它和提示词链、路由、规划一样,是绕不开的底座工程。
记忆分两种:草稿本 vs 档案馆
Two kinds of memory, two jobs.
想象你请了一位私人助理。他每天上班,桌上一定会摆两样东西:
①一张草稿本 —— 写着今天你交代的事、刚说过的细节、下一步要做的事。下班就扔。
②一个档案柜 —— 存着你历年的喜好、合同、背景资料。不管过了多久,翻出来就有。
草稿本帮你度过"今天",档案馆帮你撑起"长线"。缺了任何一个,助理都不称职。
Agent 的记忆,也是这个套路 ——
·短期记忆(Short-Term Memory):上下文窗口就是那张草稿本。存着"当前这次对话"的所有信息。窗口一关,草稿本丢掉。
·长期记忆(Long-Term Memory):向量数据库就是那个档案馆。存着"跨会话、跨用户"的所有知识。随时可查,不会丢失。
把这两个搞定,Agent 才有资格叫"助手",而不是"聊天机器人"。
短期记忆:上下文窗口就是那张草稿本
Context window = scratchpad.
每次你打开一个 AI 聊天框,背后都有一张"草稿本"在工作。它叫上下文窗口(Context Window)。
这张草稿本里,装着:你刚发的消息、AI 上一句的回复、调用工具返回的结果、AI 的内心独白。它会在每次新消息进来时,把整段历史重新喂给模型,让模型"想起来"刚才说过什么。
草稿本有 3 个硬伤,你必须知道:
✗容量有限。GPT-4 是 8K,Claude Sonnet 是 200K,听起来很大,但一旦聊长,一样爆。
✗关掉就丢。会话结束,草稿本归档,下次再开是全新的一张。
✗成本不低。每条消息都要把整段历史重新算一遍 Token,聊得越久越贵。
于是工程师们想出了两个补救方案:摘要压缩(把旧对话总结成几句话)、关键信息外提(把用户偏好这种"硬数据"抽出来,放到别的地方)。
在 Google ADK 框架里,这件"草稿本"工作被拆成了两个组件:
·Session(会话):一次完整的聊天线程。里面装着消息历史(Events)和临时数据(State)。
·State(状态):这张草稿本上的"便签条"。比如"用户现在问的是减肥",贴在 Session 上,关掉会话就没了。
短期记忆的核心,是"管好这张草稿本" —— 该压缩的压缩,该外提的外提,别让窗口爆掉。
长期记忆:向量数据库就是你的档案馆
Vector DB = the archive.
草稿本解决"今天",档案馆解决"明天"。
Agent 的"档案馆"叫向量数据库(Vector Database)。它和你在 MySQL 里查"用户 ID = 1001"完全不是一回事 —— 它存的是"含义"。
工作流程分三步:
①把一段文字(比如"用户不喜欢香菜")变成一串数字(向量)。
②需要的时候,把问题也变成向量,和档案里的向量比"距离"。
③距离最近的 N 条,就是"最相关"的那批记忆。
这个过程叫语义搜索(Semantic Search)。它不要求关键词命中,只要"意思差不多"就能召回。这是它比传统数据库牛的地方,也是 RAG(检索增强生成)能火的根本原因。
在 Google ADK 里,操作档案馆的岗位叫 MemoryService。它干两件事:
·add_session_to_memory() —— 把某次会话里有价值的内容"归档"。
·search_memory() —— 按语义从档案馆里查回相关记忆。
LangGraph 把档案馆里的内容又分了三类,这个分类很经典,值得记一下:
·语义记忆(Semantic):静态事实。比如"用户是素食主义者"。
·情景记忆(Episodic):历史经验。比如"上次推荐火锅用户很满意"。
·程序记忆(Procedural):操作规则。Agent 自己的"工作手册",甚至可以让它自己改自己。
这三类拼起来,就是 Agent 真正的"档案柜"。
实战代码:用 ADK 三步搭起来
Build it in three steps.
概念讲完,该上手了。我们用 Google 官方的 ADK 框架,3 步搭一个"有记忆的 Agent"。
①初始化 SessionService(草稿本服务):
# 1. 选一个 SessionService
from google.adk.sessions import (
InMemorySessionService
)
# 测试用,数据不持久
session_service = (
InMemorySessionService()
)
②启动 Runner(让 Agent 跑起来):
# 2. 定义 Agent,绑 Session
from google.adk.agents import (
LlmAgent
)
from google.adk.runners import (
Runner
)
agent = LlmAgent(
name="Greeter",
model="gemini-2.0-flash",
instruction="短问候语",
output_key="last_greeting"
)
runner = Runner(
agent=agent,
app_name="my_app",
session_service=session_service
)
③最关键的一步:用前缀管理 State(三种作用域,一次说清):
# 3. 用前缀定义数据作用域
state = session.state
# 跨会话:这个用户的总登录数
state["user:login_count"] = 5
# 跨用户:应用的全局配额
state["app:max_quota"] = 100
# 一次性:本轮用完就丢
state["temp:validating"] = True
三个前缀,user: 跟着用户走(关了再开会还在)、app: 跟着应用走(所有用户共享)、temp: 跟着这一轮走(用完就清)。
状态更新必须走 session_service.append_event() 流程,直接改字典会被持久化层"看不见",这种小坑上线后查起来非常痛苦。
什么时候该用,什么时候别用
The rule of thumb.
不是所有 Agent 都需要记忆。判断标准很简单 —— 如果你的 Agent 只回答一次性问题(查天气、翻译句子、生成标题),加记忆就是浪费钱。
但只要满足下面任一条,记忆管理就不是"加分项",是"必选项":
✓多轮对话:用户希望聊完这轮,下一轮接着聊。
✓个性化推荐:用户希望 Agent 记得自己的偏好,不要每次都问"您喜欢什么风格"。
✓多步任务:Agent 要跟踪一个跨多轮才能完成的工作(比如"帮客户走完退款流程")。
✓持续学习:Agent 要根据反馈越用越聪明(强化学习、用户纠错)。
电商客服、私域运营助手、AI 选品 Agent、个人助理 —— 这些场景,没一个能离得开记忆。离得开的,只有"调用一次就跑"的工具型 Agent。
一句话总结:单次任务不需要记忆,长期服务必须记忆。
写在最后
"听起来很笨,但每一个真正能用的 Agent,都是从"草稿本 + 档案馆"这两件家具开始搭的。
没有银弹,没有捷径。短期靠上下文,长期靠向量库,中间用 Session 和 State 把它们缝起来 —— 这就是 2026 年所有 Agent 框架的秘密。
下次再有人跟你说"我们的 AI 很聪明",你可以问一句:它记得住我吗?
Next Issue · 下一期
Chapter 09 · Learning and Adaptation
Agent 怎么根据经验改变自己?程序记忆的"自迭代"机制是怎么工作的?
点个在看,下期继续陪你拆解 Agent 的 24 种设计模式。
