Agent 记忆

它是什么

Agent 记忆是应用在轮次之外维护的状态仓库：把这次对话里值得留下的部分写进外部存储，下一次需要时再取回来放进上下文。它不是模型的能力，而是应用替模型做的一件事——模型本身是无状态的，每次请求它只看到当前上下文里有什么。[S1]

所以「有没有记忆」的判据不是「模型记不记得」，而是三个可检查的问题：谁来写、写到哪、什么时候删。三者缺一，系统要么什么都没留下，要么把过期的、错误的东西一直留在里面。

它是外部的、可检查的状态，不是模型内部悄悄积累的印象。

为什么需要它

因为多步任务和跨会话任务天然比一次问答长。用户上个月提过的偏好、上次没解决的工单、三步之前查到的那批数据——如果每一轮都重新问一遍，体验和成本都不可接受。

但真正让记忆从「锦上添花」变成「必须设计」的原因在另一面：记忆是错误放大器。一次问答答错了，损失就是这一轮；一条错误的记忆被写进去，之后的每一次调用都要带着它走。更糟的是，记忆错误往往不出错、只变味——系统照常回答，只是回答建立在一条已经不成立的前提上。

上下文窗口扩大不能解决这件事：窗口决定一次能装多少，记忆决定跨轮次留下什么，两者是不同的轴。

它如何工作

工程上通常分两层：

• 短期记忆：当前任务或会话内的临时信息，通常就放在上下文里（对话历史、临时变量）。它的生命周期与这次任务一致，任务结束就丢。
• 长期记忆：跨会话仍可能有用的信息——用户偏好、已确认的事实、历史结论。它存放在外部（数据库、向量数据库、文件），需要时才取回。

长期记忆的关键动作有四个：写入、取回、更新、删除。

• 写入要有一个明确的触发条件（任务成功结束时？用户明确要求记住时？），而不是「把对话全文存下来」。存全文的后果是取回时噪声比信号多。
• 取回要按相关性排序，并且受权限约束——某个用户不该看到另一个用户的记忆，这和检索的准确率是两件事。
• 更新意味着旧结论可以被新事实推翻，否则系统会同时持有互相矛盾的两条记忆。
• 删除是最容易被跳过、也最不能跳过的一项：既包括隐私合规要求，也包括「删掉一条被证伪的偏好」这种正确性需求。

必须澄清的误会

Agent 记忆 ≠ 上下文窗口。 上下文窗口是「这一次能带多少」，记忆是「上一次留下了什么」。窗口开到再大，也不会自动记住上一轮——那是应用写进去的。把两者混为一谈，会得到「我们上下文很长，所以它有记忆」这种错误结论，然后在跨会话场景里发现它什么都没记住。

Agent 记忆 ≠ 向量数据库。 向量库是一种存储与检索设施，可以承载记忆，但记忆要回答的问题比检索多：什么时候写、写什么粒度、写错了怎么改、过期了怎么清。只接一个向量库、不做写入与清理策略，得到的是「一个越来越大的、不知道哪条还成立的文本堆」。

它也不等于微调。 微调改的是模型权重，是训练期的动作；记忆是运行期的外部状态，可以随时增删改。需要「马上改掉一条已确认的信息」时，只有记忆能做得到。

还有一个反直觉的点：记忆不好用的典型原因不是「记不住」，而是「记错了还不清」。 排查记忆问题时，先看写入条件和删除策略，再考虑换存储方案。

真实例子

一个客服 Agent 的记忆设计可以长这样：工单结束时写入三个字段——用户 ID、本次确认的结论、下次需要跟进的动作；写入前先核对这条结论是否已被用户确认（未确认的不写）；取回时只取当前用户、最近 90 天、状态为「未关闭」的记录；用户要求删除时，连同后续轮次里的引用一起清掉；每次取回都在日志里留下「取了哪几条」，便于事后解释一次错误回答是因为查到了一条过期结论。[S2]

这里值得注意的不是它记住了多少，而是它明确规定了不记什么（未确认的结论、无关的闲聊、超过 90 天的记录）。记忆的质量主要由「不写什么」决定。

什么时候适合与不适合

适合：任务跨会话延续、需要个性化的稳定偏好、用户明确要求「下次别让我再说一遍」。这些场景里，记住的价值远大于多一层存储的复杂度。

不适合：信息本身不稳定或无法验证（把模型上一轮的猜测写进长期记忆，是最典型的自伤）；隐私或合规上不允许留存；以及需要强一致的场景——记忆是最终一致的，如果下游动作必须基于最新的绝对正确状态，应该去查权威数据源，而不是信任记忆。

两种失败模式值得分开看。 一种是污染：错误或过期的信息被写进记忆，之后长期影响输出——防它的办法是收紧写入条件，并给每条记忆加上来源与时间。另一种是污染扩散：一条错误记忆被取回、被用于生成、生成的结论又被写回记忆——这条环路要在架构上断开，例如规定「模型的产出不能直接成为记忆」。

亲自试一下

挑一个你手上的多步任务，用约 30 分钟在纸上写四项内容：

1. 记什么：哪些字段值得跨轮次保留（不超过 5 个）。
2. 什么时候写：写入的触发条件是什么，谁来判断「这条值得记」。
3. 什么时候取：取回时按什么排序、受哪些权限限制、最多取几条。
4. 什么时候删：过期规则、被推翻时的处理、用户要求删除时的范围。

写完后跑两次同一个任务，看第二次是否真的用上了第一次的结果。观察点不是「它记住了吗」，而是如果第一次记错了，第二次会不会照错走——如果你答不出这个问题，说明写入条件还没有把关。

接下来学什么

记忆是这一站（给手脚）的核心概念之一，它和 Agent 规划、工具调用 一起回答「怎么从给答案变成把事办完」。三者分工要分清：规划决定下一步做什么，工具调用决定用什么能力去做，记忆决定上一轮留下了什么。

如果你还没理清「模型为什么需要被喂上下文」，先读上一站的 上下文工程 与 上下文窗口（给沟通、给知识）。如果你在犹豫「这一步要不要人批」，看 人在回路 的分界。跑通之后，下一站是 给接口：把工具接入标准化，免得每个系统各接一遍。

来源与修订

把记忆与工具、规划并列为 Agent 相对固定工作流的差别，来自 Anthropic 的工程实践文章 Building Effective Agents；长期信息需要更新、删除与权限边界的判断，参考 Trustworthy Agents in Practice。[S1][S2]

需要说明一处边界：「写入触发条件、取回权限、删除范围、断开污染环路」这四条是本站在落地时总结的操作性要求，不是上述来源的原文——来源讲的是架构与风险框架，不展开存储设计细节。把它们写在这里，是因为记忆上线后最常出事的位置恰好在这四条上。

2026-09-21 按决策页规范重写，本次修订补上了写入与删除这一半：原版本只解释记忆是什么，没有回答「谁在什么时候写、什么时候删」，而那恰好是记忆真正出问题的地方。