搞懂 Claude Code 多 Agent 协作：Subagent、后台 Session 与 Agent Team 深度解析

Claude Code 的官方文档中频繁出现“Agent”一词，但这很容易引起混淆：它们往往指代的并非同一种机制。

当你提到“我开启了三个 Agent”时——这可能意味着 Agent View 中运行着三个后台 Session，也可能是在主对话中派生出的三个 Subagent，或者是实验性功能 Agent Team 中的三名 Teammate。如果不能准确区分这些概念，在实际使用和问题排查时会带来极大的困扰。

本文旨在彻底拆解这些核心概念，并在此基础上讲清任务恢复（Resume）、消息通信机制以及工作树（Worktree）隔离技术。

相关的官方文档入口：

• Subagents
• Agent view / background agents
• Agent teams
• Worktrees

[!NOTE] 软件版本非常重要。Agent View 机制自 v2.1.139 起引入；Subagent 默认后台运行机制始于 v2.1.198；而 Agent Team 的相关行为在 v2.1.178+ 发生过变更。在阅读本文前，建议先执行 claude --version 确认当前版本。

核心概念对照表

一句话总结：

• Subagent：主对话的“外包团队”。适合处理查看日志、代码搜索、执行测试等高信噪比任务，防止冗长的输出污染主会话上下文。
• Background Session：独立运行的“克隆分身”。相当于你的第二、第三个 Claude 实例，即便关闭终端也能在后台持续推进工作。
• Agent Team：能够相互沟通、自主认领任务的 Claude“项目组”。当前处于实验性阶段，开销较高且存在一定的局限性。

需要特别强调的是：Worktree 并非第四种 Agent。它仅仅是一个文件系统级别的隔离层，旨在为并行修改代码的多个 Agent 提供独立的工作目录，从而避免文件被互相覆盖。

Subagent：主 Session 内的执行者

Subagent 运行在当前 Session 的内部。它们拥有专属的上下文窗口和 System Prompt，你可以为其限定可用的工具（Tools）和模型（Model）。完成任务后，它们会将执行摘要返回给主 Claude。再次强调，Subagent 之间是无法进行横向通信的。

Claude Code 内置了几类标准 Subagent：

• Explore：专注于代码的只读搜索，避免搜索结果塞满主对话。
• Plan：在 Plan Mode 下负责前期的调研和规划工作。
• General-purpose：适用于需要同时进行大量阅读和代码修改的复杂任务。

如果需要自定义 Subagent，只需编写带有 Frontmatter 的 Markdown 文件，并将其放置在以下目录：

• 项目级别：.claude/agents/
• 全局级别：~/.claude/agents/

---
name: code-reviewer
description: Reviews code for quality and best practices. Use after code changes.
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. Be specific. Show current code and a better version.

调用方式非常灵活，你可以通过自然语言下达指令：

Use the code-reviewer subagent on the auth changes

或者在对话中直接 @ 点名。如果希望整个 Session 按照特定的 Agent 角色运行，可以执行：

claude --agent code-reviewer

前台与后台运行机制

• 前台运行：主对话会被阻塞，等待 Subagent 返回结果；任何权限审批弹窗都会直接呈现给你。
• 后台运行：主对话可以继续进行其他交互；当后台任务需要权限审批时，相关请求会被转发回主 Session（要求 v2.1.186+）。

自 v2.1.198 起，Subagent 默认倾向于在后台运行。但如果 Claude 需要立刻使用 Subagent 的结果，它也会选择前台执行。你可以通过明确要求“在后台运行”，或者使用快捷键 Ctrl+B 将当前执行的任务打入后台。

彻底关闭后台任务特性的环境变量为：CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1。

[!WARNING] 请注意区分：Background Subagent ≠ Background Session。前者只是主 Session 内部的一项后台任务；而后者是 Agent View 列表中一整行独立的会话进程。Subagent 永远不会作为独立的一行出现在 claude agents 的列表中。

Resume 机制

