多Agent共享记忆实战：MCP协议与持久化存储设计

如果你搭建过三个以上的 AI agent 协作流程，大概率遇到过这么一种尴尬：一个 agent 刚写完代码审查结论，另一个 agent 并不知道，又重新分析了一遍同样的问题；负责测试的 agent 在上一轮已经确认过某个接口正常，重启会话后它把这件事忘得一干二净。你需要的不是更强的模型，而是一个让多个 agent 都记得住、查得到、还能共享的记忆系统。Memento 这个项目，从标题就能看出它的定位——Shared, durable memory for multiple AI agents, with MCP access，翻译过来就是：面向多个 AI agent 的共享、持久化记忆，并且通过 MCP 协议接入。

这两年 AI agent 的项目已经多到让人眼花缭乱，但真正把“多 agent 协作”做出生产可用效果的并不多。原因不是模型能力不够，而是大多数 agent 的上下文是私有的、临时的、互相隔离的。每个 agent 都像一个只带了一块白板的实习生：能完成当前任务，但你没办法让它把前面同事的结论、踩过的坑、确认过的决定带进下一步。

Memento 想解决的，恰恰是这层问题。它不是要取代模型，不是要做编排框架，而是给多个 agent 提供一块“共同的、持久的工作记忆”。这篇文章我想顺着这个定位，拆一拆多 agent 共享记忆的真正难点、MCP 在其中为什么合适，以及如果要在真实项目里落地，应该从哪几步开始。

1. 多智能体协同的真正瓶颈，不是模型，而是记忆

1.1 一个记忆缺失的多 agent 协作场景

先说一个很常见的场景。你让一个规划 agent 拆解任务，让一个编码 agent 实现功能，再让一个测试 agent 验证结果。理想情况下，三个 agent 应该像同一个团队里的三个人一样协作：规划 agent 把方案和约束写清楚，编码 agent 照做，测试 agent 知道哪里可能出问题。

但现实往往是另一种样子。规划 agent 输出的任务清单只存在于它自己的上下文窗口里；编码 agent 只能重新读一遍原始需求，再去猜测任务边界；测试 agent 因为没有看到编码 agent 的修改记录，只能重新推理哪些逻辑可能被改动。三个 agent 都做了大量重复工作，最后结果还不一致。

这就是我常说的“上下文窗口不是记忆”。上下文窗口是短期工作区，任务结束、进程重启、会话切换之后，它就不会保留。而且每个 agent 的上下文窗口是私有的，即便当前会话没结束，另一个 agent 也看不到里面有什么。多个 agent 协同工作时，缺的恰恰是一个能被共同访问的公共状态区。

1.2 共享记忆要解决的其实是四件事

从 Memento 的项目定位来看，它要做的不是一个完整的记忆系统，而是先解决四个关键词：

第一是持久。记忆不能只活在一次会话里。agent 重启之后，之前的任务状态、决策记录、用户偏好都还要能恢复。

第二是共享。多个 agent 要能读写同一份记忆。这里的关键不是“都能访问”，而是“读写之间有一致性”，A 写进去的东西，B 要能读到，而且不能随随便便被覆盖掉。

第三是结构化。记忆不能是一堆无差别文本堆积。至少要能按 agent、任务、时间、主题去做查询和过滤，否则数据越多越难用。

第四是可接入。再好的记忆系统，如果每个 agent 都要定制 SDK 才能接入，成本就很高。Memento 选择用 MCP 作为接入方式，等于把“记忆能力”包装成一个标准服务，任何支持 MCP 的客户端都可以直接使用。

这四个词看起来简单，实际上每一条都对应一个工程难点。持久化要选存储模型，共享要处理并发和数据隔离，结构化要设计 schema，可接入要定义稳定的工具接口。很多 agent 项目在原型阶段跑得通，一到生产就散架，通常就是因为在“共享”和“结构化”这两层没有做好。

1.3 为什么这类项目现在才出现

