大模型智能体共享记忆机制解析：从INMS看多agent协作

最近我在调一个多智能体协作的实验性项目，内部代号就叫“模拟项目X”。项目里几个 agent 各自维护自己的上下文历史，结果负责信息收集的角色和负责内容整理的角色之间经常出现“信息不对齐”：整理方不知道收集方已经看过了哪些来源，又重复请求同一批数据。这种问题逼着我去翻“大语言模型智能体记忆”相关的论文，然后读到了 INMS。这篇论文标题是 INMS: Memory Sharing for Large Language Model based Agents，简单说就是给基于大语言模型的智能体设计一套共享记忆机制，让多个 agent 不只各存各的，还能共同读写一套结构化的记忆资源。下面是我的笔记整理，会先讲我看到的动机，再拆设计，最后聊几个我觉得没被充分讨论的点。

1. 先说说为什么需要“共享”记忆，而不是继续扩大上下文

1.1 单个 agent 的记忆系统做到什么程度了

目前大模型智能体处理记忆的方式，绕来绕去其实就三类。

第一类是把所有历史直接塞进上下文窗口，这也是最简单粗暴的做法。对话记录、工具返回结果、中间推理过程全部拼进 prompt，模型靠着长上下文能力硬读。优点是实现简单，几乎没有额外组件；缺点是成本随轮数线性增长，而且超过一定长度后，模型对早期信息的利用效率会明显下降。我自己在项目里试过把 10 轮以内的工具调用日志全放进去，效果还行，到 20 轮以上就开始出现“前面查过的结论后面又查一次”的情况。

第二类是给 agent 接一个外部向量数据库，走 RAG 路线。把对话历史切片、做 embedding、存进向量库，每次决策前检索最相关的若干条记忆。这种方式解决了上下文无限膨胀的问题，但大多数实现还是围绕“单个 agent 自己的记忆”来做，每个 agent 一套库，互不相通。

第三类是结构化的长期记忆系统，把经验沉淀成事实、偏好、任务状态等显式条目，再配合读写接口。这个方向更接近“记忆”这个词的本意，而不是单纯的上下文压缩。

这三类方案单独看都有道理，但它们默认了一个前提：agent 是独立工作的个体。一旦把场景换成多个 agent 协作，问题就立刻变味了。

1.2 多 agent 协作时，记忆问题被放大了

多 agent 场景里，最直接的浪费是重复劳动。假设甲 agent 已经检索过用户的知识库并总结出三条关键结论，乙 agent 的任务是写一份方案，它不知道甲做过什么，于是把同样的检索、同样的总结再做一遍。这不仅是 token 浪费，还可能导致两个 agent 对同一事实产生不同的理解——因为大模型生成结果本身带有随机性，就算输入相同，输出也可能有细微差别。

另一个问题是任务状态割裂。多个 agent 协同完成一个目标时，各自维护一份“当前进度”的局部视图。A 认为步骤二已经完成，B 可能还在做步骤二，因为没有共享的进度记录来对齐。这种割裂在人类团队里靠会议和文档解决，在 agent 系统里就需要一个类似“共享文档”的机制，而它的底层恰恰是记忆共享。

还有一个容易被忽视的问题是上下文冗余带来的检索污染。每个 agent 都把自己私有的历史塞进检索器，检索结果里充满大量“别的 agent 不关心”的细节。结果是每个 agent 的记忆库都不小，但有效信息密度很低。INMS 这篇论文解决的就是这个交叉地带的问题：在多个 LLM agent 之间提供统一、结构化、可控的记忆共享层，而不是让每个 agent 继续各自为政。

2. INMS 的核心设计：把记忆从“agent 内部”挪到“agent 之间”

2.1 整体分层：记忆不再是 agent 的私有变量

读这篇论文时，我比较注意的一点是它对“记忆”的抽象层次。INMS 没有简单地说“做一个共享数据库，大家都能读写”，而是把记忆从 agent 内部抽出来，分成三个逻辑层。

最底层是记忆存储层，负责保存结构化记忆项，同时提供索引和持久化能力。中间是记忆管理服务，负责写入、检索、更新、删除、冲突消解和权限控制，相当于给上层提供一个统一的记忆操作 API。最上层才是各个 agent 的推理循环，agent 不再直接拼原始对话历史，而是通过调用记忆服务来获取决策所需信息。

