别再把聊天记录当记忆了：AI Agent 的四种记忆到底怎么分？

很多人第一次听到 AI Agent 记忆，会下意识以为：不就是把聊天记录存起来吗？

但真正做 Agent 系统时，很快会发现，“保存聊天记录”只是最低级的历史归档，并不等于 Agent 真的拥有记忆。

因为 Agent 需要的不是回放过去说过什么，而是在正确的时候拿到正确的上下文。

用户刚刚上传的代码，要不要记？当前任务做到哪一步了，要不要记？这个项目的技术栈，要不要记？用户喜欢什么回答风格，要不要记？这些问题看起来都叫“记忆”，但它们其实完全不是一类东西。

如果把它们都塞进一个所谓的 memory 表里，短期看实现简单，长期看一定会变成上下文污染源。

我现在更倾向于这样理解：

AI Agent 记忆不是一个大数据库，而是一组按生命周期、作用域和写入规则分层的上下文系统。

这篇先不讲 pgvector、RRF、LLM 裁判、revision 并发控制。那些是长期记忆实现篇要解决的问题。

这篇只讲一个更基础的问题：

Agent 到底有哪些记忆？短期记忆、任务记忆、项目记忆和长期用户记忆到底怎么分？

为什么聊天记录不等于记忆

先说一个很常见的误区：

只要把用户和 Agent 的历史对话都存下来，Agent 就有记忆了。

这听起来合理，但真正用起来会有几个问题。

1. 聊天记录太长，不能每次都塞回上下文

历史对话会越来越长。

如果每次回答都把所有聊天记录塞给模型，成本、延迟和上下文窗口都会爆掉。更麻烦的是，大量历史内容对当前问题根本没有价值。

比如用户三个月前让 Agent 写过一个 SQL，今天问的是博客标题怎么改。把三个月前的 SQL 聊天记录召回来，不但没帮助，还会干扰模型判断。

记忆系统不是“全部想起来”，而是“该想起来的时候想起来”。

2. 聊天记录里有大量临时信息

聊天记录里充满临时内容：

• “先这样吧”；
• “等下再说”；
• “这次先不管”；
• “临时用 3000 端口跑一下”；
• “帮我把这个变量名改掉”。

这些信息在当时有用，但不应该长期影响未来回答。

如果 Agent 把“临时用 3000 端口”记成项目长期事实，下次就可能误导用户。

3. 聊天记录会重复、冲突、过期

用户今天可能说：

这个项目先用 npm。

三天后又说：

以后统一换成 pnpm。

如果只是保存聊天记录，系统会同时看到 npm 和 pnpm。

但如果是记忆系统，它应该知道：后者修正了前者。

这就是聊天记录和记忆的差别：

聊天记录关心：过去说过什么
记忆系统关心：现在应该相信什么

4. 聊天记录不知道什么值得记

用户说过的话不等于都值得长期保存。

比如：

今天有点困。

这是一条对当前对话可能有用的信息，但通常不应该写进长期记忆。

再比如：

以后回答我直接一点，少客套。

这就更像长期偏好，值得保留。

所以 Agent 记忆的核心不是存储，而是判断：

哪些信息有长期价值？哪些只在当前任务里有用？哪些根本不该记？

先把 Agent 记忆分成四类

为了不把所有东西都混在一起，可以先把 Agent 记忆分成四类：

这四类不是数据库表名，也不是一定要这样建模。

它们更像一个判断框架：当你想让 Agent “记住点什么”时，先问这条信息属于哪一类。

分类清楚之后，后面的存储、检索、更新、权限和过期策略才有可能清楚。

第一类：短期记忆

短期记忆就是当前对话窗口里的上下文。

它包括：

• 用户刚刚说的话；
• Agent 刚刚回答过的内容；
• 当前轮正在处理的问题；
• 刚上传的文件、图片或代码片段；
• 本轮对话里的临时约束；
• 模型当前上下文窗口里能看到的信息。

短期记忆最典型的作用，是让 Agent 能接住连续对话。

比如：

用户：帮我优化这段代码。
用户：再把它改成 TypeScript。

第二句话里的“它”，依赖的就是短期记忆。

如果没有短期记忆，Agent 不知道“它”指的是哪段代码。

短期记忆的特点是：

短期记忆最容易被误用的地方，是把它当成长期记忆。

