Claude Code 并发编排实战：让多个 Agent 同时跑起来
上一篇讲了 Workflow 与 Orchestrator 的选择，这篇进阶——当多个 Agent 之间没有依赖关系时，怎么让它们并发执行，把等待时间砍掉。
先说结论
上一篇讲的编排器是串行的——Agent A 跑完，Agent B 才开始。这没毛病，因为 B 需要 A 的结果。
但有些场景，Agent 之间互不依赖。比如前端审查和后端审查，完全可以同时跑。
并发编排的核心判断：如果 Agent B 不需要 Agent A 的输出作为输入，就没必要等，直接并发。
一、串行的性能瓶颈
上一篇的编排器，3 步全串行：
代码质量审查 → 安全漏洞扫描 → 性能优化分析
(3 min) (2 min) (2 min)
总耗时：7 分钟
这种串行没问题，因为安全扫描需要代码审查的结果来重点关注，性能分析也需要前两轮的问题线索。
但换一个场景——全栈审查，前端和后端同时检查：
前端审查（代码 + 安全 + 性能）→ 后端审查（代码 + 安全 + 性能）
(5 min) (5 min)
总耗时：10 分钟
前端和后端互不依赖，串行跑纯属浪费时间。并发跑：
前端审查 ──┐
├── 同时执行
后端审查 ──┘
总耗时：5 分钟（取最慢的那个）
节省近一半时间，结果完全一样。
二、什么时候能并发，什么时候不能
核心判断标准只有一个：Agent 之间有没有数据依赖？
能并发的典型场景
| 场景 | 并发的 Agent | 为什么能并发 |
|---|---|---|
| 全栈审查 | 前端审查 + 后端审查 | 前后端代码互不相关 |
| 多模块审查 | 模块 A 审查 + 模块 B 审查 + 模块 C 审查 | 各模块独立 |
| 代码 + 文档 | 代码审查 + 文档检查 | 两个维度独立 |
| 多语言项目 | TS 审查 + Go 审查 + Python 审查 | 语言间无依赖 |
不能并发的典型场景
| 场景 | 为什么不能并发 | 正确做法 |
|---|---|---|
| 代码审查 → 安全扫描 | 安全扫描需要代码审查的问题来重点关注 | 串行 |
| 架构设计 → 代码生成 | 代码生成依赖架构设计的输出 | 串行 |
| 代码生成 → 测试编写 | 测试依赖代码的 API 签名 | 串行 |
一句话：前面的输出是后面的输入 → 串行；互不需要 → 并发。
三、实战案例：全栈并发审查编排器
3.1 需求分析
项目是 Monorepo，前端 React + 后端 NestJS。一次全栈审查需要：
- 前端：代码质量 + 安全扫描 + 性能优化（串行，有依赖）
- 后端：代码质量 + 安全扫描 + 性能优化（串行，有依赖）
前端和后端之间互不依赖，可以并发。
3.2 编排器实现
# .claude/agents/fullstack-review-orchestrator.md
---
name: fullstack-review-orchestrator
description: 并发执行前端 + 后端审查，输出全栈综合报告
tools: Agent
model: inherit
triggers:
- 全栈审查
- 前后端审查
---
# 角色定位
你是全栈审查编排器，负责**同时**协调前端和后端两组审查 Agent 并发执行，最后整合输出综合报告。
前端和后端互不依赖，因此并发执行以节省时间。
# 你必须严格遵循的工作流程
## 步骤 1: 解析用户输入
- 获取用户指定的检查范围
## 步骤 2: 并发触发两个审查 Agent
**同时调用以下两个 Agent，不要等一个完成再调另一个：**
### 2a: 前端审查
- 调用 frontend-code-reviewer
- 检查范围：前端相关文件
- prompt: "请对前端代码进行完整审查，涵盖代码质量、安全漏洞、性能优化"
### 2b: 后端审查
- 调用 nestjs-code-review
- 检查范围：后端相关文件
- prompt: "请对后端代码进行完整审查，涵盖代码质量、安全漏洞、性能优化"
## 步骤 3: 等待两个 Agent 都完成后，评估结果
- 统计前端严重问题数量
- 统计后端严重问题数量
- 如果任一侧存在严重问题且未设置 --continue-on-error：
输出已有结果并停止
## 步骤 4: 整合输出全栈综合报告
- 分别汇总前端和后端的问题
- 统一按 P0 → P1 → P2 重新排序
- 标注每个问题归属前端/后端
- 输出格式化的综合审查报告
3.3 关键设计点
设计点 1：在 prompt 中明确说"同时调用"
编排器是 LLM 驱动的，它需要你显式告诉它"并发"。如果你写"先调用 A，再调用 B"，它就会串行。必须写"同时调用以下两个 Agent，不要等一个完成再调另一个"。
设计点 2：评估阶段等所有并发 Agent 完成
并发触发后，不能拿到一个结果就往下走。步骤 3 明确写了"等待两个 Agent 都完成后"再评估，避免拿到前端结果就急着输出。
设计点 3：整合时标注归属
并发 Agent 的输出混在一起时，用户分不清哪个问题是前端的、哪个是后端的。输出模板里每个问题都要标注 [前端] 或 [后端]。
3.4 输出模板
# 全栈代码审查报告
## 审查信息
- 触发时间: {{DATE}}
- 执行方式: 前端 + 后端并发审查
- 审查阶段: 前端审查 ✓ | 后端审查 ✓
---
## 前端审查结果
（前端审查 Agent 的完整输出）
---
## 后端审查结果
（后端审查 Agent 的完整输出）
---
## 综合优先级排序
### 🔴 P0 - 立即修复
1. [前端] ...
2. [后端] ...
### 🟠 P1 - 尽快修复
1. [前端] ...
2. [后端] ...
### 🟡 P2 - 可选优化
1. [前端] ...
2. [后端] ...
四、进阶：串行 + 并发混合模式
真实项目往往不是纯串行或纯并发，而是混合的。
4.1 混合模式示例
需求：全栈审查，前端三个维度串行（有依赖），后端三个维度也串行，但前端和后端之间并发。
并发启动 ─┬─ 前端代码质量 → 前端安全扫描 → 前端性能分析（串行链）
│
└─ 后端代码质量 → 后端安全扫描 → 后端性能分析（串行链）
两条串行链都完成后 → 整合全栈综合报告
编排器写法：
## 步骤 2: 并发触发两条串行审查链
**同时调用以下两个 Agent：**
### 2a: 前端完整审查
- 调用 full-frontend-review-orchestrator
- 这个编排器内部会串行执行：代码质量 → 安全扫描 → 性能优化
- prompt: "请对前端代码执行完整审查（代码质量 → 安全 → 性能）"
### 2b: 后端完整审查
- 调用 full-backend-review-orchestrator
- 这个编排器内部会串行执行：代码质量 → 安全扫描 → 性能优化
- prompt: "请对后端代码执行完整审查（代码质量 → 安全 → 性能）"
## 步骤 3: 等待两条链都完成
关键点：编排器可以嵌套。 全栈编排器并发调用两个子编排器，每个子编排器内部又是串行的。
4.2 更复杂的混合：三路并发 + 串行收尾
并发启动 ─┬─ 前端审查
├─ 后端审查
└─ 共享包审查
三路都完成后 → 串行执行：跨系统一致性检查（需要三路结果作为输入）
## 步骤 2: 并发触发三个审查 Agent
同时调用：
- frontend-reviewer → 审查前端代码
- backend-reviewer → 审查后端代码
- shared-package-reviewer → 审查共享包代码
## 步骤 3: 等待三者都完成
## 步骤 4: 跨系统一致性检查（串行，需要前面三路的结果）
- 调用 cross-system-consistency-checker
- 把三路审查发现的问题都传给它
- prompt: "以下是前端、后端、共享包各自的审查结果，
请检查三端之间的接口定义是否一致、类型是否对齐、API 契约是否匹配"
这个模式先并发收集信息，再串行做跨系统分析——兼顾速度和依赖。
五、并发编排的三个注意事项
注意事项 1：只对真正独立的 Agent 并发
如果 Agent B 需要 Agent A 的输出，强行并发只会让 B 拿不到数据。结果不是更快，而是更错。
快速自检：把两个 Agent 的执行顺序反过来，结果是否一样？如果一样 → 可以并发；如果不一样 → 必须串行。
注意事项 2：并发数量要控制
同时跑太多 Agent 会挤占上下文窗口和 Token 预算。一般 2-3 路并发就够了。
| 并发数 | 适合场景 | 风险 |
|---|---|---|
| 2 路 | 全栈（前端 + 后端） | 低 |
| 3 路 | 多模块（前端 + 后端 + 共享包） | 中 |
| 4+ 路 | 大型 Monorepo 多模块 | 高，上下文和 Token 可能不够 |
注意事项 3：错误处理更复杂
串行模式下，一个 Agent 出错直接停掉后续就行。并发模式下，一个出错时另一个可能还在跑：
- 保守策略：一个出错就停掉所有，输出已有结果
- 实用策略：让其他 Agent 跑完，最后统一汇报所有结果（包括出错的那个）
建议用实用策略——报错也是信息，让剩下的 Agent 继续跑，结果更完整。
六、三种编排模式速查
| 模式 | 适用场景 | Agent 关系 | 耗时 | 上一篇案例 |
|---|---|---|---|---|
| 纯串行 | 后一步依赖前一步 | 强依赖 | 所有 Agent 耗时之和 | 前端审查编排器 |
| 纯并发 | 所有 Agent 互不依赖 | 无依赖 | 最慢 Agent 的耗时 | 本文全栈审查 |
| 混合 | 部分依赖、部分独立 | 混合 | 依赖链 + 并发组 | 本文混合模式 |
选择流程：
- 列出所有 Agent，标注它们之间的依赖关系
- 没有依赖的 → 同一组，并发执行
- 有依赖的 → 串行链，按依赖顺序执行
- 多条串行链之间 → 并发
七、关键文件速查
| 文件 | 类型 | 说明 |
|---|---|---|
.claude/agents/fullstack-review-orchestrator.md | 并发编排器 | 全栈并发审查（本文新增） |
.claude/agents/full-frontend-review-orchestrator.md | 串行编排器 | 前端串行审查（上一篇） |
.claude/agents/frontend-code-reviewer.md | 子 Agent | 前端代码质量 |
.claude/agents/frontend-security-auditor.md | 子 Agent | 前端安全扫描 |
.claude/agents/frontend-performance-expert.md | 子 Agent | 前端性能优化 |
.claude/agents/nestjs-code-review.md | 子 Agent | 后端代码质量 |
.claude/agents/nestjs-security-audit.md | 子 Agent | 后端安全扫描 |
.claude/agents/nestjs-performance-audit.md | 子 Agent | 后端性能审计 |
总结口诀：有依赖就串行，无依赖就并发，复杂场景混合用。并发前先自检——把顺序反过来，结果一样吗？