这个分层对我来说很关键。它意味着记忆的“生产”和“消费”被解耦了。agent 只负责产生经验和提出查询需求，具体的存储细节、去重策略、同步逻辑都由管理服务承担。从我自己的实践看，这种解耦是让多个 agent 愿意“共用”记忆的前提——如果每个 agent 都要自己维护同步逻辑，很快就会变成各写各的，共享名存实亡。

2.2 一条记忆里到底存了什么

论文里对记忆项的建模方式，我觉得可以理解成一张结构化的“经验卡片”，而不是一段原始文本。每条记忆至少包含下面这些信息：

我一开始觉得字段有点多，但仔细想想，在共享场景里这些字段几乎都不可省。比如 source_agent 看似只是个来源标记，实际上它决定了这条记忆的“权威性”：如果一条记忆来自专门负责数据核验的 agent，它在检索排序里应该比随口记录的 agent 权重更高。没有这些元数据，共享记忆只是把一堆文本堆在一起，依然无法解决“谁说的更可信”的问题。

2.3 读写路径：从推理循环到共享池

INMS 给我印象较深的是读写路径的标准化。写入不是“把对话记录丢进数据库”，而是经过提炼和结构化之后再进入共享池。大致流程是这样的：

• agent 在推理过程中产生一条值得记住的信息；
• 系统对信息做摘要或结构提取，压缩成可检索的内容；
• 计算 embedding，并附上来源、时间、范围等元数据；
• 写入共享记忆服务，必要时触发冲突检测；
• 其他 agent 在后续推理时通过查询接口按需读取。

读取侧的伪代码逻辑大概是：

def query_memory(agent_id, query, top_k=5, allowed_scopes=None): # 1. 将查询转为向量 query_vec = embed(query) # 2. 按语义相似度召回候选记忆 candidates = memory_pool.semantic_search(query_vec, k=top_k * 2) # 3. 按权限和时间衰减过滤 visible = [ m for m in candidates if m.is_accessible(agent_id, allowed_scopes) and not m.is_expired() ] # 4. 综合排序：相关性、时效性、来源可信度 ranked = rank(visible, query_vec) return ranked[:top_k]

这套流程看起来不复杂，但它把一个很模糊的问题——“agent 应该记得什么”——变成了一个可以测试的工程问题：记忆如何产生、如何存取、如何被过滤和排序。这种“协议化”的思路，比我之前项目里直接拼历史上下文的方式要清晰得多。

3. 共享记忆最麻烦的工程点：多个 agent 同时写怎么写不乱

3.1 写冲突出现的样子

共享记忆系统一旦允许所有 agent 写入，就会面对一个经典问题：多个 agent 在同一件事上产生互相矛盾的记忆。

举个例子。在一个项目协作场景里，执行 agent 完成了子任务 A，写入一条“子任务 A 已完成，结果已验证”；同时另一个监控 agent 发现 A 的验证数据还没上传，写入一条“子任务 A 仍处于待验证状态”。两条记忆对同一对象给出了相反结论。如果没有冲突处理，下游 agent 检索时就会看到自相矛盾的信息，大概率随机采信一条，这就比没有记忆更危险。

这种冲突在单 agent 系统里几乎不会出现，因为单个 agent 的记忆是顺序写入的，后写覆盖前写即可。共享场景里写入来自多个并发主体，而且各自都有合理依据，简单按时间覆盖会把有效信息丢掉。

3.2 我看到论文里的处理思路：合并、版本与仲裁

INMS 在处理冲突时不是简单地“后写覆盖前写”，而是分了几个层次。

能合并的先合并。比如两条记忆分别是“服务器 X 在 10:00 负载偏高”和“服务器 X 在 10:05 恢复正常”，它们并不是矛盾，而是可以拼成一条带时间线的状态记录。合并逻辑不一定复杂，但需要系统能识别出这两条记忆指向同一个实体、同一个属性。

合并不了的，保留版本而不是删掉旧版本。系统给记忆项加版本号，每次修改生成新版本，检索时默认取最新版本，但旧版本仍然可追溯。这个设计很像代码管理里的分支——对共享记忆来说，保留历史比覆盖历史更稳妥，因为你无法预知下游 agent 是否会依赖旧结论。