默认情况下，每次调用 Subagent 都会启动一个拥有干净上下文的全新实例。如果你希望它接着之前的工作继续，可以要求 Claude Resume（恢复） 那个特定的 Subagent——这会保留完整的历史对话、工具调用记录以及推理轨迹，从之前的断点继续执行。

当 API 发生异常导致 Subagent 执行失败时（v2.1.199+），系统会如实上报失败详情，而不再将错误文本伪装成“调研结论”。在限流解除后，你可以选择重试或 Resume 该任务。

[!TIP] 嵌套 Subagent 存在深度限制（最多允许嵌套五层）；一旦达到层级上限，系统将不再提供 Agent 调用工具。执行 Resume 操作并不会改变该 Subagent 被派生（Spawn）时的嵌套深度。

适用场景建议

• 适用场景：高噪音操作（如大量打印测试输出、全库级代码搜索）、固定工种的重复性任务、需要严格限制为“只读”权限的场景。
• 不适用场景：需要你频繁干预和微调（Refining）的代码实现过程；多阶段任务中需要共享大量上下文的情况（此时直接使用主对话更佳）。如果任务需要多个角色之间相互辩论或认领，请使用 Agent Team，而不要硬性嵌套 Subagent。

Background Session：真正“挂载运行”的 Claude

查看当前所有独立会话：

claude agents

这会调出 Agent View 界面：它展示了一张包含所有后台 Session 的表格，并按 Working（运行中）、Needs input（需交互）、Completed（已完成）进行了分组。当你关闭这个 TUI（终端用户界面）时，这些 Session 仍在持续运行——它们由独立的 Supervisor 进程管理，不再与你的终端生命周期绑定。

如何启动一个新的 Background Session

方式一：通过 Agent View 界面
在界面底部输入任务指令并按下 Enter 键。注意：这里输入的每一条 Prompt 都会启动一个全新的 Session，而不是在旧的 Session 中追加对话。

方式二：在已有的交互 Session 中
使用 Slash 命令：

/bg
/background run the test suite and fix failures

或者在空 Prompt 的情况下直接按下 ← 左方向键（该快捷键可通过 leftArrowOpensAgents 配置关闭）。

方式三：通过 Shell 命令

claude --bg "investigate the flaky SettingsChangeDetector test"
claude --agent code-reviewer --bg "address review comments on PR 1234"
claude --bg --name "flaky-test-fix" "..."

系统会打印出短 ID 及对应的管理命令：

backgrounded · 7c5dcf5d · flaky-test-fix
  claude agents
  claude attach 7c5dcf5d
  claude logs 7c5dcf5d
  claude stop 7c5dcf5d

如果你只想在后台纯执行 Shell 命令而不调用大模型：

claude --bg --exec 'pytest -x'
# 或者在 Agent View 底部输入：! pytest -x

消息管理：Peek 与 Attach

在 Shell 环境下，你也可以使用 claude attach <id> 和 claude logs <id> 进行管理。

Detach 操作不会停止 Session 的运行。 如需停止会话：可以在 Attach 后执行 /stop，或者在列表中按 Ctrl+X，抑或是使用命令 claude stop <id>。

[!CAUTION] 双击 Ctrl+X 删除会话时，系统会一并清理 Claude 为其创建的隔离 Worktree（包含所有未提交的代码修改）。如果需要保留这些改动，请务必先执行 Commit 与 Push。不过，你自己手动通过 git worktree add 创建的目录不会被意外删除。

Session 恢复与重启

• 进程异常但会话状态存留：列表会显示 ∙ 图标；通过 Peek 或 Attach 即可从断点处继续。
• 机器休眠：唤醒后进程通常可恢复，Supervisor 会尝试重连（但不建议将其视为无限可靠的保险）。
• 机器重启：运行中的 Session 会被中止；你可以使用 claude respawn <id> 或 claude respawn --all 重新拉起这些会话，对话历史依然保留。
• 已被删除的列表项：通常本地 Transcript 依然存在，尝试执行 claude --resume 仍有机会找回。

再次强调：Background Session 不是针对 Subagent 的 Resume。它具备一段完整的会话生命周期：Background -> Attach -> Detach -> Stop -> Respawn。

