Claude Code 里的多代理机制，本质上是一种上下文治理手段：主会话负责判断和落地，容易把上下文弄脏的支线工作拆给独立 worker，并行提速只是任务可拆分之后的副产品。本文梳理 Subagent、Subtask、Fork、Agent Teams 四种机制的差异、任务委派方式与协调成本。

为什么需要多个 Agent

单会话处理跨模块任务时，麻烦集中在两点。一是过程信息膨胀：排查一个慢查询，搜索命中的无关文件、旧日志、被推翻的方案全留在上下文里，等真正动手改代码时，模型得从这堆过期材料里捞重点。二是任务惯性：刚分析完数据库问题，转头去审前端组件，上一轮的思考方式很容易被带过来。

多代理要解决的就是这个问题——保护主会话。主会话保留判断、计划和最终决策，搜索、验证、审查这些过程交给独立窗口执行，只回收结论。

四种机制按解决的问题区分：

问题 机制 说明
支线搜索污染主会话 Subagent 子代理独立工作，主会话只拿结果
想复用当前上下文做支线 /subtask 会话内派生，继承父会话上下文
复制对话后独立继续 /fork 创建可单独恢复的后台 Session
多角色分工协作 Agent Teams 独立实例 + 共享任务列表 + 消息

选择时先问一句：这些 worker 之间要不要互相沟通？查完回报就够的用 Subagent；需要互相发消息、认领任务的才上 Agent Teams。

Subagent：主会话的轻量委派

Subagent 是主会话临时派出去的 worker：有自己的上下文窗口和工具范围，任务结束后把整理过的结论回传，不把搜索过程一股脑倒回来。

上下文隔离的实现

普通 Subagent 不继承父会话的消息历史——这正是隔离的意义所在；但它仍会加载工具权限、CLAUDE.md、记忆和 Git 状态等运行上下文。它不是主会话里的一次函数调用，而是复用了完整的 Agent 运行时：有自己的工具上下文、消息流和执行记录。

/subtask 走另一条路：在当前会话内派生，继承父会话已形成的对话上下文。适合的场景是主会话刚读完一个模块、整理好计划，想顺势分几个方向试探——每个分支都拿着现成的上下文，不用重复读一遍项目。代价也明显：父会话越干净，复制越有价值；主会话已经塞满旧猜测和失败方案时再派生，等于把混乱复制给每个分支。

/fork 则是复制整段对话成为独立的后台 Session，可单独查看、恢复和继续，适合需要长期独立推进的支线。

适用场景

适合交给 Subagent 的任务有个共同点：过程不重要，结论重要。

  • 只读审查某个模块，回传问题列表；
  • 搜索某类错误日志，主会话只收结论；
  • 汇总外部库用法，不带回搜索过程；
  • 对刚完成的改动做独立验证，失败了重新派一次。

反过来，正在修改的核心文件别拆给子代理并行写，主会话和子代理同时动手大概率不是提速而是制造冲突。习惯上让子代理多做只读和验证，主线修改留在主会话。多个代理都要写代码时，用 Git Worktree 把工作区隔开，一个分支只承载一个任务，最后由人或主会话合并验收。

任务委派协议

委派的质量取决于输入输出的设计。Subagent 的定义是 Markdown 加 YAML frontmatter，其中 name 和 description 必填——description 尤其关键，框架靠它判断什么时候自动委派，写得太泛会导致误触发。

委派时的调用参数里，prompt 是交给子代理的具体任务，description 是给主会话看的简述，subagent_type 指定用哪类代理（缺省为通用型），还可以指定模型和是否后台运行。关键点：任务必须一次讲清。子代理窗口是干净的，它看不到你之前和主会话的讨论，背景、约束、期望的输出格式都要写进 prompt。

自定义 Subagent 放在 ~/.claude/agents/（用户级）或 .claude/agents/（项目级，可随仓库共享）。判断要不要沉淀一个自定义代理的标准是：同一类 worker 反复出现，且每次都要给同一套指令——比如只读代码审查、数据库安全检查这类角色和输出格式都稳定的任务。偶尔查一次文件，用内置代理或临时委派就够了。

Agent Teams：独立实例的协作网络

Agent Teams 是更重的一层：一个 session 当 lead 负责协调，若干 teammate 各自独立工作，每个 teammate 都有自己的上下文窗口，并且能互相通信。

它和 Subagent 的本质区别在协作机制上。Subagent 是「干完回来汇报」的一次性委派；Agent Teams 维护两样共享设施：

  • 共享任务列表：任务有 pending、in progress、completed 状态和依赖关系，依赖未完成时后续任务不能被认领；并发认领用文件锁防冲突。
  • mailbox：teammate 之间按名字发消息、请求信息、同步状态；空闲或失败时自动通知 lead，无需轮询。

teammate 不继承 lead 的聊天历史，只加载项目级的 CLAUDE.md、MCP servers、Skills 和 lead 发来的 spawn prompt——所以 spawn prompt 必须把关键路径、已知限制、期望产出写清楚，否则 teammate 拿到的是一个「干净到不知道讨论过什么」的窗口。teammate 可以复用已有 Subagent 定义中的 tools 和 model，定义正文会追加到其 system prompt，但 skills、mcpServers 字段不沿这条路径生效。

权限上，需要用户确认的请求会回流到 lead 统一处理，用户不用在多个窗口间分别盯确认弹窗。注意 Agent Teams 目前仍是实验特性，需要显式开启。

协调成本：多代理不是免费的

每多一个活跃 teammate，就多一份独立上下文的 Token 消耗和维护成本——开三个 teammate 相当于同时维护三个窗口，而不是把一个窗口拆成三份。控制成本的几条习惯：

  • teammate 的模型显式指定，别假设它自动跟随 lead；
  • 从 3 个左右聚焦的 teammate 起步，任务粒度控制在「一个函数、一个测试文件、一次审查」这类自包含交付物；
  • 新手先从研究、审查、排查这类不写代码的任务试起；
  • 并行写代码时按文件域划分，避免两个 teammate 改同一文件。

还有些隐性成本容易被忽略：子代理的结论需要主会话验证后再合并，矛盾结论没解决就合并会放大错误；任务强依赖、需要反复等待对方结果时，拆开反而比串行更慢；后台代理开多了，主会话没被卡住，人却开始管理一堆任务。

怎么选

  1. 任务清楚、改动范围小：单 Agent，任何拆分都是多余的调度开销。
  2. 支线探索、审查、日志分析：普通 Subagent，主会话只收结论和证据。
  3. 父会话上下文刚整理好、值得复用：/subtask；需要独立长期推进的支线用 /fork。
  4. 任务跨后端、前端、测试且角色间需要互通消息：Agent Teams。
  5. 任务边界还没拆清时，别先加 Agent——先用单会话跑通串行流水线（方案 → 实现 → 验证 → 审查），稳定后再把可独立的环节拆出去。

小结

  1. 多代理的核心价值是上下文隔离和角色分离：主会话负责判断与落地，过程性的脏活拆给独立窗口。
  2. Subagent 不继承历史、只回传结论，是最常用也最不容易用过头的机制；/subtask 与 /fork 复制上下文，只在父会话干净时才有价值。
  3. Agent Teams 用共享任务列表和 mailbox 支撑多角色协作，但需要实验开关，且每个 teammate 都是独立的 Token 开销。
  4. 协调成本真实存在：委派 prompt 要一次写清、子代理产出要验证、写 scope 要互斥；任务可分解性是决定是否拆分的先决条件。