OpenClaw多智能体系统共享记忆治理：构建权威、精简、安全的团队知识桥梁

1. 项目概述

如果你正在构建一个多智能体（Multi-Agent）系统，比如用 OpenClaw 来协调多个 AI 助手协同工作，那么“记忆管理”绝对是你迟早要面对的头号难题。每个智能体都有自己的“小本本”（私有记忆），记录着它自己的任务和上下文。但当它们需要为一个共同的项目或在一个长期存在的团队里协作时，问题就来了：信息散落在各处，今天在 A 的聊天里做的决定，明天 B 就忘了；或者更糟，所有聊天记录都被一股脑儿地塞进一个共享的“垃圾堆”里，想找点有用的信息如同大海捞针。

openclaw-shared-memory-manager这个项目，就是为了解决这个痛点而生的。它不是另一个“存储一切”的记忆插件，而是一个专为调度者（通常是main智能体）设计的“共享记忆治理”技能。它的核心思想很简单：保持私有记忆的私有性，同时为团队建立一个权威、精简、安全的共享记忆桥梁。你可以把它想象成团队的项目管理白板或知识库，只记录那些真正需要跨智能体、跨会话、长期有效的关键信息，而不是把所有聊天记录都贴上去。

这个方案特别适合那些已经在使用 OpenClaw 进行多智能体协作，并且可能已经集成了像 Ollama 这样的本地嵌入模型来增强记忆检索能力的团队。它不要求你推翻现有的架构，而是优雅地在其之上增加一个治理层，让团队的长期记忆变得清晰、可用且安全。

2. 核心设计理念与架构解析

2.1 为什么需要“记忆治理”？

在多智能体环境中，记忆天然会朝着两个方向分裂：

1. 私有记忆：每个专家智能体（如代码专家、文档专家）都需要自己持久化的私有记忆，来记住它专长领域内的任务细节、用户偏好和上下文。这部分记忆是高度专业化和隔离的。
2. 共享记忆：整个团队需要一个稳定、统一的共享记忆桥梁，用于记录项目目标、关键决策、任务分配状态、跨聊天的连续性信息等。这部分记忆是团队协作的基石。

大多数现有的记忆方案，往往只做好了其中一边，而忽视了另一边：

• 过度碎片化：所有记忆都变成了智能体的私有笔记，团队没有统一的“真相来源”（Single Source of Truth）。当需要回顾项目全貌或交接工作时，信息整合成本极高。
• 过度共享化：所有对话记录都被不加区分地转储到一个共享的向量数据库或文档中。这导致了“记忆噪音”——大量无关紧要的闲聊、临时讨论淹没了真正重要的决策和事实，使得检索效率低下，甚至可能泄露敏感信息。

openclaw-shared-memory-manager的设计目标就是避免这两种失效模式。它引入了一个“调度者”角色，由这个角色（通常是main智能体）来负责审核、提炼和写入共享记忆，确保进入共享区域的信息是经过“治理”的、权威的、精简的。

2.2 推荐的运行模型与架构

项目的核心架构建议遵循以下模型，这能清晰地划分职责边界：

1. 调度者（Dispatcher）中心化治理：由main智能体（或其他指定的调度者）独家负责共享记忆的创建、更新和维护。它扮演“信息守门人”的角色。
2. 专家智能体保持私有记忆：每个专家智能体（Specialist Agent）继续在其自己的工作空间内维护自己的私有、持久化记忆。这部分记忆不受共享记忆管理器的影响。
3. 根工作空间存储权威记忆：在 OpenClaw 工作空间的根目录下，建立一个memory/目录，专门用于存放经过治理的、权威的共享记忆。这个目录就是团队的“共享记忆桥梁”。

具体的目录结构设计如下，这种结构清晰地将共享记忆按用途分类：

你的工作空间根目录/ ├── ... (其他目录) └── memory/ # 共享记忆根目录 ├── groups/ # 用于长期协作组 │ ├── GROUP_INDEX.md # 所有协作组的索引文件 │ └── <group-slug>.md # 单个协作组的权威笔记（例如 `backend-team.md`） ├── projects/ # 用于具体项目 │ ├── PROJECT_INDEX.md # 所有项目的索引文件 │ └── <project-slug>.md # 单个项目的权威笔记（例如 `user-auth-refactor.md`） └── system/ # 用于系统级、跨会话的策略和协议 ├── cross-chat-memory-policy.md # 跨聊天记忆策略 ├── dispatch-and-delegation-protocol.md # 任务分发与委托协议 └── memory-safety-rules.md # 记忆安全规则

