Claude Code 的三种多 Agent 模式：Coordinator、Swarm 和 ForkClaude Cod

大多数 Agent 产品的“多 Agent”其实只是串行调几个子 Agent。Claude Code 里至少有三套协作机制：Coordinator 是中心化调度，Swarm 是带 team lead 的团队协议，Fork 是共享父上下文的轻量分身。它们解决的问题不同，代码路径也完全不同。

一、先讲结论

Claude Code 不是单 Agent 产品。它内部同时存在三种多 Agent 协作模式，其中 Coordinator 和 Fork 是互斥的（开启 Coordinator 会自动禁用 Fork），Swarm 则是独立的团队能力：

维度	Coordinator Mode	Agent Swarms	Fork Subagent
拓扑	中心化：协调者 + N 个 worker	弱中心化：lead 管生命周期，队友可互发消息	父进程分裂出 N 个子进程
通信方式	XML `<task-notification>` 回传	`SendMessage` + mailbox	无横向通信，只回父进程
运行环境	同进程异步	tmux/iTerm2 面板或 in-process	同进程异步
上下文共享	无（worker 独立 prompt）	无（队友独立会话）	完整继承父对话 + prompt cache
权限模型	worker 工具受限	in-process 走 leader queue，pane 模式走 mailbox 同步	bubble 冒泡到父终端
适用场景	复杂工程任务（研究→综合→实现→验证）	长期运行的并行团队	快速并行探索/微任务

几个核心判断：

Coordinator 是 Claude Code 的"项目经理模式"。适合需要全局视野、多阶段流水线的大型任务。协调者自己不执行工具，只拆任务、派活、综合结果
Swarm 是最接近"团队协作"体验的模式。pane backend 下它确实像多进程团队；但在 in-process fallback 下，队友仍跑在同一个 Node.js 进程里。它的关键不是"一定多进程"，而是 team file、mailbox、SendMessage 这套团队协议
Fork 是最轻量的选择。主 Agent 调 AgentTool 时如果不指定 subagent_type，就自动走 fork 路径；子进程继承父进程的完整对话上下文，并且尽量复用父进程的 prompt cache

如果你在做自己的多 Agent 系统，最值得学的是 Fork 路径的 prompt cache 共享设计。至少在我见过的公开实现里，它是把“子 Agent 复用父上下文”这件事做得最彻底的一种。

二、它在解决什么问题

单 Agent 的瓶颈很明显：

串行阻塞。模型在做调研时，你什么都干不了，只能等
上下文污染。让同一个 Agent 既做调研又做实现又做验证，每一步都在消耗上下文窗口，相互干扰
能力不匹配。探索代码库只需要 Haiku + 只读工具，但实现功能需要 Sonnet/Opus + 全量工具。单 Agent 只能用一个配置

多 Agent 不是为了"看起来很酷"，而是用架构解决资源分配问题——让不同的 Agent 用不同的模型、不同的工具集、不同的权限，并行处理不同的子任务。

但多 Agent 也有自己的问题：上下文传递的开销、权限管理的复杂度、子 Agent 之间的协调成本。Claude Code 的三种模式就是在不同维度上做取舍。

三、三种模式的完整工作流

flowchart TD
    subgraph C["Coordinator Mode"]
        C_L["Coordinator（协调者）<br/>AgentTool + SendMessage + TaskStop + SyntheticOutput"]
        C_W1["Worker 1<br/>标准工具集"]
        C_W2["Worker 2<br/>标准工具集"]
        C_W3["Worker 3<br/>标准工具集"]
        C_L -->|"AgentTool(worker)"| C_W1
        C_L -->|"AgentTool(worker)"| C_W2
        C_L -->|"AgentTool(worker)"| C_W3
        C_W1 -->|"&lt;task-notification&gt;"| C_L
        C_W2 -->|"&lt;task-notification&gt;"| C_L
        C_W3 -->|"&lt;task-notification&gt;"| C_L
    end

    subgraph S["Agent Swarms"]
        S_L["Team Lead<br/>TeamCreate + SendMessage + AgentTool"]
        S_T1["Teammate 1<br/>pane 或 in-process"]
        S_T2["Teammate 2<br/>pane 或 in-process"]
        S_L <-->|"SendMessage"| S_T1
        S_L <-->|"SendMessage"| S_T2
        S_T1 <-->|"SendMessage"| S_T2
    end

    subgraph F["Fork Subagent"]
        F_P["Parent Agent<br/>完整工具集"]
        F_C1["Fork Child 1<br/>继承父工具集"]
        F_C2["Fork Child 2<br/>继承父工具集"]
        F_P -->|"AgentTool(无type)"| F_C1
        F_P -->|"AgentTool(无type)"| F_C2
        F_C1 -->|"&lt;task-notification&gt;"| F_P
        F_C2 -->|"&lt;task-notification&gt;"| F_P
    end

