博客三个Agent各自为战，客服系统一周被投诉23次。本文拆解RAG作为共享记忆层的工程落地——选择性共享、双索引、冲突消解，附真实取舍。
问题的根因不是模型能力。是三条链路的 RAG 记忆互相隔离——保单节点不知道理赔节点刚刚核实过这份保单的状态，推荐节点也不知道客户正在处理理赔。它们各自读各自的文档，各自给出「在自己视角下正确」的答案。
本文是 AIcoding 商业化实战系列的第三篇。第一篇聊了 AI 编码在 Next.js 项目里怎么压缩 40% 开发周期，第二篇拆了 RAG 系统从 PoC 到生产的检索精度四层优化。本篇接续第二篇结尾抛出的问题：当 RAG 作为智能体的记忆层，多个执行单元如何共享和更新知识——不是概念科普，是工程落地里真正要做的取舍。
当前业界在记忆共享上大致分三条路线。三条路我们都做过生产环境的试错，下面附上每种方案的判断标准。
每个执行单元独立维护自己的 RAG 索引，不做任何跨节点记忆交换。这是大多数 PoC 阶段的默认选择——实现简单，不需要额外的通信层。我们那个金融客服项目的 1.0 版本就是这个架构。
适用条件：各节点的任务边界严格不重叠（例如一个只管代码审查、一个只管 CI 日志分析），且用户不会在同一个会话里横跨多个业务域。
踩坑信号：一旦用户在一次对话里切换业务域（从「查保单」切到「查理赔」再切到「问产品」），独立架构的体验会迅速崩坏。我们那个金融项目，上线第一周 23 起投诉中 18 起因跨模块信息不一致。
所有节点把每一步的输出全量写进共享短时记忆池，每次推理前拉取全部同级的最近输出作为上下文。这解决了信息孤岛，但引入了两个新坑：
2026 年 2 月，Joseph Fioresi 等人发表了 Learning to Share（LTS）方案（arXiv:2602.05965），核心思路：全局 memory bank + 轻量级 controller，由控制器决定哪些中间步骤值得写入共享记忆、哪些只留在本地。
LTS 的决策器通过逐步强化学习训练——不是预定义规则（「理赔状态变化就共享」），而是让模型从实际协作效果中学习「什么样的信息对跨节点协作有价值」。在 AssistantBench 和 GAIA 基准上，LTS 保持或提升了任务表现，同时显著降低了总体运行时间。
工程落地时的简化版本：生产环境不一定需要完整的 RL 控制器。我们目前在用的折中方案：
这个简化版在我们的金融客服项目 2.0 中，把跨模块信息冲突投诉从 18 起/周压到 2 起/周，token 消耗比全量广播降低约 60%。
| 模式 | 跨节点一致性 | 延迟开销 | 实现复杂度 | 适用规模 |
|---|---|---|---|---|
| 各自独立 | 差（易冲突） | 低 | 低 | 2-3 个节点，任务边界清晰 |
| 全量广播 | 好 | 高（token 线性增长） | 中 | 3-5 个节点，交互频率低 |
| 选择性共享 | 好 | 中（controller overhead ~50ms） | 高 | 5+ 节点，高交互频率 |
选定了共享策略后，真正的工程挑战在怎么把 RAG 从一个「单节点的检索工具」变成「多节点的共享记忆层」。我们把实现拆成四层，每层都有具体取舍。
共享记忆层的文档来源远比单节点 RAG 复杂：有各节点的私有索引、有交互日志、有外部知识库更新、有人工修正记录。不同来源的文档混在一起检索会严重稀释精度。
我们的做法：在共享记忆层强制要求每条记录至少携带三个元数据字段——
source_agent：信息由哪个执行单元产出confidence：产出时的置信度valid_until：信息的有效期（保单状态、价格等有时效性的数据必须标注）查询共享记忆层时，先按元数据做权限和时效性过滤，再做语义检索。这一步和 RAG 从 PoC 到生产中提到的「分块+元数据过滤」思路一致，但多了节点维度的隔离。
不能把所有知识都灌进一个统一的向量库——这会让检索精度崩盘，因为不同业务域的语义空间差异很大。我们的方案是双索引：
推理时的检索顺序：先查共享索引（看其他节点是否已有相关事实）→ 再查私有索引（补充领域细节）→ 合并去重后送入 LLM。共享索引的检索延迟控制在 60ms 以内（本地 BGE-M3），对整体交互延迟影响可忽略。
这是整个共享记忆层最难做对的一层：什么信息该写入、什么不该写。我们在 3 个月里迭代了 4 版：
真实取舍：v3 对大多数项目已够用。v4 适合节点数量 > 10 且交互模式复杂多变的场景。如果只有 3-5 个执行单元，不值得投入 RL 训练成本。
共享记忆层最终要回答：节点 A 在推理时，怎么高效获取其他节点留下的相关信息，又不撑爆上下文窗口。
我们的接口设计：
这个「摘要先行、按需深挖」的模式，把共享记忆带来的上下文增量控制在平均 180 token/轮，推理窗口不会失控。
共享记忆一旦有多个写入者，「同一个事实有多个版本」就是必然事件。我们在金融项目里至少遇到三种典型冲突：
冲突 A：时间窗口竞争。 节点 A 在 T1 时刻查到「保单状态=有效」并写入共享记忆。节点 B 在 T2 时刻处理了该保单的理赔结案，写入「保单状态=已结案」。节点 C 在 T3 时刻查询共享记忆，拿到两个版本。
处理方式：写入时附带 HLC（Hybrid Logical Clock）时间戳，查询时对同一实体的多条记录按「时效性优先、HLC 次之」排序——valid_until 在未来的优先于已过期；同等时效下取最新 HLC。
冲突 B：置信度矛盾。 模块 A 以置信度 0.92 写入「客户属于高风险等级」，模块 B 以置信度 0.88 写入「客户属于中风险等级」。二者基于不同数据源（A 看历史理赔频率，B 看近期缴费记录）得出不同结论。
处理方式：不自动覆盖。在共享记忆摘要里同时呈现两条记录，标注置信度和数据源。让调用方自行判断——或者引入专门仲裁节点，但对大多数项目是过度工程。
冲突 C：知识过期未清理。 共享记忆里有一批「促销活动进行中」的记录，活动结束后没人主动标记失效。模块反复引用过期信息，直到用户投诉。
处理方式：所有写入共享记忆的记录必须带 valid_until。一个定时任务每天凌晨扫描共享索引，自动标记过期记录。这套机制上线后，过期信息导致的幻觉率从 11% 降到 3%。
共享记忆不是银弹。我们在两个场景上踩了坑后，开始主动建议客户「这个项目不需要共享记忆」。
教训一：任务耦合度低的系统，共享记忆是过度工程。 我们帮一个零售客户搭了多模块商品管理系统：定价模块、库存模块、营销模块。三个模块各管各的数据表，业务流程上定价只依赖库存数据（走 API 直连），营销只读定价结果（也走 API）。加共享记忆层后，不仅没有信息增益，反而因为准入控制器的误判（把定价模块的中间计算也写进了共享索引）引入了噪声。最终回退到独立模式，稳定性反而提升了。
经验：如果模块间的信息依赖可以通过明确的 API 调用闭合，就不要引入共享记忆层。共享记忆解决的是「无法预判哪个模块在什么时候需要什么信息」的开放协作场景。
教训二：共享记忆不等于「把所有知识灌进一个库」。 我们在一个政务项目上犯过这个错：把政策文档、办事流程、案例库全部灌进同一个共享索引，3 个模块共用。检索精度比单模块时还差——政策模块检索到的 top-5 里有 3 条是案例模块的领域内容。根因是不同领域的知识类型对应的 embedding 语义空间差异太大，混在一起检索不如各自维护私有索引。
正解：共享索引只存跨模块的事实状态和决策摘要，领域知识仍放在私有索引里。AnchorRAG（arXiv:2509.01238）的方案——predictor 识别候选锚点 + 多个 retriever 并行多跳探索 + supervisor 合成——本质上也是保持各模块的检索独立性，只在最终合成层做协作。
传统 RAG 是「一个模块查一个知识库」，文档 → 索引 → 检索 → 生成。共享记忆层多了一个维度：模块 A 的输出可以变成模块 B 的检索对象。技术栈上多了一层 controller 做准入判断、多了共享索引、多了冲突解决机制。但底层检索链路（embedding、向量库、重排序）和传统 RAG 完全一致。
论文里的完整 RL controller 训练成本较高——需积累足够的协作日志做训练数据。推荐分阶段落地：先用规则+阈值版本（v3）跑起来，积累 4-6 周生产日志后，再用这些日志微调轻量级分类器（v4）。规则版本的产出质量本身也够用——v3 把冲突投诉从 18 降到 2 就是证据。
取决于索引规模和检索 QPS。我们的基准：共享索引 1.2 万条、5 个模块、QPS 约 120 时，单 Chroma 实例 + BGE-M3 的 P99 延迟 180ms，完全可控。索引超 50 万条或 QPS > 500 时，建议加 Redis 缓存层（缓存热点查询的 top-5 结果，命中率通常 40-60%）或拆分读写分离的 Chroma 集群。详见 多智能体生产部署实战 的架构部分。
技术上可以共用——在同一 Chroma collection 里用 metadata 区分。但我们建议物理隔离，三个原因：1) 共享索引写入频率高、数据量小，适合更激进的索引策略；2) 共享索引的检索 pattern（短查询、高时效性要求）和私有索引不同，分开可各自优化；3) 出问题时隔离排查成本低。
共享记忆层是存储+检索层，LangGraph / CrewAI 是编排层，两者互补。在 LangGraph 的 StateGraph 中，每个 node 输入阶段注入共享记忆查询，输出阶段将高价值输出写入共享索引。CrewAI 同理——在 Task 的 context 参数里拼接共享记忆摘要。框架不绑定存储方案，共享记忆层对编排层是透明的。
把多智能体系统的记忆从「各自为政」升级到「有选择地共享」，核心不是技术堆叠，是想清楚三件事：什么值得共享（controller）、怎么高效检索（双索引+元数据）、出错了怎么兜底（冲突消解+过期清理）。
这套框架已经在一家金融客户和一家零售客户的智能体系统上跑过生产。如果你正在搭多智能体系统，或者现有单节点 RAG 准备扩展到多节点协作——联系我们，我们可以在项目初期帮你做一轮架构评审，省掉那 3 个月的踩坑时间。