架构流程图示意： 用户与调度者（main）交互。调度者负责与各个专家智能体（A, B, C）通信，并管理共享记忆区域。共享记忆区域分为三部分：groups/、projects/、system/。这三个部分都连接到memorySearch（记忆检索）模块。同时，每个专家智能体都连接到自己私有的记忆存储。

这个架构的精妙之处在于职责分离：

• 调度者：负责判断“什么信息值得进入共享记忆”以及“如何组织这些信息”。
• 共享记忆桥梁：作为唯一的事实来源，存储结构化的、精炼的团队知识。
• 检索层：memorySearch或其他检索工具，基于共享记忆桥梁的内容进行快速查找，无需再去杂乱的历史记录里翻找。
• 嵌入模型：如 Ollama +mxbai-embed-large，为检索层提供文本的向量化表示，但本身不参与记忆的治理决策。

注意：这个技能本身不直接调用Ollama 或任何嵌入模型。它专注于“记忆治理”的逻辑层，而将“记忆检索”的底层能力（如生成嵌入向量、相似度搜索）交给像memorySearch这样的专用模块。这种分离使得系统更模块化，你可以更换嵌入模型或检索后端，而不影响上层的治理规则。

3. 快速上手与部署指南

3.1 环境准备与依赖确认

在开始之前，请确保你的环境满足以下条件：

3.2 安装共享记忆管理器技能

你有三种方式将技能集成到你的工作空间：

方案A：使用 Git 克隆（推荐）这是保持更新的最佳方式。在你的 OpenClaw 工作空间目录下执行：

# 假设你的工作空间路径是 /path/to/your/openclaw-workspace cd /path/to/your/openclaw-workspace git clone https://github.com/KongDS-alien/openclaw-shared-memory-manager.git skills/shared-memory-manager

这将在skills/目录下创建shared-memory-manager文件夹，包含所有技能文件。

方案B：下载 ZIP 包如果你不想使用 Git，可以直接从 GitHub 仓库页面下载 ZIP 压缩包，解压后，将整个文件夹放置到工作空间/skills/shared-memory-manager/路径下。

方案C：仅复制核心技能文件（最精简）如果你不希望工作空间里包含 Git 元数据，可以只复制必要的文件：

1. 从仓库中复制SKILL.md文件。
2. 复制agents/目录。
3. 复制references/目录（内含重要模板）。
4. 复制examples/目录（参考示例）。
5. 将这些内容放入你工作空间的skills/shared-memory-manager/目录中。

安装后验证： 启动你的 OpenClaw，检查技能是否被成功加载。通常，在智能体的技能列表中应该能看到与“shared-memory”或“memory governance”相关的描述。你可以尝试与main智能体对话，输入类似“帮助”或“列出技能”的指令来确认。

3.3 初始化你的共享记忆桥梁

安装技能后，你需要手动或通过调度者智能体初始化共享记忆的目录结构。这是最关键的一步。

1. 创建根目录：在你的 OpenClaw 工作空间根目录下，创建memory/文件夹。
2. 创建子目录：在memory/下，创建groups/、projects/、system/三个子文件夹。
3. 初始化索引和策略文件：将技能references/目录下的模板文件复制过来，作为初始框架。
   • 将references/group-note-template.md的内容复制到memory/groups/GROUP_INDEX.md，作为协作组索引的起点。
   • 将references/project-note-template.md的内容复制到memory/projects/PROJECT_INDEX.md，作为项目索引的起点。
   • 将references/system-files-template.md的内容分别复制到memory/system/下的三个策略文件中。

实操心得：我强烈建议在初始化后，花点时间根据你团队的实际协作习惯，修改system/下的策略文件。例如，在cross-chat-memory-policy.md中定义“什么样的决策算关键决策”、“项目状态有哪些”，在dispatch-and-delegation-protocol.md中明确任务分发的格式和状态更新流程。这些前期定义能极大提升后续记忆治理的一致性和自动化程度。

4. 核心工作流程与实操要点

技能的核心是一套由调度者智能体执行的工作流程。下面我们拆解每一步，并附上具体的操作示例和注意事项。

