方式一：手动并行（Git Worktrees）
原理：同一个 Git 仓库，checkout 出多个独立工作目录，每个目录开一个 Claude Code session。
# 主仓库gitworktreeadd../feature-frontend feature/frontendgitworktreeadd../feature-backend feature/backendgitworktreeadd../feature-tests feature/tests# 目录结构my-project/ ← 主目录（Reviewer在这里） my-project-frontend/ ← 前端Agent在这里工作 my-project-backend/ ← 后端Agent在这里工作 my-project-tests/ ← 测试Agent在这里工作然后分别在每个目录打开终端，运行claude，给不同指令：
# 终端1（前端） > 实现用户登录页面，API接口规范见 docs/api.md # 终端2（后端） > 实现登录接口 POST /api/auth/login，规范见 docs/api.md # 终端3（测试） > 等前两个完成后，为登录功能写集成测试完成后合并：
gitmerge feature/frontendgitmerge feature/backendgitmerge feature/tests关键：提前写好docs/api.md或接口约定文档，作为多个 Agent 的"共享契约"，否则各写各的会冲突。
方式二：Orchestrator + Subagents
原理：一个主 Claude 负责规划，通过调用工具或写文件的方式给子 Agent 下发任务。
这是 Claude Code 原生支持的模式，主 Agent 可以直接Bash启动子 Agent：
# 给主Claude的Prompt 你是项目架构师。需求如下：[需求描述] 请将任务拆解，然后用以下方式启动子Agent执行： - 用 `claude -p "任务描述" > output/frontend.md` 执行前端任务 - 用 `claude -p "任务描述" > output/backend.md` 执行后端任务 - 所有子Agent完成后，整合结果并汇报子 Agent 通过claude -p（print模式，非交互）运行：
# 主Agent在shell里执行这些命令（并行）claude-p"根据 docs/api.md 实现前端登录组件，输出到 src/components/"&claude-p"根据 docs/api.md 实现后端登录接口，输出到 src/api/"&wait# 等所有子Agent完成# 再启动Review Agentclaude-p"审查 src/ 下刚提交的代码，检查安全漏洞和代码质量"目录结构建议：
project/ ├── CLAUDE.md ← 全局规范，所有Agent都读 ├── docs/ │ ├── api.md ← Agent间的接口契约 │ └── tasks/ │ ├── frontend.md ← 主Agent写的任务说明 │ └── backend.md └── output/ ← 子Agent的输出和日志方式三：流水线（Pipeline）模式
原理：串行接力，上一个 Agent 的输出是下一个的输入，通过文件或 Git commit 传递。
需求文档 → [Agent1: 设计] → spec.md spec.md → [Agent2: 开发] → 代码 + commit 代码 → [Agent3: 测试] → test report 报告 → [Agent4: Review] → review.md + 修改建议 建议 → [Agent2: 修复] → 最终代码用 shell 脚本把流水线串起来：
#!/bin/bash# pipeline.shecho"=== Step 1: 架构设计 ==="claude-p" 根据需求 docs/requirements.md， 输出详细技术方案到 docs/spec.md， 包含：模块划分、接口定义、数据结构 "echo"=== Step 2: 编码实现 ==="claude-p" 根据 docs/spec.md 实现完整代码， 遵循 CLAUDE.md 中的规范， 完成后运行 npm run build 确认编译通过 "echo"=== Step 3: 测试 ==="claude-p" 为刚实现的代码编写测试，运行 npm test， 将测试结果输出到 docs/test-report.md "echo"=== Step 4: Code Review ==="claude-p" 审查本次所有改动（git diff main）， 对照 docs/spec.md 检查实现是否符合设计， 输出问题清单到 docs/review.md "# 如果review发现问题，触发修复循环ifgrep-q"BLOCKING"docs/review.md;thenecho"=== Step 5: 修复问题 ==="claude-p"根据 docs/review.md 中的 BLOCKING 问题进行修复"fi三种方式对比
| 手动并行 | Orchestrator | 流水线 | |
|---|---|---|---|
| 适合场景 | 模块独立、可并行的功能 | 复杂项目、任务依赖多 | 质量要求高、需多轮验证 |
| 速度 | 最快 ⚡⚡⚡ | 中等 ⚡⚡ | 较慢 ⚡ |
| 质量控制 | 依赖人工合并 | 主Agent协调 | 内置Review循环 |
| 上手难度 | 低 | 中 | 低 |
| 最大风险 | 接口不一致 | 主Agent上下文膨胀 | 单步失败卡住整条线 |
实际建议
实践中很少只用一种，通常是组合使用：
- 用流水线保证质量（设计→开发→测试→Review）
- 在开发阶段内部用并行提速（前端/后端同时跑）
- 写一个主 Orchestrator来自动调度，减少人工干预
最核心的还是那两样：写好 CLAUDE.md作为所有 Agent 的共同规范，以及写好接口契约文档作为 Agent 间的沟通桥梁。