比如用户在当前任务里说：

这次先用 JavaScript 写。

这句话在当前任务里有用，但不代表用户以后都喜欢 JavaScript，也不代表所有项目都用 JavaScript。

所以短期记忆解决的是“眼前这几句话怎么接上”，不是“用户长期是什么样的人”。

第二类：任务记忆

任务记忆记录的是：这件事做到哪了。

它不是用户画像，也不是项目背景，而是一个复杂任务里的工作状态。

比如用户说：

把这篇文章整理进我的博客项目，风格参考之前的实现。

Agent 可能需要做很多步：

1. 读取原文；
2. 查看博客项目结构；
3. 参考已有文章 frontmatter；
4. 新增 Markdown 文件；
5. 调整标题和描述；
6. 运行校验；
7. 提交代码。

这些中间状态就属于任务记忆。

它回答的问题不是“用户是谁”，而是：

当前目标是什么？
已经做了什么？
还剩什么？
哪些地方需要用户确认？

任务记忆通常包括：

• 当前任务目标；
• Todo / plan；
• 已完成步骤；
• 未完成步骤；
• 中间发现的问题；
• 用户临时做出的选择；
• 当前任务的阶段性结论；
• 下一步动作。

举个例子：

任务：整理长期记忆文章到博客。
已完成：
- 读取源文章
- 确认博客文章风格
- 新增 Markdown 文件
- 修改标题

待完成：
- 补充 GitHub 仓库链接
- 运行 astro check
- 提交并推送代码

这就是典型任务记忆。

它很重要，但它不应该被写进长期用户记忆。

因为三天后，这个任务完成了，里面很多状态就不再有价值。长期记住“待完成：运行 astro check”反而会污染未来回答。

任务记忆的特点是：

任务记忆更像一块工作白板。

任务没完成时，它很有价值；任务完成后，它大多只剩审计和复盘价值。

第三类：项目记忆

项目记忆是围绕某个项目、仓库、团队或业务空间稳定存在的上下文。

它解决的是：Agent 进入一个项目时，不要每次都重新认识这个世界。

比如一个代码仓库里可能有这些约定：

• 项目使用 Next.js；
• 包管理器是 pnpm；
• 文章放在 src/content/posts；
• frontmatter 必须包含 title、description、pubDatetime；
• 提交前要运行 pnpm exec astro check；
• 不要删除 .workbuddy 目录；
• 某个实验项目不是完整框架，只是博客配套 lab。

这些信息不是用户的长期偏好，而是项目自身的事实。

这就是项目记忆。

项目记忆常见来源包括：

• README.md；
• AGENTS.md；
• .cursorrules / agent 指令文件；
• 项目文档；
• package scripts；
• 目录结构；
• 历史架构决策；
• 团队约定。

项目记忆和长期用户记忆最容易混淆。

比如：

用户偏好 pnpm 作为包管理器。
这个项目使用 pnpm 作为包管理器。

这两句话看起来很像，但作用域完全不同。

第一句是用户偏好，可能跨项目生效。第二句是项目事实，只对当前项目生效。

如果把项目事实误写成用户长期记忆，Agent 未来进入另一个 npm 项目时，就可能错误地坚持使用 pnpm。

项目记忆的特点是：

项目记忆的关键是作用域。

它应该绑定到项目、仓库、团队或业务空间，而不是直接绑定到用户个人。

第四类：长期用户记忆

长期用户记忆是跨会话、跨任务长期有效的用户事实。

它解决的是：Agent 不要每次都让用户重复说明自己是谁、喜欢什么、在做什么。

长期用户记忆可以包括：

• 用户喜欢的回答风格；
• 用户常用技术栈；
• 用户长期关注的方向；
• 用户身份或角色；
• 用户长期项目背景；
• 用户明确要求长期遵守的禁忌；
• 反复确认过的重要偏好。

比如：

用户喜欢回答直接一点，少客套。
用户主要写 TypeScript 和 Next.js。
用户在维护一个 AI 工程化博客。
用户希望涉及中国语境的金融图表使用红涨绿跌。

这些信息如果每次都让用户重复说，会很烦。

这就是长期用户记忆的价值。

但长期用户记忆也是最需要谨慎的一类。

