核心用法
multi-agent-memory 是一套面向多Agent协作场景的项目管理与知识沉淀框架。其核心使用方式围绕"分层记忆"理念展开：每个Agent拥有独立的工作区（workspace-<agent>/），项目状态（todos、status）按项目严格隔离，而知识库（decisions、patterns、glossary）则跨项目共享。
使用者通过标准化的Bash脚本完成日常操作：项目初始化（init-project.sh）、每日状态检查（daily-check.sh）、以及遵循YYYY-MM-DD-HH-mm-{类型}-{描述}.md命名规范的文档创建。系统强制要求每个任务标注RACI责任矩阵（执行者、负责人、咨询者、知情者），并通过自动版本控制（保留最近3个版本）确保数据安全。关键工作流程包括每日启动时读取context.md（项目事实之源）、完成任务后写入结构化开发日志、以及每周由COMMANDER角色生成周报和里程碑更新。
搜索机制支持跨项目关键词检索，使得过往项目的决策记录和技术模式能被后续项目复用，形成"智慧涌现"效应。所有数据归档至archive/目录，支持完整的历史追溯。
显著优点
架构设计精妙：首次系统性地解决了"隔离vs共享"的经典矛盾——项目状态隔离保障并发安全，知识库共享促进经验复用。这种分层设计避免了传统单仓或完全隔离方案的极端化弊端。
工程实践完备：内置版本控制、时间戳命名、RACI责任模型、SMART里程碑管理等成熟工程实践，无需使用者从零搭建协作规范。纯Bash实现保证了极致的可移植性和可审计性。
知识沉淀机制：强制性的开发日志、周报、交接文档模板，配合关键词索引和跨项目搜索，有效对抗团队记忆中的"遗忘曲线"，特别适合长期运行的复杂项目。
零依赖轻量：无npm/node依赖，无外部API调用，单文件Bash脚本即可运行，部署成本极低，适合资源受限或安全敏感环境。
潜在缺点与局限性
协作摩擦成本：严格的文档命名规范、RACI标注、多目录结构维护，对小型项目或快速原型场景可能显得笨重，存在"为了规范而规范"的风险。
并发控制缺失：虽然项目状态隔离，但同一项目内多Agent同时写入status或todos时缺乏锁机制，依赖使用者的操作纪律，存在覆盖冲突可能。
搜索能力有限：基于grep的关键词检索无法满足语义搜索需求，随着知识库膨胀，信息发现效率可能下降。无内置的AI摘要或知识图谱功能。
可视化缺失：纯文本/命令行交互，无仪表盘、进度看板或甘特图等可视化工具，对偏好图形界面的用户不够友好。
版本控制简陋：仅保留3个历史版本，无分支、合并、差异对比等高级功能，复杂场景下不如Git专业。
适合的目标群体
- 多Agent协作开发团队：特别是基于Claude等AI Agent的自动化开发工作流，需要明确的上下文管理和交接机制
- 长期维护型项目：需要可追溯决策历史、技术演进路径的企业级项目
- 知识密集型组织：咨询公司、研究机构、技术中台团队，强调经验复用和最佳实践沉淀
- 安全敏感环境：无法使用云服务、需要完全本地化的项目管理方案
不适合：个人快速原型、短期一次性项目、或已有成熟Jira/Notion等工具链且迁移成本高的团队。
使用风险
数据持久化风险：虽然版本控制提供基础保护，但缺乏自动异地备份，单点故障可能导致知识库丢失。建议配合外部备份策略使用。
规范化衰减风险：长期运行中，团队成员可能逐渐跳过RACI标注、简化日志模板，导致知识沉淀质量下降。需要定期审计和文化建设。
路径权限问题：默认使用/root/.openclaw需要root权限，非root用户需修改配置，存在误配导致权限拒绝或意外写入其他目录的风险。
敏感信息泄露：模板和日志的开放性设计若被误用，可能导致密钥、客户数据被写入共享知识库。需建立数据分级和脱敏规则。
技能学习曲线：完整的规范体系需要1-2周适应期，初期可能因不熟悉目录结构或命名规则导致操作失误。