安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install mu-multi-agent
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 mu-multi-agent。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

mu-multi-agent 是一套实用的协调方法指南，可将包含独立子任务的工作组织成结构化的智能体团队。它帮助主智能体判断委派是否值得、在指挥官、流水线和混合模式之间做出选择、为子智能体提供所需上下文，并将其发现整合成连贯的交付成果。这个 Openclaw Skills 条目是一项方法论技能，而不是智能体运行时或特定工具的集成。
其核心防护措施旨在让编排发挥作用：不要并行处理相互依赖的步骤，保持任务指派简洁，并要求主智能体验证和综合子智能体的结果，而不是原样转发。对于重要或高风险的输出，可以由独立审查者在交付前根据评分标准评估工作。

应用场景

并行研究：
同时调查多个主题、来源或维度，然后汇总证据和发现。
批量处理：
筛选多份简历，或将数份文档作为独立任务进行翻译、摘要或格式转换。
多版本创作：
以不同风格或不同角度生成备选方案，然后进行比较并推荐一个选项。
先研究后写作：
先并行收集信息，再据此制作多个草稿或格式。
注重质量的交付成果：
对正式报告、外部文档、事实密集型分析，或用户要求审查的任务，增加一位独立审查者。
代码与内容流水线：
将相互依赖的工作组织成一系列步骤，例如规划、实施和审查。

应用场景

简单请求、专业技能可独立完成的任务，以及没有并行收益的直接顺序工作，都不需要编排。

工作原理

确认任务： 在读取文件或派遣智能体之前，先告知用户多智能体工作已开始，让用户知道请求正在处理中。
判断是否值得委派： 检查是否至少有两个相互独立的子任务、多个研究来源、批量工作、研究后需要产出多个结果，或需要独立审查。如果单个智能体或专业技能足以完成，则优先采用它们。
选择工作流： 对启用工具的并行工作使用指挥官模式；对以文本为主的顺序工作或多视角工作使用流水线模式；对需要先研究再产出多个结果的情况使用混合模式。
规划并派遣： 展示简洁的任务计划。为每个子智能体明确角色和任务，并在指派中提供必要上下文。让相互独立的工作同时启动；只有在前置任务完成后，才派遣依赖这些任务的工作。
监控执行： 跟踪已派遣的智能体，在需要时介入或停止工作，并利用可用历史记录检查结果。如果运行时不支持子智能体，则按顺序执行工作流，并尽可能保持审查环节相互独立。
整合并验证： 主智能体检查返回的结果，按主题而非智能体进行整理，并撰写最终答复或报告。不要将子智能体的原始输出直接交给用户。
审查并交付： 对适合的高风险输出进行基于评分标准的独立审查；必要时修改并再次审查，然后提供交付成果和执行统计卡片。

配置指南

此技能不指定软件包安装程序或特定智能体运行时。将 SKILL.md 文件添加到智能体宿主可识别的技能目录，然后配置或提供与该技能抽象契约对应的运行时能力：spawn、monitor、history 和 notify。实际工具名称因运行时而异；应按能力进行映射，而不要假定某种特定实现。

仅为示例：将这些占位符替换为智能体宿主所使用的路径。

mkdir -p "$AGENT_SKILLS_DIR/mu-multi-agent"
cp /path/to/SKILL.md "$AGENT_SKILLS_DIR/mu-multi-agent/SKILL.md"
安装后，确认宿主能够发现此技能，并且其运行时提供所需能力。如果无法执行子智能体，请使用文档说明的顺序回退方案。源技能未指定其他依赖项、环境变量或 CLI 配置。

数据架构

此技能定义的是一种编排方法，而非必需的数据库或机器可读项目架构。其工作信息围绕任务、智能体、工作流阶段、上下文、审查结果和最终交付成果进行组织。
工件或元数据 组织方式与用途
智能体指派 简洁的角色加任务指令。如果子智能体需要背景信息或前置结果，应一并提供。
上下文 在任务中提供相关背景，在依赖阶段之间传递结构化结果，或在背景复杂时指向上下文文件。
智能体标签 可读的角色标签，可选配表情符号，用于在计划和状态摘要中识别每位工作者。
工作流 指挥官（启用工具的并行执行）、流水线（以文本为主的工作流）或混合模式（先研究，再产出多个结果）之一。
审查评分标准 进行独立审查时，检查事实准确性、结构完整性、逻辑一致性、证据和格式；记录分数及问题。
执行统计 报告模式、智能体角色、耗时、可用时的输入 token 数量、状态、并行时间与估算串行时间，以及审查结果。
长篇输出 对于超过 500 个字符的内容，将 Markdown 报告保存到 ./workspace/projects/{topic}/report.md 等路径，并将文件与文本摘要分开发送。
最终综合由主智能体负责。除示例报告和上下文文件路径外，此技能不要求固定的目录结构，也不定义持久化元数据格式。