%% caption: Attach 进入会话，Detach 返回后台，Stop 结束会话；机器重启后可用 Respawn 恢复
flowchart LR
  B["Background<br/>后台运行"] -->|Attach| A["Attached<br/>进入会话"]
  A -->|Detach| B
  B -->|Stop| S["Stopped<br/>会话结束"]
  A -->|Stop| S
  B -. 机器重启 .-> R["待恢复"]
  R -. Respawn .-> B

自动 Worktree 隔离机制

后台 Session 默认会在你的当前工作目录启动；但在执行写操作之前，它会自动迁移至 .claude/worktrees/ 下的隔离工作树中，从而避免多个后台任务发生文件冲突。

在某些情况下（例如：已经在被链接的 Worktree 中、当前目录不是 Git 仓库、或者写入路径在仓库范围之外），自动隔离会被跳过。 如果需要强制关闭自动隔离，可以在配置文件中设置：

{
  "worktree": {
    "bgIsolation": "none"
  }
}

自 v2.1.198 起：成功实施文件隔离的后台 Session，已经具备了自行 Commit、推送专属分支并开启 Draft PR 的能力。它们不会将代码直接推送到 main/master 分支，不会进行 Force-push，也不会主动合并代码。完成开流后，Agent 列表中会出现形如 #1234 的 PR 标记。

如果在后台 Session 中再次派生（Spawn）Subagent，它们默认会继承该 Session 的当前工作目录（即已经被隔离的 Worktree）。若需要为该 Subagent 再叠加一层隔离，需显式声明 isolation: worktree。

成本预估与配额

每一个后台 Session 都会独立消耗你的订阅额度（Quota）或 API 限制（Rate Limit）。在 Agent View 中开启五个任务，等同于并行启动了五个独立的 Claude 模型，请自行评估钱包余额与请求频次。

Agent Team：具备沟通能力的项目团队

Agent Team 是目前默认关闭的实验性特性。启用方法如下：

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

在团队模式下，主 Session 充当 Lead。Teammate 是各自拥有独立上下文的完整 Claude 实例，它们通过共享的任务列表（Task List）和消息邮箱（Mailbox）进行协调。你可以绕过 Lead，直接与某个特定的 Teammate 进行沟通。

这与 Subagent 的单向汇报架构存在本质区别：

%% caption: Subagent 架构：主对话与每个 Subagent 单线联系，Subagent 之间互不可见、无法横向通信
flowchart LR
  A["工人 A（Subagent）"] -. 摘要反馈 .-> M["主对话"]
  B["工人 B（Subagent）"] -. 摘要反馈 .-> M
  class M keep
  classDef keep fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#0a0a0a

%% caption: Agent Team 架构：Lead 会话通过共享任务板 / 信箱协调，Teammate 之间可以直接互相通信
flowchart TB
  L["Lead 会话<br/>共享任务板 / 信箱"]
  L --> TA["Teammate A"]
  L --> TB["Teammate B"]
  L --> TC["Teammate C"]
  TA <--> TB
  TB <--> TC
  class L keep
  classDef keep fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#0a0a0a

由于处于实验阶段，目前的开启方式相对简单粗暴，主要依赖自然语言描述：

Spawn three teammates to explore this CLI design:
one on UX, one on architecture, one as devil's advocate.

在交互面板中，通过上下方向键选择具体的 Teammate 并按下 Enter 即可进入其 Transcript 直接交流。显示模式可以通过 teammateMode 配置为 in-process（默认）或利用 tmux/iTerm2 进行终端分屏（Split Panes）。

消息投递与任务协调

• 邮箱（Mailbox）：Teammate 之间可以通过指名道姓的方式发送消息，系统会自动完成投递。
• 共享任务面板：任务状态分为 Pending / In Progress / Completed，支持定义依赖关系；任务既可以由 Lead 指派，也可以由 Teammate 自主认领（系统通过文件锁机制防止多人抢占同一任务）。
• 空闲与异常通知：当任务完成或发生 API 异常时（v2.1.198+），系统会自动向 Lead 发送通知。