记忆问题并不是新问题。几年前做对话机器人，大家就发现长期记忆很重要，但当时每个项目都要自己定义记忆接口、自己写存储、自己设计同步逻辑。模型厂商提供的 context，或者向量数据库提供的检索，本质上解决的是“信息召回”，不是“多 agent 共享状态”。

现在情况不一样了。MCP 这类标准化协议逐渐普及，agent 的工具调用方式开始统一。记忆服务可以做成一个独立的中间层，不再和具体的 agent 实现绑定。Memento 这类项目就是在这个窗口出现的：模型的调用方式已经相对稳定，缺的是一层通用的基础设施，MCP 恰好给了这层基础设施一个标准接口。

换句话说，多 agent 系统正在经历一个类似 Web 开发里“把数据库独立出来”的过程。早期写网站，数据就是程序里的全局变量；后来发现并发、持久化、权限都绕不开，才逐步形成数据库这个独立分层。AI agent 的记忆，大概率也会走同样的路径。

2. Memento 解决的是记忆层问题，不是模型问题

2.1 它把自己定位成“记忆服务”

从项目名和定位来看，Memento 不是新的 agent 编排框架，也不是模型推理引擎，而更像是一个记忆服务层。记忆这个词很容易让人想起记忆宫殿、经验积累这类玄幻表达，但在工程里，它必须落到具体的职责划分上。

如果让我来概括它的核心职责，可以拆成四类：

• 写入：agent 把需要保存的决策、结论、中间状态、用户偏好写入记忆库。
• 读取：agent 在开始任务或任务中间，按需检索记忆库里的内容。
• 更新：当事情发生变化时，旧记忆要被修正或标记为过时。
• 删除：当记忆不再有效、或者涉及隐私数据时，要从库里移除。

这四类操作看起来和普通数据库 CRUD 很像，但记忆服务有几个数据库不一定会提供的特性。比如，记忆是有时效性的，一个结论今天有效，明天可能就要作废；记忆是有归属的，不同 agent 写入的记忆应该能被区分；记忆还需要支持灵活的检索方式，既能按关键词查，也能按语义查，最好还能结合时间和关联关系过滤。

所以，不要只把 Memento 理解成一个“接上 OpenAI 的工具”。它解决的是一整套记忆生命周期问题，这在多 agent 协同里是一个独立的技术方向。

2.2 它和 RAG 的边界在哪里

很多人会问：这个东西是不是就是 RAG？我的判断是：有关系，但不是一回事。

RAG 的核心是“从外部知识库检索信息，再把检索结果注入上下文”。它解决的问题是“模型不知道某个外部事实，怎么在生成前获取相关信息”。它的重点在知识召回，数据源通常是文档、网页、API 返回结果，使用方式是只读的。

多 agent 共享记忆的核心是“多个执行体共享工作状态”。它解决的问题是“多个 agent 怎么保持对一个任务的共同理解”。它的重点在状态同步，数据源是 agent 自己产生的中间结果、决策记录、上下文演变。

当然，两者可以结合。一个记忆服务可以把已保存的记忆向量化，然后通过语义检索暴露给 agent，这就变成了 RAG 的一种数据源。但是从工程角度看，记忆服务要比 RAG 多承担一层“写入与更新”的职责。RAG 的文档可以不管写入，因为文档已经存在；而记忆每次产生都需要主动保存，否则就丢了。

2.3 它和向量数据库也不是一回事

如果要落地一个记忆服务，底层大概率会用到向量数据库。但这不等于向量数据库就是记忆服务。

向量数据库擅长的是高维向量的存储和相似度检索。它能帮你找到“最像”的内容，但它不会告诉你这段记忆是谁写的、什么时候写、对当前 agent 是否可见、是否已经过期。这些语义和策略，需要记忆服务层去管理。

我见过不少团队直接用向量库当记忆库用，结果很快发现问题：没有 namespace 隔离，A 任务的记忆被 B 任务检索出来；没有时间戳过滤，过期的旧结论一直在污染新决策；没有写入审计，出了问题根本不知道是哪条记忆导致的。