4.1 第一步：识别共享范围事件

调度者需要被训练或配置成在特定事件触发时，调用记忆治理技能。这些事件包括：

• 新增长期协作组：例如，用户创建了一个名为“后端架构评审”的群组，并计划长期使用。
• 启动跨会话项目：一个项目（如“用户认证系统重构”）的讨论可能始于私聊，然后扩展到群组，并涉及多个智能体。
• 任务分发与委托：调度者将一项任务（如“编写API文档”）明确委托给某个专家智能体。
• 发现持久性事实：某个聊天中产生的信息（如“客户XX偏好深色模式”）被确认对其他智能体或未来会话也重要。
• 需要记忆清理或审查：发现现有的共享记忆文件变得冗杂或包含过时信息。

示例： 用户在与main的私聊中说：“我们来启动‘项目Alpha’，目标是下个月上线。我会拉上‘代码专家’和‘测试专家’一起在‘项目Alpha群’里讨论。” 这时，main应识别出：1) 一个新项目（项目Alpha）被创建；2) 一个与之关联的长期群组（项目Alpha群）被提及；3) 涉及多个专家智能体。这构成了一个典型的“共享范围事件”。

4.2 第二步：对当前会话场景进行分类

调度者需要判断当前对话发生的“场景”，以决定适用哪种记忆模板：

• 协调群组：用于长期团队协作、日常同步的群聊。
• 项目群组：为某个特定项目设立的，有明确起止时间和目标的群聊。
• 纯私聊：仅涉及用户和单个智能体的对话。通常，只有产生跨智能体价值的决策才考虑升级到共享记忆。

操作要点：这个分类可以基于聊天频道的名称、用户指令或预设的规则来自动或半自动完成。例如，所有以“项目-”开头的群组名自动归类为“项目群组”。

4.3 第三步：写入前先读取桥梁

在创建或更新任何共享记忆文件之前，必须先读取相关的现有文件。这是避免信息覆盖和冲突的关键。

1. 检查索引：查看GROUP_INDEX.md或PROJECT_INDEX.md，确认目标组或项目是否已有记录。
2. 读取现有笔记：如果已有记录，则读取对应的<group-slug>.md或<project-slug>.md文件，了解当前状态。
3. 回顾系统策略：快速浏览system/下的策略文件，确保本次更新符合既定规则。

注意事项：这一步是“治理”的体现。调度者不是简单地追加文本，而是基于现有上下文进行信息融合与精炼。例如，如果项目笔记中已有“状态：进行中”，而新信息是“已完成模块A”，那么更新后应为“状态：进行中（模块A已完成）”，而不是简单地覆盖或新增一行。

4.4 第四步：创建或更新权威笔记

根据分类，创建或更新对应的 Markdown 文件。文件命名应使用“slug”（URL友好格式），如将“项目Alpha”转化为project-alpha.md。

文件内容结构示例（基于模板）： 以创建一个项目笔记memory/projects/project-alpha.md为例：

# 项目：项目Alpha * **创建时间**：2023-10-27 * **状态**：进行中 * **负责人**：用户（产品），main（协调） * **参与专家**：代码专家，测试专家 * **关联群组**：项目Alpha群 ## 目标 在下个月上线项目Alpha的第一阶段，实现核心功能X。 ## 关键决策记录 1. **2023-10-27**：决定采用技术栈Y，因其在现有架构中兼容性更好。 2. **2023-10-28**：UI设计定稿，确认使用深色模式作为默认主题。 ## 当前任务与状态 | 任务 | 负责人 | 状态 | 截止日期 | 备注 | | :--- | :--- | :--- | :--- | :--- | | 设计数据库Schema | 代码专家 | 已完成 | 2023-10-26 | - | | 开发核心API模块 | 代码专家 | 进行中 | 2023-11-05 | 正在处理用户认证部分 | | 编写单元测试用例 | 测试专家 | 待开始 | 2023-11-10 | 等待API模块初版完成 | ## 已知阻碍 * 第三方服务Z的API文档不全，可能影响集成进度。 ## 下一步行动 1. 代码专家本周内完成用户认证API。 2. main 负责在周三同步进度给所有相关方。

4.5 第五步：仅同步持久性事实

这是记忆治理的核心原则：只写入那些可能在未来跨智能体、跨聊天、跨会话中仍然重要的信息。

应该写入的内容：