因为它会影响未来很多次回答。如果记错了、记偏了、记了不该记的隐私信息，后果比短期记忆严重得多。

长期用户记忆不应该随便写入。

不建议写入的内容包括：

• 一次性情绪；
• 临时任务状态；
• 没有确认的推测；
• 过期项目细节；
• 敏感隐私信息；
• 模型自己猜出来的用户画像。

比如：

用户今晚很累。

这可能只适合当前对话，不适合长期保存。

再比如：

用户可能是某公司高管。

如果用户没有明确说过，就不应该写成长期记忆。

长期用户记忆的特点是：

长期用户记忆的原则可以概括成一句话：

宁可少记，也不要乱记。

四类记忆放在一起看

把四类记忆放在一起，对比会更清楚：

还有一种更简单的判断方式：

当前几句话要用        → 短期记忆
当前这件事要用        → 任务记忆
当前这个项目要用      → 项目记忆
以后很多次都可能要用  → 长期用户记忆

这套判断非常实用。

当用户说“记一下”时，Agent 不应该立刻把信息写进长期记忆，而应该先判断它属于哪一层。

不是所有信息都值得记

一个好的 Agent 记忆系统，重点不是记得多，而是记得准。

每次准备写入记忆前，都可以问几个问题：

1. 这条信息以后还会不会用？
2. 它属于用户、任务还是项目？
3. 它是否稳定？
4. 它是否已经确认？
5. 它是否可能误导未来回答？
6. 它是否涉及隐私或敏感信息？

不同答案对应不同处理方式。

当前回答要用

放进短期记忆。

比如用户刚上传了一段代码，Agent 需要基于它继续修改。代码本身不一定要长期保存，只要当前上下文能看到就够了。

当前任务要用

放进任务记忆。

比如当前已经完成哪些步骤、还剩哪些步骤、用户刚确认了哪个方案。这些信息帮助 Agent 完成任务，但任务结束后未必有长期价值。

当前项目长期要用

放进项目记忆。

比如项目目录结构、运行命令、框架约定、发布流程。这些信息应该跟项目绑定，而不是跟用户个人绑定。

跨会话都稳定有效

才考虑放进长期用户记忆。

比如用户明确说：

以后回答我少一点客套，直接给结论。

这类信息跨任务也有价值，可以作为长期偏好。

不确定、不稳定、敏感、一次性

不要记。

比如：

我今天有点烦。
这次先随便写。
你猜我是不是做金融的？
这个 token 临时给你用一下。

这些信息不应该进入长期记忆。

记忆分层之后，系统设计会清楚很多

为什么一定要分层？

因为不同记忆的生命周期、访问范围、更新频率和风险完全不同。

生命周期不同

短期记忆可能几分钟后就没用了。

任务记忆可能任务完成后就应该清掉。

项目记忆可能在一个仓库里长期有效。

长期用户记忆可能跨越很多会话和项目。

如果不分层，就很容易把临时信息长期化。

访问范围不同

短期记忆只属于当前会话。

任务记忆只属于当前任务。

项目记忆只属于当前项目。

长期用户记忆属于用户本人。

访问范围不同，权限边界也不同。

更新方式不同

短期记忆通常不需要显式更新，它随着上下文窗口自然变化。

任务记忆需要频繁更新，因为任务进度一直在变。

项目记忆需要随着代码和文档变化而更新。

长期用户记忆更新最谨慎，因为它影响未来很多次交互。

检索方式不同

短期记忆通常直接在上下文里，不需要检索。

任务记忆可以按当前任务 ID 读取。

项目记忆更适合按项目、文件、文档、关键词检索。

长期用户记忆则需要按语义、类别、重要性、时间和访问统计综合检索。

过期策略不同

短期记忆自然过期。

任务记忆随任务结束过期。

项目记忆随项目变更更新。

长期用户记忆需要处理衰减、冲突、删除和用户管理。

所以，把所有记忆混在一个库里，看起来少建了几张表，实际上会把后续所有问题都混在一起。

一个具体例子

假设用户说：

这篇文章先放到 yi-notes 里，标题风格要像之前那几篇 AI 工程化文章。以后我不喜欢太客套的回答，直接一点。

这句话里其实混了好几类记忆。

短期记忆

这篇文章
之前那几篇 AI 工程化文章

这些依赖当前对话上下文和当前文件，不一定要长期保存。