四、Coordinator Mode：中心化调度

核心思路

Coordinator 是最"传统"的多 Agent 模式。它把 Agent 分成两个角色：

Coordinator（协调者）：面对用户，负责拆解任务、分派 worker、综合结果。不直接执行工具（核心工具只有 AgentTool、SendMessage、TaskStop、SyntheticOutput 四个；如果配了 GitHub 集成还会有 subscribe_pr_activity / unsubscribe_pr_activity）
Worker（工人）：接受协调者分派的任务，独立执行，完成后通过 XML <task-notification> 回传结果

这种模式的核心在于信息漏斗——用户只跟协调者对话，协调者把复杂信息压缩成人能理解的摘要。Worker 的输出可能是几千 token 的代码分析，但协调者只需要向用户汇报关键结论。

协调者的系统 Prompt

协调者的 prompt 非常结构化，定义了四个阶段流水线：

阶段	谁执行	目的
Research	Workers（并行）	调查代码库、发现问题
Synthesis	协调者自己	阅读调研结果，制定实现方案
Implementation	Workers	按方案修改代码、提交
Verification	Workers	测试变更、检查类型

Prompt 反复强调一个原则：并行是你的超能力。

"Parallelism is your superpower. Workers are async. Launch independent workers concurrently whenever possible."

Worker 的工具限制

Worker 不是全权的 Claude Code 实例——它的工具集被裁剪过：

const INTERNAL_WORKER_TOOLS = new Set([
  TEAM_CREATE_TOOL_NAME,    // 不能创建团队
  TEAM_DELETE_TOOL_NAME,    // 不能删除团队
  SEND_MESSAGE_TOOL_NAME,   // 不能互发消息
  SYNTHETIC_OUTPUT_TOOL_NAME,
])

Worker 不能用这些"元工具"，只能用标准的文件操作、Shell、搜索等工具。这是角色隔离——Worker 不需要知道它是团队的一部分，它只管完成分配的任务。

更准确地说，worker 的基础工具池来自 ASYNC_AGENT_ALLOWED_TOOLS，再扣掉这几个团队级元工具；如果当前环境连了 MCP server，或者 Skill tool 可用，它们也可以进入 worker。

Scratchpad：跨 Worker 的共享知识

Coordinator 模式有一个独特的设计——Scratchpad 目录。这是一个所有 Worker 都可以读写的共享目录，不需要权限提示：

if (scratchpadDir && isScratchpadGateEnabled()) {
  content += `\nScratchpad directory: ${scratchpadDir}\n`
  content += `Workers can read and write here without permission prompts.`
  content += ` Use this for durable cross-worker knowledge`
  content += ` — structure files however fits the work.`
}

这解决了一个实际问题：Worker A 发现了一个关键信息，Worker B 需要知道，但它们之间没有直接通信通道。Scratchpad 就是它们的"共享白板"。

不过要注意，Scratchpad 本身也是 feature gate 控制的，不是所有 coordinator session 都一定会出现。

Task Notification：异步回调

Worker 完成后，结果以 <task-notification> XML 格式注入协调者的对话：

<task-notification>
  <task-id>agent-a1b</task-id>
  <status>completed</status>
  <summary>Agent "Investigate auth bug" completed</summary>
  <result>Found null pointer in src/auth/validate.ts:42...</result>
  <usage>
    <total_tokens>15000</total_tokens>
    <tool_uses>8</tool_uses>
    <duration_ms>12500</duration_ms>
  </usage>
</task-notification>

注意：这些 notification 以 user-role message 的形式到达，但不是用户消息。Prompt 里专门提醒协调者：

"They look like user messages but are not. Distinguish them by the <task-notification> opening tag."

进度摘要：30 秒一次的后台 Fork

