17 · 并行 Agent
01. 从串行到并行：Agent 工作模式的进化
在以往的 Cursor Agent 工作流中，我们习惯了一个 Agent 从头到尾完成整个任务的方式。输入需求 -> 分析代码 -> 修改文件 -> 报错 -> 再修 -> 再报错……这种串行模式在简单任务上够用，但一旦遇到需要探索多种方案、或者任务本身具有多个独立维度时，串行 Agent 的短板就暴露无遗：
- 锁步等待：一个思路卡住，整个任务卡住。
- 思路单一：Agent 容易陷入局部最优，一旦第一次尝试方向错了，后续修补都在错误方向上打转。
- 无法并行探索：人类开发者遇到复杂问题时，会同时尝试几种思路——一个分支改方案 A，另一个分支试方案 B——但传统 Agent 没有这种能力。
Cursor 的 并行 Agent（Parallel Agents） 模式正是为了解决这个问题而生。它允许你同时启动多个 Agent，各自在隔离的环境中独立工作，最后由一个 Judge Agent（裁判 Agent）评估所有结果，选出最优方案。
一句话理解：串行 Agent 像一个人写代码改 bug，并行 Agent 像一个团队同时做原型设计，每人试一条路，最后大家坐下来选最好的方案。
02. 核心机制：Git Worktree 的隔离魔法
并行 Agent 依赖一个底层基础设施——Git Worktree。
什么是 Worktree？
通俗地说，Git Worktree 允许你在同一个仓库的不同目录下，同时 checkout 不同的分支。每个 worktree 就像仓库的一个”平行宇宙”：你可以在 worktree A 上修改方案 A 的代码，同时在 worktree B 上做完全不同的方案 B，互不干扰。
主仓库（main 分支）
├── .claude/worktrees/exp-a/ ← Agent A 的工作区（分支 feature-a）
├── .claude/worktrees/exp-b/ ← Agent B 的工作区（分支 feature-b）
└── .claude/worktrees/exp-c/ ← Agent C 的工作区（分支 feature-c）隔离带来什么好处？
| 特性 | 传统 Agent | 并行 Agent |
|---|---|---|
| 文件隔离 | 所有修改在同一个工作目录 | 每个 Agent 有独立的 worktree |
| 分支隔离 | 依赖手动 branch/stash | 自动创建独立分支 |
| 冲突风险 | 高，容易互相覆盖 | 零冲突，完全隔离 |
| 并行度 | 无法并行 | 可同时运行 N 个 Agent |
| 结果对比 | 人为记住结果 | Judge Agent 系统化评估 |
Worktree 自动管理流程
Cursor 的并行 Agent 模式下，worktree 的创建、切换、销毁是自动完成的：
EnterWorktree(name="exp-a")— 创建新的 worktree 并进入- Agent A 在 exp-a 中自由修改代码、跑测试
- Agent 完成任务后，报告结果
ExitWorktree(action="keep")— 保留 worktree 以备后续查看- 回到主目录，启动下一个并行 Agent
所有这一切对开发者几乎是透明的——你只需要告诉 Cursor 要并行跑几个 Agent 各做什么，剩下的由系统自动编排。
03. 并行 Agent 的三层架构
一个典型的并行 Agent 流程包含三个角色：
第一层：Coordinator（协调者）
协调者是”项目经理”，负责：
- 把大任务拆解成多个独立子任务
- 为每个子任务分配一个 Agent
- 指定评估标准（Judge Agent 用）
- 收集最终结果并呈现给开发者
第二层：Worker Agents（工人 Agent）
工人是”具体的执行者”，每个 Worker 独立在各自的 worktree 中工作：
- 读取相同的需求文档或接口定义
- 尝试不同的实现策略
- 输出可运行的代码、测试结果或分析报告
工人之间不通信——这正是设计意图。隔离确保了方案的独立性，避免了相互影响。
第三层：Judge Agent（裁判 Agent）
裁判是”评审委员会”，它的职责是：
- 审查所有 Worker 的输出
- 根据预设标准（正确性、性能、代码质量、可维护性等）进行打分
- 推荐最优方案
- 有时还会输出综合报告，说明为什么某个方案胜出
┌──────────────────────────────────────────────────┐
│ Coordinator │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │Worker A│ │Worker B│ │Worker C│ ... │
│ │方案 A │ │方案 B │ │方案 C │ │
│ └────┬───┘ └────┬───┘ └────┬───┘ │
│ └──────────┬┴───────────┘ │
│ ▼ │
│ Judge Agent │
│ "方案 B 最优，因为..." │
└──────────────────────────────────────────────────┘04. 实战案例：三路并行实现文件监控
让我们用一个真实的场景来演示并行 Agent 的强大。假设我们需要一个 Python 文件监控工具——当指定目录有文件变更时，自动执行某个命令。我们同时启动三个 Agent，各自采用不同的实现策略。
任务描述
在 /tmp/filewatcher 下实现一个 Python 文件监控脚本：
- 监控一个目录的文件变更（创建、修改、删除）
- 支持递归监控子目录
- 变更时执行用户指定的命令
- 支持防抖（debounce），避免短时间内反复触发三个并行方案
| Agent | 实现策略 | 关键库 | 预期优势 |
|---|---|---|---|
| Agent A | Watchdog 库 + 事件驱动 | watchdog | 成熟稳定，跨平台 |
| Agent B | inotify 系统调用 + 轮询 | pyinotify | 底层控制，性能高 |
| Agent C | 纯 polling + hash 对比 | os.stat + hashlib | 零依赖，纯 Python |
协调者拆解任务
协调者将任务拆解为三个完全相同的子任务描述，唯一区别是指明”请使用 Watchdog/请使用 inotify/请使用 polling”，然后分别派发给三个 Agent。
每个 Worker 的工作
每个 Worker 在自己的 worktree 中：
- 创建脚本文件（如
watcher_watchdog.py） - 实现核心功能（监控、命令执行、防抖）
- 创建测试文件验证功能
- 运行业务测试确保可用
- 撰写简短的自评文档
三个 Agent 完全独立运行，互不知晓对方的存在。
Judge Agent 评估
三个 Worker 完成后，Judge Agent 对比它们的输出：
┌────────────────────────────────────────────────────────────┐
│ Judge Report: File Watcher Implementation Comparison │
├──────────┬──────────┬──────────┬──────────┬───────────────┤
│ Criteria │ Agent A │ Agent B │ Agent C │ 权重 │
│ │(Watchdog)│(inotify) │ (Polling)│ │
├──────────┼──────────┼──────────┼──────────┼───────────────┤
│ 正确性 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐ │ ⭐⭐⭐ │ 40% │
│ 性能 │ ⭐⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │ ⭐⭐ │ 25% │
│ 可维护性 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐⭐ │ 20% │
│ 可移植性 │ ⭐⭐⭐⭐ │ ⭐⭐ │ ⭐⭐⭐⭐⭐ │ 15% │
├──────────┼──────────┼──────────┼──────────┼───────────────┤
│ 加权总分 │ 4.55 │ 3.70 │ 3.15 │ │
├──────────┴──────────┴──────────┴──────────┴───────────────┤
│ 推荐方案：Agent A (Watchdog) │
│ 理由：正确性满分、代码结构清晰、跨平台支持良好、社区活跃。 │
│ 性能虽略逊于 inotify 版本，但对绝大多数场景足够。 │
└─────────────────────────────────────────────────────────────┘最优方案落地
经过 Judge 评估后，Agent A 的 Watchdog 方案胜出。此时：
- Agent A 的 worktree 保留（
keep），代码被合并到主分支 - Agent B 和 Agent C 的 worktree 可以根据需要保留参考或直接清理
开发者无需手动查看三个方案的代码——Judge 的总结报告已经给出了足够的信息来做决策。
05. 什么时候用并行？什么时候用串行？
并行 Agent 不是万能的。它最适合特定类型的任务，而在其他情况下反而会增加开销。
并行 Agent 的优势场景
| 场景 | 描述 | 举例 |
|---|---|---|
| 多方案探索 | 对同一个问题，有多个候选方案 | 三种架构选型、不同算法实现 |
| 独立子任务 | 一个大任务可以拆成互不依赖的模块 | 同时实现 API 接口、数据库层、前端组件 |
| A/B 测试 | 需要对比两种实现的效果 | 两种缓存策略的性能对比 |
| 竞品分析 | 研究同类工具的优缺点 | 同时调研 3 个开源库的 API 设计 |
串行 Agent 的优势场景
| 场景 | 描述 | 举例 |
|---|---|---|
| 顺序依赖 | 第二步依赖第一步的输出 | 先建表结构，再写查询逻辑 |
| 调试排错 | 需要逐步缩小问题范围 | 追一个复杂的 bug 链 |
| 对话式探索 | 需要持续与 Agent 交互调整方向 | 从模糊需求逐步细化 |
| 小任务 | 10 分钟内能解决的简单修改 | 改一个变量名、加一个日志 |
决策矩阵
任务复杂?
├── 低 → 串行就够了
└── 高 →
├── 有多个独立方案需要探索? → 并行
├── 任务可以拆成互不依赖的模块? → 并行
├── 步骤之间有强依赖关系? → 串行
└── 不确定 → 先并行探索 → 再串行深化经验法则：如果你在脑海中想”我也可以这样做，不过那样做也行……”，这就是用并行 Agent 的信号。让机器替你 explore，你只需要 exploit 最佳结果。
06. 成本考量：并行不是免费的
并行 Agent 虽然强大，但也有成本：
Token 消耗
并行 N 个 Agent 的 Token 消耗大致是串行的 N 倍——因为每个 Agent 都要读取相同的上下文、做独立的推理。但请注意，这个 N 倍是上限，实际往往更低，因为并行 Agent 完成任务的时间更短，避免了串行中”绕远路”带来的额外 Token 浪费。
串行模式：A → B → C → D → E（5 轮交互，每轮 3000 tokens）
总 Token = 15000
并行模式：Agent A（2000 tokens） + Agent B（2500 tokens）+ Agent C（1800 tokens）
总 Token = 6300 + Judge（1500 tokens）= 7800 tokens结论：并行模式虽然同时用了三个 Agent，但由于每个 Agent 目标明确、任务聚焦，反而可能比串行中来回调试更省 Token。
时间成本
并行最大的收益是墙钟时间（wall-clock time） 的缩短。
- 串行：每步 2 分钟，5 步 = 10 分钟
- 并行（3 路）：最长的一个 Agent 3 分钟 + Judge 1 分钟 = 4 分钟
时间缩短 60%，对于 CI 等待、紧急修复等场景意义重大。
Worktree 的磁盘占用
每个 worktree 本质上是一个完整的 Git 仓库副本（虽然用了硬链接共享对象），磁盘占用大约 100-500MB 不等。运行完毕后及时清理（exitWorktree action="remove"）可以节省空间。
07. 心智模型：如何设计和编排并行 Agent
模型一：厨师模型
你是一个主厨，要准备一桌宴席。
- 串行：一个人按顺序做每道菜，做一道上一道。
- 并行：你指挥三个厨师，一个做凉菜，一个做热菜，一个做甜点，同时进行。
主厨（Coordinator）负责拆解菜单、分配任务、最后摆盘上桌（Judge 评估 + 合并）。
模型二：模拟退火 × 遗传算法
把并行 Agent 想象成遗传算法中的种群。
- 每个 Worker 是种群中的一个个体（实现方案）
- 变异 = 选择不同的库/不同的架构/不同的代码组织
- 适应度函数 = Judge Agent 的评分标准
- 选择操作 = Judge 选出最优个体，合并到主分支
- 迭代 = 如果第一轮没有满意的方案，可以基于最优方案再做一轮变异
这个心智模型帮你理解：并行 Agent 不是一次性的，你可以多轮并行，每轮在前一轮最优方案的基础上进一步优化。
模型三：Scrum 团队的 Sprint
- Sprint Planning（Coordinator 分解任务）
- Sprint 执行（Worker 们在各自分支开发）
- Sprint Review（Judge 评估成果）
- Retrospective（开发者总结经验、更新 CLAUDE.md）
用团队管理的方式理解 Agent 编排，你会发现并行 Agent 不过是自动化了你（作为 Tech Lead）的日常管理流程。
08. Worktree 隔离：深入底层机制
创建 Worktree 的幕后
当你调用 EnterWorktree(name="exp-foobar") 时，背后发生的是：
# Cursor 自动执行（类似效果）
git worktree add .claude/worktrees/exp-foobar <base-branch>
# 然后切换到该 worktree 的工作目录这个新 worktree 拥有完整的：
- 工作目录（独立的文件系统视图）
- Git 索引（独立的暂存区）
- Git 分支（自动创建新分支或基于指定分支）
为什么隔离如此重要？
场景：两个 Agent 同时修改 auth/login.tsx
无隔离的悲剧：
Agent A 在第 10 行加了登录日志
Agent B 在第 10-20 行重构了登录流程
→ 冲突！谁先写入谁就覆盖了对方
有隔离的优雅：
Agent A 在 worktree-a 中修改 auth/login.tsx
Agent B 在 worktree-b 中修改 auth/login.tsx
→ 互不干扰，Judge 胜出的方案才合并到主分支Exit Worktree 的两种结局
| 动作 | 效果 | 适用场景 |
|---|---|---|
action="keep" | 保留 worktree 目录和分支 | 方案胜出，需要后续查看或手工调整 |
action="remove" | 删除 worktree 目录和分支 | 方案未选中，不需要留下垃圾 |
如果 worktree 有未提交的变更，remove 会要求 discard_changes: true——这是防止意外丢失工作的安全机制。
09. 高级模式：多轮并行 + 迭代优化
对于真正复杂的任务，单轮并行往往不够。我们可以做分层并行：
第一轮：粗粒度方案探索
启动 3-4 个 Agent，分别探索完全不同的架构方案：
Worker 1: "用 FastAPI + SQLAlchemy 实现"
Worker 2: "用 Flask + raw SQL 实现"
Worker 3: "用 Django ORM 实现"
Worker 4: "用 Node.js Express + Prisma 实现"第二轮：细粒度实现优化
Judge 选出最优架构（比如 FastAPI + SQLAlchemy）后，再启动第二轮并行：
Worker 1: "使用 Repository 模式组装数据层"
Worker 2: "使用 Service 层 + 事务装饰器"
Worker 3: "使用 CQRS 分离读写模型"第三轮：测试和边界覆盖
Worker 1: "编写单元测试，覆盖所有错误路径"
Worker 2: "编写集成测试，覆盖数据库异常场景"
Worker 3: "编写性能基准测试"这种多轮并行模式可以系统化地构建出高质量的代码，每一轮都在上一轮最优结果上叠加。
10. 最佳实践与注意事项
DO
- 确保任务真正独立：Worker 之间不要有文件级别的依赖
- 明确的评估标准：在启动前告诉 Judge 以什么标准评分（正确性 > 性能 > 代码风格？）
- 资源管理：控制同时运行的 Agent 数量，避免本地资源耗尽（建议 3-5 个）
- 保留失败记录：即使方案没被选中，其 worktree 也值得保留一段时间供人类复盘
DON’T
- 不要给并行 Agent 同一个文件路径：虽然 worktree 本身隔离了，但如果两个 Agent 同时输出到同名文件，合并时会冲突
- 不要让 Worker 做决策性工作：Worker 只”执行”，不”选择”——选择是 Judge 的事
- 不要期望 1+1=2 的效率提升：并行有开销（创建 worktree、加载上下文、Judge 评估），3 个 Agent 并行大概能节省 50-60% 的时间，不是 66%
- 不要忽视上下文长度：每个并行 Agent 都要读一遍上下文，如果上下文很大，Token 消耗会翻倍
安全提示
并行 Agent 的工作方式意味着多个 Agent 可以同时执行可能带来副作用的命令（如安装依赖、创建文件）。确保你的项目已经配置了合适的权限控制，避免 Agent 在并行执行时做出危险操作。
11. 总结
| 维度 | 要点 |
|---|---|
| 核心理念 | 同时运行多个 Agent 探索多种方案，由 Judge Agent 择优 |
| 底层机制 | Git Worktree 提供完全隔离的运行环境 |
| 架构角色 | Coordinator（拆任务）→ Worker（执行）→ Judge（评估） |
| 适用场景 | 多方案探索、独立子任务并行、A/B 对比 |
| 不适用场景 | 强依赖链、调试排错、简单小任务 |
| 成本考量 | Token 消耗约 N 倍，但墙钟时间大幅缩短 |
| 最佳数量 | 建议 3-5 个 Worker 并行 |
| 迭代策略 | 可以多轮并行，每轮在前一轮最优方案上继续优化 |
并行 Agent 是 Cursor Agent 工作流中向系统性迈出的重要一步。它把”试错”这个原本需要开发者亲自完成的探索过程，交给了多个 Agent 高效并行完成，而你只需要在最后看报告、做决策。
如果说串行 Agent 是一个聪明的实习生，那并行 Agent 就是一个完整的研发小组——有架构师（Coordinator）、有工程师（Worker）、有技术评审（Judge）。善用这个能力，你的开发效率会上一个台阶。
下一篇：18 · Agent Team 协作模式 → 深入探讨多个 Agent 组成团队、互相通信、协同完成更大规模任务的工作模式。
本文是 Cursor Agent 工作流系列的第 17 篇。并行 Agent 模式将”单打独斗”升级为”团队协作”，让多个 Agent 在隔离环境中同时探索不同方案，最后由 Judge 选出最优解。