高级特性

自动模式路由：
根据工具需求、依赖关系以及是否需要多个输出，选择指挥官、流水线或混合编排。
运行时抽象：
使用用于启动、监控、查看历史记录和通知用户的能力契约，而不是将方法绑定到某一个智能体平台。
并行且感知依赖关系的执行：
同时运行相互独立的任务，而依赖先前结果的任务则按顺序派遣。
独立质量审查：
对适当的高风险交付成果增加独立审查者，并采用明确的评分标准以及修改后再审查的循环。
顺序回退方案：
当宿主无法运行子智能体时，仍保留工作流、审查独立性和执行统计。
上下文交接模式：
支持注入背景信息、交接前置任务结果，或在任务复杂时读取上下文文件。
关注成本的委派：
对较简单的研究或审查角色建议使用轻量级模型，并允许在质量要求合理时升级模型。
执行透明度：
要求派遣前提供任务计划，并在多智能体工作后提供统计卡片。
交付防护措施：
要求主智能体进行综合、检查任务是否完成，并在发送长篇报告时分别发送文件和文本通知。

name: mu-multi-agent display_name: 多Agent协作指挥官
version: 2.2.0
description: "多Agent并行调度中心。自动触发条件：任务可拆≥2个独立子任务、需多源同时调研、批量同类任务≥2件、调研+多版本输出、高风险输出需独立评审。三模式自动路由（指挥官/流水线/混合）。触发词：多Agent、并行调研、组队、批量处理、多个方向同时。不适用：单一Skill能搞定的任务、简单顺序任务。" tags: 多Agent,并行调度,子Agent协作,任务编排,批量处理,Agent调度中心

mu-multi-agent 🐝

多Agent协作指挥官 — 把一个人变成一支队伍

IRON LAW：①任务可拆分性必须明确判断，单一顺序任务禁止强行并行化；②极简派活——只传「谁+做什么」，禁止在派活中附加规则/输出要求/注意事项；③子Agent结果必须主Agent亲自汇总验证，不可直接透传子Agent输出。无例外。

🔧 运行时适配（三层架构）

本 Skill 是方法论 Skill，不绑定任何特定 Agent 运行时。正文只引用以下 4 个抽象能力契约：

契约 能力 说明
spawn 派出子Agent并行执行任务 同一轮发起多个 spawn = 并行执行
monitor 列出/干预/终止已派出的子Agent 超时兜底、异常介入
history 查看子Agent执行历史 复盘与统计卡取数
notify 向用户发送消息或文件 交付最终成果

推荐实现映射（运行时工具名各不相同，按能力签名对号入座）：

契约 典型工具名 典型形态
spawn Task / task / sessions_spawn 支持子任务派发的 Agent 运行时
monitor 任务列表 / task_stop / subagents 查看并干预进行中的子任务
history 任务记录 / 会话历史 / sessions_history 复盘子任务执行过程
notify 对话回复 / 写文件 / message 向用户交付消息或文件

降级路径：运行时没有子Agent能力时，主Agent串行扮演各角色逐段执行（流水线模式仍完整可用，评审Agent用「隔一段上下文再审」模拟上下文隔离），保留评审分离与统计卡。

notify 注意：发文件时说明文字须单独再发一条，文件与文字不能合并发送。

⚡ 触发描述（Quick Trigger）

多Agent并行调度。触发词：多Agent/并行调研/组队/多个方向同时/Agent小队。自动路由三模式（指挥官/流水线/混合），子Agent分工协作。不适用：单一顺序任务。

🚦 前置判断：是否需要多Agent（必检）

不是所有复杂任务都需要多Agent。先过这个检查清单：

信号 判断
输入简单+路径短+工具少+风险低 ❌ 单Agent够用，不触发本skill
有专项Skill能独立搞定 ❌ 直接用专项Skill，不触发本skill
任务跨≥2个独立子任务且无依赖 ✅ 触发并行
需要同时调研多个方向/信息源 ✅ 触发指挥官模式
需要"先调研后多版本输出" ✅ 触发混合模式
批量处理同类任务≥2件 ✅ 触发并行
高风险输出需要独立评审 ✅ 触发（加评审Agent）

