去年我开始用 Claude Code 的时候，它就是一个聊天窗口。我说需求，它写代码。跟请了个助手没区别——好用，但一个人终究只有两只手。
现在的 Claude Code 已经不是这样了。你可以同时开四五个 Agent 并行干活，有人负责调研，有人负责写代码，有人负责写测试。你坐在那，更像是在"带团队"而不是"用工具"。
这篇文章讲讲 Subagent 和 Agent Teams，以及如何用 Git Worktree 隔离Agent，防止打架。
一、什么是 Subagent
Subagent，直译是"子代理"。理解它最好的方式是一个比喻。
你是项目负责人。你手下有好几个外包——有人专做前端，有人专做测试，有人专门查文档。每个人接到你的指令就闷头干活，干完把结果汇报给你。他们之间不聊天，不需要知道其他人在做什么。
Subagent 就是这个"外包"。
在 Claude Code 里，Subagent 是从主 Agent（你也可以理解为主会话）派生出来的子任务执行单元。每个 Subagent 有三个特点：
独立上下文窗口。 Subagent 有自己的一亩三分地，不会把主会话的上下文塞爆。比如你让一个 Subagent 去读五千行日志文件，它读完、分析完、只把结论传回来。主会话干干净净，不受影响。
只向主 Agent 汇报。 Subagent 之间不能直接通信。A 做完了汇报给主 Agent，主 Agent 再告诉 B。所有信息流都以主 Agent 为枢纽。
专注于单一任务。 每个 Subagent 是为了完成一件具体的事而创建的——查资料、跑测试、分析代码、审查安全漏洞。干完活就消失。
技术上说，Subagent 是 Claude Code 内置的 Task 工具的一种使用方式。你可以预先配置好 Subagent 的"人设"——它擅长什么领域、用什么系统提示词、能访问哪些工具、用哪个模型——然后主 Agent 在需要时调用它。
如果你用过其他 AI 工具的"插件"或"自定义 GPTs"，可以类比理解，但 Subagent 更轻量，配置一分钟，随配随用。
二、什么是 Agent Teams
Agent Teams 是 Claude Code 在 2026 年 2 月推出的实验性功能。它和 Subagent 有本质区别。
还是用那个比喻。
Subagent 是你派外包去干活。Agent Teams 是你拉了一个项目群，把几个专家拉进来，你们在群里一起讨论问题、分配任务、各自推进。专家之间可以直接聊天、互相质疑、发现新信息之后立即分享。
Agent Teams 的核心组件：
Team Lead（队长）。 主会话。负责组队、拆任务、分发、协调、汇总。你可以让它切换到"委托模式"——只协调不干活。
Teammates（队友）。 每个队友是一个完整的 Claude Code 会话，有独立的上下文窗口，加载项目的 CLAUDE.md、MCP 服务器和技能。可以互相直接发消息，不需要经过队长中转。
共享任务列表。 所有队友可见。任务有三种状态：待处理、进行中、已完成。支持依赖关系（blockedBy）：前置任务没完成，后续任务自动锁定。
消息系统。 队友之间发消息就像在群聊里 @ 某人，可以指定某个队友私聊，也可以广播给所有人。消息到了对方那边是即时显示的，不用手动刷新。
一句话总结两者的核心区别： Subagent 是"干活汇报"，Agent Teams 是"讨论协作"。 Subagent 之间的通信必须经过主 Agent 中转，Agent Teams 里的队友可以直接对话。
三、如何开启和配置 Subagent
Subagent 不需要额外开启——它是 Claude Code 的内置能力，直接就能用。
方式一：对话中直接调用
最简单的方式，在对话里直接说：
派一个 Subagent 去检查 data_processor.py 里的所有函数，列出每个函数的入参和返回值。
Claude 会自动创建 Subagent，执行任务，然后把结果汇报回来。你不需要做任何配置。
方式二：自定义预配置 Subagent
如果你希望某个 Subagent 有固定的专业领域和系统提示词，可以预先配置。输入 /agents ，打开 Subagent 配置界面。
选择 "Create new agent"，然后设置：
配置好后，在对话中指定它就行：
用 code-reviewer Subagent 审查刚才提交的代码。
Claude 会在执行时自动调用该 Subagent，并且终端里会用你选的高亮颜色显示它的输出，一眼能分辨谁在干活。
Subagent 也支持 worktree 隔离 ——这个放到后面讲。
四、如何开启和配置 Agent Teams
Agent Teams 目前是实验功能，默认关闭。需要手动打开。
第一步：开启实验开关
打开 Claude Code 的配置文件 ~/.claude/settings.json ，在 env 节点下添加：
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }}
保存后重启 Claude Code。运行 /config ，往下翻，如果看到 Agent Teams 相关的配置项，就说明已生效。
第二步：选择显示模式（可选）
Agent Teams 支持两种显示模式。在 settings.json 中配置：
{ "teammateMode": "in-process"}
或者：
{ "teammateMode": "tmux"}
In-process 模式：所有队友在同一终端内运行，按 Shift+Up/Down 在不同队友之间切换查看。不需要额外工具，Windows Terminal、VS Code 终端都能用。
Split-pane 模式：每个队友一个独立窗格，可以同时看到所有人的输出。需要先装 tmux （Mac: brew install tmux ，Ubuntu: sudo apt install tmux ）。
默认是 auto ——检测到你在 tmux 里就用分屏模式，否则用进程内模式。
第三步：预批准权限（强烈建议）
Agent Teams 跑起来之后，队友做某些操作会向 Lead 请求权限。如果团队里有 4 个队友，频繁弹权限请求能烦死人。
建议在组建团队之前，先运行 /permissions ，把项目目录下的文件操作、常用命令、队友会用到的工具权限提前批好。队友拿到预设权限后就能直接执行，不用每次都打断你。
如果你完全信任团队（比如在本地安全环境），也可以启动时加参数：
claude --dangerously-skip-permissions
注意这个有风险，仅限本地可控环境。
第四步：组建团队
前面的配置都是一次性的。配好之后，每次用团队只需要自然语言描述：
创建一个 Agent Team 来审查 PR #142 。三个审查员：一个负责安全检查，一个负责性能分析，一个负责测试覆盖率验证。
Claude 会自动创建团队、生成队友、设置任务列表、开始协调。你不用操心底层细节。
你也可以精确控制：
创建一个 4 人团队，1 个用 Opus 做架构师，2 个用 Sonnet 做实现，1 个用 Haiku 做研究员。架构师只设计方案不写代码。实现者动手前必须提交计划让我审批。
第五步：运行中的控制
团队跑起来之后，你需要掌握几个关键操作：
Delegate Mode 是容易被忽略的好功能。Leader 有时会忍不住自己下场写代码而不是等队友完成。按 Shift+Tab 开启委托模式后，Lead 只能协调和调度，不能改代码。这对保持团队纪律很有用。
关闭团队时，先让 Lead 逐个关掉 Teammate：
所有 Teammate 都关掉之后，再：
顺序别乱——先关队友，再清理。有活跃队友时清理会失败。
五、使用实战
Subagent 实战：并行代码审查
假设你刚写完一个数据处理模块，想在合并前做一轮审查。用 Subagent 可以同时从多个角度检查：
派三个 Subagent 并行审查 data_pipeline.py。一个检查安全性（SQL 注入、路径遍历），一个检查性能（不必要的循环、重复 IO），一个检查代码风格（命名规范、类型注解）。各自出审查报告。
三个 Subagent 同时开工。安全审查的读文件，性能审查的跑 profiling，风格审查的做静态分析。互不干扰。完成后各自把结果汇报给主 Agent，主 Agent 汇总成一份综合报告。
这里的关键是：三个审查角度完全独立，不需要 Subagent 之间互相讨论。所以用 Subagent 刚好。
Agent Teams 实战：跨层功能开发
这个场景更复杂：开发一个数据导出功能，涉及后端 API、前端按钮和下载逻辑、数据库视图三个层面。
创建一个 3 人 Agent Team 来开发数据导出功能。队友 1 负责后端导出 API（FastAPI 路由 + pandas 导出逻辑），队友 2 负责前端按钮和下载交互（React 组件），队友 3 负责数据库视图和索引优化。队友 3 先完成数据库部分，队友 1 和 2 依赖队友 3，等它完成后再启动。文件不要互相冲突。
Team Lead 创建了三个任务，并将队友 1 和队友 2 的任务标记了 blockedBy：依赖队友 3 先完成。队友 3 改数据库，队友 1 和队友 2 进入等待。队友 3 完成后，队友 1 和队友 2 自动解锁，并行推进。
中间队友 1 改了一个 API 返回字段的名字，直接发消息告诉队友 2："export_url 改成了 download_url，你那边注意一下。"队友 2 收到后直接适配。没有转述，没有延迟。
这就是 Agent Teams 的真正价值：不只是快，是信息的即时对齐。
六、Subagent vs Agent Teams：区别、优势与选型
我把两者的核心差异压成一张表：
选型的原则只有一句话：任务之间需不需要互相沟通？
不需要 → Subagent。比如并行查资料、各写各的模块、各跑各的测试。省 token，省时间，够用。
需要 → Agent Teams。比如方案讨论、多角度审查需要交叉验证、复杂调试需要互相挑战假设。多出来的 token 消耗，换来的是更高的方案质量。
一个典型的错误： 用 Agent Teams 做简单的并行任务。四个队友各自写一个独立的工具函数，完全不需要互相知道对方在做什么。你多花了三倍的 token 在"沟通"上，但根本没有沟通的必要。
另一个典型的错误： 用 Subagent 做需要讨论的任务。让三个 Subagent 各自调研一个技术方向然后汇报，但你期待它们能互相比较优劣。Subagent 做不到——它们各自只看自己的方向，没法横向比较，也没有动机去挑别人的毛病。
混合策略： Agent Teams 做"方案讨论"，Subagent 做"模块执行"。先组一个 Agent Team 把架构和选型对齐了，关掉团队，然后派 Subagent 各自执行。既拿到了讨论的质量，又避开了执行的 token 浪费。
七、Git Worktree：给 Agent 独立的"办公室"
上面的内容解决了"谁干什么活"和"怎么配合"。还有一个实际问题没解决： 多个 Agent 同时改代码，文件不会打架吗？
这就轮到 Git Worktree 出场了。
Git Worktree 是什么
Git Worktree 是 Git 内建的一项能力，非常实用。
它的工作机制是这样的：同一个仓库，你可以把它不同分支的内容同时展开到不同目录下。每个目录像独立仓库一样工作——有自己的文件、自己的暂存区。但在底层，它们指向同一个 .git ，共享历史和远端连接。
说人话：以前你一个目录只能挂一条分支，换分支就得切来切去。Worktree 让你一条分支占一个目录，同时打开三个目录，三个分支各自干活，谁也不碍着谁。
Claude Code 原生支持 Worktree
Claude Code 内置了 --worktree 参数。一行命令就能创建隔离的工作目录：
claude --worktree feature-auth
敲完回车，Claude 帮你做好几件事：在项目的 .claude/worktrees/feature-auth/ 下搭好完整的代码目录，自动切出一个叫 worktree-feature-auth 的分支（基于远程主干），然后在这个隔离空间里启动新会话。
懒得取名的话：
claude --worktree
自动生成随机名字。
不想记命令行参数也没关系。直接在对话里跟 Claude 说"帮我在 worktree 里干活"或者"start a worktree"，它听得懂，会自动处理创建流程。
Subagent + Worktree 隔离
Subagent 同样支持 Worktree 隔离。有两种配置方式：
方式一：对话中指定
派 3 个 Subagent 并行迁移旧 API，每个 Subagent 用独立的 worktree。每个负责 10 个文件。
Claude 会为每个 Subagent 创建独立的 worktree，各自在隔离环境中工作。互不踩脚。
方式二：预配置中设置
在自定义 Subagent 的配置里，加一行：
isolation: worktree
这样每次调用这个 Subagent 时，它自动在 worktree 里运行。
任务跑完之后，如果 Subagent 什么都没改，对应的 worktree 会自动删掉，不留痕迹。有产出的话，worktree 会留着等你审查。有用的留着，没用的自动回收——这个机制挺贴心的。
最合适的场景 ：大规模代码改造。比如你的项目里有三十几个模块需要统一升级日志框架。拆成 4 个 Subagent，每人领 8 个模块，各自在独立 worktree 里改。4 个人同时开工，改的是不同文件，互不碰头。完成之后逐个 review，确认没问题了逐个 merge。
Agent Teams + Worktree 隔离
Agent Teams 目前不直接内建 Worktree 支持（它是实验功能），但你可以手动配合。
在创建 Agent Team 之前，先用 claude --worktree <feature-name> 启动一个 worktree 会话。在这个会话里创建 Agent Team。这样整个团队都在这个 worktree 里工作，和主分支隔离开。
如果你有多个独立功能要开发，创建多个 worktree，每个里面跑一个 Agent Team。三条线并行推进，哪天想合并哪个就合并哪个。
更规范的做法是借助 superpowers 插件的 using-git-worktrees 技能。它会自动检测项目结构、创建 worktree、装依赖、跑基线测试、确保一切就绪后才开始干活。
不管哪种方式，Worktree 的本质价值是一样的： 给每个 Agent（或每组 Agent）一个隔离的工作区，它们互不干扰。 改完一个 feature，review 通过，merge 到主分支；改坏了，删掉 worktree 重新来。主分支始终干净。
Worktree 使用注意事项
几个坑提前说。
依赖安装。 worktree 只复制代码，不复制 node_modules 和 .venv 这些依赖目录。进 worktree 后第一件事就是把依赖装上——Node 项目 npm install ，Python 项目重建虚拟环境。漏了这一步，后面所有的运行报错都是"找不到模块"。
端口冲突。 两个 worktree 的项目需要同时起 dev server 的话，默认端口会撞。提前给不同 worktree 分配不同端口。
.gitignore 。 一定要把 .claude/worktrees/ 写进 .gitignore ，不然 git status 会被一堆临时目录刷屏。装了 superpowers 插件的，它会自动帮你处理这一步。
基线测试。 依赖装好之后，第一时间跑完整测试套件。确认当前代码本身是绿的，再动手改。否则改到一半测试红了，你搞不清是自己引入的 bug 还是原始代码就有毛病。
清理。 退出会话时，Claude 自动处理。worktree 里没有改动的话，目录和分支自动删除。有改动会问你要不要保留。选保留就留着下次接着用，选删除就全清——包括未提交的改动，这一步要确认清楚。
八、最佳实践总结
写了这么多，归纳几条原则。
原则一：先判断任务性质，再选工具。
不是"新技术一定好"。你越是熟练地判断一个任务是"独立型"还是"协作型"，就越省 token、越少翻车。
原则二：文件边界先于代码。
不管是 Subagent 还是 Agent Teams，开工前最重要的事是划清文件归属。谁写哪个文件，白纸黑字。我翻车最多的原因不是 Agent 能力不行，是两个 Agent 同时往同一个文件里写东西。
原则三：Task 粒度宁大勿小。
太小的任务，协调成本吃掉全部收益。一个 Agent 只改一行注释，不值当启动一个 worktree。每个任务应该是"一个自包含的工作单元，有清晰交付物"。
原则四：从简单场景入门。
如果你之前没用过多 Agent，别一上来就开 5 个 Agent Team 同时改核心模块。先从"用 Subagent 并行查资料"开始，体感对了再升级到 Agent Teams。
原则五：Worktree 是好习惯。
不管你用什么 Agent 模式，凡是涉及改代码的、非 trivial 的任务，开一个 worktree。隔离的不只是文件，也是你的心智负担——你知道主分支是干净的，随时可以切回去。这个安全感值一个 claude --worktree 命令。
从 Subagent 到 Agent Teams，再到 Git Worktree 隔离——这三个东西放在一起看，Claude Code 的演进方向很清楚：它正在从一个"AI 助手"，变成一套"AI 团队操作系统"。
Subagent 解决了"一个人干不完"。Agent Teams 解决了"分工后怎么协调"。Worktree 解决了"多人同时干活文件不打架"。
你现在手里的这套工具，本质上是一个迷你的工程团队。你不再一行行写代码，你设计任务结构、划文件边界、定质量标准。Agent 帮你执行。
这个角色转变，比任何单一功能更新都重要。
