AI 代理的四种记忆：从上下文窗口到跨会话学习

这期视频表面上在讲 AI agent 的四种记忆，真正有价值的地方是它把今天已经落地的几套工程做法放进了同一张图里：上下文窗口负责眼前，Claude.md 这类项目文档负责常识，skills 负责做事的方法，跨会话记忆才负责真正意义上的“越用越熟”。原视频：https://www.youtube.com/watch?v=BacJ6sEhqMo

很多人一聊 agent 记忆，第一反应还是“把上下文做大一点”。这当然有用，但只够解决一小部分问题。上下文窗口再大，本质上也只是当前会话的工作台。会话一结束，它就清空了。

这期视频的好处，是把 agent 的记忆拆成四层：工作记忆、语义记忆、程序记忆、情景记忆。这个拆法并不花哨，但很适合拿来理解今天的实际系统。你会发现，很多看起来分散的东西，比如 Claude.md、skills、跨会话记忆，原来讲的是同一个问题：agent 到底靠什么记住、理解并继续做事。

上下文窗口只是工作台，不是仓库

第一层是工作记忆，也就是上下文窗口。它装的是 agent 此刻能看到的东西：当前对话、系统提示、临时加载的文件、眼前这一步任务需要的背景。

视频里用了一个很直接的类比：这层就像 RAM。快，能立刻访问，但会丢，而且容量终究有限。今天很多模型已经把上下文窗口做到很大，百万 token 也不算稀奇，可这不等于记忆问题已经解决。你把所有资料一股脑塞进去，模型不会自动变得更懂你，反而更容易把关键东西埋没在中间。

这也是为什么真正能用的 agent 系统，重点通常不是“无限扩窗”，而是怎么决定什么该进窗口、什么时候进、进多少。说白了，工作记忆解决的是“眼前要做什么”，不是“这个系统长期知道什么”。

语义记忆存的是常识、规则和项目知识

第二层是语义记忆。这里存的不是临时上下文，而是 agent 平时就该知道的事实和规则。

学术圈喜欢把这层讲成向量数据库、知识图谱，当然没问题。但视频里有一个很接地气的提醒：很多生产环境里的语义记忆，其实没那么复杂，往往就是一批 Markdown 文件。

Claude Code 的 CLAUDE.md 就是很好的例子。它放在项目根目录，里面写项目架构、编码约定、构建命令、哪些事情不要做。每次 session 开始，这些内容就会被加载进来。它不负责解决某个瞬时任务，而是负责给 agent 一个稳定的背景板。

这层的价值在于防止 agent 重复犯低级错误。没有语义记忆，模型每次都像第一次进项目。它可能能回答问题，也可能能写点代码，但它不知道这个项目一贯怎么做，不知道哪些坑已经踩过，更不知道哪些约束是不能碰的。

程序记忆解决的是“怎么做”，不是“知道什么”

第三层是程序记忆，也就是视频里提到的 skills。

这个区分很关键。语义记忆回答的是“什么是真的”，程序记忆回答的是“事情该怎么做”。前者更像知识库，后者更像操作手册。

一个 skill 本质上就是一套可调用的方法：什么场景触发、按什么步骤执行、过程中需要哪些模板、脚本和校验。它可以小到一个结构化 code review，也可以大到一整套内容生产或发布流程。

视频里讲到一个很重要的点：progressive disclosure，也就是按需展开。agent 不会一上来把所有 skill 全塞进上下文，因为那样很快就会把工作记忆打爆。更合理的做法是先只暴露一个轻量索引：有哪些技能、每个技能大概做什么。等某个任务真正命中，再把完整说明书和关联资源拉进来。

这也是我觉得现在很多人容易混淆的地方。提示词库不是程序记忆。只有当这些提示、脚本、校验条件被整理成一套能稳定触发、稳定执行、稳定复用的流程，它才算真正的程序记忆。

最难的一层，是跨会话的经验记忆

第四层是情景记忆，也就是 episodic memory。它记录的不是通用知识，也不是固定流程，而是过去发生过什么、做过哪些判断、从中学到了什么。

最粗糙的实现方式当然是保存全部对话记录，然后以后再搜。严格说这也算记忆，但通常没那么好用。因为一段完整 transcript 里，真正有价值的往往只有少数几条经验结论。

视频举的例子很典型：比起保存一整段 45 分钟的调试对话，更有价值的可能只是这样一句话——“上次排查 auth 模块时，问题出在 middleware 层”。

这句话里有场景、有结论、有未来复用价值。它不像 transcript 那样啰嗦，也不像通用知识那样抽象。它更像一个系统在长期工作后提炼出来的经验笔记。

也正因为如此，情景记忆是四层里最难做的一层。问题不只是怎么存，而是存什么、删什么、什么时候该忘。用户换项目了，旧经验还要不要保留？某条经验过时了，系统怎么知道它已经失效？这些都不是“把数据放进库里”就能解决的。

为什么有些 agent 只需要两层记忆，有些却四层全要