需要注意的是，Teammate 并不会继承 Lead 的对话历史。CLAUDE.md、MCP 及内置 Skills 会按照常规 Session 的逻辑加载，但具体的任务细节必须在派生（Spawn）提示词中阐述清楚。

你可以将自定义的 Subagent 模板复用于 Teammate：在 Spawn 时指定 Agent Type 即可继承其 tools 与 model 设定，且配置文件中的 Body 会被追加到 System Prompt 中。但是，位于 Teammate 路径上的 skills 和 mcpServers Frontmatter 配置不会生效——它们只能从项目或全局级别加载。

Agent Team 的已知缺陷

官方文档已明确列出该特性的部分痛点：

• in-process 模式下的 Teammate 不支持通过 /resume 或 /rewind 恢复状态；如果 Lead 执行了 Resume，可能会导致向“幽灵状态”的 Teammate 发送消息。
• 任务面板的状态可能存在滞后，当依赖链卡住时，需要人工干预（Nudge）。
• 会话关停较慢：必须等待当前工具调用执行完毕。
• 每个 Session 仅支持组建一个 Team；不支持 Team 嵌套；Lead 角色不可移交。
• in-process 模式下 Teammate 派生的 Subagent 只能在前台运行，若请求后台执行将报错（因为后台任务的生命周期不能长于其父级 Lead 进程）。
• 消耗 Token 成本极高：每个 Teammate 都需维护一份完整的上下文历史，成本呈线性增长。

适用场景：多视角代码审查、针对竞争性假设方案的 Debug、边界划分极为清晰的并行模块开发。 不适用场景：必须严格按顺序执行的任务、多个角色频繁修改同一文件的场景、以及预算敏感的情况。

Worktree：防冲突的物理护栏

Git Worktree 能够在同一仓库下创建另一套独立的工作目录并检出分支。Claude 的文件修改隔离机制正是依赖于这项底层的 Git 功能，而不是指望大模型“自觉”不去修改无关文件。

手动管理与 CLI 命令

claude --worktree feature-auth
claude --worktree              # 自动随机命名
claude --worktree "#1234"      # 基于特定 PR 编号

隔离目录默认存放在 .claude/worktrees/<name>/，对应创建的分支名为 worktree-<name>。强烈建议在 .gitignore 中排除 .claude/worktrees/ 目录。

隔离区的基线代码默认同步至 origin/HEAD（干净的远程状态）。如果希望将当前本地 HEAD 的未推送状态一并带入隔离区，请修改配置：

{
  "worktree": {
    "baseRef": "head"
  }
}

像 .env 这样被 Git 忽略的敏感配置文件，默认是不会被拷贝进 Worktree 的。如果需要同步这些文件，可以在项目根目录创建一个 .worktreeinclude 文件并罗列路径：

.env
.env.local
config/secrets.json

Worktree 与后台机制的协同关系

如果在调用多个 Subagent 并行修改代码时未能设置 Isolation，这就等同于多个开发者在同一套目录下并发盲写——文件覆盖是物理必然，而非运气问题。

对于那些没有发生任何代码改动、也未产生新 Commit 的 Worktree，在退出时系统会自动清理；若有未提交的改动则会弹窗询问。由 Background / Subagent 自动创建且已经超过了 cleanupPeriodDays 设置天数的干净 Worktree，也会被定期清理机制扫除。而你手动通过 --worktree 创建的隔离区则安全无虞，不会被这轮清扫误删。

消息模型解析

需要区分三种截然不同的“消息通信”通道，避免产生认知混淆：

1. 你 ↔ 主 Claude / 你已 Attach 的 Session
   这是最常规、最直接的交互对话通道。

2. 你 → Background Session（处于未 Attach 状态）
   通过 Agent View 界面进行 Peek 回复，或者 Attach 进入后输入指令。如果 Session 没有出现在列表中，你是无法通过这种方式与之通信的——除非先执行 /bg 或 --bg 将其调入后台列表。

