<!-- title: 并行Agent四件套：拆活分派实战指南 -->

# 并行Agent四件套：拆活分派实战指南

## 概述

本教程面向已经会用单个 Claude Code 会话改代码、却苦于"大任务卡在一个会话里"的开发者。目标只有一个：把一份大活拆成多份并行的小活，让多个 Claude 同时干。学完你能分清 Claude Code 的**四种并行 Agent 模式**（Subagent / Agent View / Agent Teams / Dynamic Workflows），知道每种什么时候用、怎么配、怎么盯，并用 Worktree 做隔离底座、`/batch` 一键收口，最终跑通一个"代码库五维并行审计"的完整案例。

## 前置条件

- 已安装 Claude Code（v2.1.200+，本文涉及 worktree 自动加载插件等特性需要此版本）
- 一个真实的 git 仓库（并行 Agent 的隔离强依赖 git）
- 基本能读懂 `settings.json` 和 YAML frontmatter
- 终端会同时开多个标签页——并行 Agent 的"代价"是 token 成本会成倍增长，开多个会话前请先确认用量额度

---

## 一、先想清楚：谁协调、要不要聊天、改不改同一份文件

很多人一听到"并行 Agent"就以为只有"子代理"这一种东西。其实 Claude Code 在 2026 年已经长出**四套**并行方案，它们的本质区别只有三个问题：

1. **谁来协调这份活？** 是你自己盯着、Claude 在会话里分派、还是一段脚本说了算？
2. **工人之间要不要互相说话？** 各干各的汇报给上级，还是共享一张任务表互相喊话？
3. **会不会改同一份文件？** 会的话，必须用 worktree 隔离。

官方给的四套对应关系如下：

| 方案 | 协调者 | 工人是否互通 | 适合场景 |
|------|--------|--------------|----------|
| **Subagent（子代理）** | 当前会话里的 Claude | 只把摘要回传上级 | 侧任务会淹没主对话（搜索结果、日志、大段文件） |
| **Agent View（`claude agents`）** | 你自己分派、一个面板盯梢 | 各自只跟你汇报 | 多个独立任务，想随时插手其中某个 |
| **Agent Teams** | 一个 lead 会话排兵布阵 | 共享任务表 + 互相发消息 | 把一个项目拆成几块，工人之间要同步 |
| **Dynamic Workflows（动态工作流）** | 一段脚本（不再靠对话里的临场判断） | 脚本收集结果并交叉验证 | 子代理数量超过个位数、需要结果互查，如全库审计、500 文件迁移 |

记住这条主线：**Subagent 是"会话内的工人"，Agent View 是"你当调度台"，Agent Teams 是"Claude 当包工头"，Dynamic Workflows 是"脚本当包工头且会互查作业"。**

下面这套决策图，能帮你 5 秒内选定方案：

```mermaid
flowchart TD
    Q1{谁来协调？}
    Q1 -->|"Claude 在当前会话里分派"| A[Subagent]
    Q1 -->|"我自己分派并盯梢"| B[Agent View]
    Q1 -->|"Claude 当 lead 统筹工人"| C[Agent Teams]
    Q1 -->|"一段脚本说了算"| D[Dynamic Workflows]

    A --> A1{工人改同一份文件？}
    B --> B1{工人改同一份文件？}
    A1 -->|是| A2[配 worktree 隔离]
    A1 -->|否| A3[直接并行]
    B1 -->|是| B2[每个会话各自 worktree]
    B1 -->|否| B3[只读任务可共用主分支]

    C --> C1[按文件分工,避免互踩]
    D --> D1{是否需要结果交叉验证？}
    D1 -->|是| D2[fan-out 后加 verify 阶段]
    D1 -->|否| D3[纯 fan-out 并行即可]
```

---

## 二、第一件套：Subagent —— 会话内的专精分包工

### 它是什么

子代理是"在当前会话里**另开一个独立上下文窗口**干完一件侧任务，只把摘要交回来"的工人。最大价值不是"快"，而是**省主上下文**：你想让 Claude 翻 50 个文件找漏洞，与其让搜索结果刷屏主对话，不如丢给一个 `security-auditor` 子代理，让它在自己窗口里翻完，只回一句"发现 3 处疑似注入，分别在……"。

### 内置子代理，开箱即用

Claude Code 自带几个内置子代理，**无需配置**，Claude 会在合适时机自动调用：

