## 概述
本教程深入Claude Code的多Agent编排体系，从内置SubAgent类型到Agent Teams协作机制，掌握任务分解、并行分发、结果聚合的完整工作流。适合已熟悉Claude Code基本操作、希望提升大规模项目处理效率的中高级开发者。你将学会如何用Agent编排替代线性执行，将数小时的重构任务压缩到分钟级。
## 前置条件
- Claude Code CLI已安装并认证（`claude --version` ≥ 1.0）
- 熟悉Git基本操作（branch、worktree概念）
- 理解Task tool的基本调用方式
- 一个中型项目（10+模块）用于实战演练
---
## 一、Agent编排架构全景
Claude Code的Agent体系不是简单的"一个Agent干所有事"，而是一个分层递归的编排系统。理解这个架构是高效编排的前提。
```mermaid
graph TB
subgraph "Coordinator Layer"
A[主Agent
Coordinator] --> B{任务分析}
end
subgraph "Dispatch Layer"
B -->|代码搜索| C[Explore Agent]
B -->|架构设计| D[Plan Agent]
B -->|代码实现| E[General-purpose Agent]
B -->|后台任务| F[Background Agent]
end
subgraph "Isolation Layer"
C --> G[主Worktree]
D --> G
E --> H[隔离Worktree]
F --> I[独立Worktree]
end
subgraph "Aggregation Layer"
G --> J[结果聚合]
H --> J
I --> J
J --> K[主Agent
继续处理]
end
style A fill:#4A90D9,color:#fff
style C fill:#50C878,color:#fff
style D fill:#FFD700,color:#333
style E fill:#FF6B6B,color:#fff
style F fill:#9B59B6,color:#fff
style K fill:#4A90D9,color:#fff
```
### 核心概念辨析
| 术语 | 定义 | 触发方式 |
|------|------|----------|
| SubAgent | 通过Task tool创建的子Agent实例 | `Task` tool调用 |
| Agent Teams | 多个独立Claude Code实例组成的协作团队 | `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` |
| Worktree Agent | 在隔离Git worktree中运行的Agent | `isolation: "worktree"` 参数 |
| Background Agent | 异步执行、不阻塞主流程的Agent | `run_in_background: true` |
### 关键区分：什么时候用什么
```
单文件修改 → 主Agent直接做
2-3个文件的搜索 → Explore SubAgent
5+模块并行重构 → 多个General-purpose SubAgent + Worktree
需要实时协调的团队 → Agent Teams（邮箱通信）
长时间后台任务 → Background Agent
```
---
## 二、四种内置SubAgent深度解析
### 2.1 Explore Agent：轻量侦察兵
Explore Agent使用Haiku模型，只读权限，适合快速搜索和代码理解。
**调用模式：**
```javascript
// Task tool参数
{
subagent_type: "Explore",
description: "搜索认证模块",
prompt: "在src/auth/目录下找到所有JWT相关的中间件函数，列出文件路径和函数签名",
model: "haiku" // 默认就是haiku，可省略
}
```
**适用场景矩阵：**
| 场景 | 推荐度 | 原因 |
|------|--------|------|
| 搜索特定函数定义 | ★★★★★ | Haiku速度快，成本低 |
| 理解模块间依赖 | ★★★★☆ | 适合快速遍历 |
| 需要修改代码 | ☆☆☆☆☆ | 只读，无写入权限 |
| 复杂推理分析 | ★★☆☆☆ | Haiku推理能力有限 |
**实际操作示例——快速摸底项目结构：**
```bash
# 在Claude Code交互模式中输入：
> 用Explore Agent搜索整个项目，列出所有数据库模型文件及其字段定义
# 等效的-p模式：
claude -p "使用Task tool启动Explore类型的subagent，搜索项目中所有数据库模型定义（包括schema.prisma、models/*.ts、entities/*.ts），输出每个模型的名称、字段列表和关联关系"
```
### 2.2 Plan Agent：架构军师
Plan Agent继承当前会话的模型（通常是Sonnet或Opus），只读权限，专注于分析和策略设计。
**核心特征：**
- 可访问当前会话上下文
- 不执行任何写操作
- 产出结构化的实施计划
- 适合在编码前做架构决策
**实战——微服务拆分方案设计：**
```bash
claude -p "启动Plan类型的subagent分析src/monolith/目录，设计将其拆分为5个微服务的方案，包括：
1. 每个微服务的职责边界
2. 服务间通信方式（同步/异步）
3. 数据库拆分策略
4. 迁移顺序和依赖关系
输出为结构化的实施计划"
```
### 2.3 General-purpose Agent：全栈执行者
这是功能最完整的SubAgent类型，拥有所有工具的完整访问权限。
**关键能力：**
- 读写文件
- 执行Bash命令
- 调用其他工具（Grep、Glob等）
- 甚至可以嵌套创建自己的SubAgent
**Worktree隔离模式：**
```javascript
// 关键参数
{
subagent_type: "general-purpose",
description: "重构认证模块",
prompt: "将src/auth/下的所有JWT逻辑迁移到src/middleware/jwt.ts...",
isolation: "worktree" // 创建独立worktree，防止冲突
}
```
Worktree隔离的工作原理：
```mermaid
sequenceDiagram
participant Main as 主Agent
participant WT as Git Worktree
participant Sub as SubAgent
Main->>WT: git worktree add .claude/worktrees/feat-auth
WT->>Sub: 切换工作目录到worktree
Sub->>Sub: 在隔离环境中修改文件
Sub->>Sub: 运行测试验证
Sub->>Main: 返回结果 + worktree路径
Main->>Main: 审查变更
Main->>WT: git merge 或 丢弃worktree
```
### 2.4 Background Agent：异步打工人
Background Agent在后台异步执行，不阻塞主Agent的工作流。
**使用模式：**
```javascript
{
subagent_type: "general-purpose",
description: "运行完整测试套件",
prompt: "执行npm run test:all并分析失败的测试用例...",
run_in_background: true // 关键参数
}
```
**Background Agent的生命周期：**
```
1. 创建 → 立即返回output_file路径
2. 执行中 → 主Agent继续处理其他任务
3. 完成 → 系统自动通知主Agent
4. 获取结果 → 使用TaskOutput工具读取
```
---
## 三、Fan-out/Fan-in编排模式
这是多Agent编排最核心的模式：一个协调者将任务分解，分发给多个并行Agent，然后聚合结果。
### 3.1 标准Fan-out/Fan-in流程
```mermaid
flowchart LR
A[任务分解] --> B[Agent 1
模块A重构]
A --> C[Agent 2
模块B重构]
A --> D[Agent 3
模块C重构]
A --> E[Agent 4
测试编写]
B --> F[结果聚合]
C --> F
D --> F
E --> F
F --> G[冲突检测]
G --> H[合并/解决冲突]
H --> I[集成验证]
style A fill:#4A90D9,color:#fff
style F fill:#FFD700,color:#333
style I fill:#50C878,color:#fff
```
### 3.2 实战：五模块并行TypeScript严格模式迁移
**场景：** 一个中型项目有5个模块需要从`noImplicitAny: false`迁移到严格模式。
**步骤一：任务分解（主Agent）**
```bash
# 先让Plan Agent分析哪些文件需要修改
claude -p "分析以下5个模块中哪些TypeScript文件存在隐式any类型：
- src/api/
- src/services/
- src/utils/
- src/models/
- src/controllers/
输出每个模块需要修改的文件数量和预估复杂度"
```
**步骤二：并行分发（Fan-out）**
```markdown
# 在Claude Code中输入：
请并行启动5个general-purpose SubAgent，每个处理一个模块的TypeScript严格模式迁移：
Agent 1 (src/api/): 为所有请求处理函数添加参数和返回值类型
Agent 2 (src/services/): 修复业务逻辑层的隐式any
Agent 3 (src/utils/): 为工具函数添加泛型约束
Agent 4 (src/models/): 确保数据模型的类型完整性
Agent 5 (src/controllers/): 补全控制器层的类型定义
每个Agent使用worktree隔离，完成后运行该模块的单元测试。
```
**关键：Claude Code会自动将这些任务作为并行的Task tool调用发出。**
**步骤三：结果聚合（Fan-in）**
```javascript
// 主Agent自动收集所有SubAgent的结果
// 典型结果结构：
[
{ agent: "Agent 1", status: "success", files_modified: 12, tests_passing: true },
{ agent: "Agent 2", status: "success", files_modified: 8, tests_passing: true },
{ agent: "Agent 3", status: "partial", files_modified: 5, tests_passing: false,
error: "src/utils/validators.ts:23 - circular type reference" },
{ agent: "Agent 4", status: "success", files_modified: 3, tests_passing: true },
{ agent: "Agent 5", status: "success", files_modified: 15, tests_passing: true }
]
```
**步骤四：冲突处理**
当多个Agent修改了有依赖的文件时：
```bash
# 查看worktree列表
git worktree list
# 检查各worktree的变更
for wt in .claude/worktrees/*/; do
echo "=== $wt ==="
git -C "$wt" diff --stat
done
# 合并成功的worktree
git -C .claude/worktrees/agent-1 merge --no-edit feat/api-types
git -C .claude/worktrees/agent-2 merge --no-edit feat/services-types
# 处理失败的worktree（手动介入）
git -C .claude/worktrees/agent-3 diff src/utils/validators.ts
```
### 3.3 三种编排策略对比
| 策略 | 适用场景 | Agent数量 | 上下文开销 | 冲突风险 |
|------|----------|-----------|-----------|----------|
| 完全并行 | 模块间无依赖 | N个同时 | 低（每个Agent独立上下文） | 低（Worktree隔离） |
| 流水线 | 有顺序依赖 | N个串行 | 中（结果传递） | 极低 |
| 混合模式 | 部分依赖 | 分组并行 | 高（需要协调层） | 中等 |
---
## 四、Agent Teams：多实例协作
Agent Teams是Claude Code 2026年的实验性功能，允许多个独立的Claude Code实例作为一个团队协同工作。
### 4.1 启用Agent Teams
```bash
# 环境变量启用
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
# 或在.claude/settings.json中配置
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
```
### 4.2 Agent Teams vs SubAgent 对比
```mermaid
graph LR
subgraph "SubAgent模式"
SA[主Agent] --> SB[SubAgent 1]
SA --> SC[SubAgent 2]
SB -->|返回结果| SA
SC -->|返回结果| SA
end
subgraph "Agent Teams模式"
TA[Agent A] <-->|邮箱消息| TB[Agent B]
TA <-->|邮箱消息| TC[Agent C]
TB <-->|邮箱消息| TC
end
style SA fill:#4A90D9,color:#fff
style TA fill:#FF6B6B,color:#fff
style TB fill:#FF6B6B,color:#fff
style TC fill:#FF6B6B,color:#fff
```
| 维度 | SubAgent | Agent Teams |
|------|----------|-------------|
| 通信模型 | 请求-响应（单向） | 邮箱（双向） |
| 生命周期 | 随主Agent结束 | 独立运行 |
| 上下文 | 隔离（可选继承） | 完全独立 |
| 协调方式 | 主Agent调度 | 对等协调 |
| 适用规模 | 2-10个Agent | 2-20个Agent |
| 稳定性 | 稳定 | 实验性 |
### 4.3 Agent Teams邮箱通信机制
每个Team成员有一个邮箱，可以发送和接收消息：
```javascript
// Agent A 发送消息给 Agent B
// 在Agent A的会话中：
"请通过邮箱通知负责前端模块的Agent，API接口已经调整完毕，新增了以下端点..."
// Agent B 检查邮箱
// 在Agent B的会话中：
"检查你的邮箱，看是否有来自后端Agent的API变更通知"
```
### 4.4 Agent Teams角色分工模板
```yaml
# .claude/team-roles.yml 示例
team:
name: "fullstack-team"
members:
- role: "coordinator"
description: "任务分解和进度跟踪"
focus: ["任务分配", "冲突调解", "集成验证"]
- role: "backend-dev"
description: "后端API和数据库开发"
focus: ["API端点", "数据库迁移", "业务逻辑"]
- role: "frontend-dev"
description: "前端UI和状态管理"
focus: ["组件开发", "状态管理", "API集成"]
- role: "qa-engineer"
description: "测试编写和质量保障"
focus: ["单元测试", "集成测试", "E2E测试"]
```
---
## 五、实战案例：微服务API版本并行迁移
### 5.1 项目背景
假设有一个Express.js项目，需要从REST API v1迁移到v2：
```
src/
├── routes/
│ ├── users.ts # v1用户路由
│ ├── products.ts # v1产品路由
│ └── orders.ts # v1订单路由
├── controllers/
│ ├── userController.ts
│ ├── productController.ts
│ └── orderController.ts
├── middleware/
│ ├── auth.ts
│ └── validation.ts
└── types/
└── api.ts
```
### 5.2 完整编排脚本
```bash
#!/bin/bash
# migrate-api-v2.sh - 使用Claude Code的多Agent编排进行API迁移
# 阶段1：分析（Plan Agent）
echo "=== Phase 1: Analysis ==="
claude -p --output-format json \
"启动Plan subagent分析当前API结构。读取src/routes/、src/controllers/和src/types/api.ts，输出：
1. 每个端点的当前签名
2. 需要变更的字段列表
3. 依赖关系图
将结果保存到.claude/migration-plan.md" \
> .claude/analysis-result.json
# 等待分析完成
ANALYSIS_EXIT=$?
if [ $ANALYSIS_EXIT -ne 0 ]; then
echo "Analysis failed!"
exit 1
fi
# 阶段2：并行迁移（Fan-out）
echo "=== Phase 2: Parallel Migration ==="
# 使用-p模式启动3个并行Claude Code实例
claude -p \
"使用general-purpose subagent在worktree中完成users模块的API v2迁移：
1. 创建src/routes/v2/users.ts
2. 更新src/controllers/userController.ts
3. 确保向后兼容v1端点
4. 运行npm test -- --grep 'user'
使用worktree隔离" &
PID_USER=$!
claude -p \
"使用general-purpose subagent在worktree中完成products模块的API v2迁移：
1. 创建src/routes/v2/products.ts
2. 更新src/controllers/productController.ts
3. 确保向后兼容v1端点
4. 运行npm test -- --grep 'product'
使用worktree隔离" &
PID_PRODUCT=$!
claude -p \
"使用general-purpose subagent在worktree中完成orders模块的API v2迁移：
1. 创建src/routes/v2/orders.ts
2. 更新src/controllers/orderController.ts
3. 确保向后兼容v1端点
4. 运行npm test -- --grep 'order'
使用worktree隔离" &
PID_ORDER=$!
# 等待所有并行任务完成
wait $PID_USER
RESULT_USER=$?
wait $PID_PRODUCT
RESULT_PRODUCT=$?
wait $PID_ORDER
RESULT_ORDER=$?
echo "User module: $([ $RESULT_USER -eq 0 ] && echo 'SUCCESS' || echo 'FAILED')"
echo "Product module: $([ $RESULT_PRODUCT -eq 0 ] && echo 'SUCCESS' || echo 'FAILED')"
echo "Order module: $([ $RESULT_ORDER -eq 0 ] && echo 'SUCCESS' || echo 'FAILED')"
# 阶段3：集成（主Agent）
echo "=== Phase 3: Integration ==="
claude -p \
"检查所有worktree中的变更，合并到主分支：
1. 列出所有worktree: git worktree list
2. 检查每个worktree的测试结果
3. 合并成功的worktree变更
4. 更新src/routes/index.ts注册v2路由
5. 更新API类型定义src/types/api.ts
6. 运行完整测试套件: npm test
7. 如果测试通过，清理worktree"
```
### 5.3 在交互模式中的等效操作
```markdown
# 在Claude Code交互模式中，一条消息触发多Agent并行：
请并行启动3个general-purpose SubAgent，分别处理以下模块的API v2迁移：
模块1 - Users:
- 创建 src/routes/v2/users.ts（新的v2端点）
- 更新 src/controllers/userController.ts（支持v2格式）
- 保留v1路由的向后兼容
模块2 - Products:
- 创建 src/routes/v2/products.ts
- 更新 src/controllers/productController.ts
- 保留v1路由的向后兼容
模块3 - Orders:
- 创建 src/routes/v2/orders.ts
- 更新 src/controllers/orderController.ts
- 保留v1路由的向后兼容
每个Agent使用worktree隔离工作。所有Agent完成后：
1. 聚合结果
2. 更新路由注册文件
3. 运行完整测试套件
4. 报告每个模块的状态
```
### 5.4 结果聚合与质量把关
```mermaid
flowchart TD
A[3个SubAgent完成] --> B{所有测试通过?}
B -->|是| C[合并Worktree]
B -->|否| D[分析失败原因]
D --> E{可自动修复?}
E -->|是| F[启动修复Agent]
E -->|否| G[标记待人工处理]
F --> B
C --> H[运行集成测试]
H --> I{集成测试通过?}
I -->|是| J[清理Worktree
完成迁移]
I -->|否| K[回滚+分析冲突]
K --> L[手动解决冲突]
style J fill:#50C878,color:#fff
style G fill:#FF6B6B,color:#fff
style L fill:#FFD700,color:#333
```
---
## 六、高级编排模式
### 6.1 MapReduce模式
适用于对大量同类文件执行相同操作：
```markdown
请执行MapReduce模式的批量操作：
Map阶段：
- 扫描src/下所有*.test.ts文件
- 每个文件分配一个Explore SubAgent
- 每个Agent分析其测试文件的质量（覆盖率、断言数量、边界情况）
Reduce阶段：
- 聚合所有Agent的分析结果
- 按模块统计测试质量分数
- 输出优先改进的前10个测试文件
```
### 6.2 流水线模式
适用于有严格依赖关系的多步骤任务：
```markdown
请按流水线模式执行以下步骤，每步完成后再启动下一步：
Step 1 (Plan Agent): 分析数据库schema变更的影响范围
Step 2 (General-purpose): 执行数据库迁移脚本
Step 3 (General-purpose): 更新所有受影响的TypeScript类型定义
Step 4 (General-purpose): 修复因类型变更导致的编译错误
Step 5 (Background Agent): 运行完整测试套件并生成报告
每一步开始前确认上一步已成功完成。
```
### 6.3 监督者模式
一个主Agent持续监控多个Background Agent的进度：
```markdown
请并行启动以下后台任务，然后持续监控进度：
后台任务1: 运行完整E2E测试套件（预计10分钟）
后台任务2: 执行npm audit安全检查
后台任务3: 运行性能基准测试
启动后，每完成一个任务就立即处理其结果。
全部完成后输出综合报告。
```
### 6.4 自定义SubAgent配置
在`.claude/settings.json`中定义项目级SubAgent：
```json
{
"subagents": {
"security-auditor": {
"description": "安全审计专用Agent，扫描OWASP Top 10漏洞",
"subagent_type": "general-purpose",
"model": "opus",
"tools": ["Bash", "Read", "Grep", "Glob"],
"system_prompt": "你是一个安全审计专家。专注于SQL注入、XSS、CSRF、认证绕过等漏洞。对每个发现评估严重程度（Critical/High/Medium/Low）并给出修复建议。"
},
"test-writer": {
"description": "测试编写Agent，为指定函数生成单元测试",
"subagent_type": "general-purpose",
"model": "sonnet",
"isolation": "worktree"
}
}
}
```
---
## 七、性能与成本优化
### 7.1 Agent数量与效率关系
```mermaid
graph LR
A[1个Agent
串行执行
基准时间: 60min] --> B[2-3个Agent
轻度并行
时间: 25-30min]
B --> C[4-6个Agent
最优区间
时间: 12-18min]
C --> D[7-10个Agent
收益递减
时间: 10-15min]
D --> E[10+个Agent
协调开销>收益
时间: 12-20min]
style C fill:#50C878,color:#fff
style E fill:#FF6B6B,color:#fff
```
### 7.2 模型选择策略
| Agent类型 | 推荐模型 | 原因 | 成本倍数 |
|-----------|----------|------|----------|
| Explore | Haiku | 搜索任务不需要强推理 | 1x |
| Plan | Sonnet | 分析需要中等推理能力 | 3x |
| General-purpose（简单修改） | Sonnet | 大多数编码任务足够 | 3x |
| General-purpose（复杂重构） | Opus | 复杂推理和多文件协调 | 15x |
| Background（长时间运行） | Sonnet | 平衡成本和质量 | 3x |
### 7.3 上下文窗口管理
```markdown
# 反模式：给SubAgent传递过多上下文
请启动一个SubAgent，以下是需要处理的全部500行代码：
[粘贴500行代码] ← 浪费上下文窗口
# 最佳实践：让SubAgent自己读取
请启动一个SubAgent处理src/api/users.ts中的类型问题。
它会自行读取文件并修复。
```
### 7.4 成本估算公式
```
总成本 ≈ 协调Agent成本 + Σ(并行Agent成本)
≈ (主Agent tokens × Opus单价) + (N × 子Agent tokens × 模型单价)
最优并行数 N* = √(总任务数 × 平均任务复杂度 / 协调开销)
```
---
## 八、常见问题与排错
### 8.1 SubAgent超时
**症状：** SubAgent执行时间过长，主Agent等待超时。
**解决方案：**
```markdown
# 方案1：拆分为更小的子任务
# 将"重构整个模块"拆分为"重构单个文件"
# 方案2：使用Background Agent
将长时间运行的任务设为run_in_background: true
# 方案3：增加max_turns
通过max_turns参数限制Agent的最大轮次：
{
max_turns: 50 // 默认通常足够，复杂任务可增加
}
```
### 8.2 Worktree冲突
**症状：** 多个Agent修改了同一文件。
**解决方案：**
```bash
# 查看冲突文件
git diff --name-only .claude/worktrees/agent-1 .claude/worktrees/agent-2
# 让主Agent解决冲突
claude -p "检查worktree agent-1和agent-2中的冲突文件，智能合并两者的修改：
- 保留两者的类型定义（取并集）
- 如果逻辑冲突，优先agent-1的版本
- 运行测试验证合并结果"
```
### 8.3 Agent结果丢失
**症状：** Background Agent完成但结果未返回。
**解决方案：**
```javascript
// 使用TaskOutput工具主动查询
{
task_id: "agent-background-abc123",
block: true, // 阻塞等待结果
timeout: 60000 // 超时时间60秒
}
// 或查看输出文件
// Background Agent会返回一个output_file路径
// 使用Read工具读取该文件
```
---
## 九、编排最佳实践清单
| # | 实践 | 原因 |
|---|------|------|
| 1 | **任务粒度适中** — 每个Agent处理1-5个文件 | 过大超时，过小调度开销高 |
| 2 | **优先用Explore侦察** — 编码前先摸底 | 避免盲区导致的返工 |
| 3 | **Worktree隔离并行任务** — 不要在主目录并行 | 防止文件冲突 |
| 4 | **显式指定模型** — 简单任务用Haiku | 节省成本 |
| 5 | **设置max_turns** — 防止Agent无限循环 | 成本控制 |
| 6 | **聚合后再测试** — 所有Agent完成再跑集成测试 | 避免浪费时间调试中间状态 |
| 7 | **错误要冒泡** — SubAgent失败时主Agent要能感知 | 避免在错误基础上继续构建 |
| 8 | **Resume模式** — 对需要多轮交互的任务 | 保持Agent的上下文连续性 |
---
## 延伸阅读
- [Claude Code官方文档 - SubAgents](https://code.claude.com/docs/en/sub-agents) — Anthropic官方SubAgent配置指南
- [Claude Code官方文档 - Agent Teams](https://code.claude.com/docs/en/agent-teams) — Agent Teams多实例协作文档
- [Claude Code官方文档 - Worktrees](https://code.claude.com/docs/en/worktrees) — 并行Worktree隔离机制
- [DeepWiki - Agent System & Subagents](https://deepwiki.com/anthropics/claude-code/3.1-agent-system-and-subagents) — 源码级架构分析
- [ccswarm - 多Agent编排系统](https://github.com/nwiizo/ccswarm) — 开源Rust多Agent编排框架
## 训练营适用性评估
| 维度 | 评估 |
|------|------|
| 适合训练营类型 | 进阶训练营（已掌握Claude Code基础） |
| 预计教学时长 | 4-5小时（含动手实操） |
| 实操占比 | 70%（编排模式设计+实际执行） |
| 最低学员水平 | 中级开发者，理解并发和任务分解概念 |
| 硬件要求 | 每人需要Claude Code Pro订阅（并行Agent消耗token较多） |
| 推荐分组方式 | 2-3人一组，每组负责一个编排模式的深入实践 |
## 参考来源
1. [Subagents in the SDK - Claude Code Docs](https://code.claude.com/docs/en/agent-sdk/subagents) — Anthropic官方SubAgent SDK文档，定义和调用接口
2. [Agent System & Subagents - DeepWiki](https://deepwiki.com/anthropics/claude-code/3.1-agent-system-and-subagents) — Claude Code源码级Agent架构分析
3. [Subagents and Parallel Execution - samanvya.dev](https://samanvya.dev/blog/claude-code-subagents-parallel) — Fan-out/Fan-in并行执行模式详解
4. [Run parallel sessions with worktrees - Claude Code Docs](https://code.claude.com/docs/en/worktrees) — 官方Worktree隔离并行会话指南
5. [Claude Code Multi-Agent Coordination - wowhow.cloud](https://wowhow.cloud/blogs/claude-code-multi-agent-coordination-agent-teams-guide-2026) — 2026年多Agent协调模式全景指南
> [!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 等场景全覆盖。