3. Agent Team 内部通道
   支持 Lead ↔ Teammate、Teammate ↔ Teammate 之间的通信。但所有权限审批请求仍然需要向上冒泡至 Lead 处理；Teammate 无权替你点击同意，更不能通过将受限操作转包给其他队友来绕过安全限制。

[!NOTE] Subagent 是不存在同级（Peer）通信机制的。它唯一的运行轨迹是：主 Agent 下发任务 → Subagent 执行逻辑 → 摘要结果返回给主 Agent。如果你希望“继续跟进某个 Subagent 的进度”，正确的做法是 Resume（恢复）该特定的 Subagent，而不是试图向其发送类似 Team 模式下的邮件指令。

场景选型决策树

%% caption: 小而连续的任务使用主对话；其他任务按独立执行、后台运行或成员协作选择
flowchart TD
  Q{"任务小且需要<br/>连续上下文？"}
  Q -->|是| A["主对话"]
  Q -->|否| N{"主要需求是什么？"}
  N -->|独立执行并汇报| B["Subagent"]
  N -->|长时间后台运行| C["Background Session"]
  N -->|成员之间协作| D["Agent Team"]
  class A,B,C,D keep
  classDef keep fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#0a0a0a

完全由主对话单线程推进
适用于小型修改、需要保持上下文连贯的连续讨论、对响应延迟极为敏感的场景。

使用 Subagent
适用于输出内容冗长（高噪音）、结果适合被提炼为摘要、执行固定工种或需要严格限制特定工具的情况。在进行代码库调研、分析复杂日志或执行“只读”代码 Review 时应优先考虑。

启动 Background Session
适用于处理数项相互完全独立的任务，且你不希望盯着屏幕等待执行过程：比如修复 Flaky Test、发起多个小型的 Refactor PR。此时可将 Agent View 作为你的任务监控仪表盘。

组建 Agent Team
适用于需要引入多方辩论、交叉验证或共享任务看板的复杂大型重构任务。使用前需评估较高的 Token 消耗及实验性特性的潜在风险。

适时挂载 Worktree
只要核心诉求是“并行写文件不产生冲突”，上述三个层级都可以挂载 Worktree 机制。Background Session 通常会自动处理；Subagent 需显式声明 isolation: worktree；而用户自身在多终端并行时则直接使用 --worktree 参数。

常见的操作反模式（Anti-patterns）：

• 部署一堆未配置 Isolation 的 Subagent 并发修改代码 → 导致灾难性的文件冲突。
• 动用庞大的 Agent Team 仅为了“跑一下单元测试” → 杀鸡用牛刀。
• 误以为后台运行的 Subagent 会显示在 claude agents 的列表中 → 它们并不会。
• 在未执行 Push 的情况下，直接从 Agent View 删除任务行 → 导致 Worktree 内未推送的代码随之蒸发。

实战演练：从 claude agents 到 Draft PR

纯粹的理论记忆并不够，让我们走一遍最短的闭环工作流：启动两件相互独立的后台任务，并行运行，最后各自（或者由你介入）生成对应的 PR 提交。

0. 准备工作

• 确认 Claude Code 版本 ≥ 2.1.139（提供 Agent View 支持）；若需自动 Commit/PR 功能，版本需 ≥ 2.1.198。
• 确保当前操作处于一个正规的 Git 仓库目录下（非 Git 仓库没有默认的 Worktree 隔离机制）。
• 权限审批模式可遵从你日常的习惯；后台分发的任务默认继承当前目录的 defaultMode，除非你清楚所有后果，否则不要轻易使用 bypassPermissions。

1. 唤出控制仪表盘

cd ~/projects/my-app
claude agents

底部是任务分发（Dispatch）的输入框，上方是空白的任务列表。按下 Esc 关闭该界面后，Session 并不会被停止——底层的 Supervisor 依然在默默守护它们。

2. 派发两条独立任务

在底部的输入框中分别输入以下两条指令并回车，列表将生成两行独立的 Session：

Fix the flaky SettingsChangeDetector test. Run the failing test, fix root cause, keep changes minimal.

Add a draft PR description outline for the auth middleware refactor: list files touched and open questions. Do not change production behavior.

