如果你搭建过三个以上的 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 至少应该提供以下几类工具这里可以作为一个设计参考操作类型典型工具名主要入参典型返回值写入save_memorynamespace、key、content、metadatamemory_id、status读取get_memorymemory_id 或 key记忆内容、更新时间、来源 agent检索search_memoryquery、namespace、limit、tags命中的记忆列表更新update_memorymemory_id、content、version更新结果删除delete_memorymemory_id、namespace、reason删除结果列表list_recentnamespace、since、limit最近写入的记忆列表这里想强调两点。第一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 跑高并发任务。先用两个固定角色手动做一组验证Agent A 写入一条记忆确认返回成功Agent B 立即读取确认能读到Agent B 修改这条记忆的内容Agent A 重新读取确认能看到更新等待 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 重新读取再更新。如果记忆服务不支持 CASCompare-and-Set至少要在 key 的设计上做约束避免多个 agent 修改同一个 key。5.3 高频问题三记忆越积越多检索结果质量下降记忆是会产生噪声的。时间久了库里充斥着过期结论、试验记录、互相矛盾的决定。如果检索时没有时间过滤模型拿到的上下文就可能包含旧信息导致回答质量反而下降。我建议在写入层就做好标记。每一条记忆都带created_at、status和source字段。检索时默认排除statusfailed或已过期的记录优先返回最近一段时间内的内容。不要把所有希望都寄托在向量检索的相似度上时间和状态过滤往往比相似度更有效。5.4 高频问题四一个 agent 把中间状态写进了公共库有些 agent 会把“未完成的想法”“临时计算结果”也写入共享记忆结果其他 agent 读到时误以为是最终结论。解决方式有两种一是区分公共区和私有区agent 完成一个阶段性目标后才把内容发布到公共区二是在记忆内容里加state字段标记为draft、confirmed、deprecated检索时默认只返回已确认的内容。5.5 高频问题五没有权限控制敏感信息暴露前面已经提过这里再补充一个判断标准如果你的 agent 会处理账号、密钥、内部系统地址、用户信息那你必须像设计一个内部系统那样设计记忆库的权限。不要让一个测试 agent 读取到生产环境相关的所有记忆。如果项目早期不想引入复杂的用户系统至少要做到两点namespace 级别的隔离以及记忆内容中不存储明文密钥。密钥应该只存放引用标识实际值从专门的密钥服务读取。5.6 一套通用的排查链路当多 agent 记忆出现异常时我习惯按照下面这个顺序排查这个顺序对大多数问题都有效先看服务MCP server 是否启动日志里有没有报错连接是否正常再看客户端MCP 配置是否加载成功工具列表里有没有记忆相关工具接着看认证与配置token、服务地址、namespace、agent 标识是否匹配然后看工具调用参数是否完整JSON 结构是否正确schema 类型是否匹配再看数据本身是否成功写入检索条件是否与写入时的字段一致最后看版本MCP 协议版本、客户端版本、SDK 版本之间是否有兼容性差异。这条链路看起来长实际上前两步一分钟之内就能确认。很多时候你以为是大模型“记错了”其实是 MCP server 压根没启动成功工具调用直接失败agent 只能硬着头皮瞎编。先排查接入层再怀疑模型这是吃了一次亏以后最重要的教训。6. 共享记忆不是银弹先判断你的场景值不值得6.1 适合引入共享记忆的场景根据我在真实项目里的体感下面几类场景特别适合引入 Memento 这类共享记忆服务第一长期项目。多个 agent 要跨会话、跨天完成任务需要记住之前已经确认过的决定、偏好和约束。比如在一个持续迭代的代码仓库里agent 需要记住团队的技术选型、代码风格偏好、历史踩坑记录。第二多角色协作。规划、编码、测试、文档等多个 agent 面对同一个任务时必须共享一份项目状态否则就会出现重复分析、重复执行、结论不一致。第三有状态的工作流。任务被拆成多个步骤由不同 agent 接力完成时前一步的结果必须传递给后一步。如果只靠上下文传递任务一长就容易断。第四审计和复盘需求。如果你希望知道每个 agent 在哪个阶段做了哪些决策共享记忆就是一个天然的审计日志源。6.2 不适合引入共享记忆的场景反过来以下几种情况不建议急着上共享记忆一次性的短对话。用户问一个问题agent 回答完就结束不需要保存任何状态。这时候引入记忆服务反而是增加延迟和维护成本。纯检索型任务。如果 agent 只需要去文档里找答案用 RAG 就够不需要多 agent 共享状态。高频低价值写入。如果每个动作都要往记忆库写一条记忆库会迅速变成垃圾桶。共享记忆适合保存“值得跨会话共享的决策”不是每条日志都要存。强隐私合规场景。如果系统涉及大量用户隐私数据而且当前没有完善的数据脱敏、权限控制和删除机制那么多 agent 共享记忆会显著增加合规风险。6.3 一个选型检查表你可以用下面这个表格快速判断当前项目要不要引入共享记忆层。检查项适合引入暂不引入任务是否跨多个会话是经常跨天否单次问答是否有多个 agent 协同是角色明确否单个 agent 足够是否需要共同状态是任务相互依赖否互相独立能否接受新增基础设施能有独立运维能力否希望最小成本是否有审计或追溯需求是否敏感信息是否可控是有隔离和权限设计否无法保证可见范围如果大多数都落在“适合引入”栏那 Memento 这类项目确实值得试用。如果大多数都落在“暂不引入”那么老老实实用单 agent 长上下文可能反而是最优解。6.4 未来的基础设施层回顾 Web 开发早期业务逻辑和数据存储混杂在一起后来数据库变成独立基础设施再后来缓存、消息队列、对象存储都各自独立成层每一层都解决一类通用的重复问题。AI agent 系统也在经历同样的分层过程。模型负责推理编排框架负责流程工具层负责和能力系统交互而记忆层负责状态和上下文的持久化。Memento 这类项目正是在往“记忆层”这个基础设施角色上走。你可以在自己的项目里提前实践这件事但不一定非要等到团队规模很大才动手。最少只需要两步第一选定一个记忆存储方案第二把它封装成 MCP server暴露标准的读、写、检索工具。然后用两个 agent 跑一轮“写入、读取、更新、重启后再读取”的完整链路确认它能稳定工作。先跑通再治理最后再扩展到更多 agent。别一开始就想着把所有状态都放进去那也是过度设计。真正成熟的路径往往是先让一个关键决策被记住让另一个 agent 能查到然后慢慢才长出完整的记忆体系。多 agent 系统最需要的也许不是更聪明的模型而是一块让大家记得住、查得到、能协作的白板。Memento 正好站在这个方向上。