到了必须仲裁的时候，INMS 会看来源的可信度和任务目标的相关性。做过验证的 agent 写入的内容，比未经核实的 agent 写入的内容优先级更高；和当前主任务目标更相关的记忆，也会被优先保留。这组规则未必能覆盖所有情况，但它给了系统一个相对合理的默认行为。

3.3 一致性与时效性的取舍：我做项目时的补充体会

论文里对一致性的讨论我认为是比较收敛的。它不是要求所有 agent 同一时刻看到完全相同的记忆快照，而是允许短暂的不一致，再通过事件通知和异步同步来收敛。这种最终一致模型对 agent 系统是合适的，因为 agent 的决策通常不要求毫秒级一致，只要在读取关键信息前拿到最新状态就够了。

我在“模拟项目X”里用到过类似的思路：不给每个 agent 直接暴露共享对象，而是让写入方发出变更事件，订阅方收到后自行更新本地缓存。一开始我觉得多这一步很麻烦，但后面发现它反而让系统更容易调试——每个 agent 的本地视图是确定的，出问题可以查事件流，而不是在共享表里翻来翻去。

实现上有一点值得提：冲突检测的粒度不要太细。如果系统对每条记忆的每个字段都做 diff，会产生大量无效冲突。实际操作中应该选择一个“冲突单元”，比如以实体加属性为单位判断是否冲突，而不是以整条记忆为单位。这一点论文里没有细讲，但我在实践中确认是必要的。

4. 记忆不是存进去就结束：检索、遗忘与隔离

4.1 检索时怎么决定拿哪几条

共享记忆池里的记忆数量会越来越多。如果检索只是按语义相似度取 top-k，效果通常不好，因为最相似的几条未必是最有用的。INMS 的排序逻辑在我看来是三个因素的加权：语义相关性、时间衰减、来源可信度。

一个可参考的排序公式长这样：

score = ( alpha * semantic_similarity + beta * recency_decay(timestamp) + gamma * source_authority(source_agent) )

alpha、beta、gamma 是权重。相关性保证内容对口，时效性保证信息不过时，来源可信度保证“谁说的”有分量。三个权重需要根据场景调：在连续对话场景里时效性权重可以高一些，在知识总结场景里相关性权重更重要。

我自己之前做单 agent 检索时只用了相似度，导致一个明显问题：很久之前的一条旧结论因为表述和当前问题很像，被反复检索出来，但实际上它已经被新结论替代了。加入时间衰减之后，这个问题基本上消失了。所以读到 INMS 把多维排序纳入记忆服务时，我很有共鸣。

4.2 遗忘为什么是共享记忆的必需品

很多人容易忽略遗忘这件事。实际上对共享记忆系统来说，遗忘不是可选项，而是刚需。

原因是多方面的。存储成本是一方面，但更关键的是检索噪音。记忆无限增长后，任意查询都可能召回一堆低质量、过时或者和当前目标无关的条目，这不仅拖慢检索速度，还干扰模型判断。从这个角度看，遗忘是一种主动的性能优化。

我看到的遗忘策略大致有三种：总结、归档、降权。总结是把一批旧记忆压缩成一条概括性记忆，保留要点但去掉细节；归档是把冷记忆从热存储移到低频存储，不直接参与常规检索；降权是降低旧记忆的检索得分，让它只有在没有新记忆可用时才被翻出来。

这三种策略我都在项目里试过。总结的效果最好，但实现成本最高，需要额外的生成调用和一致性校验；归档最简单，配合时间戳定期迁移即可；降权最轻量，几乎不需要额外存储，但对排序权重的调参要求高。INMS 把遗忘作为记忆生命周期的正式环节，这个定位我觉得比把它当成“清理任务”要合理得多。

4.3 不同 agent 之间的信息隔离与权限

共享不意味着所有信息对所有 agent 开放。实际协作里，不同 agent 的角色不同、密级不同、职责边界也不同。一个负责内容排版的 agent 不需要知道另一个 agent 的内部调试日志，更不应该有权限修改它。