核心原则：多Agent不是比单Agent更高级的形态，它只是复杂任务下的一种组织方式。多数人的问题不是"Agent不够多"，而是"还没把一只Agent养明白就急着养一群"。

🤖 自动触发条件（无需用户说"组队"）

主Agent在分析用户任务时，遇到以下情况自动激活本skill，不需要等用户显式提及"多Agent""组队"等触发词：

并行可拆：任务自然拆成≥2个独立子任务（如"调研A+调研B"）
多源调研：需要从多个不同信息源/维度同时获取信息
批量同类：同一类型任务≥2件需要批量处理（批量评估、批量筛选、批量翻译）
调研+生成：先需要调研/采集，再基于结果生成多版本输出
执行+评审：高风险输出（评估报告、正式报告、对外文档）需要独立质量检查

不自动触发的情况：

专项Skill能独立完成的单一任务 → 直接用专项Skill
简单顺序任务（一步接一步，无并行收益）
纯闲聊/简单问答
🧬 Skills vs 子Agent 判断指南
你想复用的是… 选择 举例
一套动作规范/方法 Skills 怎么检索知识库、怎么格式化文档、怎么清洗数据
一个完整子任务+独立上下文 子Agent 写评估报告、做深度调研、独立评审报告

简单判断：如果去掉这个"角色"，换成一段说明书塞给主Agent也能做好 → 它应该是Skill，不是子Agent。

⚡ 铁律：立即公告

收到任务后，第一件事必须是发公告，不得先读文件或先派Agent。

原因：读文件、派Agent都需要时间，先公告能消灭沉默感，避免用户以为没响应。

🐝 mu-multi-agent 已唤醒
多Agent并行模式启动，我来组建小队处理这个任务。

正确顺序： 收到任务 → 发公告 → 分析任务 → 派Agent 错误顺序： ❌ 收到任务 → 读文件 → 分析 → 发公告 → 派Agent

🗺️ 三模式自动路由

不需要用户指定模式，根据任务信号自动判断：

用户输入
│
▼
需要联网/工具/实时信息？
YES ──→ 同时需要多版本输出？
│ YES → 🔀 混合模式（先调研后多版本）
│ NO → 🎯 指挥官模式（spawn并行）
│
NO ──→ 纯文本任务（写作/分析/翻译）
→ 🔄 流水线模式（快速，无工具）

信号 示例 触发模式
联网/调研/搜索 "调研"、"最新"、"搜一下" 指挥官 or 混合
多版本/多角度 "几个版本"、"不同风格"、"多个角度" 流水线 or 混合
两者都有 "调研后给我几版报告" 混合
都没有 "分析这段文字"、"翻译" 流水线
🦐 子Agent派发（核心规则）
快速通道（最先判断）

如果任务满足以下全部条件，直接调Skill，跳过本Skill的全部流程：

① 不需要spawn子Agent（主Agent自己能干完）
② 只需调用1个Skill
③ 预计≤3次工具调用
需要spawn子Agent时

派活一句话："谁+做什么"（如"给某位候选人写面试评估"/"把这份报告翻译成英文"）。 子Agent自己匹配Skill→通读Skill说明→严格执行。禁止在派活时附加规则、输出要求、注意事项。

📋 执行前：任务规划公告

派Agent前，先展示规划（让用户知道要做什么）：

🚀 [N]个方向同时开搞，全面覆盖你的问题。

📋 任务规划：
🔍 调研员A — [任务描述，一句话]
🔍 调研员B — [任务描述，一句话]
📊 分析师 — 等前[N]个结果后跟进（串行）

模式：🎯 指挥官模式
预计耗时：~[X]s（[N]个Agent并行）
正在派出Agent小队...

角色 Emoji 参考：

角色 Emoji 适合任务
调研员 🔍 搜索、情报收集
分析师 📊 对比、深度分析
写作者 ✍️ 报告、文档、文案
程序员 💻 代码、实现
审核员 🔎 质量校验、Review
规划师 📋 任务拆解、路径设计
批评者 🧐 风险挑战、反驳
评估师 🎭 人才/方案评估
翻译官 🌐 多语言翻译
知识管理 ⛏️ 知识库沉淀
评审员 🔎 独立质量检查（rubric挑错）
🔎 评审Agent（执行与评审分开 — 最关键的一刀）

核心洞察：同一个Agent既当选手又当裁判，会高估自己输出质量。把评审单独拿出去，即便底层是同一模型，也因上下文独立而显著改善自评偏差。

何时启用评审Agent：

评估报告、正式报告、对外文档等高风险输出
涉及事实核查的长文分析
木老师明确要求"帮我审一下"

评审Agent标准模板：

spawn({
"task": """你是独立评审员。你的职责是按评审标准挑错，不是夸奖。

[评审标准 Rubric]

1. 事实准确性：有没有编造或无法验证的事实？
2. 结构完整性：有没有缺失的必要模块？
3. 逻辑一致性：前后观点有没有矛盾？
4. 证据充分性：结论是否有具体数据/案例支撑？
5. 格式规范性：是否符合要求的输出格式？

[待评审内容]
读取文件：{output_file_path}

[输出要求]

• 逐条打分（1-5分）+ 具体问题描述
• 如果发现问题，给出修改建议
• 如果质量合格（5项均≥4分），输出"✅ 通过"
• 如果有项≤3分，输出"⚠️ 需修改"并列出具体修改项 """,
  "label": "🔎 评审员"
  })

评审结果处理：

✅ 通过 → 直接发给木老师
⚠️ 需修改 → 主Agent根据评审意见修改，或派原执行Agent修改后重新评审
🎯 指挥官模式（有工具，真并行）

通过 spawn 派出子Agent，每个都有完整工具（联网搜索、文件读写等）。

并行机制： 同一轮工具调用中的多个 spawn 同时执行。

# ✅ 同一轮派出 = 并行执行

BG = "[背景] 木老师在做XXX，需要了解YYY。"

spawn({"task": f"{BG}\n\n[你的任务] 调研A，返回5条要点，每条≤100字，不要写完整报告。", "label": "🔍 调研员A"})
spawn({"task": f"{BG}\n\n[你的任务] 调研B，返回5条要点，每条≤100字。", "label": "🔍 调研员B"})
spawn({"task": f"{BG}\n\n[你的任务] 调研C，返回5条要点，每条≤100字。", "label": "🔍 调研员C"})

# 三个同时跑 → 全部返回后主Agent汇总写报告

串行（后续Agent依赖前序结果）：

# Phase 1: 并行调研

spawn({"task": "...[调研A]...", "label": "🔍 调研员A"})
spawn({"task": "...[调研B]...", "label": "🔍 调研员B"})

# Phase 2: 等结果回来，主Agent汇总，不需要再派写作Agent
# 主Agent自己写最终报告（避免子Agent token限制）

关键规则：

✅ 子Agent只返回摘要（≤100字/条），不写完整报告
✅ 主Agent负责写最终报告（避免子Agent输出过长导致截断）
✅ 并行Agent互相独立，不能依赖彼此结果
✅ 需要依赖前序结果的Agent，等前序完成后再派
🔄 流水线模式（纯文本，快速）

无工具，适合写作/分析/翻译/多模型对比等纯文本任务。

串行流水线（前一个的输出是后一个的输入）：
规划 → 写作 → 审核

并行扇出（多角度同时处理）：
┌─ 视角A ─┐
输入 ──────┼─ 视角B ─┼──→ 主Agent综合
└─ 视角C ─┘

适用场景：

多角度分析（每个Agent负责一个维度）
多模型对比（相同任务，不同Agent）
代码流水线（规划→写代码→Review）
批量处理（翻译/总结多份文档）
🔀 混合模式（调研 + 多版本）

先用指挥官模式调研，再用流水线模式生成多版本：

Phase 1（指挥官，并行调研）：
调研员A ──┐
调研员B ──┤ → 汇总调研结果
调研员C ──┘

Phase 2（流水线，并行写作）：
写作者1（风格A）──┐
写作者2（风格B）──┤ → 主Agent对比/综合
写作者3（风格C）──┘

🤖 模型选择（成本意识）
角色 默认模型 原因
🔍 调研员 默认（轻量） 搜索任务，轻量够用
📊 分析师 默认 长上下文整合
✍️ 写作者 默认 创意写作
💻 程序员 默认 代码理解
🔎 审核员 默认（轻量） 简单判断，不需重炮
📋 规划师 默认 结构化规划

成本意识原则：

任务简单 → 轻量模型
木老师明确指定 → 照用户说的来
最高质量需求 → 升级模型，说明原因
📊 执行统计卡（每次必输出）

多Agent跑完后，输出标准统计卡：

📊 执行统计

模式：🎯 指挥官模式（spawn，联网并行）

⏱ 并行耗时：~45s | 串行预估：~136s | 节省：~91s（67%）⚡
🧹 上下文隔离：子Agent平均输入 2.4k token（vs 单Agent预估 15k+）
🔎 独立评审：✅ 通过（5项均≥4分）

📤 结果交付规则

永远不直接粘贴子Agent原始输出。 主Agent重新整理，按内容逻辑组织：

1. 📊 执行统计卡（告知跑了什么）
2. 🎯 核心结论（3-5条最重要发现）
3. 📖 分主题展开（按内容逻辑，不按Agent顺序）
4. 🚀 下一步建议

✅ 任务完成门控（何时视为完成）：

所有子Agent已返回结果（或超时被终止并有兜底处理）
主Agent已完成结果整合（不是直接粘贴子Agent输出）
若启用评审Agent，评审结果为"✅ 通过"或修改后重新通过
执行统计卡已输出
最终交付物已发送给用户

缺少任何一项，不得声称"任务完成"。

消息平台长文处理：

内容 >500字 → 先保存为 .md 文件，发文件 + 一句摘要
多数即时通讯工具不渲染 Markdown 表格和标题符号，长文不要直接贴

# 保存报告

write("./workspace/projects/{topic}/report.md", content)

# 发文件（notify 契约）

notify(media="./workspace/projects/{topic}/report.md", filename="report.md")

# 再发一条摘要文字（两次调用，不能合并）

notify(message="📋 报告已生成，核心结论：...")

🔗 上下文传递给子Agent

子Agent是全新会话，不知道背景。必须在 task 里注入 [背景] 块：

模式1：背景注入（推荐，95%场景）

[背景] 木老师在评估一位候选人，岗位是XX，需要了解YYY。受众：HR团队。

[你的任务] 搜索ZZZ，返回5条要点，每条≤100字，不要写完整报告。

模式2：前序结果传递（串行场景）

[前序调研结果]

• A框架：优势是...缺点是...
• B框架：...

[你的任务] 基于上述结果，补充搜索C框架，返回3条独特发现（不重复上面已有内容）。

模式3：读文件（复杂背景）

[背景文件] 读 ./workspace/projects/xxx/context.md 获取完整背景。

[你的任务] 基于背景文件，搜索YYY，返回要点摘要。

🏗️ 工作流拓扑设计原则

避免意大利面图：

❌ 错误（所有Agent互连）：
A ←→ B ←→ C（混乱，难debug）

✅ 正确（线性/扇出）：
线性：A → B → C
扇出：A → [B, C, D] → E（E依赖B/C/D结果）

添加连接前问：

Agent B真的需要Agent A的输出吗？
没有这个连接，B能独立工作吗？
这个连接是"以防万一"加的吗？（如果是，删掉）
⚠️ 常见坑
坑 错误做法 正确做法
沉默坑 先读文件再公告 先公告再读文件
Token爆坑 让子Agent写完整报告 子Agent返回摘要，主Agent写报告
依赖坑 同轮派出的Agent互相依赖 并行Agent必须独立；依赖关系用串行
固定数量坑 总是派3个Agent 按任务复杂度决定数量
长文直贴坑 在消息平台发大段Markdown 长内容发文件，摘要发文字
Skill绕过坑 有专项Skill却自己干 先用专项Skill，失败再自己兜底
假忙坑 Agent互相转述/确认/总结，产出没提升 每个Agent必须产出独立增量价值
orchestrator膨胀坑 主Agent又路由又采集又汇总 主Agent只做路由+汇总，采集也派子Agent
层层失真坑 中间态过度摘要，后续Agent在损失信息上加工 中间态必须结构化（证据/结论/待确认点）
💡 适合用多Agent的场景
场景 方案
批量简历初筛 N个评估子Agent并行跑，主Agent汇总对比表
多维度竞品分析 调研员A（价格）+调研员B（功能）+调研员C（口碑）→ 主Agent整合
全网搜索某话题 N个搜索子Agent（多关键词并行）→ 主Agent综合
批量文档处理 翻译/总结/格式转换按文档并行，主Agent验收
重要报告产出 调研员（背景）+ 写作者（初稿）+ 评审员（挑错）流水线
多版本文案 写作者×N（不同风格并行）→ 主Agent对比推荐
快速触发示例

# 并行调研

"帮我同时调研A、B、C三个方向"
"多个Agent并行搜索这几个话题"

# 多版本生成

"帮我出3个不同风格的XXX"
"用多个角度分析这个问题"

# 批量处理

"这10份简历帮我批量初筛"
"同时翻译这几段文字"

# 组队协作

"先搜行业背景，同时让写作Agent起个初稿"

PhotoFresco

EIN.LLC 激活续传