当 Worker 在后台运行时，用户怎么知道它在干什么？Claude Code 的方案是 Agent Summary——每 30 秒 fork 一次 Worker 的对话，让 LLM 用 3-5 个词描述当前动作：

const SUMMARY_INTERVAL_MS = 30_000

function buildSummaryPrompt(previousSummary: string | null): string {
  return `Describe your most recent action in 3-5 words using 
  present tense (-ing). Name the file or function, not the branch.
  Do not use tools.`
}

这里的关键技巧是：摘要 fork 共享 Worker 的 prompt cache。工具定义保留在请求中（为了 cache key 一致），但通过 canUseTool 回调全部 deny——模型看得到工具但不能用，因为它只需要输出一句话。

五、Agent Swarms：带协议的团队协作

核心思路

Swarm 是最"团队化"的模式。pane backend 下，每个队友都可以是一个独立的 Claude Code 进程，跑在自己的终端面板里；in-process 模式下，它们又会退回同一个 Node.js 进程。

所以它和 Coordinator 的本质区别，不是“是不是独立进程”，而是团队协议被显式建模了：有 TeamFile、有 mailbox、可以 SendMessage，队友之间能直接发消息，而不是一切都必须经由 coordinator。

团队生命周期

sequenceDiagram
    participant L as Team Lead
    participant T as TeamFile (config.json)
    participant M1 as Teammate 1
    participant M2 as Teammate 2

    L->>T: TeamCreate({team_name: "auth-fix"})
    Note over T: 写入 team file，注册 lead

    L->>M1: AgentTool({name: "researcher", prompt: "..."})
    Note over M1: pane backend: 独立进程/面板<br/>in-process: 同进程
    M1->>T: 写入 members[]

    L->>M2: AgentTool({name: "implementer", prompt: "..."})
    M2->>T: 写入 members[]

    M1->>L: SendMessage({to: "team-lead", message: "..."})
    M1->>M2: SendMessage({to: "implementer", message: "..."})
    M2->>L: SendMessage({to: "team-lead", message: "..."})

    L->>M1: SendMessage({type: "shutdown_request"})
    M1->>L: SendMessage({type: "shutdown_response", approve: true})
    L->>T: TeamDelete()
    Note over T: 清除 team 目录和 worktree

通信能去中心化，控制面没有

Swarm 最容易被误读成“完全去中心化”。源码里其实不是这样。

更准确的描述是：消息面接近点对点，控制面仍然以 lead 为中心。 队友之间可以直接 SendMessage，但团队创建、团队清理、成员发现、权限聚合、很多 UI 呈现仍然围着 lead 打转。这也是为什么它看起来比 Coordinator 更自由，但又没有真的变成一个“无主集群”。

三种 Backend

Swarm 的队友执行有三种 backend：tmux、iTerm2、in-process。前两种是 pane 模式（各队友有独立终端面板），第三种跑在同一个 Node.js 进程里。

面板后端的检测优先级（detectAndGetBackend）：

// 1. 在 tmux 里 → 直接用 tmux（即使在 iTerm2 中也优先）
// 2. 在 iTerm2 + 有 it2 CLI → 用 iTerm2 原生分屏
//    （如果用户之前选择了 preferTmux，跳过 iTerm2）
// 3. 在 iTerm2 + 无 it2 → 返回"需要安装"信息，继续往下
// 4. tmux 可用 → 创建外部 tmux session
// 5. 都没有 → 抛错，提示安装 tmux

in-process 模式是独立判定路径，由 isInProcessEnabled() 决定：

teammateMode 设置为 'in-process' → 始终 in-process
teammateMode 设置为 'tmux' → 始终用 pane backend
teammateMode 为 'auto'（默认） → 非交互 session（SDK/-p 模式）强制 in-process；在 tmux 或 iTerm2 里则用 pane；否则 in-process
如果之前某次 spawn 因为没有可用 pane backend 而退回了 in-process，后续也保持 in-process

in-process 队友不创建独立进程。优点是零进程开销、不依赖 tmux；缺点是没有独立终端面板可看。

另外，Swarm 在外部构建里也不是默认常开：需要 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 或 --agent-teams，再叠加 GrowthBook killswitch（tengu_amber_flint）；内部 ant build 才是默认开启。

TeamFile：团队的配置中心

团队状态存储在 TeamFile（JSON），包含：

