关于 Agent Orchestrator
Agent Orchestrator 是用于协调专业 AI Agent、技能与工具的技能,面向需要多方协作的复杂任务。它负责拆分任务、管理并行或串行执行及故障,并整合和验证结果。
主要功能
- 01任务拆分与委派
- 02并行和串行 Agent 工作流
- 03按需选择专业 Agent
- 04故障恢复与备用方案
- 05结果整合与验证
适用场景
- 01将复杂项目分配给不同专家
- 02并发执行相互独立的子任务
- 03通过 Agent 流水线传递结果
- 04处理 Agent 超时或错误
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ eddiebe147/ claude-settings --skill agent-orchestrator安装后在 Claude Code 中输入/agent-orchestrator确认已加载。
详细介绍
Agent 编排器
Agent 编排器技能负责协调多个专业 AI Agent、技能和工具,以完成需要发挥分布式专业知识优势的复杂任务。它充当指挥者,将子任务委派给合适的 Agent,管理依赖关系,整合结果,并确保最终输出连贯一致。
此技能了解可用 Agent(通用型、运营经理和专业技能)的能力,确定最优的任务分解方式,管理 Agent 间的通信,处理故障,并综合多样化的输出,形成统一结果。它是让多 Agent 协作发挥作用的元层。
对于需要多种专业知识的复杂项目、适合并行执行的任务,或专业 Agent 优于通用方法的工作流,请使用此技能。
核心工作流
工作流 1:分解任务并委派
- 分析复杂任务:
- 最终目标是什么?
- 任务包含哪些部分?
- 需要哪些专业知识?
- 匹配可用 Agent/技能:
- 哪些 Agent 具备相关能力?
- 每个 Agent 的专长是什么?
- 它们可以使用哪些工具/MCP?
- 分解为子任务:
- 按专业领域划分
- 确定依赖关系
- 确定执行顺序
- 委派给合适的 Agent:
- 分配子任务并提供明确指示
- 提供必要的上下文
- 设定成功标准
- 指定输出格式
- 监控执行:
- 跟踪进度
- 发现阻塞因素
- 处理故障
- 整合结果:
- 收集 Agent 的输出
- 解决冲突
- 综合形成连贯的整体
- 验证最终结果
工作流 2:并行执行 Agent
- 识别可并行处理的子任务:
- 哪些任务相互独立?
- 哪些任务没有共同依赖?
- 哪些任务可以并发运行?
- 准备并行执行:
- 将子任务分配给 Agent
- 提供彼此隔离的上下文
- 设置超时限制
- 并行启动Agent:
- 同时启动所有 Agent
- 保持上下文彼此独立
- 监控所有执行过程
- 协调任务完成:
- 等待所有任务完成
- 处理迟迟未完成的任务
- 管理超时故障
- 汇总结果:
- 收集所有输出
- 合并相关发现
- 解决不一致之处
- 综合最终输出
工作流 3:顺序 Agent 流水线
- 设计流水线流程:
- 按依赖关系排列 Agent 顺序
- 定义交接节点
- 指定数据转换方式
- 按顺序执行流水线:
- Agent 1:处理初始输入 → 输出 A
- 验证输出 A
- Agent 2:处理输出 A → 输出 B
- 验证输出 B
- Agent N:处理输出 (N-1) → 最终输出
- 管理Agent 之间的状态:
- 向后续 Agent 传递相关数据
- 在需要时保留上下文
- 丢弃临时产物
- 处理流水线故障:
- 确定发生故障的阶段
- 重试或使用备用方案
- 不要传递错误数据
- 验证端到端结果
工作流 4:自适应 Agent 选择
- 动态评估任务需求:
- 需要哪些能力?
- 复杂程度如何?
- 有哪些限制条件?
- 选择最合适的 Agent:
- 将能力与需求相匹配
- 考虑 Agent 是否可用
- 将过往表现纳入考量
- 适当情况下优先选择专家型 Agent,而非通用型 Agent
- 提供上下文并委派:
- 提供针对任务的具体指示
- 包含相关背景信息
- 设定明确的期望
- 评估Agent 的表现:
- 是否达到标准?
- 质量是否足够?
- 耗时是否可以接受?
- 总结经验以供今后选择:
- 记录各 Agent 擅长的领域
- 留意故障模式
- 优化选择逻辑
工作流 5:错误恢复与回退
- 检测 Agent 故障:
- 任务未完成
- 输出质量不足
- 超时
- 抛出错误
- 诊断故障原因:
- 任务是否不明确?
- Agent 是否选错?
- 输入是否格式错误?
- 依赖项是否不可用?
- 尝试恢复:
- 如果是暂时性错误,使用同一个 Agent 重试
- 如果是能力不匹配,使用不同的 Agent 重试
- 如果任务过于复杂,简化任务后重试
- 如果无法恢复,则升级给人工处理
- 记录故障与恢复情况
- 如果恢复成功,则继续工作流
快速参考
| 操作 | 命令/触发语 |
|---|---|
| 委派复杂任务 | "Orchestrate agents for [task]" |
| 并行运行 Agent | "Run these tasks in parallel: [tasks]" |
| 创建 Agent 流水线 | "Create pipeline: [agent1] → [agent2] → [agent3]" |
| 选择最佳 Agent | "Which agent should handle [task]?" |
| 协调工作流 | "Coordinate [workflow] across agents" |
| 处理 Agent 故障 | "Agent [X] failed on [task], recover" |
| 整合 Agent 输出 | "Synthesize outputs from [agents]" |
最佳实践
-
根据任务匹配专业能力:专业工作使用专门的 Agent
- 使用 Operations Manager 协调项目
- 使用 UI Builder 设计组件
- 使用 Database Designer 设计架构
- 不要事事都使用通用型 Agent
-
提供清晰的上下文:每个 Agent 都需要了解自己的角色
- 更大的目标是什么?
- 这个 Agent 的具体职责是什么?
- 预期输出是什么?
- 这项工作如何融入工作流?
-
管理依赖关系:明确执行顺序
- Agent B 需要 Agent A 的输出
- Agent C 可以与 Agent A 和 B 并行运行
- Agent D 等待 Agent B 和 C
-
验证交接内容:不要在 Agent 之间传递错误数据
- 检查输出格式
- 验证完整性
- 根据架构验证
- 出现问题时立即失败
-
妥善处理故障:Agent 有时会失败
- 准备备用 Agent
- 实施重试逻辑
- 避免故障级联
- 记录信息以供事后复盘
-
优化沟通:尽量减少 Agent 之间的交流
- 只传递必要的数据
- 使用结构化格式
- 避免冗余信息
- 适当压缩
-
监控进度:了解当前情况
- 跟踪哪些 Agent 正在运行
- 找出瓶颈
- 尽早检测故障
- 提供状态更新
-
周全地整合:协调整合不同输出
- 解决冲突
- 保持一致性
- 保留重要细节
- 形成统一的叙述
Agent 能力图谱
可用 Agent/技能
| Agent/技能 | 专长 | 最适合 | 不适合 |
|---|---|---|---|
| General-Purpose | 广泛任务 | 快速任务、通用编码 | 复杂编排 |
| Operations Manager | 项目协调 | 工作流、时间线、资源 | 编写代码 |
| UI Builder | 前端设计 | 组件、布局、样式 | 后端逻辑 |
| Database Designer | 架构设计 | 表、关系、RLS | 前端工作 |
| API Designer | 端点设计 | RESTful API、验证 | UI/UX |
| Testing QA | 测试创建 | E2E 测试、测试计划 | 功能开发 |
| Performance Optimizer | 速度优化 | 指标、缓存、延迟加载 | 初始开发 |
| Deployment Automation | CI/CD | Vercel、环境、流水线 | 功能编码 |
| Prompt Engineer | AI 优化 | 改进提示词、AI 工作流 | 非 AI 任务 |
| Skill Creator | 技能开发 | 创建新技能 | 日常任务 |
| Workflow Designer | 流程设计 | 复杂工作流 | 简单任务 |
| Chain Builder | 提示词序列 | 多步骤 AI 任务 | 单条提示词 |
MCP/工具访问
| Agent | 可用 MCP/工具 |
|---|---|
| 通用 | 全部(Playwright、Supabase、GitHub、Firecrawl、Memory) |
| 运营经理 | GitHub(PR、问题),Memory(跟踪) |
| UI 构建者 | Playwright(测试),Memory(设计决策) |
| 数据库设计师 | Supabase(迁移、查询),Memory(架构) |
| 测试 QA | Playwright(端到端测试),GitHub(测试运行) |
编排模式
模式 1:专家小组
Task → [Expert A, Expert B, Expert C] → Synthesize → Decision
适用场景:需要针对同一问题征求多方意见 示例:架构决策 → [性能专家、安全专家、可维护性专家] → 建议
模式 2:流水线
Task → Agent A → Agent B → Agent C → Output
适用场景:需要按顺序进行转换 示例:设计 → 实现 → 测试 → 部署
模式 3:分而治之
Task → Split → [Agent 1: Part A, Agent 2: Part B, Agent N: Part N] → Merge → Output
适用场景:大型任务可拆分为多个独立部分 示例:多页面应用 → [每个页面由一个 Agent 负责] → 集成
模式 4:监督者-工作者
Supervisor analyzes → Delegates to Workers → Workers execute → Supervisor integrates
适用场景:需要集中协调 示例:项目经理 → [功能开发者] → 集成
模式 5:协作改进
Agent A: Draft → Agent B: Critique → Agent A: Revise → Validate → Output
适用场景:通过迭代提升质量 示例:作者 → 审阅者 → 作者 → 定稿
模式 6:专家路由
Analyze task → Route to appropriate specialist → Specialist executes → Return
适用场景:不同类型的任务需要不同的 Agent 示例:问题分流 → [Bug 交给 QA | 功能交给开发者 | 运维交给 DevOps]
委派模板
标准委派
**Agent**: [Agent name]
**Task**: [Clear, specific task description]
**Context**: [Relevant background information]
**Inputs**: [Provided data/resources]
**Expected Output**: [Format and content requirements]
**Success Criteria**: [How to know it's done well]
**Constraints**: [Limitations or requirements]
**Deadline**: [If time-sensitive]
并行委派
**Parallel Execution**: [N agents]
**Agent 1**: [Agent name]
- Task: [Task 1]
- Output: [Output 1]
**Agent 2**: [Agent name]
- Task: [Task 2]
- Output: [Output 2]
**Integration**: [How to combine outputs]
流水线委派
**Pipeline**: [Agent A] → [Agent B] → [Agent C]
**Stage 1**: [Agent A]
- Input: [Initial data]
- Task: [Transform 1]
- Output: [Intermediate 1]
**Stage 2**: [Agent B]
- Input: [Intermediate 1]
- Task: [Transform 2]
- Output: [Intermediate 2]
**Stage 3**: [Agent C]
- Input: [Intermediate 2]
- Task: [Transform 3]
- Output: [Final output]
协调策略
实时协调
- 适用场景:Agent 需要在执行过程中交互
- 方式:共享上下文、消息传递、状态更新
- 权衡:更复杂,但更灵活
批量协调
- 适用场景:Agent 独立工作,最后再集成
- 方式:收集所有输出,然后合并
- 权衡:更简单,但适应性较差
层级协调
- 适用场景:权责结构明确
- 方式:监督者进行委派,工作者汇报结果
- 权衡:结构清晰,但可能形成瓶颈
点对点协调
- 适用场景:Agent 平等协作
- 方式:共享工作区、相互了解进展
- 权衡:灵活,但需要明确的协议
冲突解决
当 Agent 产出互相冲突时:
-
识别冲突:
- 哪些内容不一致?
- 哪些 Agent 意见不一?
- 分歧的性质是什么?
-
评估来源:
- 哪个 Agent 在此问题上更权威?
- 置信度如何?
- 理由是什么?
-
使用策略解决:
- 权威性:信任专家
- 投票:少数服从多数(适用于多个 Agent)
- 综合:结合双方的优点
- 升级处理:请人类作出决定
-
记录解决结果:
- 冲突是什么?
- 如何解决的?
- 为什么选择这种方案?
性能优化
降低开销
- 单个 Agent 足以完成时,不要进行编排
- 尽量减少交接和数据传递
- 对独立任务使用并行执行
- 缓存重复计算结果
负载均衡
- 在各 Agent 间均匀分配工作
- 避免单个 Agent 成为瓶颈
- 考虑 Agent 的容量和速度
- 使用排队机制处理突发工作负载
故障隔离
- 不要让一个 Agent 的故障导致工作流崩溃
- 对不可靠的 Agent 使用熔断器
- 准备备用方案
- 实施超时限制
监控与可观测性
跟踪以下指标:
- Agent 利用率:每个 Agent 有多忙?
- 任务完成时间:每个 Agent 需要多长时间?
- 成功率:哪些 Agent 成功或失败?
- 交接效率:交接是否顺畅?
- 集成质量:输出整合得如何?
- 错误率:故障发生在哪里?
- 成本:每个 Agent 的 Token 用量
编排示例
功能开发工作流
**Orchestrator**: Coordinate feature development
1. **Requirements Analysis** (Operations Manager)
- Clarify requirements
- Define scope
- Identify constraints
2. **Parallel Design Phase**
- **UI Builder**: Design components
- **Database Designer**: Design schema
- **API Designer**: Design endpoints
3. **Integration Review** (Orchestrator)
- Ensure designs are compatible
- Resolve conflicts
- Approve for implementation
4. **Implementation** (General-Purpose)
- Build based on approved designs
5. **Quality Assurance** (Testing QA)
- Generate E2E tests
- Run test suite
- Report issues
6. **Fix Issues** (General-Purpose)
- Address failing tests
7. **Deployment** (Deployment Automation)
- Deploy to staging
- Verify deployment
- Deploy to production
内容创作流水线
**Orchestrator**: Create technical blog post
1. **Research** (General-Purpose + Firecrawl)
- Gather sources
- Extract key information
2. **Parallel Analysis**
- **Prompt Engineer**: Analyze for clarity
- **Workflow Designer**: Identify structure
- **Output Formatter**: Determine format
3. **Draft** (General-Purpose)
- Write based on research and analysis
4. **Review & Edit** (Prompt Engineer)
- Review for quality
- Suggest improvements
5. **Revise** (General-Purpose)
- Apply feedback
6. **Format** (Output Formatter)
- Format for target platform
7. **Generate Metadata** (General-Purpose)
- SEO metadata
- Social snippets