Agent orchestra

Agent Orchestra — 多智能体协作系统

251 个专业 Agent · 19 个部门 · 总调度 + 专业执行 + 审查门禁

核心理念：先评估、再调度、审评分立、跨 Agent 协作，追求的不是快，而是稳。

---

目录

1. 系统架构
2. 快速开始
3. 任务评估与决策
4. Agent 调度流程
5. 跨 Agent 通信机制
6. 审查门禁
7. 最佳实践

---

1. 系统架构

用户请求
    │
    ▼
┌─────────────────────────────────────┐
│          任务评估（由 SKILL 完成）     │ ← 评估复杂度、跨领域程度、交付要求
│  简单 → 直接处理  │  复杂 → 进入调度  │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│     总调度 Agent（agents/dispatcher/） │ ← 负责任务拆解、Agent 匹配、分配、协调
└──────────┬──────────────────────────┘
           │
    ┌──────┼──────────┬──────────┐
    ▼      ▼          ▼          ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────────┐
│专业 A │→│专业 B │→│专业 C │ │  审查官   │
│      │←│      │  │      │ │ (门禁)   │
└──────┘ └──────┘ └──────┘ └──────────┘
   │        │        │           │
   └────────┴────────┴───────────┘
              │
              ▼
        最终交付物

角色分工

角色	职责	是否执行工作	文件位置
总调度	任务评估、Agent 匹配、分配调度、跨 Agent 协调	❌（只分配不执行）	agents/dispatcher/总调度.md
专业 Agent	在各自领域内编写代码/设计/内容/分析	✅	agents/<department>/
审查官	多维度审查（功能/代码/安全/架构/合规）	❌（只审不写）	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：总调度分配任务

总调度明确以下信息后分配任务：

## 调度指令

**任务**：[子任务描述]
**目标 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 应输出：

## 协作请求

**请求方**：[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 + 审查官 的三层架构，确保每个环节都有明确的责任人和质量检查点。

---

致谢与声明

本 SKILL 中集成的 251 个 Agent 定义文件基于以下开源项目：

• agency-agents-zh — 中文版 AI 智能体专家团队（266 个角色，19 个部门）
• agency-agents — 上游英文原版

感谢以上项目的贡献者。本 SKILL 在完整翻译和本土化的基础上，对文件结构进行了重组，并增加了总调度 Agent 和审查 Agent 两个核心角色。