所以，向量数据库是底座，记忆服务是底座之上的语义层。Memento 这类项目如果做得好，应该是把“底座能力 + 语义策略”组合起来，而不是让使用者直接面对裸的向量库。

2.4 它和 agent 编排框架是配合关系

LangGraph、AutoGen 这类编排框架管的是流程：哪一步由哪个 agent 执行，条件分支怎么走，结果怎么传给下一步。它们解决的是“控制流”问题。

Memento 解决的是“状态流”问题：每一步执行完之后，哪些信息需要留下来，下一步如何获取这些信息。

两者天然互补。你可以在编排框架里调用 Memento 的工具，让 agent 在重要节点执行记忆写入；也可以在任务开始前从 Memento 读取历史记忆，作为上下文注入。一个好的多 agent 系统，应该是编排框架管控制流、Memento 类服务管状态流、模型管推理，三层职责各不越界。

3. MCP 是记忆分发的正确接口

3.1 MCP 解决了“每个 agent 都要单独接一遍记忆”的问题

MCP 的全称是 Model Context Protocol，它把模型和外部工具、资源、提示词之间的交互标准化。过去你要让 agent 能使用记忆服务，需要为每个 agent 写一套适配代码；现在只要把记忆能力封装成一个 MCP server，任何支持 MCP 的客户端都能在配置里直接挂载。

这一点对多 agent 系统很重要。因为 agent 的类型很可能不是一种，有的是 MCP 原生客户端，有的是基于函数调用封装，有的跑在云端工作流里。如果每次接入一个记忆服务都要开发定制适配器，这个记忆层就不可能成为基础设施。

MCP 的价值就在于，它把“记忆服务”变成了一种可以即插即用的工具资源。你不需要关心客户端内部是哪种模型、哪种调用方式，只需要保证 MCP server 实现了约定的工具接口即可。

3.2 记忆服务更适合做成 MCP，而不是 Skill

很多人在网上问 “Skill 和 MCP 有什么区别”，我在实际项目中看到不少人把两者搞混。

简单来说，Skill 是一组打包好的提示词、指令或工作流，它告诉 agent “遇到什么情况应该怎么做”。它更像是人的“职业技能”，比如“如何做代码审查”“如何写单元测试”。Skill 本身不依赖外部服务，它只是改变了 agent 的行为方式。

MCP 是外部资源和工具的标准化接入协议。它解决的是“agent 如何调用一个外部系统”。比如把文件系统暴露给 agent、把数据库暴露给 agent、把设计稿工具暴露给 agent，这些都是 MCP 的典型场景。

记忆服务天然属于 MCP 场景，而不是 Skill 场景。因为它是一个有存储、有状态、需要多个客户端共享的外部系统。用 Skill 去描述记忆流程，只能让单个 agent 按照某种策略保存记忆，但无法让多个 agent 共享同一份数据。真正要做的是把“写记忆、读记忆、检索记忆”做成标准工具，通过 MCP 暴露给所有 agent。

在 MCP 的工具设计里，inputSchema是一个关键点。记忆服务通常会有多个工具，比如写入、查询、删除、列出变更等，每个工具的入参和返回值都要定义清楚。如果你在真实项目里做记忆 MCP server，需要注意 schema 是否支持类型嵌套，因为记忆内容的元数据往往是嵌套结构，比如一条记忆包含 namespace、agent_id、content、tags、timestamp，而 tags 本身是数组，历史版本可能又是对象数组。设计 schema 时先想清楚这层嵌套关系，比后面反复改协议要省事得多。

3.3 记忆工具接口的通用设计思路

虽然目前我不确定 Memento 最终暴露的工具名和 schema 细节，但从通用经验看，一个记忆型 MCP server 至少应该提供以下几类工具，这里可以作为一个设计参考：

这里想强调两点。

第一，namespace很重要。多个 agent 共享一个记忆服务时，如果所有数据都堆在同一层，很快就会互相污染。至少要有一个维度区分不同任务、不同项目或不同类型的 agent。