- **Explore**：只读搜索代理，扫目录/命名约定，读片段不读整文件，适合"帮我定位实现某功能的代码在哪"。
- **Plan**：软件架构师代理，产出分步实现计划，识别关键文件。
- **general-purpose**：通用兜底代理，多步搜索与执行。

一个容易忽略的细节：**Explore 和 Plan 会跳过你的 `CLAUDE.md` 和 git 状态**，所以又快又省 token；其它内置和自定义子代理则会正常加载这两者。

### 造一个自定义子代理：security-auditor

当你发现自己反复"派同一种工人、说同一种话"，就该把它固化成自定义子代理。新建文件 `.claude/agents/security-auditor.md`：

```markdown
---
name: security-auditor
description: 审计源码中的注入风险、硬编码密钥、不安全反序列化。当代码评审涉及安全漏洞时使用。
tools: Read, Grep, Glob, Bash
model: sonnet
---

你是安全审计员。对给定目录做静态安全审计，只报告、不修改任何文件。

输出结构化清单，每条包含：
- file: 文件路径
- line: 行号
- severity: critical | high | medium | low
- issue: 一句话描述
- evidence: 周围 5 行上下文

不要给出大段修复代码，只指出问题与位置。
```

几个关键点：

- **`description` 写清楚**：Claude 靠它判断"什么时候该派这个工人"。描述越准，自动触发命中率越高。
- **`tools` 收紧**：审计员给 `Read/Grep/Glob/Bash` 即可，不必给 `Edit/Write`——它本来就不该改文件，权限从根上挡住误操作。
- **`model` 路由**：高价值的审计用 `sonnet`；若是机械的批量分类活，可设 `model: haiku` 降本。

**预期结果**：保存后无需重启，下次你说"帮我审一下 `src/auth` 的安全风险"，Claude 会自动把活派给 `security-auditor`，主对话只会收到一份精简清单，搜索噪声全留在子代理窗口里。

### 常见问题

- **子代理"不触发"？** 八成是 `description` 写得像通用任务。加触发词，比如"当代码评审涉及安全漏洞时使用"。
- **想强制派活而非等自动？** 直接点名："用 security-auditor 审计 src/auth"。
- **并行跑多个子代理？** 可以。Claude 会在同一轮里发出多个子代理调用同时执行，结果一起收。命名后台子代理还会出现在 `@` 提及列表里，能看到状态。

---

## 三、第二件套：Agent View —— 一个面板分派+盯梢后台会话

Subagent 是"会话内的工人"，Agent View 则是**把整个会话本身当工人**：你用 `claude agents` 打开一个面板，分派若干**后台会话**，每个会话自动落进自己的 worktree，互不干扰；你在一个屏幕里看全部状态，哪个需要你插手就切进去。

```bash
claude agents
```

它解决的是 Subagent 解决不了的问题——**你想完全把任务"交出去"，回头再来看**。比如：

- 派 1 号会话去重构认证模块，2 号去补测试，3 号去升级依赖——三条线并行，各干各的。
- 你只关心"谁卡住了、谁需要我确认"，而不是每个细节都跟。

> 注意：Agent View 是 research preview；`/agents` 是另一回事——自 v2.1.198 起 `/agents` 不再开面板，只打印子代理文件位置提示。**调度台是 `claude agents`，管理子代理定义才用 `/agents`，两者别混。**

**预期结果**：面板里每行一个会话，显示状态（运行中/等待输入/完成）、所在 worktree；点进去即可接管或继续。

### 常见问题

- **会话之间要传数据？** Agent View 的会话彼此独立、只跟你汇报。需要互相通信，请用下一件套 Agent Teams。
- **后台会话占用大？** 每个会话都是独立 Claude 实例，token 成本线性叠加，建议控制并发数。

---

## 四、第三件套：Agent Teams —— 多个会话共享任务表、互相发消息

这是最"像团队"的模式：一个 **lead 会话**负责拆活、排期、督工，多个 **worker 会话**认领任务、干活、**还能互相发消息**。区别于 Agent View 的地方就是工人之间**共享一张任务清单**并可直接通信。

典型场景：你要做一个不算小的项目——前端、后端、测试三块。lead 把它拆成三条任务，分派给三个 worker；前端 worker 发现接口字段变了，直接给后端 worker 发消息同步，不用绕回 lead。

> 注意：Agent Teams 是**实验特性、默认关闭**。它不适合 teammates 会改同一批文件的情况——Teams 默认不在 worktree 里隔离工人，所以**按文件分工**（每个 worker 负责不同目录）是安全前提。要共用文件，请回到 Subagent + worktree。

