如果前七课一路学下来到这里已经有了一个相当完整的 Agent。它能看 Context。能让 LLM 做 Decision。能调用 Tool。能读取文件、搜索 Web、执行 Shell。能从 Environment 获得 Observation。还能通过 State 知道任务做到哪里。第七课结束以后我们已经把 Agent Loop 推到了这里State↓Build Context↓LLM↓Decision↓Action↓Runtime↓Environment↓Observation↓Update State↓New State到这个阶段Agent 已经不像一个普通 Chatbot 了。它可以处理一个持续几十步的任务而且不会每走一步都重新猜“我刚才做到哪里了”因为 State 已经替它维护了当前任务现场。比如处理 20 份报告已完成 12 份失败 2 份当前正在处理 report_15.pdf剩余 6 份status running这就是第七课解决的问题Where am I now?当前任务进行到哪里原课程也正是这样定义 State它回答的是当前任务的进展而当任务结束后“过去有哪些东西值得跨任务留下来”就成为下一个问题。问题是——任务结束以后呢一个 Agent 真正开始“长大”往往是从第二次见到你开始想象一个很普通的场景。星期一你对 Agent 说“帮我分析这份销售 Excel。最终报告用英文异常数据单独放一个 Sheet。”Agent 做完了。State 最后变成status completed程序关闭。到这里一切正常。星期五你又上传了一份 Excel只说“跟上次一样处理。”这时候问题来了。Agent 应该知道什么叫“跟上次一样”它至少要知道两件事最终报告用英文异常数据单独放一个 Sheet可这两个信息已经不是星期一那个任务的 State 了。星期一的任务已经结束。当前任务甚至已经变成另一份文件。那么这些信息到底应该放在哪里这就是 Memory 出现的原因。我认为理解 Agent Memory 最重要的一刻不是第一次看到 Vector Database也不是第一次写 Embedding。而是突然意识到State 解决的是“现在做到哪里”Memory 解决的是“过去有什么值得带到未来”。这两个东西看起来都叫“记住”但在系统里承担的是完全不同的职责。一、先把一个最大的误解打掉保存聊天记录不等于有 Memory很多所谓“带长期记忆的 Agent”最初版本其实只是把 conversation history 保存下来。下次启动时再读回来。这当然有价值。但如果把这件事情直接叫作完整的 Memory很容易从一开始就把概念学偏。假设用户和 Agent 聊了三个月。数据库里有 12,000 条消息。里面记录着“你好。”“打开 sales.xlsx。”“文件读取成功。”“刚才那个格式不错。”“继续。”“搜索一下退款政策。”“Tool timeout。”“再试一次。”“成功了。”“下次报告还是英文吧。”……这些东西是什么首先是History。也就是过去发生过什么。问题是三个月以后当用户再次让 Agent 做报告时你真的准备把这 12,000 条消息全部塞回 Context 吗当然不应该。真正值得留下来的可能只有一句用户偏好管理报告默认使用英文。这里发生了一个关键变化原始 History“下次报告还是英文吧。”经过理解和筛选以后变成Memory“用户偏好管理报告默认使用英文。”所以真正的 Memory 不是录像。更像是从录像里提炼出来、未来仍然值得使用的信息。这是第八课第一个要吃透的地方History ≠ Memory。History 强调过去发生过什么。Memory 强调过去发生的这些东西里面什么值得未来继续保留和使用。二、一个办公室就能把 Context、State、History、Memory、Skill 全部分清如果这些词一直混在一起可以想象一个项目经理的办公室。桌面上放着今天正在看的客户要求、当前文件、刚刚查询到的数据。这是Context。因为这是你现在工作时真正摆在眼前的信息。墙上白板写着“20 份报告已完成 12 份目前正在做第 13 份。”这是State。因为它描述的是任务现在进行到哪里。办公室的监控录像记录着早上 9 点打开 Excel。9 点 10 分清洗数据。9 点 30 分程序失败。9 点 35 分重试。9 点 40 分成功。这是History。因为它记录的是过去发生过什么。档案柜里面写着“这个客户习惯英文报告。”“这个客户的财年从 4 月开始。”“这个项目以前遇到过某类特殊数据格式。”这是Memory。因为这些是过去留下来、以后还可能使用的信息。旁边还有一本 SOP“处理销售 Excel 时先检查日期格式再去重再计算 GM%最后输出异常行。”这是Skill。因为它不是在告诉你“以前发生过什么”。而是在告诉你遇到这类事情应该怎么做。原课程其实已经给出了同样的核心边界Context 是当前模型能看到什么Memory 是过去积累的信息而 Skill 更接近“面对某类问题时已经总结出的可复用解决方法”。现在可以把五个概念压缩成五句话Context这一轮模型看到了什么。State当前任务现在是什么情况。History一路上发生过什么。Memory过去有什么值得未来继续使用。Skill以后遇到这类问题应该怎么做。如果这五句话真的分清第八课已经理解了一半。三、最关键的分界Memory 里有不代表 LLM 现在知道这是很多人在理解 Memory 时真正卡住的地方。假设一个 Agent 已经积累了 50,000 条 Memory。里面有用户喜欢英文报告。客户 A 财年从 4 月开始。客户 B 使用 USD。Project Alpha 使用 PostgreSQL。某个 PDF 上次解析失败。某个网站需要特殊登录方式。某次 ERP 调用出现 Timeout。某位客户要求最终输出 PDF。……那么问题来了LLM 每次调用的时候都要看到这 50,000 条吗当然不是。这会直接把 Context 搞废。所以一定要把两个概念分开Memory Store 里有什么和这一轮模型看到什么不是一回事。假设用户现在说“分析一下 sales.xlsx。”Runtime 根据当前任务去 Memory Store 查询。最后只找出来两条“管理报告默认使用英文。”“异常数据单独放一个 Sheet。”然后 Context Builder 把这两条放进本轮 Context。这时候 LLM 才真正“知道”它们。完整过程是Memory Store↓Retrieval↓Relevant Memory↓Context Builder↓Context↓LLM所以以后听到一句“Agent 记得用户以前说过什么。”不要把它理解成模型脑子深处神秘地保存着一段东西。从 Agent Runtime 的角度看更常见的工程解释是系统以前把信息保存了下来。到了新任务Runtime 找到相关 Memory。再把它重新放进 Context。最后 LLM 才看见。这么一拆Memory 就不神秘了。四、Context 和 Memory 的关系很像工作台和档案室沿着这个类比继续看。一个大型公司可能有几十年的档案。但一个员工今天处理订单的时候不会把几十年的文件全部铺在桌上。档案室负责东西长期存在。工作台负责现在需要什么。Agent 也是如此。Memory 的价值不是“存得越多越好。”而是需要的时候能取出正确的那几条。所以一个 Memory System 的质量不能只看“它保存了多少信息。”更应该看它能不能在正确的时间想起正确的东西。关键就在这里。因为 Memory System 最常见的失败不一定是“没记住。”还有另一种什么都记住了而且什么都往 Context 里塞。后者有时候更糟。五、真正的 Memory System其实有两道门理解这一点之后Memory 的工程结构会一下清楚很多。它至少有两道非常重要的门。第一道Write Gate。决定什么值得记第二道Retrieval Gate。决定现在应该想起什么这两道门任何一道设计差了Memory 都会失控。Write Gate不是发生过的事情都值得记用户说“今天上海下雨。”要不要存成长期 Memory大多数情况下没有必要。用户说“以后月度管理报告都使用英文。”这就很可能值得保存。用户说“打开 report_07.pdf。”没有必要永久保存。用户说“这个客户的财年从每年 4 月开始。”这可能会影响未来大量任务。所以写入 Memory 前可以先问四个问题这个信息未来还可能用到吗“最终报告默认英文。”很可能会。“刚刚第 3 次 Tool Call 花了 2.1 秒。”通常不值得长期保存。它稳定吗“用户今天想要 PDF。”可能只是当前任务要求。“用户以后所有月报都要 PDF。”语义完全不同。它跨任务有价值吗“当前正在处理 report_08.pdf。”没有。这是 State。“这个客户每次都要求金额使用 USD。”可能有。它可靠吗这一点不能省。如果用户明确说“以后报告都用英文。”这是强来源。但如果 LLM 自己推测“用户好像比较喜欢英文。”这能不能直接写成永久 Memory危险。因为模型的推测一旦进入长期 Memory问题就不再只是一次普通的 Hallucination。它可能变成Persistent Hallucination。持久化幻觉。六、为什么 Memory 里的错误比普通回答里的错误更危险假设 LLM 某一轮错误判断“客户使用 USD。”如果这个错误只存在于当前回答里任务结束以后可能就过去了。但是 Memory Writer 把它保存成“客户默认结算货币USD。”一个月以后新任务来了。Memory Retrieval 搜出来“客户默认结算货币USD。”模型相信 Memory。于是又按 USD 处理。下个月还是一样。一个瞬时错误被系统变成了一个长期事实。所以成熟的 Memory 不能只有content最好还知道这条 Memory 是什么类型来自哪里是谁说的针对哪个用户、客户或项目什么时候创建是否仍然有效可信程度如何有没有被后来的信息覆盖背后的核心概念叫Provenance。也就是一条记忆必须知道自己是从哪里来的。比如“用户明确说过。”和“模型根据行为推测。”这两种信息的可信等级根本不应该一样。七、Memory 不是一条字符串而是一条有生命周期的信息刚开始写 Demo可以很简单memory 用户喜欢英文报告但稍微进入真实系统你马上会发现不够。更合理的 Memory 可能长成memory { type: user_preference, content: 管理报告默认使用英文, scope: user, source: explicit_user_statement, confidence: 1.0, status: active, }为什么需要这些字段因为人会改变。用户今天说“以后全部使用英文。”三个月以后又说“之后都改成中文。”如果 Memory System 只是不断 append“喜欢英文。”“喜欢中文。”然后下一次两条一起 Retrieve 给 LLM那不叫记忆。那叫制造冲突。正确做法应该是新信息进来↓识别它和旧 Memory 的关系↓更新 / 替代 / 失效旧 Memory所以真正的 Memory System 必须考虑CreateUpdateInvalidate甚至Forget记忆不仅要会写。还得会改。还得会忘。八、这时我们终于可以给 Memory 一个更完整的定义如果只说“Memory 就是过去的信息。”还是太宽。我更推荐把 Agent Memory 理解成Memory 是 Runtime 对跨任务仍有潜在价值的信息进行选择、持久化、检索、更新和再利用的一套机制。注意里面有五个动作选择。不是全部保存。持久化。任务结束以后它还在。检索。未来能够找回来。更新。现实变化以后不会永远停留在旧版本。再利用。真正进入新的 Decision。所以Memory ≠ Database。Database 主要解决“放在哪里。”Memory System 解决的是“什么值得放、什么时候拿、拿什么、怎么使用、什么时候改掉。”九、原课程里的四种 Memory到底应该怎么理解原课程把 Memory 划分为Semantic MemoryEpisodic MemoryUser MemoryConversation Memory。这几个词如果只是背定义很快就忘。我们直接看它们各自在回答什么问题。Semantic Memory我知道什么Semantic Memory 更接近事实和知识。比如“客户 A 的财年从 4 月开始。”“Project Alpha 使用 PostgreSQL。”“某套内部系统的订单状态字段叫 order_status。”它描述的不是“某次发生了一件什么事情。”而是系统目前认为某个事实是什么。所以可以把 Semantic Memory 理解成Knowledge。Episodic Memory我经历过什么假设一个 Coding Agent 遇到dependency installation failed第一次它升级 pip。失败。换镜像。还是失败。最后发现Python 版本不兼容。换版本以后成功。如果这次经历被保存下来“上次在 Project Alpha 遇到同类 dependency error最终原因是 Python 版本不兼容。”这就是Episodic Memory。因为它记录的是一次经历。所以两者的区别可以这样记Semantic我知道什么。Episodic我经历过什么。一个偏 Knowledge。一个偏 Experience。十、为什么 Episodic Memory 对 Agent 特别有意思因为 Agent 真正想越来越好不只是积累事实。还应该积累“以前做过什么结果怎么样。”例如一个 Research Agent 以前经历过来源 A 经常返回摘要页。来源 B 能拿到完整 PDF。某类论文搜索词效果不好。换另一组 Query 后召回明显更好。这些东西不一定是稳定的世界知识。但它们属于过去执行任务留下来的经验。以后遇到类似任务时如果这些经验能被找回来Agent 就不一定每次都从零开始试错。这就开始出现真正有意思的东西Experience Reuse。十一、User Memory为什么它是最容易产生“这个 Agent 真的记得我”的地方用户 Memory 很直观。例如“用户偏好简洁回答。”“最终报告默认英文。”“异常数据单独输出一个 Sheet。”“汇报时先给 Executive Summary。”它们有一个共同特点当前任务结束以后它们仍然可能影响未来任务。所以它们显然不是State。假设今天的 State 是“report_07 正在生成。”这个任务完成以后这条 State 就失去了运行价值。但是“最终报告使用英文。”明天、下周、下个月仍然可能有用。这就是 Memory 的典型跨任务属性。十二、Conversation Memory 又是什么它绝对不是把聊天全部保存下来这么简单这是另一个特别容易混淆的地方。Conversation History 可能是用户方案 A 怎么样Assistant……用户太贵了。Assistant可以考虑方案 B。用户方案 B 可以就按这个方向。这些原始消息属于History。但一个月以后未来任务真正需要的也许只是“之前已经确定采用方案 B方案 A 因成本过高被否决。”这才更像Conversation Memory。也就是说History 是原始事件流。Conversation Memory 更接近从过去对话中压缩、提取出的可复用信息。所以长期对话 Agent 很重要的一件事并不是“无限延长 Context Window。”而是知道哪些过去对话应该被压缩成 Memory。十三、到这里你应该能看懂一个完整的 Memory Write 流程用户说“以后所有销售分析报告都用英文异常数据单独一个 Sheet。”首先这句话进入当前Context。因为模型现在看得到。然后任务正常执行。与此同时Memory Writer 可以判断“以后所有……”这是一个明显的跨任务偏好。于是生成两个候选 Memory“销售分析报告默认使用英文。”“异常数据单独输出 Sheet。”然后检查是否已经存在类似 Memory有没有冲突来源是否可靠最终决定Write。于是User Message↓Memory Candidate↓Write Policy↓Normalize↓Deduplicate / Resolve Conflict↓Memory Store注意这整个过程和 Agent 当前任务 State 是两条不同的线。State 负责“Excel 分析做到哪里。”Memory 负责“这里面有没有东西值得未来继续使用。”十四、接下来是另一半Retrieve写进去只是第一步。真正难的是什么时候应该想起来假设 Memory Store 已经有 100,000 条记录。用户现在说“分析 sales.xlsx。”系统应该检索哪些 Memory当然不会是“去年某个 Coding Agent 的 Python 环境出过问题。”也不应该是“某个完全无关客户的退款周期是 30 天。”真正相关的可能是“当前用户的报告默认英文。”“销售分析异常数据单独 Sheet。”“这个客户财年从 4 月开始。”所以 Retrieval 的本质是从过去大量信息中找出对当前 Decision 真正有帮助的少量信息。这比“存下来”困难得多。十五、为什么一条“正确的 Memory”也可能不应该被 Retrieve这一点非常值得理解。假设 Memory 中有“用户做 Excel 分析时喜欢异常项单独 Sheet。”这条 Memory 完全正确。但用户现在问“帮我解释一下 Python decorator。”这时候要不要 Retrieve 那条 Excel Memory没有必要。所以 Memory 系统会出现一个很有意思的判断某条 Memory 可以同时满足True但Irrelevant。它是真的。但现在没用。如果 Memory Retrieval 不做相关性控制最后会变成Memory Store 越大↓每次 Retrieve 越多↓Context 越脏↓模型越难判断当前任务重点这就是Context Pollution。所以好的 Memory System 追求的不是Remember Everything。而是Remember the Right Things, Recall Them at the Right Time。十六、Memory Retrieval 可以怎么做最简单的方式是 Keyword。当前任务有sales report那么找包含sales、report、Excel之类关键词的 Memory。再进一步可以做 Metadata Filter。例如先限定user_idcustomer_idproject_idtask_type只查当前范围里的 Memory。再进一步可以使用 Semantic Retrieval。根据语义相似性寻找相关记录。真实系统也可能把几种方式组合Metadata FilterKeyword SearchSemantic SearchReranking但这里千万别把注意力全部放到算法上。第八课最值得学的是第一性原理Retrieval 的目的不是“搜到最多”而是“找出当前 Decision 最值得看到的过去信息”。十七、所以 Vector Database 根本不等于 Memory这是 Agent 领域非常常见的概念偷换。有人说“我的 Agent 有 Memory。”你问“怎么做的”他说“用了 Vector DB。”这两个东西不是同一个层级。Vector Database 可以帮助完成Retrieval。特别是语义相似搜索。但它不会自动回答这句话到底值不值得记这条信息是不是已经过期这两条 Memory 是否冲突用户改变偏好以后旧记录怎么办这个 Memory 应该属于 user、project 还是 organization什么时候应该删除什么时候不应该 Retrieve这些全部仍然属于Memory System。所以Vector DB 是可能实现 Memory 的一个基础设施组件。而不是Memory 本身。就像PostgreSQL不等于ERP。数据库只是底层能力。业务语义还在上面。十八、现在再把 Memory 和 Persistence 分开一次第七课已经讲过State 和 Persistence 不是一回事。例如completed 67 remaining 33这是 State。把这个 State 存进 SQLite这是 Persistence。到了第八课同样成立。不要因为某个信息“跨了两天还在数据库里”就自动叫 Memory。假设一个任务做了一半。Statecurrent_file report_068.pdf今天程序 Crash。明天从数据库恢复这个 State。它仍然是State。因为它回答的依旧是“这个任务现在做到哪里”而“用户喜欢英文管理报告”才更接近 Memory。为什么因为它回答的是“过去沉淀了什么未来其他任务还可能使用”所以一个非常重要的判断标准不是保存多久。而是这个信息在系统里承担什么语义角色。十九、State 到底什么时候会变成 Memory这个问题值得单独想一层。假设任务执行过程中有state[retry_count] 3任务结束以后这个字段还有必要作为 Memory 吗通常没有。但是如果整个任务最终发现“这个客户上传的扫描 PDF默认 Parser 连续失败三次换 OCR Pipeline 后成功。”这段经历可能值得留下。所以不是State 整体搬进 Memory。而更像Task StateHistoryResult↓Memory Extraction↓挑出未来可能有价值的部分↓Memory这一步不能省。也就是说任务结束并不是把 State 永久保存就叫 Memory。而是需要进行一次Knowledge / Experience Extraction。二十、Memory 甚至应该有“遗忘”很多人做 Memory 的直觉是既然叫记忆那当然越多越好。真实情况恰恰可能相反。假设一个 Agent 使用五年。每天产生几百条 Memory。最后会发生什么大量信息已经过时。互相重复。价值很低。甚至互相矛盾。例如2024“项目使用 Python 3.10。”2025“项目升级到 Python 3.12。”2026“项目迁移到另一个 Runtime。”如果全部无脑 Retrieve模型看到的不是 Memory。而是历史垃圾场。所以成熟 Memory System 必须考虑Forgetting。遗忘不一定意味着物理删除。也可以是标记旧版本。降低权重。Archive。设置有效期。被新事实覆盖。不再进入默认 Retrieval。所以忘记不是 Memory System 的失败。很多时候正确地忘记本身就是智能的一部分。二十一、现在来看一个 Memory 冲突假设系统里已经有“管理报告默认使用英文。”今天用户说“以后管理报告全部改成中文。”如果 Memory Writer 只是append()现在就有Memory 1英文Memory 2中文下一次 Retrieval两条都出来。LLM这就是为什么 Memory Update 很重要。系统应该识别新 Memory 和旧 Memory 不是两个并列事实。它们存在Supersede Relationship。新信息覆盖旧信息。于是旧 Memory 可以status superseded新 Memorystatus active这样下次默认 Retrieval 只返回最新有效版本。到这里它才开始像一个完整的软件系统。二十二、还有一个更难的问题Memory Scope假设 Agent 记住“报告使用英文。”这是谁的偏好某一个用户某一个客户某一个项目整个公司这几种语义完全不同。比如用户 A“我喜欢中文报告。”客户 X“所有交付必须使用英文。”这两条都可能是真的。如果没有 Scope下一次处理客户 X 的任务时系统应该听谁所以 Memory 往往需要作用范围User ScopeProject ScopeCustomer ScopeOrganization ScopeTask-Type Scope不同 Scope 的 Memory 可能同时存在。Runtime 最终需要根据当前任务决定哪些能够应用。这也是为什么Memory 不能只是“一堆字符串 Vector Search。”真正难的是语义治理。二十三、Memory 和 Skill 的区别到了这里应该彻底清楚原课程用了一个很好的例子。Memory“上一次 Excel 的日期列是 C 列。”Skill“处理销售 Excel检查日期列Normalize Date去 Duplicate计算 GM%输出异常行。”它们之间最大的区别不是一个长一个短。而是Memory 在说我知道 / 经历过什么。Skill 在说我已经知道这类事情该怎么做。再举一个例子。Memory“上次处理某类扫描 PDF 时Parser A 失败Parser B 成功。”这是一次经历。但是如果 Agent 后来不断发现扫描 PDF 用 Parser B 的成功率更高最后总结出“检测到扫描型 PDF 时优先使用 Parser B失败再进入 OCR。”这就开始从Episodic Memory向Skill转变。这条演化路径很清楚Experience↓Repeated Pattern↓Generalization↓Reusable Procedure↓Skill所以后面课程里的MemorySkillsLearning Loop实际上不是三个完全孤立的专题。它们是一条成长链。二十四、一个 Agent 怎样真正“从经验中成长”假设第一天Agent 遇到错误 X。尝试 A。失败。尝试 B。成功。它可以保存一条 Episodic Memory“在环境 Y 中遇到 X 时B 曾经成功。”第二次又遇到类似 X。Retrieve 到过去经验。优先尝试 B。成功。第三次再次成功。这时候系统可能发现这个规律已经不只是一次经历。它开始具有可泛化性。于是可以进一步整理成Skill“遇到 X 环境 Y 时优先执行 B。”这里发生的是过去一次一次的经历↓逐渐形成稳定方法这才是所谓Learning Loop真正值得研究的部分。它不是神秘地“模型自己越来越聪明。”而是 Runtime 开始把Experience转化成Reusable Knowledge / Procedure。二十五、我们现在可以把第八课真正的 Agent Loop 补完整了第七课只有当前任务State↓Build Context↓LLM到了第八课Context Builder 的输入已经发生变化。它不再只有 State。现在可能是User RequestCurrent StateRetrieved MemoryRelevant HistoryTool Definitions↓Context Builder↓Context↓LLM其中 Memory 有自己独立的一条生命周期Past Interaction / Experience↓Memory Candidate↓Write Gate↓Memory Store新任务Current Task↓Retrieval Gate↓Relevant Memory↓Context Builder↓LLM任务过程中又产生新信息↓Memory Candidate↓Write / Update / Ignore↓Memory Store这就是一个完整的Memory Loop。二十六、现在写08_memory.py你真正应该实现什么这一课如果最后只是接一个 Vector Database我认为教学价值反而很低。最好的实验应该保持简单。先不用复杂框架。甚至第一版不用 Embedding。我们只实现四件事remember()retrieve()update()build_context()先定义 Memory Storememories []写入def remember(memory): memories.append(memory)例如remember({ type: user_preference, content: 管理报告默认使用英文, scope: user, })然后做一个极简 Retrievaldef retrieve(task): results [] for memory in memories: if memory_is_relevant( memory, task, ): results.append(memory) return results新任务开始task { goal: 分析 sales.xlsx }Runtimerelevant_memories retrieve(task)然后context build_context( statestate, memoriesrelevant_memories, )最后decision llm(context)这一版可能很笨。但它已经把 Memory 最核心的机制完整暴露出来了存。找。放回 Context。以后换成SQLitePostgreSQLVector DBHybrid SearchReranker都只是不断替换具体实现。第一性原理没有变。二十七、再给08_memory.py加一道最重要的门should_remember()不要让 Agent 什么都存。def should_remember(candidate): if not candidate[future_value]: return False if not candidate[reliable]: return False if candidate[task_local_only]: return False return True真实系统当然不会这么简单。但这个函数不能省。因为它在提醒我们Memory Write 本身就是一个 Decision。不是发生了什么↓全部保存而是发生了什么↓这件事未来值得留下吗↓值得↓Memory这一步就是Memory Selection。二十八、然后再加一个 update_memory()假设旧 Memory“管理报告默认英文。”新信息“以后改成中文。”Runtime 不应该简单追加。可以def update_memory(old, new): old[status] superseded new[status] active memories.append(new)这时候 Memory System 就开始拥有时间。它不再认为所有过去信息永远同时为真。而开始理解事实可能变化。偏好可能变化。项目可能变化。现实可能覆盖旧认知。对 Production Agent 来说这一点直接关系到系统是否可靠。二十九、以后 Debug Memory Agent不要只看“模型为什么没记住”从第八课开始Debug 应该 Trace 一条新的链。第七课我们已经会看State Before↓Context↓Decision↓Action↓Observation↓State After现在 Memory 再增加Memory Store Before↓Retrieval Query↓Retrieved Memories↓Context Built↓LLM Decision↓Memory Candidates↓Write / Update Decision↓Memory Store After以后 Agent 说“我怎么不知道你喜欢英文报告”不要立刻怪 LLM。先查那条 Memory 当时写进去了吗写到了哪个 Scope后来有没有被覆盖当前 Retrieval Query 是什么有没有 Retrieve 出来Retrieve 出来以后有没有进入 Context模型真正看到的是什么很多“Agent 失忆”问题最后根本不是模型问题。可能只是Memory Write Bug。或者Retrieval Bug。甚至Context Builder Bug。这和第七课的 State Bug 是完全一样的工程思路。三十、Memory 设计真正厉害的人会反过来警惕“记得太多”做到这里你会慢慢产生一个反直觉判断。一个好的 Agent不应该追求“什么都记得。”而应该追求知道什么值得记。知道什么时候该想起来。知道什么时候旧记忆已经不能用了。知道什么时候应该忘掉。这和人其实非常像。如果你脑子里过去二十年发生的每个细节在每次思考时同时跳出来那不是超强记忆。那会让正常思考变得困难。Agent 也是一样。Memory 最终服务的目标不是Storage。而是Decision Quality。如果某条 Memory 进入 Context 以后反而让 Decision 变差那么即使它完全正确也可能不应该在这一轮出现。这是理解 Agent Memory 非常重要的一层。三十一、到这里再回答一次Context ≠ Memory 到底是什么意思到这里这个问题已经很清楚。Memory系统过去留下了什么。Context模型这一轮实际看到了什么。所以Memory 里面存在一个事实不等于LLM 当前知道这个事实。只有经过Retrieval↓Selection↓Context Injection模型才真正“想起来”。换句话说Memory 是潜在可用的信息。Context 是当前正在使用的信息。这是整个第八课最值得记住的区别。三十二、最后把 Agent 的“现在”和“过去”放在同一张脑图里第七课解决的是现在。Environment现实世界是什么。Observation刚刚看到了什么。State吸收这些 Observation 后当前任务是什么情况。Context这一轮把哪些信息给模型看。LLM下一步怎么做。第八课增加的是过去。History以前发生过什么。Memory Candidate其中什么可能值得留下。Memory Store哪些东西真正跨任务保存。Retrieval现在应该想起哪些。Relevant Memory从过去找回的相关信息。然后重新进入Context。于是整个 Agent 的信息流开始变成过去 → Memory → Retrieval ↘Context → LLM → Action → EnvironmentObservation → State ↗你会发现State 和 Memory 最终都会进入 Context。但是它们来自完全不同的地方。State 代表当前任务现实。Memory 代表过去积累、现在可能有用的信息。Context Builder 把两边的信息组合起来再交给 LLM 做当前 Decision。到这里一个真正有连续性的 Agent 才逐渐出现。三十三、第八课真正应该带走的不是 Vector DB如果学完这一课只记住“Agent Memory 可以用 Vector Database。”那其实没有真正学懂。真正应该带走的是下面这些判断。Memory 不是 History。History 保存过去发生了什么。Memory 保存过去有什么值得未来复用。Memory 不是 Context。Memory 是潜在可以取回的信息。Context 是这一轮模型真正看到的信息。Memory 不是 State。State 描述当前任务现在在哪里。Memory 跨任务保存过去的知识、经验和偏好。Memory 不是 Persistence。Persistence 解决“东西怎么活下来”。Memory 解决“什么东西值得跨任务留下来以及未来怎么再利用”。Memory 不是 Vector Database。Vector DB 只是 Retrieval 的一种基础设施。Memory 也不是 Skill。Memory 是知道什么、经历过什么。Skill 是以后遇到这种事情怎么做。更重要的是好的 Memory 不是记得越多越好。而是该记的记住该想起来的时候想起来过期的会更新不该干扰当前任务的就别出现。结语Agent 真正的“成长”不是 Context 越来越长很多人第一次做长期 Agent会产生一个非常自然的想法只要把过去所有 Conversation 都留着Agent 就会越来越懂用户。但继续做下去一定会撞墙。History 越来越长。Context 越来越贵。旧信息越来越多。冲突越来越严重。错误也可能被不断带进未来。真正成熟的方向不是无限延长过去。而是从过去中提炼价值。今天发生了一千件事。也许只留下两条 Memory。一周后面对新任务。也许 10,000 条 Memory 里面只 Retrieve 三条。但是恰好就是这三条让 Agent 不必重新问用户“报告想用什么语言”“异常项怎么处理”“这个客户的财年怎么算”这一刻人会自然产生一种感觉它记得。但现在你已经知道这背后根本不是魔法。它其实是一条非常清楚的软件链路过去发生事情↓提取候选信息↓判断值不值得记↓保存↓新的任务出现↓寻找相关记忆↓筛选↓放进 Context↓帮助当前 Decision↓必要时更新或遗忘这就是 Agent Memory。第七课让 Agent 拥有了现在。第八课开始让 Agent 拥有过去。而后面真正有意思的问题会变成如果 Agent 不只是记得过去还能从反复出现的成功经验中总结“以后遇到这种事情我应该这样做。”那么过去的 Memory就开始向另一种东西进化Skill。而当 Memory、Skill、Reflection、Learning Loop 连起来以后Agent 才真正开始从一个“每次重新开始的软件”走向一个可以积累经验的软件系统。