1. 项目概述如果你正在构建一个多智能体Multi-Agent系统比如用 OpenClaw 来协调多个 AI 助手协同工作那么“记忆管理”绝对是你迟早要面对的头号难题。每个智能体都有自己的“小本本”私有记忆记录着它自己的任务和上下文。但当它们需要为一个共同的项目或在一个长期存在的团队里协作时问题就来了信息散落在各处今天在 A 的聊天里做的决定明天 B 就忘了或者更糟所有聊天记录都被一股脑儿地塞进一个共享的“垃圾堆”里想找点有用的信息如同大海捞针。openclaw-shared-memory-manager这个项目就是为了解决这个痛点而生的。它不是另一个“存储一切”的记忆插件而是一个专为调度者通常是main智能体设计的“共享记忆治理”技能。它的核心思想很简单保持私有记忆的私有性同时为团队建立一个权威、精简、安全的共享记忆桥梁。你可以把它想象成团队的项目管理白板或知识库只记录那些真正需要跨智能体、跨会话、长期有效的关键信息而不是把所有聊天记录都贴上去。这个方案特别适合那些已经在使用 OpenClaw 进行多智能体协作并且可能已经集成了像 Ollama 这样的本地嵌入模型来增强记忆检索能力的团队。它不要求你推翻现有的架构而是优雅地在其之上增加一个治理层让团队的长期记忆变得清晰、可用且安全。2. 核心设计理念与架构解析2.1 为什么需要“记忆治理”在多智能体环境中记忆天然会朝着两个方向分裂私有记忆每个专家智能体如代码专家、文档专家都需要自己持久化的私有记忆来记住它专长领域内的任务细节、用户偏好和上下文。这部分记忆是高度专业化和隔离的。共享记忆整个团队需要一个稳定、统一的共享记忆桥梁用于记录项目目标、关键决策、任务分配状态、跨聊天的连续性信息等。这部分记忆是团队协作的基石。大多数现有的记忆方案往往只做好了其中一边而忽视了另一边过度碎片化所有记忆都变成了智能体的私有笔记团队没有统一的“真相来源”Single Source of Truth。当需要回顾项目全貌或交接工作时信息整合成本极高。过度共享化所有对话记录都被不加区分地转储到一个共享的向量数据库或文档中。这导致了“记忆噪音”——大量无关紧要的闲聊、临时讨论淹没了真正重要的决策和事实使得检索效率低下甚至可能泄露敏感信息。openclaw-shared-memory-manager的设计目标就是避免这两种失效模式。它引入了一个“调度者”角色由这个角色通常是main智能体来负责审核、提炼和写入共享记忆确保进入共享区域的信息是经过“治理”的、权威的、精简的。2.2 推荐的运行模型与架构项目的核心架构建议遵循以下模型这能清晰地划分职责边界调度者Dispatcher中心化治理由main智能体或其他指定的调度者独家负责共享记忆的创建、更新和维护。它扮演“信息守门人”的角色。专家智能体保持私有记忆每个专家智能体Specialist Agent继续在其自己的工作空间内维护自己的私有、持久化记忆。这部分记忆不受共享记忆管理器的影响。根工作空间存储权威记忆在 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 环境准备与依赖确认在开始之前请确保你的环境满足以下条件依赖项状态说明与检查点OpenClaw 工作空间必需确认你的 OpenClaw 可以正常加载技能Skill。通常意味着你的工作空间结构支持skills/目录。可写的根工作空间必需确保你有权限在 OpenClaw 工作空间的根目录创建和写入memory/文件夹及其子文件。调度者智能体必需通常是main智能体。你需要能在与该智能体的交互中触发和使用此技能。memorySearch技能强烈推荐这是 OpenClaw 生态中常用的本地记忆检索模块。共享记忆建立后需要通过它来查询。确保它已安装并配置。Ollama mxbai-embed-large推荐这是为memorySearch提供高质量本地嵌入向量的黄金组合。mxbai-embed-large模型在语义表征上表现优异。你需要先安装 Ollama然后拉取该模型ollama pull mxbai-embed-large。专家智能体的私有记忆推荐现有的专家智能体应已配置其私有记忆如各自的MEMORY.md。本技能将与它们共存而非替代。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 元数据可以只复制必要的文件从仓库中复制SKILL.md文件。复制agents/目录。复制references/目录内含重要模板。复制examples/目录参考示例。将这些内容放入你工作空间的skills/shared-memory-manager/目录中。安装后验证 启动你的 OpenClaw检查技能是否被成功加载。通常在智能体的技能列表中应该能看到与“shared-memory”或“memory governance”相关的描述。你可以尝试与main智能体对话输入类似“帮助”或“列出技能”的指令来确认。3.3 初始化你的共享记忆桥梁安装技能后你需要手动或通过调度者智能体初始化共享记忆的目录结构。这是最关键的一步。创建根目录在你的 OpenClaw 工作空间根目录下创建memory/文件夹。创建子目录在memory/下创建groups/、projects/、system/三个子文件夹。初始化索引和策略文件将技能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 第三步写入前先读取桥梁在创建或更新任何共享记忆文件之前必须先读取相关的现有文件。这是避免信息覆盖和冲突的关键。检查索引查看GROUP_INDEX.md或PROJECT_INDEX.md确认目标组或项目是否已有记录。读取现有笔记如果已有记录则读取对应的group-slug.md或project-slug.md文件了解当前状态。回顾系统策略快速浏览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)openclaw-shared-memory-manager私有记忆专家智能体各自的任务细节、专业上下文、临时备忘各专家智能体智能体原有的记忆机制如各自的MEMORY.md检索层基于嵌入向量的语义搜索系统memorySearchOllama(或其他嵌入模型)实操中的共存你的“代码专家”智能体继续在其私有记忆里记录它写某个函数时遇到的特定库版本问题。同时main智能体将“项目决定升级到库版本v2.0”这个决策结果写入共享的project-alpha.md。当未来“测试专家”需要了解项目技术栈时它通过memorySearch查询共享桥梁立刻知道当前使用的是v2.0而无需去翻看代码专家的私有聊天记录。5.2 安全迁移指南从零开始渐进式整合如果你已经有一个积累了杂乱记忆的系统请遵循以下低风险迁移步骤完整备份首先备份你整个工作空间的memory/目录或所有智能体的记忆文件。这是最重要的安全网。在新工作空间或快照中测试强烈建议在一个全新的 OpenClaw 工作空间或者当前工作空间的一个完整副本中先安装和测试本技能。熟悉其工作流程。仅新增不修改在初期只使用本技能为新出现的群组和项目创建权威笔记。绝对不要用它去自动重写或整理已有的旧记忆文件。手动审查与提炼定期例如每周手动回顾重要的旧聊天或记忆文件。对于其中真正具有长期共享价值的信息由你或指导main智能体手动地、精炼地总结到对应的共享笔记中。逐步停用旧模式当某个项目或群组的共享笔记已经足够完善成为大家查询的首要来源时可以停止向旧的、分散的记忆文件中写入该主题的长期信息。但旧的私有记忆文件可以保留作为历史档案。迁移禁忌切忌在第一天就运行一个“自动整理所有记忆”的脚本。切忌批量删除旧的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检索不到新创建的共享笔记可能原因1memorySearch的索引未更新。排查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中的规则是否足够严格。检查调度者的判断逻辑。解决收紧策略重新定义“关键决策”和“持久性事实”的标准。例如只有涉及多人确认、影响后续工作的结论才算。人工审核在初期设置为“建议写入”模式让调度者生成更新建议由用户确认后再实际写入文件。定期维护将“记忆清理”设为定期任务。每月回顾一次共享笔记归档或删除已完结项目/群组的笔记合并重复条目。6.4 问题Ollama 服务未运行或mxbai-embed-large模型未加载导致memorySearch失效可能原因1Ollama 服务没有启动。排查在命令行运行ollama list如果报错或没有输出说明服务未运行。解决启动 Ollama 服务。在 Linux/macOS 上可能是systemctl start ollama或ollama serve。在 Windows 上检查 Ollama 是否在后台运行。可能原因2所需嵌入模型未拉取。排查运行ollama list查看列表中是否有mxbai-embed-large。解决如果没有运行ollama pull mxbai-embed-large进行拉取。可能原因3memorySearch配置中指定的模型名称不正确。排查检查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智能体之间的协作更像一个真正有章法、可积累的团队。