任务记忆

当前任务：把文章放到 yi-notes。
要求：标题风格参考之前 AI 工程化文章。

这是当前任务要用的信息。

项目记忆

yi-notes 是博客项目。
AI 工程化文章有固定 frontmatter 和 series 约定。

这是项目相关背景，应该绑定到 yi-notes。

长期用户记忆

用户不喜欢太客套的回答，希望直接一点。

这是跨会话也可能有用的稳定偏好。

如果 Agent 不做分类，就可能把整句话原封不动写进长期记忆。

这就很糟糕。

因为“这篇文章先放到 yi-notes”是任务状态，不是长期用户事实；“标题风格像之前几篇”是当前任务要求，也不是长期偏好。

真正值得长期记住的，只有最后那句回答风格偏好。

四类记忆之间怎么配合

一个比较理想的 Agent 工作方式是：

短期记忆负责理解当前对话
任务记忆负责推进当前目标
项目记忆负责遵守项目约定
长期用户记忆负责个性化和连续性

比如用户让 Agent 修改一个项目里的代码。

Agent 应该同时用到：

• 短期记忆：用户刚刚说的具体需求；
• 任务记忆：已经读过哪些文件、改了哪些地方、测试有没有跑；
• 项目记忆：项目技术栈、目录结构、代码规范、运行命令；
• 长期用户记忆：用户喜欢简洁汇报、偏好中文说明、讨厌无意义客套。

这四层一起工作，Agent 才会像一个真正熟悉上下文的协作者。

但它们的写入边界必须分清。

否则，Agent 就会出现几类典型问题：

• 把临时任务当长期偏好；
• 把项目约定带到其他项目；
• 把聊天记录噪音召回到当前回答；
• 把过期事实当成当前事实；
• 把用户没有确认的信息写进画像。

这些问题不是模型参数能解决的，而是记忆系统设计问题。

什么时候需要真正做长期记忆系统

如果只是一个简单聊天机器人，不一定要一上来就做复杂记忆系统。

很多早期产品只需要：

• 保留最近几轮对话；
• 给当前任务一个 plan；
• 从项目文档里读取约定；
• 少量人工配置用户偏好。

这已经能解决很多问题。

真正需要长期记忆系统，通常是出现这些信号：

• 用户反复告诉 Agent 相同偏好；
• Agent 经常忘记历史决策；
• 同一个用户跨多个任务长期协作；
• 同一个项目需要持续维护上下文；
• 多个 Agent 或多个会话会同时工作；
• 记忆需要更新、合并、删除和审计；
• 不能再靠简单 prompt 或固定 profile 解决。

到了这个阶段，才需要认真设计长期记忆的数据模型、检索、去重、更新和并发控制。

这也是为什么我把“记忆分类”和“长期记忆实现”拆成两篇。

先搞清楚有哪些记忆，再去讨论怎么实现长期记忆，顺序会更自然。

总结

AI Agent 的记忆，不是简单保存聊天记录。

更准确地说，它是一套上下文分层机制：

• 短期记忆：解决当前对话怎么接上；
• 任务记忆：解决当前任务做到哪了；
• 项目记忆：解决当前项目有哪些背景和约定；
• 长期用户记忆：解决用户长期偏好和稳定事实怎么继承。

这四类记忆的生命周期、作用域、写入规则和风险都不一样。

如果混在一起，系统会越来越像一个装满历史噪音的大仓库；如果分清楚，Agent 才能在正确的时候拿到正确的上下文。

记忆系统真正要解决的，不是“存下更多东西”，而是：

什么该记，记在哪里，什么时候用，什么时候忘。

理解了这一点，再去看长期记忆实现，就会清楚很多。

下一篇就可以继续展开：如果我们真的要做“长期用户记忆”，数据模型、检索、去重、更新和并发控制应该怎么设计？

也就是这篇：我手搓了一个 AI Agent 记忆框架，才发现“长期记忆”不是存聊天记录。

AI 工程化相关阅读

• 我手搓了一个 AI Agent 记忆框架，才发现“长期记忆”不是存聊天记录
• RAG 为什么回答流程问题会漏步骤？原因和改进方案
• 企业级 RAG 怎么落地？不只是向量检索和大模型
• MCP 权限怎么分级？只读、可操作和高风险动作