### 常见问题

- **Teams 和 Dynamic Workflows 都"有协调"，区别？** Teams 的协调是 **Claude 临场判断**（lead 看情况排活）；Workflows 的协调是**写死的脚本**（按固定流程跑）。需要稳定、可复现、可批量重跑选 Workflows；需要灵活、动态决策选 Teams。
- **什么时候不用 Teams？** 任务之间几乎没依赖、各干各的——那用 Agent View 更轻；任务只有一两块——直接 Subagent 就够。

---

## 五、第四件套：Dynamic Workflows —— 脚本编排大批子代理并交叉验证

当一份活大到"超过 Claude 一轮一轮判断的舒适区"，或者需要**结果互查**（比如审计发现要被另一个视角复核），就该让脚本接管编排。

核心机制：你写一段 JavaScript 工作流脚本，用 `agent()` 派子代理、用 `parallel()`/`pipeline()` 控并行与流水线、用 `phase()` 分阶段。脚本本身持有计划，子代理只管执行并回数据。运行后用 `/workflows` 看进度——每个阶段、多少个 agent 完成、一目了然。

它相比 Subagent 的杀手锏是**交叉验证**：第一阶段 fan-out N 个发现者，第二阶段对每条发现再派验证者去"试着推翻它"，多数否决就丢掉。这正是对抗"听起来有理实则错误"的发现的关键。

### 一个最小工作流骨架（fan-out + verify）

保存为 `.claude/workflows/repo-audit.mjs`（或直接交给 Claude 以动态工作流运行）：

```javascript
export const meta = {
  name: 'repo-audit',
  description: '多维度代码库审计 + 交叉验证',
  phases: [{ title: 'Audit' }, { title: 'Verify' }],
}

// schema：强制子代理返回结构化数据，省去解析
const FINDINGS = {
  type: 'object',
  properties: {
    findings: {
      type: 'array',
      items: {
        type: 'object',
        properties: {
          title: { type: 'string' },
          file: { type: 'string' },
          severity: { type: 'string' },
        },
        required: ['title', 'file', 'severity'],
      },
    },
  },
  required: ['findings'],
}

const VERDICT = {
  type: 'object',
  properties: { isReal: { type: 'boolean' }, reason: { type: 'string' } },
  required: ['isReal', 'reason'],
}

// 五个审计维度，各自一个子代理，并行 fan-out
const DIMENSIONS = [
  { key: 'security',  prompt: '审计注入风险与硬编码密钥，输出 findings' },
  { key: 'types',     prompt: '找出潜在的类型错误与 any 滥用，输出 findings' },
  { key: 'tech-debt', prompt: '扫描 TODO/FIXME 与重复实现，输出 findings' },
  { key: 'deps',      prompt: '检查依赖中已知漏洞与过期版本，输出 findings' },
  { key: 'tests',     prompt: '定位测试覆盖缺口，输出 findings' },
]

// pipeline：每个维度审完立即进入验证，维度间无需互相等待
const results = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { label: `audit:${d.key}`, phase: 'Audit', schema: FINDINGS }),
  (audit, d) =>
    parallel(
      (audit.findings || []).map(f => () =>
        agent(
          `试着推翻这条发现，默认存疑：${f.title}（${f.file}）`,
          { label: `verify:${d.key}`, phase: 'Verify', schema: VERDICT }
        ).then(v => ({ ...f, dimension: d.key, verdict: v }))
      )
    )
)

// 只保留经得起验证的发现
const confirmed = results
  .flat()
  .filter(Boolean)
  .filter(f => f.verdict && f.verdict.isReal)

return { confirmed, count: confirmed.length }
```

**为什么用 `pipeline` 而不是先 `parallel` 全部审完再验证？** 因为维度 A 的发现可以边出边验证，不必等最慢的维度 E。`pipeline` 让每个维度独立流过两阶段，墙钟时间取决于最慢的那一条链，而不是所有阶段之和。

**预期结果**：运行后输入 `/workflows` 看到两阶段进度树；最终返回一份"已交叉验证"的发现清单，剔除了大量误报。

### 常见问题

- **`agent()` 返回 null？** 用户中途跳过某 agent 会让其返回 null。链路上用 `.filter(Boolean)` 兜底，别裸用 `.map`。
- **并发被限流？** 工作流默认每轮约 `min(16, CPU核数-2)` 个 agent 并发，超出会排队。传入 100 个 item 也会全部完成，只是分批。