注意：在 Agent View 中输入的每条 Prompt 都会生成一个新的 Session，而非向上一条对话追加内容。要跟进某一项的具体进展，请使用 Space 键进行 Peek，或使用 Enter 键进行 Attach。

当然，你也可以直接在终端命令行中将它们拉起：

claude --bg --name "flaky-test" "Fix the flaky SettingsChangeDetector test..."
claude --bg --name "auth-notes" "Add a draft PR outline for auth middleware..."

3. 监控任务进度与隔离状态

默认情况下，后台 Session 在实施代码修改前，会自动将上下文迁入 .claude/worktrees/ 目录中。这两项任务将分别写入各自独立的分支与隔离目录，不会破坏主 Checkout 的代码状态。

• 列表中呈现黄色提示 / Needs input：按下 Space 键调出 Peek 预览，回答 Agent 的提问或同意相关操作。
• 列表项中出现 #1234 标记：代表该 Session 已经成功挂载（或自行发起）了对应的 PR 请求。
• 若想沉浸式审视完整的交互记录：按下 Enter 进行 Attach 操作；审阅完毕后，在输入框为空时按下 ← 左方向键进行 Detach（脱离）。除非确实需要终止任务，否则切勿盲目输入 /stop。

在 v2.1.198+ 环境下且成功完成代码隔离的后台 Session，已经具备了自行 Commit、推送自身专属分支并开启 Draft PR 的自主权。但它们严格受限：不会向 main/master 推送代码，不会进行危险的 Force-push，也不会自动 Merge 合并。如果你在提示词中明确指示“不要开 PR”，它将严格遵从并跳过该环节。

4. 介入干预的两种姿势

轻量级介入：在 Peek 视图中随口留下一句“记得跑完测试再 commit”或“请使用 conventional commits 规范”。

重量级介入：直接 Attach 进去，像使用正常的 Claude Code 交互式对话那样操作——随时修改提示词、切换 /model，或是审阅 Diff 差异。操作完毕后 Detach 退出，让它在后台默默推进。

如果进程异常退出但会话记录还在（显示 ∙ 图标）：只需重新 Attach 或执行 claude respawn <id>，系统即可从中断处精准恢复，免除从零开始的困扰。

5. 工作流收口清理

再次警示：在执行删除操作前，未执行 Push 的改动都有永远丢失的风险。命令行指令 claude rm <id> 在处理带有未提交改动的 Worktree 时会更加谨慎保守（它将打印出具体路径，留给你手动清理的机会）。

6. 实战变体：其他原语的融合方式

在主对话推进过程中，想执行一次全量测试，且不想阻塞当前交互：

Use a subagent to run the full test suite and report only failures with stack traces.

这是一个典型的 Subagent 场景，它不会出现在 claude agents 的大盘列表中。在后台悄悄运转的是依附于主 Session 的内部任务，而不是一个崭新的 Background Session。

有两块代码需要并行修改，且仍需在同一个会话中统筹协调：

Spawn two subagents with isolation worktree:
one fixes the flaky test, one drafts the auth notes.
Return each worktree branch name when done.

遇到极其棘手的问题，需要三方视角的交叉辩论（预警：费用不菲）： 首先确保环境变量 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 已生效，然后输入：

Spawn three teammates to review PR #N: security, performance, tests.
Debate, then one synthesis for me.

实战工程建议：最优路径是先使用 Background Session 将各任务并行推进完毕 → 开启 PR 申请 → 若遇到分歧或难点，再祭出 Team 机制进行精细 Review。切忌一上来就让 Team 下场直接写代码，因为随之而来的惊人 Token 消耗与错综复杂的协调成本都会让你感到极不友好。

7. 结语与核心心智模型

1. claude agents 统一管理的是拥有完整生命周期的独立会话，绝非 Subagent 列表。
2. 并行修改代码的安全屏障主要是靠底层的 Worktree 隔离 提供的，绝不能寄希望于大模型“自带的谨慎自觉”。
3. 消息投递共有四条清晰的轨道：列表 Peek 预览、Attach 进入主对话、Team 内部私信沟通、以及针对 Subagent 的 Resume 恢复。
4. 交付验收的标准是检查真实的 PR 编号或 Git 分支提交记录，绝不能仅凭大模型一句“我已经完成了修改”就信以为真。