这个四分法还有一个现实价值：它提醒你，不是每个 agent 都配得上完整记忆栈。

一个非常窄的 routing bot，可能只要工作记忆就够了。一个只负责密码重置的客服 agent，可能再加一条 procedural skill 也就差不多了。你没必要为了这种任务上完整的知识库和跨会话记忆系统。

但只要任务开始变长、开始跨文件、跨步骤、跨会话，记忆层级就会立刻变重要。coding agent 就是典型例子。它需要工作记忆来处理当前任务，需要语义记忆来理解项目约束，需要程序记忆来调用稳定流程，还需要情景记忆来积累过去做对和做错的经验。

换句话说，记忆架构不是越全越先进，而是要和任务复杂度匹配。很多团队一上来就想做“大而全的 agent memory platform”，最后只是在给一个窄任务机器人配航母。

这套框架最大的价值，是把分散的工程做法放回原位

这期视频最有启发的地方，不是告诉你“四种记忆”这个名词，而是帮你把很多已经见过的工程实践重新归位。

你会突然明白：
– 上下文工程，本质上是在管工作记忆
– CLAUDE.md、项目 wiki、约定文档，本质上是在做语义记忆
– skills、脚本、操作流程，本质上是在做程序记忆
– 跨 session 的经验提炼，本质上是在做情景记忆

一旦这样看，很多争论就会清楚得多。比如“只靠超长上下文够不够”“skills 到底是不是 prompt 包装”“把所有聊天记录存下来算不算记忆”，这些问题都可以直接落回四层模型里去判断，而不用靠感觉争。

真正难的，不是把记忆存起来，而是把记忆治理好

这期视频没有深入展开的一点，也是我觉得真正难的部分：记忆治理。

存储不是最难的。今天谁都能把资料、文档、日志、对话存起来。难的是让系统长期保持干净、有效、不过时。

语义记忆会遇到版本漂移。程序记忆会遇到 skill 过时。情景记忆更麻烦，它很容易从“经验提炼”慢慢退化成“垃圾堆积”。一旦没有筛选和淘汰机制，记得越多，系统不一定越聪明，反而可能越混乱。

所以四层记忆真正指向的，不是“多存一点”，而是“分层管理”。哪些东西该常驻，哪些东西只按需加载，哪些应该沉淀成稳定流程，哪些只能以经验形式短期保留。把这些分清，agent 才有可能越用越稳。

最后一句实用判断

如果你今天还在把“更长上下文”当成 agent 记忆的主要答案，这期视频值得看。

它提醒我们，能让 agent 看得更多，不等于让 agent 真的记得更久。真正把 chatbot 和 agent 拉开差距的，也不是会不会调用工具，而是有没有一套分层的记忆结构：眼前的问题放进工作台，长期的规则放进知识层，反复执行的任务沉淀成技能，真正值得留下的经验再进入跨会话记忆。

这样一来，系统才不是每次都从零开始。

附：完整中文整理

AI 代理有不同的记忆方式，每一种都服务于不同目的。

所以这次我们来看看 AI 代理记忆的四种主要类型：先从一些很基础的东西讲起，再到我觉得已经开始变得很有意思的一些新方向。

我觉得先值得想一件事：人类的记忆到底是怎么工作的？

我们可以先把人的记忆理解成短期记忆。也就是此刻正在大脑里活跃的东西，比如我现在这一秒正在说的话。

这是一种记忆。但还有一种记忆叫事实性知识。比如你记得公司的安全策略，或者你知道 Python 是一门解释型语言。

然后还有学会的技能。比如，嗯，在玻璃板上反着写字——就像我现在显然正在做的这样。这里绝对没有任何摄影机戏法。

再然后是个人经验。比如我有一次花了三个小时排查 Kubernetes 集群，最后才发现——我从头到尾连错了集群。

真的，那三个小时就这么没了。

总之，设计得好的 AI agent，其实也需要这几种记忆。准确地说，就是我这里列出的四种记忆。

而且这背后其实有一个很有名的框架，来自普林斯顿的一支研究团队。他们把它叫作 CoALA，也就是 Cognitive Architectures for Language Agents。这个框架把 agent 需要的记忆分成了四种明确的类型。

下面我们一类一类过，看看它们今天在真实的 agent 系统里到底是怎么工作的。

第一类，是工作记忆。

这就是 agent 的上下文窗口。它此刻能看到的所有东西都在这里：当前对话、系统指令，如果有的话也在这里；还有任何已经被塞进 prompt 里的文件和数据，也都在这里。

所以它其实就是一个临时工作台。

大家最常用的类比是：它就像 RAM，也就是随机访问内存。

它很快，能立刻访问，但它是易失的。一次 session 结束，它就没了。

而且它容量有限。虽然今天最大的上下文窗口已经很大了，可能是一百万 token，甚至更大，但它依然有上限。你如果往里面硬塞太多东西，模型的表现还是会下降，因为那些被埋在中间的信息会慢慢失焦。

所以每个 agent 都有工作记忆，但每个聊天机器人其实也有。因为本质上它就是上下文窗口。