---

## 六、隔离底座：Worktrees 让并行不踩脚

四种模式只要涉及"多个工人改代码"，都得靠 **worktree** 防互踩。一个 worktree 是同一个仓库的**独立工作目录 + 独立分支**，共享历史与远端，但文件互不污染。

### 一键开 worktree

```bash
# 在 .claude/worktrees/feature-auth/ 下开新分支 worktree-feature-auth
claude --worktree feature-auth
# 等价简写
claude -w feature-auth

# 不取名，自动生成如 bright-running-fox
claude --worktree
```

在会话里也能临时切："帮我在一个 worktree 里做这件事"，Claude 会调 `EnterWorktree` 创建，还能在 `.claude/worktrees/` 下的不同 worktree 间直接切，旧的不动。

### 选基准分支

新 worktree 默认从 `origin/HEAD`（远端默认分支）拉，保证干净起点。两种覆盖方式：

```jsonc
// 项目根 settings.json
{ "worktree": { "baseRef": "head" } }   // 从本地 HEAD 拉，带上你未推送的提交
```

`baseRef` 只接受 `"fresh"`（默认）或 `"head"`，**不能填任意 ref**。要基于某个 PR：

```bash
claude --worktree "#1234"   # 自动 fetch pull/1234/head，落到 .claude/worktrees/pr-1234
```

### 把 .env 之类带进 worktree

worktree 是全新检出，`.env`、`.env.local` 这类 **gitignore 文件不会出现**，会导致跑不起来。在项目根放一个 `.worktreeinclude`（用 `.gitignore` 语法），列出要复制的 gitignore 文件：

```gitignore
# .worktreeinclude
.env
.env.local
config/secrets.json
```

规则是"既匹配模式、又是 gitignore 的文件"才会被复制，**受版本控制的文件永不会被重复**，安全。

最后别忘了把 `.claude/worktrees/` 加进 `.gitignore`，免得主检出里冒出一堆未跟踪文件。

---

## 七、一键发射：`/batch` 把一个大改动切成 N 个 worktree 各自提 PR

如果你嫌上面几种都要自己编排，`/batch` 是**打包好的开箱方案**：你给一个大改动，Claude 把它拆成 **5 到 30 个 worktree 隔离的子代理**，每个独立完成后**各自开一个 PR**。本质是 Subagent + Worktree 的封装，不是第五种协调风格。

适合"一个大特性、想拆成多个小 PR 平行评审"的场景。代价同样明显——PR 数量多、token 消耗大，适合有充分 review 带宽的团队。

---

## 八、实战案例：代码库五维并行审计

把四件套串起来：用 **Subagent 做单点深挖**、**Dynamic Workflow 做五维 fan-out + 交叉验证**、**Worktree 隔离**、最后用 **`/batch` 把修复切成多个 PR**。

**目标**：对 `src/` 做安全/类型/技术债/依赖/测试五维审计，互查后产出可执行修复清单。

### 第 1 步：准备隔离底座

```bash
# 项目根
echo ".claude/worktrees/" >> .gitignore

# 让 worktree 带上本地未推送的工作
cat > settings.json <<'EOF'
{ "worktree": { "baseRef": "head" } }
EOF

# 复制必要的 gitignore 文件
cat > .worktreeinclude <<'EOF'
.env
.env.local
EOF
```

### 第 2 步：固化两个专精子代理

除第五节的 `security-auditor` 外，再补一个 `tech-debt-scout`（`.claude/agents/tech-debt-scout.md`）：

```markdown
---
name: tech-debt-scout
description: 扫描 TODO/FIXME、重复实现、过期 API 用法并分级排期。当评估技术债时使用。
tools: Read, Grep, Glob
model: haiku
---
你是技术债侦察兵。按"烧不烧人"给每条债分级：
critical(阻塞发布) / high(本迭代还) / medium(季度内) / low(有空再说)。
输出 file、line、severity、issue、suggested_fix_at。
```

注意 `tech-debt-scout` 用 `haiku`——机械的分类活降本，`security-auditor` 这种高价值的才上 `sonnet`。

### 第 3 步：动态工作流 fan-out + 交叉验证

把第五节的 `repo-audit.mjs` 放进 `.claude/workflows/`，然后在会话里说"按 repo-audit 工作流审计 src/"。Claude 启动工作流，五个维度并行；用 `/workflows` 观察进度：

