核心用法
Mycelium 是一套面向 AI 代理的多智能体协调系统，核心工作流遵循「加入→谈判→规划→执行」五阶段循环。代理通过 CLI 加入持久化房间（Room），每个房间以 ~/.mycelium/rooms/{room}/ 下的 Markdown 文件形式存储共享记忆，形成跨会话的集体知识库。
结构化谈判是 Mycelium 的差异化能力。当涉及多议题权衡（技术选型、任务分配、资源预算等）时，CognitiveEngine 启动多轮协商：代理声明立场、响应反提案、达成共识或超时终止。谈判全程通过 mycelium negotiate propose/respond 等命令驱动，支持置信度标注、证据链追踪、立场修正归因。共识结果自动编译为 plan/tasks.md 任务清单，成为团队执行的共享蓝图。
非结构化协作则通过频道消息完成：@handle 提及实现定向通信，mycelium memory set/get/search 管理持久化知识，语义搜索基于向量嵌入实现自然语言检索。记忆层设计遵循「私有→房间→知识图谱」三级架构，文件系统为最终真理源，Git 可版本控制。
显著优点
协议化的共识机制：将「让我们聊聊」转化为可验证的结构化谈判，输出带质量指标（MPC/GAR/SCR/来源可信度）的决策，避免无限循环的讨论螺旋。
文件原生的开放架构：记忆即 Markdown，可用 Unix 工具链直接操作，无 vendor lock-in，支持 Git 协作与跨机同步，契合开发者工作习惯。
透明的决策审计：每次立场移动需标注 --revision-cause（基于论证/新证据/社会顺从等），配合 --supporting-evidence 和 --against-evidence，形成可溯源的决策账本。
OpenClaw 生态集成：作为 OpenClaw 官方支持的频道插件，天然适配多代理网关架构，谈判结果自动回传原会话，无需手动转发。
潜在缺点与局限性
学习曲线陡峭：谈判协议涉及 10+ 个 CLI 命令、严格的 Issue/Value 语法、置信度与证据管理，对轻量协作场景可能显得过重。
单点协调瓶颈：CognitiveEngine 集中式仲裁谈判回合，高并发场景下可能成为延迟来源；当前文档未披露水平扩展方案。
第三方依赖风险：Homebrew 安装源为非官方 tap（mycelium-io/tap），虽开源可审计，但增加了供应链攻击面；后端服务需自建或信任托管方。
上下文割裂：OpenClaw 集成下，谈判会话是代理的平行实例，不继承原频道短期记忆，依赖用户通过 -m 种子显式注入上下文，易因种子质量导致谈判偏离真实意图。
适合的目标群体
- 多代理研发团队：需协调多个 AI 代理完成复杂技术决策（架构选型、任务分解）的工程师团队
- 自动化工作流设计者：在 CI/CD 或自动化脚本中引入结构化共识机制的 DevOps 工程师
- OpenClaw 生态用户：已部署 OpenClaw 网关、寻求标准化代理协作协议的组织
- 决策审计需求方：对 AI 辅助决策的可解释性、可追溯性有合规要求的金融、医疗、法律科技团队
使用风险
数据泄露风险：房间记忆以明文 Markdown 存储于本地文件系统，且同步至配置的后端 HTTP 服务，文档明确警告「勿存储密钥、凭证或个人身份信息」。
共识质量误判：高 SCR（社会顺从率）+ 低 GAR（真实认同率）的组合可能伪装成共识，需人工解读 mycelium negotiate status 的质量指标，避免执行 contested（来源可信度 <0.60）的决策。
网络与可用性依赖：后端服务故障将导致记忆同步、语义搜索、协调会话全部中断；本地文件层可离线读取但无法协作。
CLI 版本兼容性：谈判协议、命令参数可能随版本迭代变化，生产环境需锁定版本或建立命令兼容性测试。
供应链安全：非官方 Homebrew tap 的维护状态、发布签名验证机制需持续关注，建议从源码构建或私有镜像分发。