INMS 在记忆项上挂了 scope 和 access_policy，本质上就是把“谁能读、谁能写”纳入记忆的元数据。我理解这个设计是想表达：共享记忆的安全性不是靠约定，而是靠机制。写入方声明自己的记忆范围，读取方只能看到自己被允许看到的内容。

权限还有一个容易被忽略的作用：防止误改。常见的情况是 agent 检索到一条其他 agent 写的记忆，觉得“不对”，于是直接改写。如果没有写权限控制，共享池里的信息很快会被改得面目全非。我建议在实现中至少分三级：只读、可评论、可编辑。只读角色只能引用，可评论角色能附加补充信息但不能动原文，可编辑角色才有覆盖权限。这套机制不复杂，但能挡住相当一部分协作事故。

5. 评估、局限和我自己会怎么改进

5.1 论文用什么样的任务来证明有效性

INMS 论文里的实验部分，我印象中主要围绕多 agent 协作的模拟任务展开，场景包括协同写文档、多轮信息收集、软件开发中的分工执行等。这些场景的共同特征是：任务本身需要多个 agent 交换中间结果，单靠各自的私有上下文很难高效完成。

对比的基线大致有四类：完全不使用记忆；每个 agent 使用独立私有记忆；所有 agent 共享原始对话上下文的简单方案；以及 INMS 的结构化共享记忆。评估指标除了任务完成准确率之外，还关注 token 消耗、重复劳动次数、检索命中质量这些工程指标。

任务完成准确率能反映“共享记忆到底有没有用”，而 token 消耗和重复劳动次数能反映“这种有用是用多大成本换来的”。这两个维度必须放在一起看，如果准确率只提升 1% 但 token 消耗翻倍，这套机制在工程上是划不来的。

5.2 哪些结论让我觉得相对可信

读完整篇论文，我有几个结论是比较认可的。

结构化共享记忆优于简单共享上下文。把原始对话全部塞给所有 agent，信息量虽然大，但噪音也大，而且缺乏字段级控制。INMS 把记忆条目化之后，检索和权限都变得可操作，这一点和我在实际项目里的观察一致。

记忆去重和遗忘能显著降低 token 消耗。多个 agent 各自维护私有记忆时，同样的事实会被重复存储多次；共享池配合去重后，存储量和检索量都会下降。这个结论即使不看实验数据，从存储模型也能推出来。

冲突处理是共享记忆里必须显式设计的一环。论文把冲突消解分为合并、版本、仲裁三层，这种方法在实践里确实比单纯的后写覆盖要稳得多。

5.3 我认为论文没有完全展开的地方和可扩展方向

论文把主干逻辑讲清楚了，但有几块我觉得还可以继续深挖。

记忆项之间的语义级去重还做得不够细。目前常见的做法是算 embedding 相似度，相似度超过阈值就视为重复。但语义重复并不等于完全等价，两条记忆可能角度不同、粒度不同，硬合并会丢信息。更稳妥的做法是引入“面向实体的记忆融合”：先识别出记忆提到的实体和属性，再做属性级别的对齐。这个方向论文里没有展开。

另一个是隐私和安全性。共享记忆意味着信息从单个 agent 的私有空间进入了一个多方可达的存储，如果其中包含用户敏感数据，泄漏风险会放大。论文里给了访问权限的框架，但没有讨论机密数据的脱敏、审计和追溯机制。我认为这是从论文走向生产环境之前必须补上的模块。

可扩展方向上，我自己比较感兴趣的是把共享记忆和工作流状态结合。现在多数 agent 框架用独立的状态机管理任务进度，记忆系统只管信息存取，两者是割裂的。如果能把任务状态也作为记忆写进共享池，让各 agent 通过记忆来同步进度，整个协作系统的状态管理会简化很多。

在“模拟项目X”里，我基于 INMS 的思路做了一个很轻量的简化版：一张记忆表加一个向量索引，所有 agent 读写同一套接口，配合基本的权限字段和按天归档的清理策略。效果比我预想的好，至少整理资料的 agent 不再重复请求已经处理过的来源。读论文的意义对我而言就是这样——不是照搬它的实现，而是借它的思路把自己系统里的模糊点变得可以讨论、可以测试、可以改进。