必备最小命令速查表

claude agents                 # 开启任务管理仪表盘
claude attach <id>            # 介入接管特定 Session
claude logs <id>              # 快速调阅最近的日志输出
claude stop <id>              # 强行终止任务执行
claude respawn <id>           # 对话记录保留，重新拉起已中断的进程
claude --worktree feature-x   # 显式开启一个全新的隔离终端会话

自定义 Subagent 文件依然放置于 .claude/agents/*.md 目录下。若需要使其默认在后台运行并开启代码隔离，请进行如下配置：

---
name: feature-dev
isolation: worktree
background: true
---

总结陈词

在纷繁复杂的 Claude Code Agent 叙事体系中，开发者最需要厘清的是生命周期的边界问题：

• Subagent 存活于主 Session 的单向委托关系中。
• Background Session 寄生于系统底层 Supervisor 进程树的庇护下。
• Agent Team 运作于一套基于 Lead、Mailbox 和 Task List 编织而成的复杂协作协议里。
• Worktree 则牢牢扎根在 Git 原生的工作目录文件系统层级。

Resume 恢复机制、通信消息通道、文件隔离屏障——每一层的技术原语都具有截然不同的语义。在启动任何一条大语言模型的命令前，请先扪心自问：“我当前需要的究竟是单向摘要回流、一个隔离并行的独立会话，还是多个执行单元相互交互沟通？”

只有准确识别了自身的需求并选择了匹配的技术原语，你才能驾驭这股力量。选错工具并导致灾难性结果时，别急着抱怨“大模型不够聪明”，那大概率是因为你把项目经理、独立外包团队和办公室隔音挡板错误地认作了系统操作界面上的同一个按钮。

延伸阅读指南

概念厘清与技术选型请以本文为准；若需深挖某一具体知识点，切忌试图在一篇文章中找到所有的“百科全书式”解答。

官方文档（核心事实源）

• Subagents — 深入了解 Frontmatter 规范、Resume 机制以及嵌套深度限制。
• Agent view — 掌握 Peek/Attach 操作、Supervisor 守护原理，以及后台自动执行 Worktree 隔离与发起 PR 的底层机制。
• Agent teams — 了解其启用条件、Mailbox 通信规范以及各类已知的系统局限。
• Worktrees — 学习 --worktree 参数用法、baseRef 指定、.worktreeinclude 白名单以及定期清理规则。

中文进阶参考（深度对比）

• Claude Code + Git Worktree + Agent Teams：多 Agent 并行 — 将三种并行方式并排比对，问题域与本文最为契合；在钻研 Worktree / Teams 的底层细节时推荐作为对照参考。
• Claude Code 多 Agent 协作：Subagents 和 Agent Teams 怎么选？ — 提供友好的“二选一”叙事逻辑，非常适合初学者建立“分身任务 vs. 组队打怪”的直觉认知（该文未深入探讨 Agent View）。
• Claude Code Agent View 上手体验 — 专精剖析 claude agents 仪表盘与后台 Session 的各类边缘 Case。

英文文献（聚焦 Team 与实战）

• Claude Subagents vs Agent Teams · Avi Chawla — 提供了极其干净、结构化的架构设计对比。
• Collaborating with agent teams · Heeki Park — 记录了在真实高强度使用场景中遇到的各种锋利问题与采坑指南。
• Claude Code Worktrees Guide 2026 — 专注于深挖 Worktree 在各种极端条件下的表现。

最后，给你的阅读建议：先通过本文建立起立体的概念坐标系 → 查阅官方文档核对命令参数与支持版本 → 针对你当下遇到瓶颈的具体技术点，挑选一篇垂直深度的专文进行攻克。请务必避免同时打开五篇声称“绝对完整、从零到一”的教程，以免自己彻底迷失、溺水在浩如烟海的专有名词海洋中。