type TeamFile = {
  name: string
  leadAgentId: string
  leadSessionId?: string
  teamAllowedPaths?: TeamAllowedPath[]  // 所有队友可编辑的路径
  members: Array<{
    agentId: string
    name: string
    model?: string
    color?: string
    planModeRequired?: boolean
    tmuxPaneId: string
    cwd: string
    worktreePath?: string
    subscriptions: string[]
    backendType?: BackendType
    isActive?: boolean
    mode?: PermissionMode
  }>
}

teamAllowedPaths 明显是在为“团队共享允许路径”做准备：队友启动时会把这里已有的规则同步到自己的 permission context。

但这里要收一下表述强度。我在源码里明确看到的是“读取和应用链路”已经存在；至于“某个队友获批后，马上稳定写回 team file，再让全队复用”的完整闭环，没有这篇稿子里写得那么直接。更稳妥的说法是：这是一个已经埋进数据结构、但打磨程度还不算完全落地的方向。

权限冒泡

Swarm 里的权限通过 Leader Permission Bridge 冒泡。当 in-process 队友需要权限确认时，它不是弹自己的对话框——它使用 leader 注册的 setToolUseConfirmQueue：

// 注册到模块级 bridge
export function registerLeaderToolUseConfirmQueue(
  setter: SetToolUseConfirmQueueFn
): void { registeredSetter = setter }

// 队友需要权限时，通过 bridge 获取 leader 的 queue
export function getLeaderToolUseConfirmQueue(): SetToolUseConfirmQueueFn | null {
  return registeredSetter
}

但这条 bridge 只覆盖 in-process 队友。如果拿不到 leader 的 queue，代码会退回 permissionSync.ts 里的 mailbox / 文件同步方案：worker 先写 pending request，leader 轮询并回复，worker 再继续执行。

换句话说，Swarm 的权限转发不是一条单线，而是 leader UI bridge + mailbox sync 双路径。最终目标仍然是尽量把确认集中到 leader 这一侧。

Teammate 的 Prompt 增补

每个队友的系统 prompt 会额外追加一段，告诉它通信规则：

"You are running as an agent in a team. To communicate with anyone on your team: use the SendMessage tool. Just writing a response in text is not visible to others on your team."

这个设计向模型明确了一个关键约束：你的文本输出别人看不到，必须通过工具通信。

六、Fork Subagent：轻量级分身

核心思路

Fork 是三种模式里最轻、也最讲究 cache 工程的一种。它的核心思想是：子 Agent 不重新搭 prompt，而是直接继承父 Agent 的完整对话上下文和系统 prompt。

使用方式极其简单——当 isForkSubagentEnabled() 开启时，调用 AgentTool 不指定 subagent_type，就自动走 fork 路径：

const effectiveType = subagent_type 
  ?? (isForkSubagentEnabled() ? undefined : GENERAL_PURPOSE_AGENT.agentType)
const isForkPath = effectiveType === undefined

值得注意的是，fork gate 还顺手改了另一个行为：一旦这条实验路径开启，AgentTool 的 spawn 会统一偏向后台异步执行，用同一套 <task-notification> 交互模型回到主线程。也就是说，fork 不是单独长出的一条支线，它还影响了整个 agent spawn 的交互形态。

Prompt Cache 共享：字节精确一致

Fork 的最大卖点是 prompt cache 前缀几乎可以完整复用。为什么？看数据结构：

export const FORK_AGENT = {
  tools: ['*'],           // 和父 Agent 完全一样的工具集
  model: 'inherit',       // 继承父 Agent 的模型
  permissionMode: 'bubble', // 权限冒泡到父终端
  // getSystemPrompt 是空函数——fork 路径不走这里，
  // 直接用 toolUseContext.renderedSystemPrompt
}

关键代码在 buildForkedMessages()。它的设计目标是让所有 fork 子进程产生字节一致的 API 请求前缀：

保留父 Agent 的完整 assistant message（所有 tool_use blocks）
为每个 tool_use 生成一个用相同占位符的 tool_result
最后追加一个 per-child 的 directive text block

const FORK_PLACEHOLDER_RESULT = 'Fork started — processing in background'

// 结果：[...history, assistant(all_tool_uses), user(placeholder_results..., directive)]
// 只有最后一个 text block 不同——最大化 cache 命中

