我要投稿

上下文不等于记忆：从单Agent到多Agent协作，记忆系统是关键

发布日期：2025-12-24 10:40:54 浏览次数： 1518

作者：晨光里的AI

微信搜一搜，关注“晨光里的AI”

开篇

在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 的本质。作为一个推理引擎，它在记忆层面存在三个结构性缺陷：

参数记忆的静态性：对于模型来说，世界在训练截止日那天就停止了。
上下文窗口的临时性：上下文窗口虽然变大了，但它本质上只是工作记忆。一旦会话结束或超出窗口限制，信息就会瞬间消失。
无状态本质：LLM本身没有跨会话的持久状态概念。它不知道你是谁，除非你在每一次交互中都重新告诉它。

更糟糕的是，即便我们强行塞入海量上下文，真正被有效利用的部分往往只有20-30%。随着输入长度增加，模型的注意力会分散，导致Lost in the Middle，连简单的指令遵循能力都会退化。

那么该如何解决呢？

我们可以向人类的认知架构取取经。👇

人类大脑是一个极强的CPU，但我们的工作记忆（RAM）非常有限。我们之所以能处理复杂任务，是因为我们拥有强大的外置认知层——笔记、书籍、数据库。我们不强求记住所有，而是擅长索引和检索。

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) 以及连接两者的协调机制。👇

1、短期记忆 (STM)：系统的草稿纸

这是Agent的前台接待处，负责处理高频、瞬时的信息流。

工作记忆：

即当前的上下文窗口。它负责当下的推理任务，就像人脑的RAM，容量有限，随用随清。
语义缓存：

这是降低成本的神器。如果用户曾问过“如何重置密码”，系统直接从缓存层返回答案，而无需再次调用昂贵的 LLM。

👉 响应时间从 2秒 -> 50毫秒，Token成本降为0。

2、长期记忆 (LTM)：系统的硬盘

这是 Agent 产生智能积累的核心区域。随着时间推移，Agent会越来越聪明，全靠这一层～

程序性记忆：记录「怎么做」

存储工作流状态、工具使用方法以及成功的任务路径（SOP）。这让 Agent 像老员工一样，越干越熟练。
情景记忆：记录「发生了什么」

存储历史对话日志和摘要。它提供了连续性的体验，让Agent记得你们上周聊过的开心事。
语义记忆：记录「什么是真实的」

存储事实知识库、实体信息（如用户的职位、名字）以及 Agent 自身的角色设定。

3、架构升级：从个人笔记到团队白板

当场景升级到多智能体协作时，仅仅只有个体的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像生物一样，建立起从原始数据到智慧经验的完整转换管道。

1、数据炼金：记忆的生命周期

一个成熟的记忆系统，数据不再是静态的记录，而是一条流动的数据流。如下图所示，原始数据需要经历一个完整的转换管道，才能成为可用的记忆。

在这个管道中，每一个环节都至关重要：

聚合与过滤：

去噪：不要把“你好”、“在吗”这种废话存入长期记忆。
提炼：利用 LLM 从嘈杂的交互中提取高价值信号（例如：“用户意图是重置密码”），而非原始对话流。

编码：将信息转化为向量（用于模糊语义搜索）和结构化数据（JSON/图数据库，用于精确属性查询）。

存储：

元数据丰富化：存入数据库时，必须打上时间戳、来源、置信度等标签，为后续的检索提供上下文。

检索与组织：

动态索引：根据时间顺序或主题相关性建立索引，确保在正确的时间提取正确的信息。

遗忘：

至关重要的一环：遗忘不是系统的Bug，而是Feature。系统需要智能地降低过时信息（如去年的天气）的权重。没有遗忘，记忆就会变成垃圾场。

这是不是和rag的流程很像呢🤔（老师经常强调学好rag是学习agent的基础）

2、工程落地指南：记忆系统的五大支柱

知道了原理，如何构建这样一套复杂的系统呢？

MongoDB的技术团队为我们总结了工程落地的五大支柱。这五个维度构成了记忆工程的基石。👇

（1）持久化：写入上下文

👉 多智能体系统必须超越上下文窗口，拥有独立的持久化层。

共享Todo列表：这不仅仅是一个文本文件，而是一个动态的状态机。所有Agent都能看到当前的目标进度，确保劲往一处使。
程序性记忆演进：优秀的系统不仅记录发生了什么（情景记忆），还记录怎么做（程序性记忆）。随着项目进行，系统应能自动更新工作流，将成功的协作模式固化下来。

（2）检索：选择上下文

👉 在多智能体环境中，检索不再是简单的向量相似度匹配。

基于 Agent 角色的查询：当财务Agent查询“Q3数据”时，它应该得到详细的报表；而文案Agent查询同一关键词，可能只需要一个总结数字。记忆系统必须理解谁在提问。
时序协调：紧急的信息（如“数据库已锁死”）必须拥有高优先级，能够打断Agent的当前任务并注入其上下文；而普通信息则应被缓存，等待Agent空闲时获取。

（3）优化：压缩上下文

👉 为了防止token成本指数级增长，优化至关重要。

分层摘要：Agent A 和 Agent B 之间可能交互了 50 轮，但对于 Agent C 来说，它只需要知道“他们决定采用 Python 编写后端”。系统需要自动生成不同颗粒度的摘要。
智能遗忘：这是一种高级的生命周期管理。我们不直接删除数据，而是降低其记忆强度。随着时间推移，不再被激活的记忆会逐渐淡出检索范围，就像人类的遗忘曲线一样。

（4）分离：隔离上下文

👉 多智能体协作最怕大杂烩。

领域隔离：确保 Agent 专注于其专业领域的记忆。营销 Agent 不需要加载全量的技术架构文档，这不仅节省 Token，还能防止非专业领域的知识干扰决策（减少幻觉）。
协调边界：在系统层面，需要有专门的记忆管理Agent来负责跨团队的记忆搬运，而不是让每个工作Agent自己去翻阅所有档案。

（5）整合：同步上下文

👉 这是多智能体系统最棘手的部分：并发与一致性。

原子操作：当多个Agent试图同时更新共享记忆（例如修改同一个PRD）时，系统必须支持原子操作：要么全部更新成功，要么全部失败回滚，绝不能出现「写了一半」的脏数据。
冲突解决机制：当 Agent A 说“用户是男性”，Agent B 说“用户是女性”时，系统需要基于置信度、数据新鲜度或角色权威性来自动仲裁。