核心用法
claw-multi-agent 是 OpenClaw 平台的多智能体并行编排技能，通过将串行任务转为并行执行，显著提升复杂任务的处理效率。
三种运行模式
| 模式 | 场景 | 技术实现 |
|------|------|----------|
| **🎯 Orchestrator** | 需要联网搜索/文件操作 | `sessions_spawn` 并行调用，子 Agent 拥有完整工具权限 |
| **🔄 Pipeline** | 纯文本任务（写作、分析、翻译） | Python CLI 本地执行，快速多版本生成 |
| **🔀 Hybrid** | 搜索+多草稿对比 | 先并行搜索，再基于结果生成多版本 |
典型应用场景
- 并行调研：5 个框架同时搜索，各写摘要，主 Agent 整合报告
- 多模型对比：同一问题交给 Claude/Gemini/Kimi 同时回答，对比差异
- 代码流水线：规划 → 编码 → 审核，自动串行交接
- 批量处理：多文档并行翻译/分析/摘要
交互规范（强制）
1. Step 0 立即公告：收到任务后第一时间发送激活通知，再进行任何操作
2. 预生成计划：调用 sessions_spawn 前必须公告 Agent 分工、模型选择、预计耗时
3. 结果重组：禁止直接粘贴子 Agent 原始输出，必须按内容逻辑重新组织（核心结论→分主题细节→行动建议）
4. 渠道适配：Feishu 必须发文件附件，Discord/Telegram 可直接发 Markdown
模型选择策略
| 角色 | 默认模型 | 理由 |
|------|----------|------|
| 研究员 | GLM | 便宜、快、中文好 |
| 分析师 | Kimi | 128K 长上下文，适合资料整合 |
| 写作者 | Gemini | 创意表达最佳 |
| 程序员 | Kimi | 代码理解能力强 |
| 规划师/审核员 | Sonnet | 结构化推理稳健 |
显著优点
1. 效率提升明确：官方宣称 50-65% 时间节省，通过并行执行将串行等待转为并发处理
2. 架构设计清晰：三种模式自动路由，用户无需理解底层差异，描述意图即可
3. 交互体验优化：强制性的「先公告后执行」模式避免用户面对长时间沉默
4. 输出质量可控：主 Agent 重写整合，避免子 Agent 输出直接拼接导致的碎片化
5. 模型差异化利用：根据任务特性分派不同模型，平衡成本与质量
6. 渠道感知交付：区分 Feishu（无 Markdown 渲染）与其他平台，避免格式灾难
潜在缺点与局限性
1. 学习曲线陡峭：大量强制规范（Step 0 公告、角色 Emoji、统计卡格式）需严格遵守，新开发者易踩坑
2. 上下文隔离风险：并行 Agent 之间无共享上下文，依赖型任务若误并行会导致空结果（Gotcha 3）
3. Token 限制隐患：子 Agent 输出上限约 4096 token，长报告必须由主 Agent 撰写，增加主 Agent 负担
4. 成本复杂度：多模型并行调用时费用计算不透明，GLM/Kimi/Gemini/Sonnet/Opus 价差大
5. 调试困难：并行执行时错误定位复杂，需依赖执行统计卡回溯
6. 过度工程嫌疑：简单任务（如单主题搜索）强制走多 Agent 流程可能反而降低效率
适合人群
- 技术团队调研场景：需要对比多个技术方案、框架、竞品的工程师或架构师
- 内容创作团队：需要同一主题多版本草稿供选择的编辑、运营、文案
- AI 应用开发者：希望探索多 Agent 协作范式，理解并行编排最佳实践
- 效率敏感型用户：愿意为 50%+ 时间节省支付额外成本和复杂度
常规风险
| 风险类型 | 具体表现 | 缓解措施 |
|----------|----------|----------|
| **流程违规** | 未先公告就读文件，导致激活通知丢失 | 建立「收到任务→立即公告」的肌肉记忆 |
| **依赖错位** | 分析 Agent 与搜索 Agent 同批 spawn，分析 Agent 无数据 | 严格区分并行（独立）与串行（依赖）阶段 |
| **输出超限** | 子 Agent 写长报告导致截断，文件写入静默失败 | 子 Agent 只返回摘要，主 Agent 统一撰写 |
| **渠道格式灾难** | Feishu 直接粘贴 Markdown，用户看到 raw 符号 | 强制检查渠道，Feishu 走附件或文档链接 |
| **模型误配** | 简单任务用 Opus，复杂推理用 GLM | 参考 Role→Model 映射表，默认即可 |
总体评估
claw-multi-agent 代表了一种规范优先的多智能体工程实践。其价值不在于技术复杂度（并行调用本身简单），而在于通过强制交互契约解决了多 Agent 系统的典型 UX 问题：用户不知道发生了什么、结果从哪里来、如何信任输出质量。
对于愿意遵守规范的用户，它能稳定产出高质量并行研究成果；对于追求快速上手的用户，大量的 Iron Rules 可能形成阻碍。建议作为生产环境的多 Agent 标准模板参考，而非临时脚本使用。