第二，返回值里要包含元数据。没有时间戳、来源、版本的记忆，只能算文本，不能算可用的工程数据。

4. 把 Memento 式记忆接入多 agent 系统：最小落地路径

4.1 第一步：不要一开始就设计复杂 schema，先跑通一条记忆链路

如果你想在自己的多 agent 项目里引入共享记忆，我建议不要一上来就追求完整权限体系、向量检索、自动过期这些高级能力。先做一个最简闭环：一个 agent 写入一条记忆，另一个 agent 能读出来，然后服务重启后数据还在。

这个闭环能验证的其实是三层：存储是否能持久化、MCP server 是否工作正常、客户端是否能正确调用工具。这三层任何一层有问题，后面做再多设计都是空中楼阁。

以常见的接入方式为例，在客户端里配置 MCP server，大致会使用这样一个结构，我这里只给一个通用示意：

{ "mcpServers": { "memento": { "command": "your-memory-server", "args": ["--storage", "./memory.db"], "env": { "MEMORY_NAMESPACE": "project-alpha" } } } }

这里command、args、env的名字可能因具体实现而不同。你要做的不是照抄，而是先弄清你选择的记忆服务到底是怎样启动的、数据存在哪里、配置项有哪些。

启动一个 MCP memory server 后，最常见的验证方式是在 MCP 客户端里调用记忆工具，比如：

{ "tool": "save_memory", "input": { "namespace": "project-alpha", "key": "decision/db-connection", "content": "数据库连接使用读写分离，写入走 master，读取走 replica" } }

然后再用另一个会话、另一个 agent 去查询这条记忆。如果查询不到，问题不一定在模型，更可能在服务连接、namespace、或者工具参数上。

4.2 第二步：为每个 agent 划分命名空间和可见范围

多 agent 共享记录，最怕的是“看起来大家都在写，实际上互相看不见，或者互相覆盖”。

我建议从第一天就引入一个简单的隔离机制。至少要有 namespace 这个维度。它可以对应一个项目、一条业务线、或者一个长任务。更细一点，可以增加scope字段，用来区分“这个 agent 私有”和“所有 agent 共享”。

一条记忆的常见结构，可以设计成下面这个样子：

{ "namespace": "project-alpha", "agent_id": "code-reviewer", "key": "decision/lint-rule", "content": "统一使用 eslint，禁止关闭 no-unused-vars", "tags": ["code-quality", "rule"], "created_at": "2025-01-01T10:00:00Z", "expire_at": null }

这里有几个字段是后来排查问题时最重要的：

• namespace：任务或项目的隔离维度；
• agent_id：来源 agent，方便审计和追溯；
• key：业务标识，避免重复写入太多相同内容；
• expire_at：过期时间，防止记忆无限堆积。

不管底层用 SQLite、PostgreSQL 还是向量库，这个结构层面的设计都应该先想清楚。结构设计不是数据库表字段的堆砌，而是决定未来记忆能否被检索、清理和审计的基础。

4.3 第三步：验证多 agent 共享的一致性

多 agent 共享记忆，比单 agent 记忆麻烦的地方在于一致性。

一个典型场景是：Agent A 写入一条“接口已调通”，Agent B 在下一个任务里读取时，有几种可能读不到。MCP server 可能缓存了旧数据；写入是异步的，还没落盘；B 用的 namespace 和 A 不一致；B 的检索 filter 和 A 写入的 tag 不匹配。

所以在第三步，不要直接让多个真实 agent 跑高并发任务。先用两个固定角色，手动做一组验证：

1. Agent A 写入一条记忆，确认返回成功；
2. Agent B 立即读取，确认能读到；
3. Agent B 修改这条记忆的内容；
4. Agent A 重新读取，确认能看到更新；
5. 等待 5 分钟，再次读取，确认没有回滚或丢失。

这个验证看起来简单，但会产生两个关键结论：一是多 agent 读写路径是否真实可用，二是你对数据一致性的信心有多少。

