Claude Code 并行指南：子代理与代理团队的 7 个选择标准

你正在用Claude Code开发一个功能，需要同时搜索代码库、写前端、写后端。你启动了3个子代理并行工作，结果前端代理返回的API调用格式和后端代理实际实现的接口对不上——你花了2小时调试这个衔接问题。

这不是你的错。子代理的设计初衷是"独立执行、返回结果"，而不是"相互协调、实时同步"。2025年末，Anthropic发布了Agent Teams功能，给出了另一种答案：让多个Claude实例组成团队，它们可以相互对话、共享上下文、自主协调。

问题来了：你应该用哪个？这篇文章给你7个选择标准，让你在30秒内做出正确决策。

第一章：两种并行模式，两种完全不同的工作方式 #

Claude Code提供了两种并行执行机制，它们看起来相似，但架构本质完全不同。

**子代理（Subagents）**是轻量级工作单元。你给它一个任务，它在独立的上下文窗口中执行，完成后返回摘要给你。它就像一个承包商——你告诉他要什么，他交付结果，期间不需要沟通。子代理之间看不见彼此，所有协调都必须经过你。

**代理团队（Agent Teams）**是多个完整Claude Code实例组成的协作小组。每个队友都有自己的上下文窗口、都能读取项目配置、都能独立工作。关键是：队友之间可以直接发消息，不需要经过你。它们共享一个任务列表，可以自主认领任务、标记完成、相互通知。

用一句话概括：子代理汇报结果，代理团队相互对话。

这个架构差异决定了它们适合完全不同的场景。选错了，你会在调试循环中浪费大量时间；选对了，复杂协作可以一次成型。

第二章：标准1-2——任务独立性与协调需求 #

选择并行模式，先问两个问题。

问题1：任务之间是否独立？

如果A任务的输出不影响B任务的执行方式，它们就是独立的。代码库搜索、安全审计、性能分析——这些任务各自为战，不需要知道其他人在做什么。这种情况下，用子代理。

如果A任务的决定会影响B任务的做法，它们就有依赖。后端定义API契约，前端据此构建数据层——后者需要知道前者的决定。这种情况下，考虑代理团队。

问题2：工作过程中需要协调吗？

子代理的设计假设是：任务开始前，输入已经明确；任务结束后，输出一次性返回。如果你需要在执行过程中调整方向、同步发现、协商接口，子代理做不到——它只能返回给你，你再转发给另一个子代理。

代理团队允许队友实时沟通。后端队友定好API响应结构，直接发消息告诉前端队友，不需要你当传声筒。Charles Jones在OAuth实现中测试了这个模式：前端和后端第一次就匹配上了，因为接口契约是队友间直接共享的，而不是通过摘要传递。

快速判断：如果你的任务清单像"三个人各自写报告"，用子代理；如果像"三个人一起搭积木"，用代理团队。

第三章：标准3-4——Token预算与调试复杂度 #

并行模式的选择，直接影响你的Token消耗和调试成本。

标准3：你的Token预算有多紧张？

子代理更省Token。执行完成后，只有摘要回到主上下文。你可以让子代理读完30个文件，最后只返回3段话给你——中间的探索过程不占用你的上下文窗口。

代理团队更费Token。每个队友都是完整的Claude实例，各自维护独立上下文。5个队友同时工作，Token消耗是单代理的5倍。如果你的任务是"读20个文件找模式"，用子代理就够了；如果用代理团队，就是用大炮打蚊子。

标准4：调试复杂度有多高？

这里有个反直觉的结论：代理团队虽然Token成本更高，但可能总体更省时间。

原因在于"衔接调试"。子代理模式下，A返回的结果是摘要，B基于摘要做判断——摘要丢失细节，就会产生理解偏差。你花1小时写代码，花2小时修"哦，这个字段是数组不是对象"这种问题。

代理团队模式下，队友共享完整的上下文，不是摘要。后端队友决定的响应结构，前端队友看到的是原始信息，没有信息损耗。Charles Jones的OAuth实现报告：“零bug，第一次前后端就匹配上了”。省下的调试时间，可能远超多花的Token成本。

成本公式：子代理成本 = Token消耗；代理团队成本 = Token消耗 - 节省的调试时间。

第四章：标准5-6——上下文共享与会话管理 #

这两个标准决定了你的工作流能不能持续运转。

标准5：执行过程中需要共享上下文吗？

子代理之间完全隔离。子代理A读到的内容，子代理B看不到。如果你想让他们共享发现，你必须在主对话中汇总再分发——这会快速膨胀你的上下文窗口。

代理团队天生共享上下文。通过共享任务列表和邮箱机制，队友可以随时看到彼此的进展。代码审查场景特别适合：安全审查队友发现一个问题，发消息给架构审查队友讨论影响范围——这种交叉反馈在子代理模式下无法实现。

