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

在 Agent 的浪潮中，我们经历了一次又一次的认知迭代。

最初是提示工程，我们学习如何更好地提问；随后是上下文工程，随着窗口从 8k 卷到 1M，我们误以为「塞进去」就是「记住了」。但当 Manus、Anthropic 等团队开始引入 file system 和 agent skill 等概念后，上下文工程的边界又变得日益模糊。

最近看了 AWS re:Invent 2025 中关于 memory 的一场技术演讲以及 MongoDB 的一篇技术博客（演讲者与作者都是 Mikiko Bazeley），让我对「上下文」和「记忆」这两者有了更清晰的认知：

上下文（Context）不等于记忆（Memory）。

大多数 Agent 的失败，不是推理的失败，而是记忆的失败。

因为我们正在试图用本质上无状态的大语言模型，去解决高度有状态的现实世界问题。

要构建能够长期运行、处理复杂任务甚至多智能体协作的系统，我们必须跨越上下文工程，正式迈入记忆工程。

LLM 的内生局限与破局

在谈论记忆之前，我们需要先认清 LLM 的本质。作为一个推理引擎，它在记忆层面存在三个结构性缺陷：

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

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

那么该如何解决？可以向人类的认知架构取取经。

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

AI Agent 的进化方向正是如此：从「全量上下文」转向「外挂记忆库」。这意味着我们不再追求把所有信息一次性塞进 prompt，而是构建一套持久化的记忆系统。这套系统的价值在于连续性：它能确保 Agent 在与用户的第 100 次交互时，依然能精准调用第 1 次交互时留下的关键线索，从而产生真正的默契。

走出误区：从上下文工程到记忆工程

这是最容易混淆的概念，先明确定义：

• 上下文（Context）：LLM 在单次交互中能够处理的文本量。它是临时的、易失的，本质上是工作记忆。
• 记忆（Memory）：一种持久化的管理系统，它能将无状态的 Agent 转变为能够学习、适应并保持连续性的实体。

上下文工程和记忆工程是紧密协作但截然不同的两个领域：记忆工程负责构建持久的、智能的存储系统，决定「保留什么」和「遗忘什么」；上下文工程则利用这些系统，动态地筛选出与当前决策最相关的片段，决定「让模型此刻看到什么」。

目前许多 Agent 开发仍停留在上下文工程阶段。我们通过 RAG、prompt 优化等手段，试图在有限的窗口内塞入更多信息。但上下文工程面临着垃圾场效应：随着对话进行，上下文窗口会迅速变成一个充满了提示词、工具调用结果、错误尝试和无关元数据的垃圾场。这不仅极其昂贵，还会引入噪音，导致模型幻觉。

要解决这个问题，仅仅优化「怎么塞」是不够的，我们需要优化「存什么」。

记忆的进阶：从私人助理到智能团队

既然无限堆叠上下文行不通，那就针对不同的 Agent 形态，设计差异化的记忆架构。AI Agent 主要有三种应用模式，它们对记忆的要求层层递进。

1、助手模式：解决连贯性。场景是客服、私人助理，核心需求是会话连贯性——需要记住用户的偏好、历史对话，保持人设一致。痛点是一旦切断会话，用户就像面对一个新客服一样需要重述问题。

2、工作流模式：解决鲁棒性。场景是自动化流程、数据处理管道，核心需求是逐步执行过程的记忆——需要记录检查点、中间状态和工具输出。痛点是任务中断后，Agent 能否从第 8 步继续，而不是从第 1 步重头再来。

3、多智能体模式：解决一致性。这里是记忆工程真正的挑战。研究显示，多智能体系统的失败率高达 40% 到 80%，其中大量的失败源于智能体间的不对齐：

• 工作重复：Agent A 搜索了资料，Agent B 不知道，又去搜了一遍。
• 状态不一致：Agent A 认为任务已完成，Agent B 认为还在进行中。
• 通信爆炸：为了同步信息，Agent 之间疯狂对话，消耗了海量 Token 却只为了解释背景。
• 级联故障：一个 Agent 的幻觉传播给了所有其他 Agent，导致整个系统崩溃。

解决这些问题的唯一途径，就是构建一个结构化的、共享的记忆工程体系。

记忆类型解剖：分层管理

我们不能把所有数据一股脑丢进数据库，要像人类的大脑一样，对记忆进行精密的分层管理。一个成熟的记忆系统由三大板块构成：短期记忆、长期记忆，以及连接两者的协调机制。

1、短期记忆（STM）：系统的草稿纸

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