而且字节一致不只靠消息前缀。runAgent() 在 useExactTools 路径下，还会继承父 Agent 的 availableTools、renderedSystemPrompt、thinkingConfig 乃至 isNonInteractiveSession，尽量避免 cache key 因为工具定义、预算或 prompt 重新渲染而失效。

这意味着同时 fork 出 5 个子进程时，它们会尽量共享同一个 prompt cache：系统 prompt、工具定义、历史消息大面积命中，只有最后的 directive 是新的。相比重新构造一个独立子 Agent，这会明显降低输入侧的成本和延迟，但没必要把它夸成“几乎零输入成本”。

子进程的严格约束

Fork 子进程有一组硬编码的行为约束（boilerplate 注入），共 10 条：

1.  系统 prompt 说"default to forking"是给父进程的，你就是 fork，不要再 spawn 子 Agent
2.  不要对话、不要提问、不要建议下一步
3.  不要加元评论（meta-commentary）
4.  直接用工具执行：Bash, Read, Write 等
5.  如果改了文件就先 commit，报告里带 commit hash
6.  工具调用之间不要输出文本，最后统一报告一次
7.  严格限制在 directive 范围内，scope 之外的东西最多提一句
8.  报告不超过 500 words
9.  回复必须以 "Scope:" 开头，不要前言、不要 thinking-out-loud
10. 用固定格式：Scope → Result → Key files → Files changed → Issues

反递归保护

Fork 子进程保留了 AgentTool（为了工具定义字节一致不破坏 cache），但有双重防护禁止递归 fork：

// 防护 1：检查 querySource（compaction-resistant）
if (toolUseContext.options.querySource === `agent:builtin:fork`) return error

// 防护 2：扫描消息历史中的 boilerplate tag（兜底）
if (isInForkChild(toolUseContext.messages)) return error

为什么需要两层？因为 autocompact 可能重写消息历史，删掉 boilerplate tag。querySource 是在 spawn 时设置到 context.options 上的，不会被 compact 修改——这是主防线。消息扫描是兜底。

Worktree 隔离

Fork 还支持 git worktree 隔离——子进程在一个独立的 worktree 中工作，修改不会影响父进程的文件：

if (isForkPath && worktreeInfo) {
  promptMessages.push(createUserMessage({
    content: buildWorktreeNotice(getCwd(), worktreeInfo.worktreePath)
  }))
}

Notice 告诉子进程：你继承的上下文路径是父目录的，要翻译成 worktree 路径；可能过时的文件要重新读。

七、为什么外部构建禁了 Agent 套 Agent

一个容易忽略的细节是反嵌套保护。所有子 Agent 在过滤工具列表时，会移除 ALL_AGENT_DISALLOWED_TOOLS 中的工具：

export const ALL_AGENT_DISALLOWED_TOOLS = new Set([
  TASK_OUTPUT_TOOL_NAME,
  EXIT_PLAN_MODE_V2_TOOL_NAME,
  ENTER_PLAN_MODE_TOOL_NAME,
  // 外部构建禁止 Agent 嵌套；内部 (ant) 放开
  ...(process.env.USER_TYPE === 'ant' ? [] : [AGENT_TOOL_NAME]),
  ASK_USER_QUESTION_TOOL_NAME,
  TASK_STOP_TOOL_NAME,
  // 阻止子 Agent 里递归执行 Workflow
  ...(feature('WORKFLOW_SCRIPTS') ? [WORKFLOW_TOOL_NAME] : []),
])

关键那行：只有 Anthropic 内部构建（USER_TYPE === 'ant'）才允许子 Agent 使用 AgentTool（即 Agent 调 Agent）。外部构建直接从工具列表里移除，模型甚至看不到这个工具的存在。外部用户如果需要多 Agent 协作，应该走 Coordinator、Swarm 或 Fork 这些显式结构，而不是放开任意递归。

但 Fork 子进程是个例外——它保留 AgentTool 但通过运行时检查（而非工具列表过滤）阻止递归。这是为了让工具定义字节一致、不破坏 prompt cache。

八、三种模式的适用场景对比

场景	推荐模式	原因
大型功能开发（调研→设计→实现→测试）	Coordinator	需要全局视野和阶段性综合
长期运行的并行团队（多个独立子系统）	Swarm	需要独立终端、持久连接、队友互通
快速并行调研/代码搜索	Fork	轻量、共享 cache、不改变交互模式
需要 git worktree 隔离的并行实现	Fork + worktree	各改各的分支，不冲突
SDK/API 集成的批量任务	Coordinator	Fork 在非交互 session 下被 gate 禁用；Coordinator 提供结构化输入输出，适合程序化控制
用户想实时看每个 Agent 在干什么	Swarm (tmux)	每个队友有独立面板

