企业官网建设流程全解析

title: 记忆系统与 Agent 定制完全指南（六）Agent 编排与调度——多 Agent 协作开发
date: 2026-07-10
category: AI 开发工具
tags: [Claude Code, Agent, 编排, 调度, 协作]

记忆系统与 Agent 定制完全指南（六）：Agent 编排与调度

一个 Agent 做好一件事，多个 Agent 协作做好一件事。本篇教你编排多个 Agent 协同工作，让 Claude 变成一个真正的开发团队。

前言

想象一个场景：

你要开发一个"数据报表"模块，包含： - 后端 API（Controller + Service + Mapper） - 前端页面（列表、详情、导出） - 类型定义 - 路由配置 - 单元测试 如果让一个 Agent 串行做，可能要 30 分钟。 但如果派出 4 个 Agent 并行做，可能 8 分钟就完成了。

这就是 Agent 编排的力量。

一、Agent 编排的基本模式

1.1 串行编排

Agent A → Agent B → Agent C

前一个 Agent 的输出是后一个 Agent 的输入。

典型场景：需求分析 → 代码生成 → 测试编写

需求分析 Agent： 输入：用户描述 输出：接口清单 + 数据结构 代码生成 Agent： 输入：接口清单 + 数据结构 输出：后端代码 测试编写 Agent： 输入：后端代码 + 接口清单 输出：单元测试

1.2 并行编排

┌→ Agent A1 │ Master Agent ──────→→ Agent A2 │ └→ Agent A3

多个 Agent 同时工作，最后汇总结果。

典型场景：前后端并行开发

Master Agent（调度器） ├── 后端 Agent：开发 API 接口 ├── 前端 Agent：开发页面组件 └── 类型 Agent：定义数据结构

1.3 条件编排

Agent A → 条件判断 → Agent B1 或 Agent B2

根据 Agent A 的结果，动态选择后续 Agent。

典型场景：代码审查后自动修复

审查 Agent： 发现问题 → 修复 Agent 执行修复 无问题 → 结束 审查 Agent： 发现安全问题 → 安全 Agent 深入审查 发现性能问题 → 性能 Agent 深入审查 发现质量问题 → 质量 Agent 深入审查

二、Agent 调度器：Master Agent

2.1 什么是 Master Agent

Master Agent 是一个特殊的 Agent，它的唯一职责是调度其他 Agent。它不直接写代码，而是把任务分发给专业 Agent。

2.2 Master Agent 定义

--- name: master-developer description: 多 Agent 协作调度器，分配任务给专业 Agent model: opus effort: high tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, TaskCreate, TaskUpdate, TaskList] --- # 多 Agent 协作调度器 ## 角色定义 你是一个多 Agent 协作调度器。你的职责是理解需求， 拆分成子任务，分发给专业 Agent 并行执行， 最后汇总结果并验证一致性。 ## 可用的专业 Agent | Agent | 职责 | 工具 | |-------|------|------| | backend-developer | 后端 Java 开发 | Read, Write, Edit, Glob, Grep, Bash | | frontend-developer | 前端 Vue 开发 | Read, Write, Edit, Glob, Grep, Bash | | db-engineer | 数据库设计与迁移 | Read, Write, Bash | | tester | 测试编写 | Read, Write, Bash | ## 调度流程 ### 步骤 1: 需求分析 理解用户需求，拆分成独立的子任务。 ### 步骤 2: 依赖分析 确定子任务之间的依赖关系： - 无依赖的任务 → 并行执行 - 有依赖的任务 → 串行执行 ### 步骤 3: 任务分发 将子任务分配给对应的 Agent。 ### 步骤 4: 进度跟踪 监控各 Agent 的执行进度。 ### 步骤 5: 结果汇总 汇总所有 Agent 的输出，验证一致性。 ### 步骤 6: 集成验证 运行类型检查、构建、测试，确认集成成功。 ## 输出格式

🔄 多 Agent 协作开发
━━━━━━━━━━━━━━━━━━━━━

需求：开发数据报表模块

任务拆分：

1. 类型定义（无依赖，立即执行）→ 类型 Agent
2. 后端 API（依赖任务 1）→ 后端 Agent
3. 前端页面（依赖任务 1）→ 前端 Agent
4. 单元测试（依赖任务 2）→ 测试 Agent

并行执行：
[1/4] 类型定义 → 类型 Agent（独立，立即执行）
[2/4] 后端 API → 等待类型定义完成
[3/4] 前端页面 → 等待类型定义完成
[4/4] 单元测试 → 等待后端 API 完成

执行中…

✅ 类型定义完成（2s）
✅ 后端 API 完成（45s）
✅ 前端页面完成（38s）
✅ 单元测试完成（12s）

集成验证：
TypeScript 编译：✅
单元测试：42/42 通过
构建：✅

