这门 LangGraph 课讲清了 Agent 为何记不住纠正

LangChain 联合创始人兼 CEO Harrison Chase 用 1 小时 24 分钟，带学员做一个很普通的练习：先搭一个邮件助手，再逐一给它加上三类记忆。对前线部署工程师（FDE）来说，最大的价值不在这个库，而在三分法本身。Agent 重复犯错时，它能帮你看清该在哪里修。

Long-Term Agentic Memory with LangGraph 是 DeepLearning.AI 上的一门中级短课，与 LangChain 合作制作。

设想部署的第三周：客户第三次纠正 Agent 的同一个错误，问它为什么记不住。这门课能帮你准确说出问题所在，还给出现成的实现模式来回应，而不是在提示词里再打一行补丁。

一个邮件助手，三次升级

贯穿课程的项目是一个邮件助手。课程按顺序展开：先做基线，再加语义记忆，然后是情景记忆，最后是程序性记忆。

每一课都建立在上一课之上，所以你能看到每类记忆挂在同一个 Agent 的哪个位置，而不是孤立地学三个概念。入门门槛也不高：熟悉 Python，对提示词和 LLM 应用开发有基本了解即可。

反复出现的错误：Agent 缺的是哪类记忆？

课程不教错误诊断，但它的三分法非常适合拿来诊断。LangMem 概念指南里的定义足以作为起点。

语义记忆存储支撑 Agent 回答的事实，课程举的例子是日程 Agent 要记住的重要生日。情景记忆把成功的交互保留下来，作为后续交互的示例。程序性记忆规定 Agent 应当如何行事和回应。

有这三条定义，就能把一句笼统的抱怨拆成三种不同的修法。举一个假设的例子，某物流公司的客服邮箱：

类型	客户的抱怨	应当存什么
语义	“它给这个客户报的处理时效承诺还是错的”	每个客户的合同时效承诺
情景	“上次这类邮件它处理得对，这次怎么分错了？”	那封邮件及其正确分类
程序性	“我们早就告诉过它，退款必须转给审批人”	写进 Agent 指令里的审批人转交规则

所以在客户现场，第一件事不是挑存储工具。先收集用户纠正 Agent 的记录，按上表逐条标注，再从出现最多的那一类入手。

少样本示例和系统提示词也是记忆

课程中，情景记忆是分类环节的少样本（few-shot）示例，程序性记忆是根据反馈不断改进的系统提示词。技术上，这两样你大多已经会了；区别在于，它们是从 Agent 的经历中逐步积累起来的。

Chase 在一篇关于 Agent 记忆的博客文章中也写道，情景记忆在实践中通过少样本示例实现，有些 Agent 还会更新自己的系统提示词。

但 Agent 的行为一旦随反馈而变，就需要一把固定的尺子。假设在 100 封已标注邮件上，基线分错 15 封。调整提示词后，分错的邮件中有 6 封改对了，原本分对的却有 4 封出错。

两个方向都算上，分错的是 13 封，只减少了 2 封，而客户可能只看到新修好的 6 例。那 4 例弄坏的，没人评测的话，会以新投诉的形式回来。

在客户那里启用任何优化机制之前，先备好这套测试集，并保存提示词的每个版本，以便回滚。

适合谁学，按什么顺序学

这门课最适合已经做出可用 Agent、或即将把 Agent 交付客户的工程师。如果从未写过 LLM 应用，先补基础，因为课程默认你已经掌握。

合理的顺序是按课程编排逐课学习，不要直接跳到程序性记忆部分。之后读 LangMem 概念指南，对照它对每类记忆的定义，再用邮件以外的数据重做一遍练习。课程页面显示更新于 2026 年 7 月 17 日，所以要对照该库的最新文档检查自己的代码。

一个人的记忆，该不该扩散到整个团队？

记住这个练习的局限：它只围绕一个邮件助手。在企业里，你还得厘清记忆归谁所有、某位员工的偏好是否该扩散给同事、谁可以查看和删除。

LangGraph 文档描述了一种可以拿来讨论这些问题的结构：每条记忆放在一个自定义命名空间里，类似文件夹，并有自己的键，类似文件名。

上线之前，和客户一起按员工、按团队画出命名空间，因为画图本身会逼双方回答上面这些问题。

写进简历的是错误数，不是课程名

把这个项目写进简历时，不要只写课程名。写清你加了哪类记忆、在多少样本上评测、错误数如何变化。

职位描述提到 Agent 时，可以问面试官他们怎么处理长期记忆。答案往往能看出他们的产品是在客户那里长期运行过，还是停留在演示阶段。

客户不会问你的 Agent 用哪个记忆库。他们只关心一件事：上周修好的错误有没有再出现。