一个具体例子：修 auth 空指针 bug 时怎么选

如果需求是“先找问题，再给 patch，最后独立验证”，Coordinator 最顺手。两个 research worker 并行摸底，coordinator 读完结果后再派 implementer / verifier。
如果你想同时开“后端修复”“前端回归”“CI 盯盘”三个长期角色，而且希望它们能互相 ping，Swarm 更像一个真团队。
如果你只是想把“在 auth 目录里找所有 null check 漏洞”拆成 3 个角度并行扫一遍，Fork 成本最低，因为不需要为每个子任务重建 prompt。

需要注意的是，Coordinator 和 Fork 互斥——开启 Coordinator 模式会自动禁用 Fork。而且 Fork 本身也受编译时 feature flag 控制：

export function isForkSubagentEnabled(): boolean {
  if (feature('FORK_SUBAGENT')) {       // 编译时 gate，外部构建不一定开
    if (isCoordinatorMode()) return false  // 互斥
    if (getIsNonInteractiveSession()) return false  // SDK/-p 模式下禁用
    return true
  }
  return false
}

注意最外层的 feature('FORK_SUBAGENT') 是 Bun 编译时 flag（bun:bundle），不是运行时检查。也就是说 Fork 不是"默认开启"——它需要构建时打开这个 flag 才存在。同理，isCoordinatorMode() 也受 feature('COORDINATOR_MODE') 保护。这种编译时 gate + 运行时 env var 的双层控制是 Claude Code 管理实验性功能的通用模式。

九、局限与坑

1. Coordinator 的综合瓶颈

所有 Worker 的结果都回到协调者——如果 5 个 Worker 同时完成，协调者需要在一个上下文窗口里消化所有结果。当结果量很大时，协调者自己会触发 compact，可能丢失 Worker 的部分输出。

2. Swarm 的环境依赖

如果你要的是完整的 pane 体验，Swarm 需要 tmux 或 iTerm2。虽然有 in-process fallback，但这个 fallback 会丢失最核心的体验——独立的终端面板。而且 in-process 模式下队友不能 spawn background agents，能力受限。

3. Fork 的"无通信"限制

Fork 子进程之间没有任何通信机制。它们各干各的，结果只能回传给父进程。如果两个 fork 子进程修改了同一个文件（且没开 worktree 隔离），会产生冲突——而且没有检测机制。

4. 成本考量

三种模式的 token 成本差异很大：

Fork 最便宜：输入前缀大面积命中 cache，但不是“没有输入成本”
Coordinator 中等：Worker 各有独立 prompt，但 Worker 的工具定义相对精简
Swarm 通常最贵：每个队友都更像一份完整会话，系统 prompt 和工具定义复用最少

5. 摘要质量

Agent Summary 的 30 秒 fork 是个巧妙的设计，但摘要质量完全取决于模型在有限 context 下的理解能力。当 Worker 在做复杂的多文件操作时，"3-5 个词的描述"可能不够准确。

十、最后总结

Claude Code 的三种多 Agent 模式回答了一个架构问题：多 Agent 系统应该怎么分层？

答案是根据上下文共享策略和协调方式分三层：

Fork：零协调开销，父进程分裂，子进程独立执行后汇报。适合"同一件事用不同角度看"
Coordinator：中心化调度，有完整的 Research→Synthesis→Implementation→Verification 流水线，Worker 只执行不决策。适合"需要全局视野的多步骤工程任务"
Swarm：持久化团队协议，lead 管生命周期、队友互发消息、有独立终端面板。适合"真正有人在并行协作"的场景

三层之间最核心的技术差异不在通信方式，而在上下文共享策略：

Fork 完全共享（字节一致的 prompt cache）
Coordinator 完全隔离（Worker 各有独立 prompt）
Swarm 基本隔离（队友是独立 teammate session；pane 模式下通常还是独立进程）

这个设计暗示了一个判断标准：如果子任务需要理解父对话的完整上下文，用 Fork；如果子任务可以用一句话描述清楚，用 Coordinator/Swarm。 换言之，上下文传递的成本决定了你应该选择哪种模式。