```
▶ Audit        [████████░░] 4/5
▶ Verify       [██░░░░░░░░] 7/23
```

### 第 4 步：综合出修复计划

工作流返回 `{ confirmed: [...], count }`。把它喂给会话里的 Claude："根据这些已验证发现，给一份修复计划，按严重度排序，标出每条涉及的文件。"

### 第 5 步：`/batch` 切成多 PR 收口

确认计划后：

```
/batch 把上面修复计划按模块拆成多个独立 PR，每个 PR 聚焦一个模块
```

`/batch` 自动为每个模块开 worktree、派子代理修、各自提 PR。你在 GitHub 上逐个 review 合并即可。

### 完整架构

```mermaid
flowchart LR
    Repo[(代码库 src/)] --> WF

    subgraph WF[Dynamic Workflow: repo-audit]
        direction TB
        Audit{五维 fan-out}
        Audit --> S1[security-auditor sonnet]
        Audit --> S2[types 检查]
        Audit --> S3[tech-debt-scout haiku]
        Audit --> S4[deps 检查]
        Audit --> S5[tests 覆盖]
        S1 & S2 & S3 & S4 & S5 --> V[Verify 阶段<br/>逐条试着推翻]
    end

    WF -->|confirmed findings| Plan[Claude 出修复计划]
    Plan --> Batch["/batch 拆 N 个 worktree"]
    Batch --> PR1[PR: auth 模块]
    Batch --> PR2[PR: 依赖升级]
    Batch --> PR3[PR: 测试补全]
    PR1 & PR2 & PR3 --> Review((GitHub Review))
```

---

## 延伸阅读

- **官方"Run agents in parallel"**：四套方案的权威对照表与选择指引，本文决策框架的直接来源。
- **官方"Create custom subagents"**：子代理 frontmatter 全字段、内置子代理行为、后台/前台运行、权限模式。
- **官方"Run parallel sessions with worktrees"**：`--worktree`、`baseRef`、`.worktreeinclude`、PR 模式、非 git VCS 钩子。
- **`claude --help` 与 `/agents`、`/tasks`、`/workflows` 三个斜杠命令**：分别对应"看子代理定义、看会话内后台任务、看动态工作流运行"。

---

## 训练营适用性评估

- **适合营型**：中高阶"AI 工程化 / 多 Agent 协作"训练营；也适合企业内训的"研发提效"专题。不适合零基础营——学员需先掌握单会话用法与 git。
- **难度**：⭐⭐⭐⭐（四星）。难点不在命令，而在"选型判断"与"工作流脚本设计"。
- **预计教学时长**：约 4 小时。建议拆为：1 小时讲四套方案选型（配决策图）+ 1 小时 Worktree 隔离实操 + 1.5 小时跑通五维审计案例 + 0.5 小时答疑。
- **考核点**：能给定一个真实仓库，30 秒内说清该用哪套方案并讲清理由；能独立写出带 `verify` 阶段的动态工作流脚本。
- **成本提示**：并行 Agent token 成本线性叠加，教学时务必预先告知用量上限，建议先用小仓库演示。

---

## 参考来源

1. [Run agents in parallel — Claude Code Docs](https://code.claude.com/docs/en/agents) — 四种并行 Agent 方案（subagents / agent view / agent teams / dynamic workflows）的官方对照与选择指引
2. [Run parallel sessions with worktrees — Claude Code Docs](https://code.claude.com/docs/en/worktrees) — `--worktree`、`baseRef`、`.worktreeinclude`、PR 模式与隔离机制的权威说明
3. [Create custom subagents — Claude Code Docs](https://code.claude.com/docs/en/sub-agents) — 自定义子代理 frontmatter 字段、内置 Explore/Plan/general-purpose、后台/前台运行与权限
4. [Claude Code Subagents and Multi-Agent Workflows (2026) — explainx.ai](https://explainx.ai/blog/claude-code-subagents-multi-agent-workflows-2026) — orchestrator/worker 模型、worktree 并行子代理、orchestrator vs subagent CLAUDE.md 的实践讲解
5. [Git Worktrees + Claude Code: The 2026 Playbook — developersdigest](https://www.developersdigest.tech/blog/git-worktrees-claude-code-parallel-agents-guide) — 多个并行 Claude 代理共用单仓库时用 worktree 避免冲突的工程化实战

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)