━━━━━━━━━━━━━━━━━━━━━
🎉 开发完成！新增文件 8 个，修改文件 2 个

三、实战：多 Agent 协作开发一个模块

3.1 场景

@master-developer 帮我开发一个设备管理模块

3.2 调度过程

Step 1: 需求分析

设备管理模块需要： - 设备列表页面（前端） - 设备详情页面（前端） - 设备 CRUD API（后端） - 设备类型（前端 + 后端共用） - 设备列表路由（前端）

Step 2: 依赖分析

无依赖： - 类型定义（前后端都需要） 依赖类型定义： - 后端 API（使用类型定义） - 前端页面（使用类型定义） 依赖后端 API： - 后端单元测试

Step 3: 并行执行

Phase 1（并行）： Agent 1: 类型 Agent → 创建 device.ts 类型定义 Agent 2: 后端 Agent → 创建 DeviceController/Service/Mapper Agent 3: 前端 Agent → 创建设备列表和详情页面 Phase 2（等待 Phase 1 完成）： Agent 4: 测试 Agent → 创建设备 API 的单元测试

Step 4: 结果汇总

✅ 类型定义：src/types/device.ts（+45 行） ✅ 后端 API：DeviceController.java, DeviceService.java, DeviceMapper.java（+234 行） ✅ 前端页面：Device/List.vue, Device/Detail.vue（+312 行） ✅ 测试：DeviceServiceTest.java（+89 行） 总计：新增 4 个文件，修改 1 个文件（路由配置）

Step 5: 集成验证

TypeScript 编译：✅ 0 errors 后端编译：✅ BUILD SUCCESS 单元测试：✅ 12/12 passed 构建：✅ dist/ (2.5 MB)

四、Agent 间的通信

4.1 通过文件共享数据

Agent A 生成的类型定义文件，Agent B 可以直接读取：

后端 Agent 读取 src/types/device.ts → 生成符合类型定义的 Controller 和 Service

4.2 通过 SendMessage 通信

Agent 之间可以直接发消息：

后端 Agent → SendMessage → 前端 Agent "API 接口已定义，路径是 /api/devices，参数是 DeviceQuery"

4.3 通过 Task 系统协调

Master Agent 使用 Task 系统管理进度：

TaskCreate: "创建设备类型定义" TaskCreate: "创建设备后端 API" TaskCreate: "创建设备前端页面" TaskUpdate: "创建设备后端 API" → addBlockedBy: ["创建设备类型定义"] TaskUpdate: "创建设备前端页面" → addBlockedBy: ["创建设备类型定义"]

五、Agent 调度的最佳实践

5.1 任务拆分原则

✅ 好的拆分： - 每个子任务独立（低耦合） - 任务粒度适中（不要太粗也不要太细） - 依赖关系清晰 ❌ 坏的拆分： - 一个任务包含 10 个文件（太粗） - 每个方法一个任务（太细） - 循环依赖（A 依赖 B，B 依赖 A）

5.2 并行度控制

同时运行的 Agent 数量建议： 小型项目（< 10 个文件）：1-2 个 Agent 中型项目（10-50 个文件）：3-5 个 Agent 大型项目（> 50 个文件）：5-8 个 Agent

太多 Agent 并行会导致：

• Token 消耗爆炸
• 结果混乱，难以汇总
• 资源竞争（多个 Agent 改同一个文件）

5.3 错误处理

当某个 Agent 执行失败时： 1. 停止依赖该 Agent 的所有后续任务 2. 报告错误信息 3. 尝试重新分配或调整任务 4. 如果无法恢复，通知用户

六、Agent 调度 vs Workflow

建议：确定性流程用 Workflow，创造性任务用 Agent 调度。

七、这一章的核心心得

1. Agent 编排有三种模式——串行、并行、条件分支
2. Master Agent 是调度器——它不写代码，只分配任务
3. 依赖分析是关键——无依赖的任务并行执行，有依赖的任务串行执行
4. 任务粒度要适中——一个模块一个 Agent，不要一个方法一个 Agent
5. Agent 间通过文件共享数据——类型定义是天然的共享接口
6. 并行度要控制——3-5 个 Agent 并行是sweet spot

八、下一步

学会了 Agent 的编排与调度，下一篇我们看 Agent 如何与外部工具深度集成——让 Agent 调用数据库、访问 API、操作服务器。

系列目录：

1. 初识记忆系统——什么是记忆？为什么需要记忆？
2. 记忆文件编写规范——怎么写一条好的记忆
3. 记忆的检索与使用——Claude 如何在对话中调用记忆
4. 自定义 Agent 开发（一）——Agent 的定义与结构
5. 自定义 Agent 开发（二）——Agent 的工具与权限
6. Agent 编排与调度← 本篇
7. Agent 与工具的深度集成（待写）
8. 记忆系统与 Agent 配合——构建智能开发助手（待写）