在设计AI Agent时，记忆功能是核心需求，但不少开发者存在的常见误区是搞错了方向。有的Agent记不住用户随口提过的需求，有些却被赋予了远超实际需要的复杂记忆结构。这两种问题的根源，往往都指向同一个悬而未决的设计问题：不同类型的信息，到底应该存活多久，又该以什么方式来检索？

Agent的记忆策略，理应像它的编排（Orchestration）逻辑一样，被审慎设计。不同的是，记忆很少是一个单一的技术选型。当前的对话内容、用户的长期偏好、过往的交互记录、以及逐渐固化的行为模式，这些本质上都是不同类型的信息，每一样都需要匹配不同的记忆层。因此，一个更有价值的问题不是“Agent该用哪种记忆系统”，而是“每一类信息，究竟适合放在哪一层”。

这篇文章会覆盖这几个关键点：

• 区分工作记忆、语义记忆、情景记忆和程序记忆这四个核心概念
• 一个由五个问题构成的决策树，用来精准归类特定信息的需求
• 如何将分类结果组合成实际可用的分层记忆架构
• 记忆系统上线后常见的陷阱与修正方法

在深入决策树之前，我们先搞清楚一件事：为什么这个分类本身这么重要？

为何选对AI Agent的记忆策略如此关键？

让我们先明确一下，每个记忆层对于被分配的信息，到底做出了哪些前提假设。

• 工作记忆的前提是：所有当前相关的信息都存在于活跃的对话和有限的Token预算中。它假设剪裁或总结较旧的对话轮次，不会默默丢掉Agent仍然需要的关键信息。
• 语义记忆假设某些信息是足够稳定且可复用的，将其存储为典型表示，比每次都要重新推理、询问或处理要划算得多。它包括用户的持久性信息（如姓名、角色、偏好语言）、领域知识（如业务规则、产品规格），以及从重复交互中提炼出的通用知识。
• 情景记忆基于这样的预期：事件的历史本身就有价值，不仅仅是当前状态。它记录了过去的决策、投诉或交易，这些记录能为下一次交互提供参考。
• 程序记忆认为，反复解决同一类问题，应该让Agent的下一次尝试更快、更可靠，而不是仅仅留下一堆过往尝试的转录记录。

这四个层回答了关于信息的不同问题，这正是为什么大多数生产级Agent都需要不止一个记忆层。

举个客户支持Agent的例子：它可能用工作记忆处理当前工单，用语义记忆保存客户的订阅等级，用情景记忆记录历史投诉，并用程序记忆来固化一套处理退款的逻辑。每层各司其职。

当信息被放错层级时，问题就来了。把稳定的用户信息扔进向量数据库，只会让检索变慢且更不可靠；而漫无目的地搜索整个交互历史，可能会翻出过时或自相矛盾的信息，这些信息本可以被一个结构化的记录所覆盖。说到底，在上下文工程（Context Engineering）中，记忆只是为有限的上下文窗口争抢空间的众多信息来源之一。因此，只有当信息能显著改善Agent的回复质量时，才值得被检索出来。

接下来，就是这个决策树的核心：它通过五个分支问题，根据每一类信息的具体属性，逐层缩小它的需求范围。记住，要为一类信息运行一次完整的决策树，而不是为整个Agent只跑一次。一个支持Agent的“当前工单”、“账户详情”和“投诉历史”是三个独立的信息类别，它们各自会在决策树上找到不同的落脚点。

问题 1：这条信息需要跨越当前对话轮次持续存在吗？

这个问题用于区分，哪些信息真正需要记忆，哪些只是看起来需要。

• 自包含、无延续需求：比如一次性的分类请求措辞、仅用于回答当前问题的工具调用中间结果。
• 需要延续，必须借助记忆：比如支持Agent在本轮对话中已经解决了哪个问题、Agent要接续昨天的一个编程项目。

如果信息是自包含的 → 无需任何记忆层，当前的上下文窗口就够了。如果需要延续 → 进入问题2。

问题 2：它需要跨越单次会话存活吗？

这个问题用于区分工作记忆和需要持久化的信息。

• 仅限单次会话内：已经问过什么、调用过哪些工具、解决了哪些问题 → 一个会话缓冲区就够，通过剪裁或总结来维持边界。
• 需要跨会话：老客户的偏好、进行中的项目状态、跨多天的任务 → 工作记忆无法胜任，因为信息必须独立于任何一次单独的对话而存在。

如果仅需会话内连续性 → 工作记忆就是答案。如果需要跨会话存活 → 进入问题3。

⚠️ 一个常见的设计失误，就是把信息的生命周期弄错了：要么把会话级的状态当成了永久数据，要么为只需要在对话中存在的信息，搭建了持久化记忆的基础设施。

问题 3：它是稳定的事实，还是演进的事件？