• 目的与范围：项目/群组为什么存在，边界在哪里。
• 关键决策：达成的共识、选择的技术方案、确定的设计。
• 所有权：谁负责什么。
• 状态与进展：当前完成度、里程碑达成情况。
• 阻碍与风险：影响进度的关键问题。
• 下一步行动：明确的、可执行的任务项。
• 影响多智能体的用户规则：例如“在所有回复中，对客户XX使用尊称”。

不应写入的内容：

• 完整的聊天记录：严禁直接转储。
• 临时性的讨论过程：例如“我们是不是可以考虑A方案？B方案呢？”这种探索性对话。
• 无关紧要的社交寒暄。
• 任何形式的密钥、密码、令牌等敏感信息。

4.6 第六步：保持委托关系显式化

当任务涉及多个智能体时，在项目笔记中清晰地记录委托关系。使用固定的字段来描述，如“负责人”、“期望产出”、“状态”、“阻碍”、“下一步”。这为调度者跟踪任务状态提供了结构化数据。

4.7 第七步：返回最小化的更新摘要

操作完成后，调度者应向用户（或其他请求方）报告一个简洁的摘要：

• 动作：创建了/memory/projects/project-alpha.md。
• 内容概要：更新了项目目标、记录了2项关键决策、明确了3个任务的负责人和状态。
• 安全排除：本次未将聊天中的技术细节讨论A和B写入，因其属于过程性探索，已由相关专家记录在私有记忆中。

这个闭环反馈让整个过程透明、可信。

5. 与现有记忆方案的共存与安全迁移

5.1 共存策略：分层治理

这个技能的设计初衷是增强而非取代。它与现有记忆的关系应该是这样的：

实操中的共存：

• 你的“代码专家”智能体继续在其私有记忆里记录它写某个函数时遇到的特定库版本问题。
• 同时，main智能体将“项目决定升级到库版本v2.0”这个决策结果写入共享的project-alpha.md。
• 当未来“测试专家”需要了解项目技术栈时，它通过memorySearch查询共享桥梁，立刻知道当前使用的是v2.0，而无需去翻看代码专家的私有聊天记录。

5.2 安全迁移指南：从零开始，渐进式整合

如果你已经有一个积累了杂乱记忆的系统，请遵循以下低风险迁移步骤：

1. 完整备份：首先，备份你整个工作空间的memory/目录（或所有智能体的记忆文件）。这是最重要的安全网。
2. 在新工作空间或快照中测试：强烈建议在一个全新的 OpenClaw 工作空间，或者当前工作空间的一个完整副本中，先安装和测试本技能。熟悉其工作流程。
3. 仅新增，不修改：在初期，只使用本技能为新出现的群组和项目创建权威笔记。绝对不要用它去自动重写或整理已有的旧记忆文件。
4. 手动审查与提炼：定期（例如每周）手动回顾重要的旧聊天或记忆文件。对于其中真正具有长期共享价值的信息，由你（或指导main智能体）手动地、精炼地总结到对应的共享笔记中。
5. 逐步停用旧模式：当某个项目或群组的共享笔记已经足够完善，成为大家查询的首要来源时，可以停止向旧的、分散的记忆文件中写入该主题的长期信息。但旧的私有记忆文件可以保留，作为历史档案。

迁移禁忌：

• 切忌在第一天就运行一个“自动整理所有记忆”的脚本。
• 切忌批量删除旧的MEMORY.md文件。
• 切忌试图将所有的历史聊天记录都导入到新系统中。迁移的目标是提炼精华，而不是搬运数据。

6. 常见问题与排查技巧实录

在实际部署和使用中，你可能会遇到以下典型问题。这里记录了我的排查思路和解决方法。

6.1 问题：调度者智能体无法正确触发或使用该技能

• 可能原因1：技能未正确加载。
  • 排查：检查skills/shared-memory-manager/目录是否存在且包含SKILL.md和agents/文件夹。检查 OpenClaw 的日志，看是否有加载错误。
  • 解决：确保目录结构正确，并重启 OpenClaw。有时需要检查技能文件的格式是否符合 OpenClaw 的解析要求。
• 可能原因2：调度者智能体的配置（如config.yaml）中没有启用或正确引用该技能。
  • 排查：查看调度者智能体的配置文件，确认skills列表或相关配置项中包含了shared-memory-manager或其标识符。
  • 解决：参照examples/目录下的配置示例，修改调度者的配置文件。