4.4 第四步：再考虑治理能力

如果你确定多 agent 共享记忆已经成为项目的一部分，那么治理能力迟早要补。

核心是四件事：

• 生命周期：不需要的记忆要能删除或过期，避免垃圾数据污染检索结果。
• 权限：不是每个 agent 都应该看到所有记忆。至少要有命名空间级别的读写控制和按 agent 隔离的能力。
• 审计：每次写入、更新、删除都要留有记录。多 agent 系统出问题时，最后能从记忆层恢复决策链路。
• 导出和备份：记忆是数据资产，不能因为服务实例重启就丢，更不能因为服务器故障就全没。

从工程经验看，这个阶段最容易被忽略的是权限。大家觉得“反正都是 agent，让它们共享”没太大问题，但 agent 的上下文里经常夹带 API Key、内部服务器地址、用户隐私信息。一旦某个 agent 的记忆被另一个不相关 agent 读走，问题就被放大了。

5. 多 agent 共享记忆最容易踩的坑

5.1 高频问题一：A 写入后 B 读不到

这是多 agent 记忆落地时出现频率最高的问题。

排查顺序应该是：先看 MCP server 是否注册成功，再看客户端工具列表里是否有对应的记忆工具，接着确认两个 agent 是否使用了相同的 namespace、服务和 token，最后检查查询条件是否太严格，比如 filter 里的 tag 没对上。

最容易忽略的是异步写入。很多记忆服务为了性能会把写入做成队列，返回成功后不代表已经立即可查。遇到这类问题，先等几秒再查，或者查一下服务日志，确认写入的存储位置。

5.2 高频问题二：两个 agent 同时写同一条记忆，后者覆盖前者

多 agent 共享带来的直接风险是竞争条件。

Agent A 和 Agent B 同时修改“部署状态”这条记忆，最后谁晚提交谁覆盖。解决方案一般是引入版本号或更新时间戳，写入时带上预期版本，服务端发现版本不一致就拒绝写入，让 agent 重新读取再更新。如果记忆服务不支持 CAS（Compare-and-Set），至少要在 key 的设计上做约束，避免多个 agent 修改同一个 key。

5.3 高频问题三：记忆越积越多，检索结果质量下降

记忆是会产生噪声的。时间久了，库里充斥着过期结论、试验记录、互相矛盾的决定。如果检索时没有时间过滤，模型拿到的上下文就可能包含旧信息，导致回答质量反而下降。

我建议在写入层就做好标记。每一条记忆都带created_at、status和source字段。检索时默认排除status=failed或已过期的记录，优先返回最近一段时间内的内容。不要把所有希望都寄托在向量检索的相似度上，时间和状态过滤往往比相似度更有效。

5.4 高频问题四：一个 agent 把中间状态写进了公共库

有些 agent 会把“未完成的想法”“临时计算结果”也写入共享记忆，结果其他 agent 读到时误以为是最终结论。

解决方式有两种：一是区分公共区和私有区，agent 完成一个阶段性目标后才把内容发布到公共区；二是在记忆内容里加state字段，标记为draft、confirmed、deprecated，检索时默认只返回已确认的内容。

5.5 高频问题五：没有权限控制，敏感信息暴露

前面已经提过，这里再补充一个判断标准：如果你的 agent 会处理账号、密钥、内部系统地址、用户信息，那你必须像设计一个内部系统那样设计记忆库的权限。不要让一个测试 agent 读取到生产环境相关的所有记忆。

如果项目早期不想引入复杂的用户系统，至少要做到两点：namespace 级别的隔离，以及记忆内容中不存储明文密钥。密钥应该只存放引用标识，实际值从专门的密钥服务读取。

5.6 一套通用的排查链路

当多 agent 记忆出现异常时，我习惯按照下面这个顺序排查，这个顺序对大多数问题都有效：

