Claude Code 目前提供四种让 Claude 同时处理多项任务的方式——Subagents（子代理）、Agent View（代理视图）、**Agent Teams（代理团队）**和 Dynamic Workflows（动态工作流）。它们看起来功能相近，但适用场景差异很大。本文基于官方文档梳理选型逻辑。
核心区别：谁来协调工作
官方文档给出的判断标准非常清晰：
The right approach depends on whether you want to stay in each conversation yourself, hand tasks off and check back later, or have Claude coordinate a group of workers for you.
| 方式 | 提供什么 | 适用场景 |
|---|---|---|
| Subagents | 单个会话内的委托工作者，在自己的上下文中完成子任务并返回摘要 | 一个子任务会用大量搜索结果、日志或文件内容淹没主对话，而这些内容你之后不会再引用 |
| Agent View | 一屏统一调度和监控后台运行的会话（claude agents 打开），研究预览阶段 | 你有多个独立任务想直接甩出去，只在需要时快速查看状态并介入 |
| Agent Teams | 多个协调的会话，共享任务列表并可互相通信，由一个 Lead 统一管理，实验性功能默认禁用 | 你想让 Claude 把一个项目拆解成多块、分配下去，并让各个工作者保持同步 |
| Dynamic Workflows | 一段脚本运行大量子代理并交叉核对结果，适合大到无法逐轮协调的任务 | 任务规模超出了少量子代理能处理的范围，或者你需要多方结果互相验证：全代码库审计、500 文件迁移、交叉核实的研究、多角度草拟方案 |
关键决策维度
官方文档提炼出三个具体的决策问题：
1. 谁来协调工作？
Claude 在一次对话内委托并收集结果 → Subagents
你甩出独立任务，之后再回来检查 → Agent View
Claude 规划、分配、监督一组工作者 → Agent Teams（实验性，默认禁用）
一段脚本掌控计划，而不是 Claude 逐轮判断 → Dynamic Workflows
2. 工作者之间需要互相沟通吗？
- Subagents：只向生成它的对话汇报结果，工作者之间互不通信
- Agent View：会话只向你本人汇报，彼此独立
- Agent Teams：队友之间共享任务列表，可以直接互相发消息
3. 任务会不会改动同一批文件？
- 用 [Worktrees] 隔离工作——你自己运行的会话和 Subagents 都可以各自使用独立的 Worktree
- Agent Teams 不会自动把队友隔离到不同 Worktree，所以需要你自己手动划分工作范围（每个队友负责不同的文件集合），避免冲突
Subagents vs Agent Teams 详细对比
这两者最容易混淆，官方文档给出了明确的对比表：
| 维度 | Subagents | Agent Teams |
|---|---|---|
| 上下文 | 拥有自己的上下文窗口；结果返回给调用者 | 拥有自己的上下文窗口；完全独立 |
| 通信 | 只向主 Agent 汇报结果 | 队友之间直接互相发消息 |
| 协调 | 主 Agent 管理所有工作 | 共享任务列表，自我协调 |
| 最适合 | 只关心结果的聚焦型任务 | 需要讨论和协作的复杂工作 |
| Token 成本 | 较低：结果汇总后返回主上下文 | 较高：每个队友都是独立的 Claude 实例 |
简单记忆法：需要快速、聚焦、只看结果的工作者，用 Subagents；需要工作者之间互相分享发现、挑战对方观点、自主协调的复杂工作，用 Agent Teams。
两个容易被忽视的辅助能力
文档中特别指出，还有两个工具支撑并行工作但本身不是一种独立的协调方式：
Worktrees：为每个会话提供独立的 Git 检出，让并行会话不会同时编辑相同的文件。Agent View 会自动把每个派发的会话移入独立的 Worktree，你手动生成的 Subagents 也可以各自获得一个/batch：这是一个 Skill，让 Claude 把一个大改动拆分成 5-30 个 Worktree 隔离的子代理，每个子代理各自开一个 PR。它是 Subagents + Worktrees 的一种打包用法，不是单独的协调方式
另外还有三个容易和「多 Agent 并行」混淆、但解决的是不同问题的功能：
- 后台 Bash 命令：只是让一个 Shell 命令不阻塞对话运行，不会生成 Agent
- Forked Subagent：一种继承你完整对话上下文（而不是从零开始）的 Subagent，本质上是生成 Subagent 的一种方式，不是独立的协调风格
- Routine：在 Anthropic 云端按计划定时运行一个会话，不是在你本机并行运行
实用选型速查
场景：需要查一个大型日志文件找报错原因，但不想让日志内容占满对话
→ Subagents
场景：同时有 5 个独立的小功能要开发，想分别派发出去，稍后统一查看进度
→ Agent View（claude agents）
场景：设计一个新功能，想让「UX 视角」「架构视角」「唱反调视角」三个角色互相讨论
→ Agent Teams（需要先手动启用）
场景：给 500 个文件做统一迁移，需要每个改动互相交叉验证
→ Dynamic Workflows
场景：一次性把一个大重构拆成 20 个 PR 并行处理
→ /batch（Subagents + Worktrees 的打包方案）
总结
四种并行方式并非互相替代关系，而是分别针对不同的协调需求：谁来做决策（Claude 逐轮判断还是脚本预先设定）、工作者要不要互相说话、以及任务规模有多大。理解这三条决策线，能帮你在实际项目中快速选对工具，避免为了简单任务引入 Agent Teams 这类高 Token 成本的重型方案，也避免用单一 Subagent 硬扛本该用 Dynamic Workflows 处理的超大规模任务。
来源：Run agents in parallel — Claude Code 官方文档，Anthropic