标准6：你需要会话持久性吗？

这是代理团队目前的短板。Agent Teams是实验性功能，会话恢复后队友会丢失。如果你今天创建了团队，明天继续会话，队友已经不在了——你需要重新创建。

子代理不存在这个问题。每次调用都是独立的，不依赖会话状态。如果你的工作跨越多天、需要频繁中断恢复，子代理更可靠。

实用性建议：单次会话能完成的复杂协作用代理团队；跨多天的长期项目用子代理的阶段性调用。

第五章：标准7——团队规模与任务复杂度 #

最后一个标准是关于规模边界的。

团队规模限制：一个会话只能运行一个代理团队，队友不能嵌套创建自己的团队。这意味着你的并行度上限就是队友数量——通常3-5个。

任务复杂度阈值：不是所有复杂任务都需要代理团队。判断标准是：协调成本是否超过独立执行成本。

用一个具体例子说明。你要重构一个模块，涉及5个文件：

• 用子代理：分别改5个文件，最后你手动解决冲突。可能花30分钟处理冲突。
• 用代理团队：队友协商谁改哪个文件的哪部分，实时同步接口变化。可能花10分钟协调，但零冲突。

如果冲突处理时间 > 协调时间，代理团队更优。反之，子代理更优。

规模建议：

• 2-3个独立任务：子代理足够
• 3-5个相互依赖的任务：代理团队优势明显
• 超过5个任务：拆成多轮执行，无论哪种模式

第六章：实战决策——3个场景的选择过程 #

理论讲完了，看3个真实场景怎么选。

场景1：代码库探索

任务：搜索"API端点"、“数据库模型”、“认证逻辑"三个主题，返回发现。

决策过程：

• 任务独立性：✅ 完全独立
• 需要协调：❌ 不需要
• Token考量：搜索类任务上下文膨胀快，需要隔离

选择：子代理（Explore类型）

原因：三个搜索任务互不影响，最后只需要汇总结果。用代理团队是浪费。

场景2：OAuth多提供商实现

任务：同时实现GitHub和Google OAuth，包括后端处理、前端UI、测试用例。

决策过程：

• 任务独立性：❌ 前后端需要共享API契约
• 需要协调：✅ 后端定好响应结构，前端据此实现
• 调试复杂度：高，接口不匹配是常见问题

选择：代理团队

原因：后端队友可以直接告诉前端队友响应格式，省去接口调试环节。实测零bug完成。

场景3：多假设调试

任务：一个bug有3种可能原因，需要同时验证。

决策过程：

• 任务独立性：✅ 验证过程独立
• 需要协调：✅ 验证结果需要相互质疑、交叉验证
• 上下文共享：✅ 一个假设被排除，需要通知其他队友

选择：代理团队

原因：对抗性调试需要队友之间相互挑战。子代理只能各自返回结论，无法形成讨论。

第七章：代理团队的启用与配置 #

决定使用代理团队，需要先启用实验性功能。

启用方式：

在 ~/.claude/settings.json 中添加：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

或设置环境变量：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

创建团队的提示词模板：

创建一个代理团队来实现用户通知系统。

生成三个队友：
- 一个负责后端API和数据库层
- 一个负责前端组件和状态管理
- 一个负责集成测试和错误处理

后端队友在确定API契约后，应该直接分享给前端队友。

关键配置选项：

• Delegate Mode：按 Shift+Tab 切换。开启后，主代理只负责协调，不直接修改代码。推荐开启，避免职责混乱。
• Plan Approval：敏感任务可以要求队友先提交计划，你审批后再执行。数据库迁移等高风险操作建议开启。
• Split Pane Mode：如果用tmux或iTerm2，每个队友有独立面板，可以同时看到所有人的输出。

注意事项：

• 会话恢复后队友会丢失，需要重新创建
• 任务状态可能滞后，需要手动提醒队友更新
• 每个队友都是完整Claude实例，Token消耗是倍数关系

第八章：决策框架速查表 #

8章内容，浓缩成一张决策表。

30秒决策流程：

1. 任务是否相互独立？是 → 子代理
2. 执行中需要协调吗？否 → 子代理
3. Token预算紧张吗？是 → 子代理
4. 调试衔接问题成本高吗？是 → 代理团队
5. 需要会话跨天持续吗？是 → 子代理

如果走到第5步还没明确答案，默认用子代理——它是更成熟的机制。

场景对照表：

一句话总结：

子代理是承包商，给你交付结果；代理团队是工程师小组，在同一个房间里协作。选承包商还是选小组，取决于你的任务是"各自交报告"还是"一起搭积木”。

记住这句话就够了：需要对话用团队，独立执行用子代理。