那问题就来了：agent 系统还需要什么别的东西？

第二类，是语义记忆。

这就是 agent 的知识库。语义记忆存的是事实、规则、约定和文档。

在学术文献里，这一层经常会被描述成向量数据库或者知识图谱。没错，这些实现当然都存在。

但在今天很多真正跑在生产里的 agent 系统里，语义记忆往往比这简单得多。

它可能就只是 Markdown 文件，也就是 .md 文件。

拿 Claude Code 举例。它有一个这样的 Markdown 文件，叫 Claude.md，放在项目根目录。

这个文件里会写项目架构、编码约定、构建命令、该用什么框架，以及不要做什么。

而且这个文件会在每次 session 一开始就被加载进上下文窗口。

所以语义记忆负责告诉 agent：在一般情况下，它需要知道什么。

如果没有这一层，agent 基本注定会一错再错，因为它没有任何持久知识可调用。

有了工作记忆、语义记忆，还有什么？

第三类，是程序记忆。

程序记忆负责的是：agent 知道怎么做事。

这一层现在其实已经有一个开放标准，叫 agent skills，用的文件格式叫 skill.md。

一个 skill 本质上就是一个文件夹，里面有一个 Markdown 文件，描述这个技能是什么、能做什么，以及执行这个技能时的一步一步说明。

它可以是任何事：从生成一份 PowerPoint，到执行一套结构化代码审查流程。

Skill 还有一个很关键的机制，叫渐进式披露（progressive disclosure）。也就是说，agent 不会在一开始就把所有 skill 全都塞进上下文窗口，也就是工作记忆里。

因为如果可用 skill 很多，这样会直接把工作记忆预算打爆。

所以更常见的方式是：agent 先只看到一个很轻的索引，里面只有每个 skill 的名字和简介。

假设每个 skill 只占一百个 token 左右。

等到某个任务进来，恰好匹配到某个 skill 的描述，agent 才会去加载这份完整说明。如果这个 skill 还引用了别的文件、模板、脚本，这些东西也只会在执行时按需再拉进来。

所以 agent 的方式是：先知道自己有哪些 skill；需要时再把说明书调进来；执行过程中如果还需要别的资源，再继续按需加载。

这和语义记忆不一样。语义记忆里的知识，通常是一开始就常驻在上下文里的。

第四类，是情景记忆。

情景记忆记录的是：过去的交互里发生过什么、做过什么决策、又从中学到了什么。

最朴素的实现方式，就是把所有对话记录都存下来，然后需要时去搜。严格来说，这当然也算情景记忆。

但很多时候，它其实并不好用。

所以真正的生产系统通常会多做一步提炼。

也就是说，agent 在跨 session 工作时，会慢慢给自己积累笔记，但它不会把所有东西都存下来。

它会判断：哪些信息在未来的对话里真的还有价值，才值得留下。

最后留下来的，是提炼过、压缩过的经验。

比如说：上次我们排查 auth 模块时，问题其实出在 middleware 层。

这种信息就比完整保存一段 45 分钟的调试对话有用得多。

而这也是记忆开始真正像“学习”的地方。因为 agent 会随着时间推移越用越熟。

不过，情景记忆也是四类里最难设计的一层。

因为你总得回答几个麻烦问题：什么该删？信息什么时候算过时？如果用户换工作了，旧项目的记忆还要不要保留？还是应该忘掉？

人类其实很擅长遗忘。我自己就天天在忘。

虽然这有时候挺烦，但它其实也很有用。

可对 agent 来说，遗忘不是自然现象，而是一个工程问题。

所以，总结一下，agent 的四种记忆是：工作记忆、语义记忆、程序记忆、情景记忆。

但并不是每一种 agent 都一定需要四种全配。

举个例子。

如果你做的是一个很简单的反射式 agent，比如恒温器，或者一个非常基础的路由机器人，那它可能只需要工作记忆，也就是上下文窗口，这就差不多够了。

如果再复杂一点，比如一个客服 agent，但它仍然很窄，只做密码重置这种事情，那它当然还是需要工作记忆，同时大概率还需要程序记忆，因为它要调起“重置密码”这项 skill。

但可能也就到这里了。

可如果你做的是一个 coding agent，它大概率会四种都要。

它当然需要工作记忆，也就是上下文窗口；还需要从语义记忆里拿产品知识；需要程序记忆里的 skill 系统；还需要情景记忆里的自动记忆，来实现跨 session 的学习。

所以，真正把 chatbot 和 agent 区分开的，其实就是记忆。

聊天机器人只是给出一个回答。

而 agent 给出的回答，是被持久知识和累积经验塑形过的回答。

它记得项目，记得偏好。好的记忆架构还会记住那些犯过的错，这样我们才不会一次又一次重蹈覆辙。

说真的，如果当时有个 agent 能在第三个小时之前提醒我 Kubernetes 那个集群连错了，我会很感激它。

这就是 AI agent 的四种记忆。

你在自己的 agent 工作流里，已经用上了哪几种？

谢谢。