• 可能原因3：触发指令或意图不匹配。
  • 排查：技能通常通过特定的关键词或意图触发。检查SKILL.md或agents/openai.yaml中定义的触发条件。
  • 解决：调整你与调度者的对话方式，使用更明确的指令，如“请为当前对话创建共享记忆摘要”或“更新项目X的状态”。

6.2 问题：memorySearch检索不到新创建的共享笔记

• 可能原因1：memorySearch的索引未更新。
  • 排查：memorySearch通常不是实时索引文件系统的。它可能有一个扫描间隔，或者需要手动触发索引更新。
  • 解决：查阅memorySearch的文档，找到更新索引的命令或配置。例如，可能需要运行一个update-index命令，或者在配置中缩短scan_interval。
• 可能原因2：索引路径未包含新的memory/目录。
  • 排查：检查memorySearch的配置文件，看其index_paths或directories_to_watch是否包含了你的工作空间根目录下的memory/文件夹。
  • 解决：将memory/目录添加到memorySearch的监控/索引路径列表中。
• 可能原因3：文件格式或编码问题。
  • 排查：确保创建的.md文件是 UTF-8 编码，并且内容是可读的文本。有时文件权限问题也可能导致无法读取。
  • 解决：用文本编辑器打开文件确认内容，并检查文件读写权限。

6.3 问题：共享笔记内容迅速变得冗杂，违背了“精简”原则

• 可能原因：调度者被过度触发，或者写入规则太宽松，将过程性讨论、临时想法都写了进去。
  • 排查：回顾system/cross-chat-memory-policy.md中的规则是否足够严格。检查调度者的判断逻辑。
  • 解决：
    1. 收紧策略：重新定义“关键决策”和“持久性事实”的标准。例如，只有涉及多人确认、影响后续工作的结论才算。
    2. 人工审核：在初期，设置为“建议写入”模式，让调度者生成更新建议，由用户确认后再实际写入文件。
    3. 定期维护：将“记忆清理”设为定期任务。每月回顾一次共享笔记，归档或删除已完结项目/群组的笔记，合并重复条目。

6.4 问题：Ollama 服务未运行或mxbai-embed-large模型未加载，导致memorySearch失效

• 可能原因1：Ollama 服务没有启动。
  • 排查：在命令行运行ollama list，如果报错或没有输出，说明服务未运行。
  • 解决：启动 Ollama 服务。在 Linux/macOS 上可能是systemctl start ollama或ollama serve。在 Windows 上检查 Ollama 是否在后台运行。
• 可能原因2：所需嵌入模型未拉取。
  • 排查：运行ollama list，查看列表中是否有mxbai-embed-large。
  • 解决：如果没有，运行ollama pull mxbai-embed-large进行拉取。
• 可能原因3：memorySearch配置中指定的模型名称不正确。
  • 排查：检查memorySearch的配置文件，确认embedding_model或类似配置项的值是否为mxbai-embed-large（或正确的模型标识符）。
  • 解决：修正配置文件中的模型名称，并重启memorySearch服务。

6.5 性能与扩展性考量

• 笔记数量增长：当共享笔记达到数百个时，纯文件系统的检索效率可能会下降。此时，memorySearch结合向量检索的优势就体现出来了。确保你的memorySearch配置了合适的索引机制。
• 多用户/多团队：当前设计侧重于单个调度者管理的单团队场景。如果是多团队，可以考虑为每个团队建立独立的memory/子目录结构（如memory/team-a/,memory/team-b/），并配置不同的调度者或技能实例来管理。这需要更复杂的权限和路由逻辑。
• 与云端知识库集成：虽然项目强调本地优先，但如果你需要将部分权威笔记同步到 Confluence、Notion 等云端工具，可以编写一个简单的导出脚本，定期将memory/projects/下的 Markdown 文件转换为相应格式并上传。切记，同步时务必排除system/下的内部策略文件以及任何可能包含敏感信息的字段。

这套openclaw-shared-memory-manager方案，本质上是在为你的多智能体系统引入一种“信息纪律”。它开始可能会觉得有些繁琐，但一旦习惯，你会发现团队协作的上下文清晰度、决策追溯能力和知识沉淀效率都会得到质的提升。它让AI智能体之间的协作，更像一个真正有章法、可积累的团队。