首页 › tutorials › 并行Agent四件套：拆活分派实战指南

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

概述

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

前置条件

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

很多人一听到"并行 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 秒内选定方案：

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 会跳过你的 CLAUDE.md 和 git 状态，所以又快又省 token；其它内置和自定义子代理则会正常加载这两者。

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

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

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

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

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

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

几个关键点：

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

常见问题

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

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

claude agents

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

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

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

常见问题

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

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

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

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

常见问题

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

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

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

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

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

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

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 看到两阶段进度树；最终返回一份"已交叉验证"的发现清单，剔除了大量误报。

常见问题

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

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

一键开 worktree

# 在 .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（远端默认分支）拉，保证干净起点。两种覆盖方式：

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

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

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

把 .env 之类带进 worktree

worktree 是全新检出，.env、.env.local 这类 gitignore 文件不会出现，会导致跑不起来。在项目根放一个 .worktreeinclude（用 .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 步：准备隔离底座

# 项目根
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）：

---
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 合并即可。

完整架构

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))

延伸阅读

训练营适用性评估

参考来源

  1. Run agents in parallel — Claude Code Docs — 四种并行 Agent 方案（subagents / agent view / agent teams / dynamic workflows）的官方对照与选择指引
  2. Run parallel sessions with worktrees — Claude Code Docs — --worktree、baseRef、.worktreeinclude、PR 模式与隔离机制的权威说明
  3. Create custom subagents — Claude Code Docs — 自定义子代理 frontmatter 字段、内置 Explore/Plan/general-purpose、后台/前台运行与权限
  4. Claude Code Subagents and Multi-Agent Workflows (2026) — explainx.ai — orchestrator/worker 模型、worktree 并行子代理、orchestrator vs subagent CLAUDE.md 的实践讲解
  5. Git Worktrees + Claude Code: The 2026 Playbook — developersdigest — 多个并行 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学通信知识星球海报-扫码加入

📎 本分类最新文章