1. 先看服务：MCP server 是否启动，日志里有没有报错，连接是否正常；
2. 再看客户端：MCP 配置是否加载成功，工具列表里有没有记忆相关工具；
3. 接着看认证与配置：token、服务地址、namespace、agent 标识是否匹配；
4. 然后看工具调用：参数是否完整，JSON 结构是否正确，schema 类型是否匹配；
5. 再看数据本身：是否成功写入，检索条件是否与写入时的字段一致；
6. 最后看版本：MCP 协议版本、客户端版本、SDK 版本之间是否有兼容性差异。

这条链路看起来长，实际上前两步一分钟之内就能确认。很多时候你以为是大模型“记错了”，其实是 MCP server 压根没启动成功，工具调用直接失败，agent 只能硬着头皮瞎编。先排查接入层，再怀疑模型，这是吃了一次亏以后最重要的教训。

6. 共享记忆不是银弹，先判断你的场景值不值得

6.1 适合引入共享记忆的场景

根据我在真实项目里的体感，下面几类场景特别适合引入 Memento 这类共享记忆服务：

第一，长期项目。多个 agent 要跨会话、跨天完成任务，需要记住之前已经确认过的决定、偏好和约束。比如在一个持续迭代的代码仓库里，agent 需要记住团队的技术选型、代码风格偏好、历史踩坑记录。

第二，多角色协作。规划、编码、测试、文档等多个 agent 面对同一个任务时，必须共享一份项目状态，否则就会出现重复分析、重复执行、结论不一致。

第三，有状态的工作流。任务被拆成多个步骤，由不同 agent 接力完成时，前一步的结果必须传递给后一步。如果只靠上下文传递，任务一长就容易断。

第四，审计和复盘需求。如果你希望知道每个 agent 在哪个阶段做了哪些决策，共享记忆就是一个天然的审计日志源。

6.2 不适合引入共享记忆的场景

反过来，以下几种情况不建议急着上共享记忆：

一次性的短对话。用户问一个问题，agent 回答完就结束，不需要保存任何状态。这时候引入记忆服务，反而是增加延迟和维护成本。

纯检索型任务。如果 agent 只需要去文档里找答案，用 RAG 就够，不需要多 agent 共享状态。

高频低价值写入。如果每个动作都要往记忆库写一条，记忆库会迅速变成垃圾桶。共享记忆适合保存“值得跨会话共享的决策”，不是每条日志都要存。

强隐私合规场景。如果系统涉及大量用户隐私数据，而且当前没有完善的数据脱敏、权限控制和删除机制，那么多 agent 共享记忆会显著增加合规风险。

6.3 一个选型检查表

你可以用下面这个表格快速判断，当前项目要不要引入共享记忆层。

如果大多数都落在“适合引入”栏，那 Memento 这类项目确实值得试用。如果大多数都落在“暂不引入”，那么老老实实用单 agent + 长上下文，可能反而是最优解。

6.4 未来的基础设施层

回顾 Web 开发，早期业务逻辑和数据存储混杂在一起，后来数据库变成独立基础设施；再后来，缓存、消息队列、对象存储都各自独立成层，每一层都解决一类通用的重复问题。

AI agent 系统也在经历同样的分层过程。模型负责推理，编排框架负责流程，工具层负责和能力系统交互，而记忆层负责状态和上下文的持久化。Memento 这类项目，正是在往“记忆层”这个基础设施角色上走。

你可以在自己的项目里提前实践这件事，但不一定非要等到团队规模很大才动手。最少只需要两步：第一，选定一个记忆存储方案；第二，把它封装成 MCP server，暴露标准的读、写、检索工具。然后用两个 agent 跑一轮“写入、读取、更新、重启后再读取”的完整链路，确认它能稳定工作。

先跑通，再治理，最后再扩展到更多 agent。别一开始就想着把所有状态都放进去，那也是过度设计。真正成熟的路径，往往是先让一个关键决策被记住，让另一个 agent 能查到，然后慢慢才长出完整的记忆体系。

多 agent 系统最需要的，也许不是更聪明的模型，而是一块让大家记得住、查得到、能协作的白板。Memento 正好站在这个方向上。