Claude Code-12并发编排实战测评：多Agent协同运行

Claude Code 并发编排实战：让多个 Agent 同时跑起来

上篇我们讨论了编排器，但那是串行模式——Agent A 完成后 Agent B 才启动。这种设计完全合理，因为 B 依赖 A 的输出结果。

然而在某些场景中，Agent 之间互不依赖。举个例子，前端审查和后端审查完全可以并行展开。

并发编排的核心判断逻辑其实很直观：若 Agent B 不需要 Agent A 的输出作输入，就无需排队等待，直接并行执行即可。

一、串行的性能瓶颈

先分析串行的问题——别误解，串行本身没问题，但用错地方就成了性能瓶颈。上篇的编排器，三步全串行：

代码质量审查 → 安全漏洞扫描 → 性能优化分析
   (3 min)        (2 min)         (2 min)总耗时：7 分钟

这种串行逻辑站得住脚，因为安全扫描需要基于代码审查结果圈定重点，性能分析也得依靠前两轮的问题线索才能做到精准定向。

但换一个场景——全栈审查，前端与后端各自独立：

前端审查（代码 + 安全 + 性能）→ 后端审查（代码 + 安全 + 性能）
           (5 min)                       (5 min)总耗时：10 分钟

前端和后端互不依赖，串行执行纯粹是浪费时间。换成并发：

前端审查 ──┐
           ├── 同时执行
后端审查 ──┘总耗时：5 分钟（取最慢的那个）

能节省将近一半的时间，而结果完全一致。

二、什么时候能并发，什么时候不能

判断标准其实只一条：Agent 之间是否存在数据依赖？

能并发的典型场景

不能并发的典型场景

一句话总结：前面的输出是后面的输入 → 串行；彼此不需要 → 并发。

三、实战案例：全栈并发审查编排器

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 路并发就够用了。

注意事项 3：错误处理更复杂

串行模式下，一个 Agent 出错直接停掉后续就行，简单粗暴。但并发模式下，一个出错时另一个可能还在跑：

• 保守策略：一个出错就停掉所有，输出已有结果
• 实用策略：让其他 Agent 跑完，最后统一汇报所有结果（包括出错的那个）

建议用实用策略——报错本身就是信息，让剩下的 Agent 继续跑，结果会更完整。

六、三种编排模式速查

选择流程：

1. 列出所有 Agent，标注它们之间的依赖关系
2. 没有依赖的 → 划为同一组，并发执行
3. 有依赖的 → 做成串行链，按依赖顺序执行
4. 多条串行链之间 → 可以并发

七、关键文件速查

总结口诀：有依赖就串行，无依赖就并发，复杂场景混合用。并发前先自检——把顺序反过来，结果一样吗？

来源：互联网