• 工作记忆：即当前的上下文窗口，负责当下的推理任务，就像人脑的 RAM，容量有限，随用随清。
• 语义缓存：这是降低成本的神器。如果用户曾问过「如何重置密码」，系统直接从缓存层返回答案，无需再次调用昂贵的 LLM——响应时间从 2 秒降到 50 毫秒，Token 成本降为 0。

2、长期记忆（LTM）：系统的硬盘

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

• 程序性记忆（记录「怎么做」）：存储工作流状态、工具使用方法以及成功的任务路径（SOP），这让 Agent 像老员工一样越干越熟练。
• 情景记忆（记录「发生了什么」）：存储历史对话日志和摘要，提供连续性的体验。
• 语义记忆（记录「什么是真实的」）：存储事实知识库、实体信息（如用户的职位、名字）以及 Agent 自身的角色设定。

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

当场景升级到多智能体协作时，仅有个体的 STM 和 LTM 是不够的，需要引入第三层维度。在多 Agent 环境下，记忆工程面临三个全新的挑战：一致性、隔离性与并发性。

（1）共享一致性：引入白板机制

这是团队的实时会议室——一个实时的、共享的短期外部记忆区。所有 Agent 都在这里交换情报、同步状态，它是动态的，随任务结束而清空。

当 Agent A 完成了步骤 1，它不需要给所有 Agent 汇报，只需更新白板；Agent B 看一眼白板，就知道自己该接手步骤 2 了。

（2）跨 Agent 协调：确立共识机制

这是团队的公司法和 SOP——存储经过验证的团队规程的长期记忆区。当 Agent 之间产生分歧（A 说向左，B 说向右）时，共识记忆是唯一的真理来源。

这里还存储了团队组织架构图，定义了每个 Agent 的权限边界，防止「财务 Agent」去修改「代码库」，确保专业分工互不干扰。

（3）隔离与隐私：独立的上下文窗口

虽然有共享，但每个 Agent 依然保留独立的短期内部记忆。财务 Agent 的草稿纸上不应该出现营销 Agent 的头脑风暴记录。保持上下文的纯净和隔离，是防止逻辑干扰和幻觉的关键。

记忆工程的核心：从生命周期到五大支柱

明白了记忆的分类（存什么），接下来的核心问题是：怎么存和怎么管？

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

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

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

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

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

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

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

这个流程是不是和 RAG 很像？（老师经常强调，学好 RAG 是学习 Agent 的基础。）

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

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

多智能体系统必须超越上下文窗口，拥有独立的持久化层。共享 Todo 列表不仅仅是一个文本文件，而是一个动态的状态机，所有 Agent 都能看到当前的目标进度。此外，优秀的系统不仅记录「发生了什么」，还记录「怎么做」，随着项目进行自动更新工作流，把成功的协作模式固化下来。

（2）检索：选择上下文

在多智能体环境中，检索不再是简单的向量相似度匹配。基于 Agent 角色的查询：当财务 Agent 查询「Q3 数据」时应该得到详细报表，而文案 Agent 查询同一关键词可能只需要一个总结数字，记忆系统必须理解「谁在提问」。时序协调：紧急信息（如「数据库已锁死」）必须拥有高优先级，能够打断 Agent 的当前任务并注入其上下文；普通信息则应被缓存，等待 Agent 空闲时获取。

（3）优化：压缩上下文

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

（4）分离：隔离上下文

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

（5）整合：同步上下文

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

记忆系统的评估

回顾一下，为什么要有记忆工程？因为没有它会出现这几类失败：

• 记忆失败：遗忘、编造虚假记忆或存储过多噪音，导致上下文退化和中毒。
• 检索失败：提取无关、过时或处于上下文中间的信息。
• 工作流失败：丢失状态、中断多步骤任务、循环或传播错误。
• 协调失败：Agent 冲突、重复工作或覆盖共享内存。

那么有了记忆系统之后，如何判断是否成功？一个优秀的记忆系统应该符合 RBC 框架：

• Reliable（可靠）：不丢失任务状态，推理可复现。
• Believable（可信）：保持角色一致性，建立用户信任。
• Capable（有能力）：随着时间推移能扩展技能，从经验中学习。

也可以根据上面的五个支柱维度，结合具体业务构建数据集进行评估。

最后

Mikiko Bazeley 在演讲结尾留了三个建议：首先，你需要区分可见性与持久性；其次，记忆必须通过模式来设计流程和评估循环；再者，只有当记忆系统可靠且有用时，智能体本身才能变得可靠且有用。

AI 的未来，不仅仅在于更强的模型，更在于更强的记忆。它让 Agent 拥有了时间感，拥有了经验，更拥有了与小伙伴们并肩作战的信任基础。