多 Agent 协作
SubAgents、Agent Teams、Fan-out 批处理——让多个 Claude 并行工作
一个 Claude Code 已经很强了，但有些场景下你需要多个 Claude 同时工作。比如一个人写代码、一个人做 Code Review；或者同时处理 10 个文件的迁移任务；又或者一个 Agent 做调研、另一个做实现。
Claude Code 支持多种多 Agent 协作模式，从简单的 SubAgent 到复杂的 Agent Teams，选合适的就行。
SubAgents：自动创建的子 Agent
SubAgent 是最基础的多 Agent 模式。当 Claude Code 觉得某个子任务需要独立处理时，会自动创建一个 SubAgent 来做。
关键特性：独立上下文。 SubAgent 有自己的上下文窗口，它做的调研和思考不会挤占主 Session 的空间。任务完成后，只有结论返回给主 Session。
典型场景：
帮我重构 src/shared/components/ 下的所有组件，把 class 组件改成函数式组件。
在动手之前，先调研一下哪些组件有复杂的 lifecycle methods 需要特别处理。Claude Code 可能会启动一个 SubAgent 去扫描所有组件文件，分析哪些有 componentDidMount、shouldComponentUpdate 等需要转换的生命周期方法。调研完成后，主 Session 拿到结论，然后有针对性地开始重构。
你也可以显式要求使用 SubAgent：
用一个 subagent 帮我调研 src/extensions/ 目录下所有 payment provider 的接口差异，
然后给我一个统一接口的设计方案。Agent Teams：分工协作
Agent Teams 是更结构化的协作方式。你给不同的 Agent 分配不同的角色，让它们各司其职。
Writer/Reviewer 模式
最经典的模式是一个写、一个审：
我需要两个 Agent 协作：
- Writer：负责实现 src/app/api/payments/ 下的支付接口
- Reviewer：每次 Writer 写完一个文件，Reviewer 审查代码质量、安全性和错误处理
Writer 先开始，每写完一个文件通知 Reviewer。
Reviewer 给出修改意见后 Writer 执行修改。测试驱动模式
一个 Agent 先写测试，另一个 Agent 写实现让测试通过：
Agent 1：根据需求文档先写测试用例（放在 __tests__/ 目录下）
Agent 2：写实现代码，目标是让所有测试通过四阶段协调模式
对于复杂项目，可以把工作分成四个阶段，每个阶段由专门的 Agent 负责：
| 阶段 | 职责 | 输出 |
|---|---|---|
| Research | 调研技术方案、阅读相关代码、分析依赖关系 | 技术调研报告 |
| Synthesis | 把调研结果整合成可执行的方案 | 架构设计文档、实现计划 |
| Implementation | 按方案写代码、写测试 | 可运行的代码 |
| Verification | 运行测试、检查边界情况、做安全审查 | 验证报告 |
这个模式特别适合大型功能开发，比如"给系统加一个完整的权限管理模块"。
Fan-out 批处理
当你需要对大量文件或任务做相同操作时，Fan-out 批处理可以让多个 Claude 并行工作，大幅提升效率。
-p 参数：非交互模式
-p 参数让 Claude Code 以非交互模式运行，执行完就退出，不等待用户输入：
# 单个任务
claude -p "把 src/components/Button.tsx 从 class 组件改成函数式组件"
# 指定输出到文件
claude -p "分析 src/app/api/ 下所有路由的错误处理是否完善" > analysis.md脚本批处理
结合 Shell 脚本，你可以让多个 Claude 实例并行处理不同文件：
#!/bin/bash
# batch-migrate.sh - 批量迁移组件
components=(
"src/components/Header.tsx"
"src/components/Footer.tsx"
"src/components/Sidebar.tsx"
"src/components/Modal.tsx"
"src/components/Dropdown.tsx"
)
for component in "${components[@]}"; do
claude -p "把 $component 从 class 组件重构为函数式组件，保持所有现有功能不变，用 hooks 替代 lifecycle methods" &
done
# 等待所有后台任务完成
wait
echo "所有组件迁移完成"[!WARNING] 并行处理时要注意：不同的 Claude 实例不要同时修改同一个文件，否则会产生冲突。每个实例处理独立的文件。
/batch 命令
除了手动写脚本，Claude Code 也提供了内置的 /batch 命令来做批处理：
/batch 对 src/shared/components/ 下的每个组件文件，添加 JSDoc 注释远程与异步执行
有些任务需要长时间运行，或者你想在后台执行不阻塞当前工作。
claude --remote
--remote 参数让 Claude Code 在远程环境中执行，不占用你本地的终端：
# 在远程执行一个长时间的代码审查任务
claude --remote -p "审查 src/ 下所有文件的 TypeScript 类型安全性，生成报告"/schedule 和 /loop
/schedule：安排一个定时任务，比如每天早上自动跑一次代码质量检查/loop：循环执行一个任务，比如每 5 分钟检查一次部署状态
/loop 5m 检查 https://my-app.vercel.app 是否正常响应，如果挂了立刻通知我/schedule "0 9 * * 1-5" 每个工作日早上 9 点跑一次 pnpm test 和 pnpm lint，把结果写到 daily-report.md实战经验
多 Agent 协作听起来很酷，但用不好反而会添乱。以下是一些踩坑后总结的经验：
从 2 个 Session 开始
不要一上来就搞 5 个 Agent 并行。先从两个开始——一个写代码、一个做 Review，或者一个做后端、一个做前端。等你熟悉了协作节奏再增加。
每个 Session 给明确的角色
模糊的分工会导致 Agent 之间重复劳动或互相冲突。开 Session 的时候就定义好角色：
# Session 1 的开场 prompt
你是这个项目的后端开发，负责 src/app/api/ 和 src/shared/models/ 下的代码。
不要动前端代码。所有 API 变更写到 docs/api-changes.md 让前端同步。
# Session 2 的开场 prompt
你是这个项目的前端开发，负责 src/app/[locale]/ 和 src/shared/components/ 下的代码。
API 接口信息看 docs/api-changes.md，有疑问写到 docs/questions.md。用 Git 分支隔离
这是最重要的一条。每个 Session 工作在独立的 Git 分支上，最后通过 PR 合并：
# Session 1 工作在 feature/backend-payment 分支
git checkout -b feature/backend-payment
# Session 2 工作在 feature/frontend-payment 分支
git checkout -b feature/frontend-payment
# 各自开发完成后，分别提 PR 到 main不要让多个 Session 操作同一分支
这是最容易犯的错。两个 Claude 同时在一个分支上改代码，必定会产生冲突，而且冲突会很难解决。
一个分支 = 一个 Agent。 没有例外。
[!TIP] 如果你需要多个 Agent 共享信息，不要通过代码文件传递。用一个专门的
docs/或notes/目录放协作文档，或者利用 CLAUDE.md 来传递全局性的约定。
选择合适的模式
不同场景适合不同的协作模式：
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 快速调研某个技术方案 | SubAgent | 不污染主上下文 |
| 功能开发 + Code Review | Writer/Reviewer | 写和审分离，质量更高 |
| 批量修改大量文件 | Fan-out 批处理 | 并行处理，效率最高 |
| 大型功能开发 | 四阶段协调 | 分阶段保证质量 |
| 前后端同时开发 | 独立 Session + 分支隔离 | 互不干扰，最后合并 |
| 长时间运行的任务 | --remote | 不阻塞本地终端 |
记住：简单场景不需要多 Agent。 一个 Session 能搞定的事情就不要搞两个。多 Agent 的协调成本不是零，只有当任务确实需要并行或分工时才值得引入。
本章节为会员专属内容
购买全站技能解锁即可免费阅读所有进阶教程，包括对话技巧、扩展能力、实战项目和思维模型等完整内容。
已购买会员？请先登录你的账号，即可自动解锁。