开篇
在Agent的浪潮中，我们经历了一次又一次的认知迭代。
最初是提示工程，我们学习如何更好地提问；随后是上下文工程，随着窗口从8k卷到1M，我们误以为塞进去就是记住了。但当Manus、Anthropic 等团队开始引入file system和agent skill等概念后，上下文工程的边界又变得日益模糊。😳
最近看了AWS re:Invent 2025 中关于memory的一场技术演讲以及MongoDB的一篇技术博客，让我对上下文和记忆这两者有了更清晰的认知。
“上下文（Context）不等于记忆（Memory）。”
“大多数 Agent 的失败，不是推理的失败，而是记忆的失败。”
“因为我们正在试图用本质上无状态的大语言模型，去解决高度有状态的现实世界问题。”
“要构建能够长期运行、处理复杂任务甚至多智能体协作的系统，我们必须跨越上下文工程，正式迈入记忆工程。”
这篇文章是我对视频和博客以及之前自己零散的理解做的一次梳理，如果你也对memory有些困惑，希望这篇文章可以给你一些帮助～😊
原视频和原文链接如下～：https://www.youtube.com/watch?v=asWTC3oc-SA、https://www.mongodb.com/company/blog/technical/why-multi-agent-systems-need-memory-engineering（演讲者与作者都是Mikiko Bazeley）。以下如果有理解错误的地方，恳请大家指正。
在谈论记忆之前，我们需要先认清 LLM 的本质。作为一个推理引擎，它在记忆层面存在三个结构性缺陷：
参数记忆的静态性：对于模型来说，世界在训练截止日那天就停止了。
上下文窗口的临时性：上下文窗口虽然变大了，但它本质上只是工作记忆。一旦会话结束或超出窗口限制，信息就会瞬间消失。
无状态本质：LLM本身没有跨会话的持久状态概念。它不知道你是谁，除非你在每一次交互中都重新告诉它。
更糟糕的是，即便我们强行塞入海量上下文，真正被有效利用的部分往往只有20-30%。随着输入长度增加，模型的注意力会分散，导致Lost in the Middle，连简单的指令遵循能力都会退化。
AI Agent 的进化方向正是如此：从「全量上下文」转向「外挂记忆库」。
这意味着，我们不再追求把所有信息一次性塞进prompt，而是构建一套持久化的记忆系统。这套系统的价值在于连续性：它能确保 Agent 在与用户的第 100 次交互时，依然能精准调用第 1 次交互时留下的关键线索，从而产生真正的默契。
这是最容易混淆的概念。下面明确一下定义～
上下文（Context）：是指 LLM 在单次交互中能够处理的文本量。它是临时的、易失的，本质上是工作记忆。
记忆（Memory）：是一种持久化的管理系统，它能将无状态的Agent转变为能够学习、适应并保持连续性的实体。
如上图所示，上下文工程和记忆工程是紧密协作但截然不同的两个领域：
记忆工程负责构建持久的、智能的存储系统，决定「保留什么」和「遗忘什么」。
上下文工程则利用这些系统，动态地筛选出与当前决策最相关的片段，决定「让模型此刻看到什么」。
目前许多Agent开发仍停留在上下文工程阶段。我们通过RAG、prompt优化等手段，试图在有限的窗口内塞入更多信息。
但上下文工程面临着垃圾场效应。
如图所示，随着对话进行，上下文窗口会迅速变成一个充满了提示词、工具调用结果、错误尝试和无关元数据的垃圾场。这不仅极其昂贵（Token 成本爆炸），还会引入噪音，导致模型幻觉。
要解决这个问题，仅仅优化怎么塞是不够的，我们需要优化存什么——这就引出了记忆工程。👇
既然无限堆叠上下文行不通，那么就可以针对不同的Agent形态，设计差异化的记忆架构。根据MongoDB演讲者的定义，AI Agent主要有三种应用模式，它们对记忆的要求层层递进：
1、助手模式：解决连贯性
场景：客服、私人助理。
核心需求：会话连贯性。需要记住用户的偏好、历史对话，保持“人设”一致。
记忆痛点：一旦切断会话，用户就像面对一个新客服一样需要重述问题。
2、工作流模式：解决鲁棒性
场景：自动化流程（如 dify）、数据处理管道。
核心需求：逐步执行过程的记忆。需要记录检查点、中间状态和工具输出。
记忆痛点：如果任务中断，Agent 能否从第 8 步继续，而不是从第 1 步重头再来？
3、多智能体（Deep Research）模式：解决一致性
这里是记忆工程真正的挑战，从构建单一助手转向多智能体系统时，对记忆的需求发生了质的飞跃。
研究显示，多智能体系统的失败率高达 40%-80%，其中大量的失败源于智能体间的不对齐。具体的失败模式包括：
工作重复：Agent A 搜索了资料，Agent B 不知道，又去搜了一遍。
状态不一致：Agent A 认为任务已完成，Agent B 认为还在进行中。
通信爆炸：为了同步信息，Agent 之间疯狂对话，消耗了海量 Token 却只为了解释背景。
级联故障：一个 Agent 的幻觉（污染的上下文）传播给了所有其他 Agent，导致整个系统崩溃。
解决这些问题的唯一途径，就是构建一个结构化的、共享的记忆工程体系。👇
我们不能把所有数据一股脑丢进数据库，要像人类的大脑一样，对记忆进行精密的分层管理。
如上图可以清晰地看到，一个成熟的记忆系统由三大板块构成：短期记忆 (STM)、长期记忆 (LTM)以及连接两者的协调机制。👇
这是Agent的前台接待处，负责处理高频、瞬时的信息流。
工作记忆：
即当前的上下文窗口。它负责当下的推理任务，就像人脑的RAM，容量有限，随用随清。
语义缓存：
这是降低成本的神器。如果用户曾问过“如何重置密码”，系统直接从缓存层返回答案，而无需再次调用昂贵的 LLM。
👉 响应时间从 2秒-> 50毫秒，Token成本降为0。
这是 Agent 产生智能积累的核心区域。随着时间推移，Agent会越来越聪明，全靠这一层～
程序性记忆：记录「怎么做」
存储工作流状态、工具使用方法以及成功的任务路径（SOP）。这让 Agent 像老员工一样，越干越熟练。
情景记忆：记录「发生了什么」
存储历史对话日志和摘要。它提供了连续性的体验，让Agent记得你们上周聊过的开心事。
语义记忆：记录「什么是真实的」
存储事实知识库、实体信息（如用户的职位、名字）以及 Agent 自身的角色设定。
当场景升级到多智能体协作时，仅仅只有个体的STM和LTM是不够的。我们需要引入第三层维度。
Mikiko Bazeley提出的多智能体记忆架构（如下图所示），清晰地展示了如何通过引入外部共享记忆，解决团队协作难题。
在多Agent环境下，记忆工程面临三个全新的挑战：一致性、隔离性与并发性。
（1）共享一致性：引入白板机制
👉 这是团队的实时会议室。
定义：一个实时的、共享的短期外部记忆区。
作用：所有的 Agent 都在这里交换情报、同步状态。它是动态的，随任务结束而清空。
场景：当 Agent A 完成了步骤1，它不需要给所有 Agent 汇报，只需更新白板。Agent B 看一眼白板，就知道自己该接手步骤2了。
（2）跨Agent协调：确立共识机制
👉这是团队的公司法和SOP。
定义：存储经过验证的团队规程的长期记忆区。
作用：当 Agent 之间产生分歧（例如 A 说向左，B 说向右）时，共识记忆是唯一的真理来源。
人设记忆：同时，这里还存储了团队组织架构图，定义了每个 Agent 的权限边界，防止“财务 Agent”去修改“代码库”，确保专业分工互不干扰。
（3）隔离与隐私：独立的上下文窗口
👉虽然有共享，但每个Agent依然保留独立的短期内部记忆。
财务Agent的草稿纸上不应该出现营销 Agent的头脑风暴记录。保持上下文的纯净和隔离，是防止逻辑干扰和幻觉的关键。
明白了记忆的分类（存什么），接下来的核心问题是：怎么存和怎么管？
记忆工程绝不仅仅是把数据丢进数据库。它是一门复杂的系统设计学科，让Agent像生物一样，建立起从原始数据到智慧经验的完整转换管道。
一个成熟的记忆系统，数据不再是静态的记录，而是一条流动的数据流。如下图所示，原始数据需要经历一个完整的转换管道，才能成为可用的记忆。
在这个管道中，每一个环节都至关重要：
聚合与过滤：
去噪：不要把“你好”、“在吗”这种废话存入长期记忆。
提炼：利用 LLM 从嘈杂的交互中提取高价值信号（例如：“用户意图是重置密码”），而非原始对话流。
编码：将信息转化为向量（用于模糊语义搜索）和结构化数据（JSON/图数据库，用于精确属性查询）。
存储：
元数据丰富化：存入数据库时，必须打上时间戳、来源、置信度等标签，为后续的检索提供上下文。
检索与组织：
动态索引：根据时间顺序或主题相关性建立索引，确保在正确的时间提取正确的信息。
遗忘：
至关重要的一环：遗忘不是系统的Bug，而是Feature。系统需要智能地降低过时信息（如去年的天气）的权重。没有遗忘，记忆就会变成垃圾场。
这是不是和rag的流程很像呢🤔（老师经常强调学好rag是学习agent的基础）
2、工程落地指南：记忆系统的五大支柱
知道了原理，如何构建这样一套复杂的系统呢？
MongoDB的技术团队为我们总结了工程落地的五大支柱。这五个维度构成了记忆工程的基石。👇
（1）持久化：写入上下文
👉 多智能体系统必须超越上下文窗口，拥有独立的持久化层。
共享Todo列表：这不仅仅是一个文本文件，而是一个动态的状态机。所有Agent都能看到当前的目标进度，确保劲往一处使。
程序性记忆演进：优秀的系统不仅记录发生了什么（情景记忆），还记录怎么做（程序性记忆）。随着项目进行，系统应能自动更新工作流，将成功的协作模式固化下来。
👉 在多智能体环境中，检索不再是简单的向量相似度匹配。
基于 Agent 角色的查询：当财务Agent查询“Q3数据”时，它应该得到详细的报表；而文案Agent查询同一关键词，可能只需要一个总结数字。记忆系统必须理解谁在提问。
时序协调：紧急的信息（如“数据库已锁死”）必须拥有高优先级，能够打断Agent的当前任务并注入其上下文；而普通信息则应被缓存，等待Agent空闲时获取。
👉为了防止token成本指数级增长，优化至关重要。
分层摘要：Agent A 和 Agent B 之间可能交互了 50 轮，但对于 Agent C 来说，它只需要知道“他们决定采用 Python 编写后端”。系统需要自动生成不同颗粒度的摘要。
智能遗忘：这是一种高级的生命周期管理。我们不直接删除数据，而是降低其记忆强度。随着时间推移，不再被激活的记忆会逐渐淡出检索范围，就像人类的遗忘曲线一样。
👉多智能体协作最怕大杂烩。
领域隔离：确保 Agent 专注于其专业领域的记忆。营销 Agent 不需要加载全量的技术架构文档，这不仅节省 Token，还能防止非专业领域的知识干扰决策（减少幻觉）。
协调边界：在系统层面，需要有专门的记忆管理Agent来负责跨团队的记忆搬运，而不是让每个工作Agent自己去翻阅所有档案。
👉这是多智能体系统最棘手的部分：并发与一致性。
原子操作：当多个Agent试图同时更新共享记忆（例如修改同一个PRD）时，系统必须支持原子操作：要么全部更新成功，要么全部失败回滚，绝不能出现「写了一半」的脏数据。
冲突解决机制：当 Agent A 说“用户是男性”，Agent B 说“用户是女性”时，系统需要基于置信度、数据新鲜度或角色权威性来自动仲裁。
回顾一下，为什么要有记忆工程呢？
因为会有以下几种情况出现～👇
记忆失败：遗忘、编造虚假记忆或存储过多噪音，导致上下文退化和中毒。
检索失败：提取无关、过时或处于上下文中间的信息。
工作流失败：丢失状态、中断多步骤任务、循环或传播错误。
协调失败：代理冲突、重复工作或覆盖共享内存。
那么，有了记忆系统之后，该如何判断是否成功呢？
MongoDB的技术团队提到一个优秀的记忆系统应该符合RBC 框架：
Reliable (可靠)：不丢失任务状态，推理可复现。
Believable (可信)：保持角色一致性，建立用户信任。
Capable (有能力)：随着时间推移能扩展技能，从经验中学习。
或者也可以通过以下四个失败信号来判断👇
此外，也可以根据上面的五个支柱维度，结合具体业务构建数据集进行评估。
Mikiko Bazeley在演讲结尾留了三个建议：
首先，你需要区分，可见性与持久性。
其次，记忆必须通过模式来设计流程和评估循环。
再者，只有当记忆系统可靠且有用时，智能体本身才能变得可靠且有用。
AI 的未来，不仅仅在于更强的模型，更在于更强的记忆。
它让Agent拥有了时间感，拥有了经验，更拥有了与小伙伴们并肩作战的信任基础。👥
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |