# Agent Orchestra > 多智能体协作 SKILL —— 拥有 251 个专业 Agent（覆盖 19 个部门）的完整多 Agent 协作系统。包含总调度 Agent、专业部门 Agent 和审查 Agent。当用户需要完成复杂任务、跨领域协作、多阶段工作流，或涉及前端/后端/设计/营销/安全/金融/GIS/游戏等专业领域时，使用此 SKILL。即使是单领域但高复杂度的任务也应启用。注意：不要因为用户没有明确提到"多智能体"就不使用——任何涉及多种技能或专业知识的任务都是此 SKILL 的适用场景。 - Skill: `marecgents/agent-orchestra` (Agent Skill, multi-file: 258 files) - Install (CLI): `npx skillmds@latest add marecgents/agent-orchestra` - Raw SKILL.md: https://api.skillmd.com/api/skills/marecgents/agent-orchestra/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: MarecGents (https://skillmd.com/u/marecgents) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/marecgents/agent-orchestra --- # Agent Orchestra — 多智能体协作系统 > 251 个专业 Agent · 19 个部门 · 总调度 + 专业执行 + 审查门禁 > > 核心理念：**先评估、再调度、审评分立、跨 Agent 协作**，追求的不是快，而是**稳**。 --- ## 目录 1. [系统架构](#1-系统架构) 2. [快速开始](#2-快速开始) 3. [任务评估与决策](#3-任务评估与决策) 4. [Agent 调度流程](#4-agent-调度流程) 5. [跨 Agent 通信机制](#5-跨-agent-通信机制) 6. [审查门禁](#6-审查门禁) 7. [最佳实践](#7-最佳实践) --- ## 1. 系统架构 ``` 用户请求 │ ▼ ┌─────────────────────────────────────┐ │ 任务评估（由 SKILL 完成） │ ← 评估复杂度、跨领域程度、交付要求 │ 简单 → 直接处理 │ 复杂 → 进入调度 │ └──────────────────┬──────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 总调度 Agent（agents/dispatcher/） │ ← 负责任务拆解、Agent 匹配、分配、协调 └──────────┬──────────────────────────┘ │ ┌──────┼──────────┬──────────┐ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │专业 A │→│专业 B │→│专业 C │ │ 审查官 │ │ │←│ │ │ │ │ (门禁) │ └──────┘ └──────┘ └──────┘ └──────────┘ │ │ │ │ └────────┴────────┴───────────┘ │ ▼ 最终交付物 ``` ### 角色分工 | 角色 | 职责 | 是否执行工作 | 文件位置 | |------|------|------------|---------| | **总调度** | 任务评估、Agent 匹配、分配调度、跨 Agent 协调 | ❌（只分配不执行） | `agents/dispatcher/总调度.md` | | **专业 Agent** | 在各自领域内编写代码/设计/内容/分析 | ✅ | `agents//` | | **审查官** | 多维度审查（功能/代码/安全/架构/合规） | ❌（只审不写） | `agents/reviewer/审查官.md` | > **关键规则**：写工作和审工作的永远分开。又当裁判又当运动员等于没审。 --- ## 2. 快速开始 ### 2.1 目录结构 ``` agent-orchestra/ ├── SKILL.md ← 本文件：主技能定义 ├── references/AGENTS-CATALOG.md ← Agent 目录与部门总览（按需加载） └── agents/ ← 251 个 Agent 定义文件 ├── dispatcher/ 总调度.md ├── reviewer/ 审查官.md └── 19 个部门目录（engineering/, marketing/, design/ ...） ``` > 如需查看完整部门分类和 Agent 列表，在需要调度 Agent 时加载 `references/AGENTS-CATALOG.md`。 ### 2.2 使用方式 当收到用户请求后，按以下流程操作： 1. **先评估**（见 §3）— 判断任务是否需启用多 Agent 2. **如需调度** → 先加载 `references/AGENTS-CATALOG.md` 了解 Agent 部门分布，然后加载 `agents/dispatcher/总调度.md` 让总调度进行任务拆解和精确 Agent 匹配 3. **专业执行** → 按总调度分配，加载对应部门的 Agent 文件执行具体工作 4. **跨 Agent 协作** → 按需通过总调度协调多个 Agent 5. **最终审查** → 加载 `agents/reviewer/审查官.md` 进行最终审查 --- ## 3. 任务评估与决策 这是多 Agent 系统的入口判断。**不要默认启用多 Agent，也不要默认不启用。** 先评估，再决策。 ### 3.1 评估维度 | 维度 | 低（1 分） | 中（2 分） | 高（3 分） | |------|-----------|-----------|-----------| | **技术复杂度** | 简单 CRUD、单文件修改 | 多模块联调、中等算法 | 系统架构设计、复杂算法、多系统集成 | | **跨领域程度** | 单一领域（纯前端/纯后端/纯设计/纯营销等） | 跨 2 个领域（如前端+后端） | 跨 3 个及以上领域（如前端+后端+数据库+部署） | | **交付要求** | 单一文件输出 | 多文件、多格式 | 完整系统、多阶段交付 | | **风险等级** | 不影响业务 | 影响局部功能 | 影响核心业务或安全 | > **关于跨领域程度的说明：** 同一大领域内的多技术栈（如后端架构 + 数据库优化、前端页面 + 组件库）仍视为单一领域，不额外计分。跨领域指的是**完全不同职责的领域**（如前端开发与后端开发、设计与开发、工程与营销）。 ### 3.2 决策矩阵 | 总分 | 决策 | 说明 | |------|------|------| | **4-5 分** | ✅ **直接处理** | 单 Agent 或当前会话直接完成，无需调度 | | **6-8 分** | 🔄 **调用总调度** | 启用总调度 Agent，匹配 1-3 个专业 Agent | | **9-12 分** | 🚀 **完整多 Agent 流程** | 总调度拆解 → 多 Agent 分阶段执行 → 审查门禁 | ### 3.3 决策示例 ``` 用户说："帮我写一个 React 组件" → 纯前端、单文件、低风险 → 总分 4 → ✅ 直接处理 用户说："帮我搭建一个电商网站，包括前端页面、后端 API 和数据库设计" → 跨前端+后端+数据库、多文件 → 总分 8 → 🔄 调用总调度 用户说："设计并实现一个包含用户认证、支付集成、数据分析面板和部署方案的 SaaS 平台" → 全栈+安全+支付+部署+分析 → 总分 11 → 🚀 完整多 Agent 流程 ``` --- ## 4. Agent 调度流程 当决策为「调用总调度」或「完整多 Agent 流程」时，按以下步骤执行： ### 步骤 1：加载总调度 加载 `agents/dispatcher/总调度.md`，将任务交给总调度 Agent。如需了解 Agent 部门分布，可先查阅 `references/AGENTS-CATALOG.md`。 总调度会： - 分析任务，进行结构化拆解 - 在 Agent 注册表中搜索匹配的 Agent - 确定执行顺序和依赖关系 ### 步骤 2：总调度分配任务 总调度明确以下信息后分配任务： ```markdown ## 调度指令 **任务**：[子任务描述] **目标 Agent**：[Agent 名称]（`agents/<部门>/<文件名>.md`） **输入**：[前置条件 / 依赖数据] **预期输出**：[交付物说明] **协作接口**：[如需与其他 Agent 对接，说明接口] **截止**：[时间节点 / 依赖链中的位置] ``` ### 步骤 3：加载并执行 Agent 根据总调度的分配，加载对应部门的 Agent `.md` 文件，让该 Agent 按自身定义的工作流程执行任务。 每个专业 Agent 的 `.md` 文件包含： - **YAML 头**：name / description / emoji / color - **身份与记忆**：角色定位、性格、经验 - **核心使命**：具体职责和核心工作内容 - **关键规则**：做事的原则和红线 - **技术交付物**：代码示例和产出模板 - **工作流程**：分步骤的执行流程 - **沟通风格**：话术和表达方式 - **成功指标**：可量化的衡量标准 ### 步骤 4：阶段性汇总 每个 Agent 完成后，总调度收集产出物： - 检查是否满足预期输出 - 判断是否需要调用其他 Agent 继续 - 如有跨 Agent 通信需求，进入 §5 的通信机制 ### 步骤 5：提交审查 所有 Agent 执行完毕后，提交审查 Agent（`agents/reviewer/审查官.md`）进行最终审查（见 §6）。 ### 步骤 6：交付 审查通过后，汇总所有 Agent 的产出物，形成最终交付物给用户。 --- ## 5. 跨 Agent 通信机制 这是多 Agent 协作的核心能力——Agent 之间可以通过总调度进行有序通信和协作。 ### 5.1 通信原则 1. **中心化调度**：所有 Agent 间的通信必须通过总调度，Agent 之间不直接耦合 2. **需求明确**：发起方必须明确「需要什么 + 为什么需要 + 期望输出格式」 3. **上下文传递**：总调度负责维护全局上下文，确保信息完整传递 ### 5.2 通信流程 ``` Agent A 执行中需要 Agent B 协助 │ ▼ Agent A 向总调度提出协作需求 │ ▼ 总调度评估需求的合理性和紧急性 │ ├── 合理 → 调度 Agent B │ │ │ ▼ │ Agent B 执行协助任务 │ │ │ ▼ │ Agent B 返回结果给总调度 │ │ │ ▼ │ 总调度将结果交回 Agent A │ │ │ ▼ │ Agent A 继续执行原任务 │ └── 不合理 → 向 Agent A 说明原因，协商替代方案 ``` ### 5.3 通信模板 当 Agent A 需要 Agent B 协助时，Agent A 应输出： ```markdown ## 协作请求 **请求方**：[Agent A 名称] **协助方**：[Agent B 名称] **请求原因**：[为什么需要协助] **前置上下文**：[Agent A 已经完成的工作 / 已知信息] **具体需求**： 1. [需求 1] 2. [需求 2] **期望输出**：[Agent B 需要返回什么] **接口定义**：[数据格式 / API 接口 / 文件格式] ``` 总调度收到后： 1. 确认需求完整性和合理性 2. 加载 Agent B 的定义文件 3. 将协作需求转发给 Agent B（附带上下文） 4. Agent B 完成后，将结果和上下文一并交回 Agent A ### 5.4 多阶段协作示例 ``` 项目：开发一个电商网站 阶段 1：前端开发（Agent A: 前端开发者） → 完成页面 UI 后，需要后端 API 定义 → 向总调度发出协作请求 阶段 2：后端开发（Agent B: 后端架构师） → 总调度将前端的需求转发给后端架构师 → 后端架构师设计 API 并返回接口规范 阶段 3：继续前端开发（Agent A） → 总调度将 API 规范交回前端开发者 → 前端开发者对接 API 完成开发 阶段 4：数据库优化（Agent C: 数据库优化师） → 总调度根据整体需求，在必要时调度数据库优化师 阶段 5：最终审查（审查官） → 所有开发完成后，提交审查官进行最终审查 ``` --- ## 6. 审查门禁 所有经过多 Agent 流程产生的交付物，最终必须经过审查 Agent 的验收。 ### 6.1 审查流程 ``` 专业 Agent 交付产出 │ ▼ 加载 agents/reviewer/审查官.md │ ▼ 审查官进行五维审查： ┌─────────────────────────────┐ │ ① 功能性审查 │ │ ② 代码质量审查 ← 可调代码审查员│ │ ③ 安全审查 ← 可调安全Agent│ │ ④ 架构审查 ← 可调架构师 │ │ ⑤ 完整性审查 │ └─────────────────────────────┘ │ ├── ✅ 通过 → 总调度确认合并 → 交付用户 │ └── ❌ 不通过 → 返回对应 Agent 修改 → 重新审查 ``` ### 6.2 审查分级 | 级别 | 标记 | 含义 | 处理方式 | |------|------|------|---------| | 🔴 阻塞性 | 必须修复 | 存在功能性缺陷或安全漏洞 | 返回原 Agent 修复后重新审查 | | 🟡 建议性 | 应修复 | 不符合最佳实践或存在优化空间 | 建议修复，可协商延期 | | 🔵 可优化 | 值得考虑 | 可进一步优化的方向 | 记录到改进清单，非强制 | ### 6.3 审查结论 - **✅ 通过**：所有阻塞性问题已修复，交付物可合并 - **🔄 有条件通过**：存在建议性问题但已协商处理方案 - **❌ 不通过**：存在阻塞性问题，需返回修改 --- ## 7. 最佳实践 ### ✅ 推荐做法 | # | 实践 | 说明 | |---|------|------| | 1 | **先评估再调度** | 不要默认启用多 Agent，按 §3 的评估矩阵判断 | | 2 | **精准匹配 Agent** | 根据 Agent 的 `description` 精确匹配，不要只看部门名 | | 3 | **审评分立** | 总调度不执行具体工作，审查官不参与编写，保持客观 | | 4 | **上下文完整传递** | 跨 Agent 通信时确保上下文信息完整，避免信息丢失 | | 5 | **按需启用** | 简单任务直接处理，5 分钟能搞定的事不走多 Agent 流程 | ### ❌ 避免做法 | # | 陷阱 | 后果 | |---|------|------| | 1 | 所有任务都用多 Agent | 大炮打蚊子，浪费时间和 token | | 2 | Agent 之间直接通信 | 上下文混乱，调度失控 | | 3 | 同一人又写又审 | 等于没审，bug 自检不出来 | | 4 | Agent 匹配不精确 | 输出质量下降，需要反复修改 | | 5 | 跳过审查门禁 | 问题遗漏到交付物中 | ### 🎯 多 Agent 的真正价值 > **多 agent 最大的价值不是快，是稳。** > > 单 agent 长 session 干着干着就偷懒、丢上下文、看不出自己的 bug。拆开之后每个 agent 上下文干净只干一件事，输出质量稳定很多。 > > 总调度 + 专业 Agent + 审查官 的三层架构，确保每个环节都有明确的责任人和质量检查点。 --- ## 8. 测试与评估 本 SKILL 附带一组可复用的评估用例（`evals/evals.json`），用于验证任务评估决策是否准确： - **用途**：每个用例给定一个任务描述（`prompt`），预期得到决策结论（`expected_decision`：`direct_handle` / `call_dispatcher` / `full_multi_agent`）、评分区间（`expected_score`）与匹配的 Agent 列表（`expected_agents`） - **使用方式**：修改 SKILL 或 `总调度.md` 后，用这些用例自测评估逻辑；将实际决策与 `expected_*` 字段对比，不一致即说明评估规则回归 - **评分基准**：`expected_score` 取值区间对应 §3.2 决策矩阵（4-5 直接处理 / 6-8 调用总调度 / 9-12 完整多 Agent 流程） - **当前用例**：跨领域电商（full_multi_agent）、高并发秒杀架构（call_dispatcher）、简单组件（direct_handle） - **注意事项**：`expected_agents` 中的 Agent ID 必须存在于 `agents/` 目录（新增/删除 Agent 时同步更新用例） --- ## 致谢与声明 本 SKILL 中集成的 251 个 Agent 定义文件基于以下开源项目： - [agency-agents-zh](https://github.com/jnMetaCode/agency-agents-zh) — 中文版 AI 智能体专家团队（266 个角色，19 个部门） - [agency-agents](https://github.com/msitarzewski/agency-agents) — 上游英文原版 感谢以上项目的贡献者。本 SKILL 在完整翻译和本土化的基础上，对文件结构进行了重组，并增加了总调度 Agent 和审查 Agent 两个核心角色。