这个问题经常被忽略，结果就是所有需要持久化的信息，不论形态如何，都被塞进了同一个存储里。

• 稳定事实（语义记忆）：比如姓名、订阅等级、偏好语气、默认收货地址，或者其他跨会话保持有效的持久知识。把这些存为规范化事实，比反复推断或询问更有价值。
• 演进事件（情景记忆）：比如上个月提交的投诉、早期项目阶段做过的决定、跨多次交互的行为模式。

记忆架构借用了认知科学对人类记忆的分类方法，将稳定的知识与特定过去事件的记忆区分开。一些框架甚至直接将时间维度构建到存储层中。比如Zep，它在知识图谱上建模事实，每个事实都带有一个有效时间窗口，过时的事实会被失效处理，而不是静静地与新信息矛盾。

稳定事实应该放在一个持久的存储里，可以是结构化记录（用于用户属性）、知识图谱（用于关系），或是向量数据库（用于语义可搜索的领域知识）。演进事件则更适合放在一个类似日志的地方，条目不断累积，旧的记录可能需要总结或修剪。

如果这类信息主要是事实和领域知识 → 语义记忆。如果主要是历史 → 情景记忆。下一个问题是，这个日志如何规模化地进行检索，这就引出了问题4。

问题 4：这个记忆将如何被检索？

这个问题说的是，要根据存储的大小、结构和增长速度来匹配合适的检索策略，而不是所有地方都用同一个方法。

• 小型、有边界的存储（少量用户事实或单个配置文件）：在会话开始时完整读取整个存储。Anthropic的记忆工具就是这么干的，因为存储足够小，完整读取的成本不高。
• 大型、可搜索的存储（交互历史、文档库、不断增长的知识库）：只检索最相关的条目，使用语义搜索或混合检索。因为全部读取很快就不现实了。Google的Memory Bank就是为此设计的，像Mem0这类与供应商无关的记忆框架，也能与LangGraph、CrewAI等框架配合使用。

一个Agent同时需要这两种检索模式很常见：对结构化的小型语义存储进行完整读取，同时对较大的情景日志或语义知识库进行相似性搜索。

一旦检索策略与每个存储的实际大小和结构匹配好了，就进入问题5。

问题 5：Agent是否需要学习可复用的流程？

这就是程序记忆登场的时刻。它是在现有的语义和情景层之上的叠加层，而不是替代它们。

• 重复出现的任务模式，且应随着重复而改进（同一类重构、同一类工单）：值得提炼成程序记忆，这样Agent就能应用优化后的流程，而不是重放过去的尝试。
• 一次性或不重复的任务：跳过这一层，之前选择的语义或情景记忆已经足够。

Agent的记忆模块通常与规划、工具层并列，将学到的上下文反馈到未来的计划制定中。关键的设计决策在于写入什么。原始运行的日志捕捉的是情景记忆，而程序记忆存储的是从这些经历中提炼出的教训、成功步骤和可复用的策略。一个有用的程序记忆存储是为未来应用而写的，它允许Agent将经过验证的工作流和模式直接应用到类似任务上。

上述五个问题，最终会形成一个像下图这样的决策树：

记忆层是如何组合的

为每类信息运行决策树，得到的不是一个单一的答案，而是一个记忆配置文件。将这些配置文件整合起来，就能揭示出最适合Agent需求的记忆架构。

比如，一个编程Agent可能用工作记忆处理当前会话的编辑，用语义记忆保存用户偏好和工具知识，用情景记忆记录跨项目的变更历史，并用程序记忆存储经过反复使用而优化的可复用的测试验证工作流。而一个简单的FAQ Agent，可能只需要工作记忆，因为它没有任何信息需要跨会话持久化。

两个都是同一个决策过程的有效结果；差异来源于Agent需要保留的信息类型以及它如何使用这些信息。

AI Agent记忆的常见陷阱（及修复方法）

即便为每个信息类别选对了记忆层，记忆系统在实际运行中还是容易出一些模式化的问题。下面这个表格，把常见的症状、可能的原因和修复方案都列出来了。

总结与下一步

这个决策树把记忆设计从单一的默认方案，变成了一组清晰的选择。它在任何存储架构搭建之前，就提出了关键问题：这条信息需要存多久？它是稳定事实还是过往事件？以后如何检索它？它是否代表一种可以通过改进未来任务的可复用行为？

许多记忆问题的根源，都是把Agent处理的所有信息当成同一类型的数据。正如我们讨论的，工作记忆、语义记忆、情景记忆和程序记忆服务于不同目的，需要不同的存储和检索策略。一个高效的Agent，会根据哪些信息需要持久化、如何被检索、以及是否应改进未来行为，来组合这些层级。

下一步，就是探索实际可用的Agent记忆框架和工具。我们将在后续的文章中，详细讲解如何评估这些框架，并根据你的应用需求做出正确选择。