一张官方对比表
| 方式 | 给你什么 | 什么时候用 |
|---|---|---|
| Subagents | 会话内的委派工人：独立上下文干旁支任务，回摘要 | 搜索结果、日志、文件内容会灌爆主对话，而你只要结论 |
| Agent view | claude agents 打开的一屏：派发、看状态、谁卡了点谁（研究预览） | 几个互不相干的任务想撒手，只在需要时介入 |
| Agent teams | lead 协调的一组会话：共享任务清单 + 队友互发消息（实验性，默认关） | 想让 Claude 自己拆项目、派活、保持同步 |
| 动态工作流 | 脚本驱动大量子智能体并交叉验证结果 | 任务大过几个 subagent 的量级，或结论需要互查 |
所有方式里的 worker 都是 Claude 会话；要让别的工具参战，以 MCP 服务器形式暴露给 Claude。
决策框架：三个问题
1. 谁协调工作？
- Claude 在一个对话里派发并收集 → subagents
- 你派发独立任务、稍后回来看 → agent view
- Claude 规划、分配并监督一组 worker → agent teams
- 计划握在脚本手里而不是 Claude 的逐轮判断 → 动态工作流
2. workers 要互相通信吗？
subagent 只向派它的会话汇报；agent view 会话只向你汇报；teammates 直接互发消息并共享任务清单； 你自己跑的多个会话之间可以用跨会话消息传递发现与状态（本机、其他机器、网页会话都可达）。
3. 动不动同一批文件？
会动就上 worktree：每会话独立 Git 检出，互不踩踏。agent view 派发的会话自动各进一个 worktree；subagent 也可以逐个分配。唯一的例外是 agent teams——teammates 不做 worktree 隔离，官方要求靠任务划分让每人拥有不同文件集。
容易混淆的「伪并行」三件
- 后台 Bash 命令：只是不阻塞对话地跑一条 shell 命令，没有 spawn 任何智能体。
- fork 出的子智能体（/subtask）：继承全部对话上下文的 subagent——是 spawn 方式的变体，不是新的并行面；/fork 则是把整个会话复制成并行的后台会话。
- Routine：按日程在云上跑会话，解决的是「定时」不是「并行」。
Agent Teams 实操要点
// settings.json —— 实验性，默认关闭
{
"env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }
}开启后自然语言即可组队，官方示例的结构值得模仿——三个角色彼此独立、无需互相等待：
我在设计一个帮开发者跟踪代码库 TODO 注释的 CLI 工具。
Spawn 三个 teammates 从不同角度探索：
一个管 UX，一个管技术架构，一个唱反调。- lead 填共享任务清单、spawn 队友、汇总结论；面板里上下键选队友、Enter 进它的对话直接交流、Esc 可打断其当前轮。
- Claude 有时会用 subagents 代替组队（两者共用同一个面板，看面板分不出来）——没组成就再要一次、点名要 agent team。
- 两个连带行为要知道：开启后 Claude 给 subagent 命名就会把它拉成 teammate（可能没让组队也组了）；-p 非交互与 Agent SDK 里不会 spawn teammates。
- 已知限制集中在会话恢复、任务协调与关停行为——这是实验性标签的实际含义，生产流程别依赖它。
适合与不适合
| 适合 teams | 更适合单会话 / subagents |
|---|---|
| 多角度研究评审、互相挑战结论 | 顺序依赖强的任务 |
| 新模块开发，每人独占一块 | 要改同一批文件的工作 |
| 竞争性假设并行排查 bug | 依赖链复杂、协调成本大于并行收益 |
| 跨前端 / 后端 / 测试的分层改动 | 只要结果不要过程的聚焦任务 |
怎么查各路并行的进度
claude agents：agent view 一屏看全部后台会话状态（注意与 /agents 是两回事——后者现在只打印子智能体文件位置）。/tasks：当前会话的后台项清单（含已完成的 subagents），可查看、附身、停止。/workflows：动态工作流的运行列表、所处阶段与完成数。- Desktop 用户：侧边栏 + tasks 面板是同一信息的图形化。
成本与选型清单
- 并行度 = token 倍数：teams 每个队友都是完整会话，成本远高于「摘要回传」的 subagents。
- 升级路径按序走：单会话 → subagents → agent view → workflows / teams，每一步都先确认上一档确实不够。
- 动文件必隔离：worktree 是默认答案；用 teams 就手动划清文件归属。
- /batch 是包装好的捷径：一个大改动拆成 5–30 个 worktree 隔离的 subagents 各开一个 PR。
- 限流频繁说明并行度超了套餐承载：收缩规模、错峰，或参考套餐对比升档。
并行不是目的，是「探索空间大于单上下文容量」时的手段。官方框架的价值在于把选择题变成三个可回答的问题—— 谁协调、要不要通信、动不动同一批文件。答完这三问，选型就只剩一个格子。