公众号名称：Agent开发笔记

作者名称：Agent开发笔记

发布时间：2026-04-17 18:30

协调 Claude Code 会话团队：什么时候该组队，什么时候别折腾

一个 Claude Code 会话，干简单活挺顺。真到复杂任务，比如我要同时排查一个线上问题：一边读后端日志，一边核对前端调用链，一边验证是不是测试环境配置漂了，再补一份修复方案。单会话不是不能做，是来回切上下文太伤，问着问着就糊了。

Claude Code 现在给了一个更像“组织协作”的玩法：Agent teams。不是多开几个窗口自己盯着，而是把多个会话组织成一个团队，一个负责人协调，多个队友并行干活，最后再收口。这个东西我看下来，重点不在“新功能”，而在于它把 AI 从单助手，抬到了可分工、可协同、可汇总的工作形态。

这篇我不讲花活，就讲四件事：什么时候该用、和 subagents 怎么选、怎么启用、怎么把团队控住。先说结论：复杂任务值得组队，线性任务别硬上。

Claude Code 会话团队到底是什么

先把定义说死：Agent teams 是 Claude Code 的实验性功能，默认禁用。

它的结构很清楚。一个会话当负责人，负责拆任务、分配工作、盯进度、汇总结论。其他会话是队友，各自有独立的 context window，各干各的，不会把一堆无关上下文搅在一起。

这个设计真正有用的地方，不是“多几个 Claude Code 实例”，而是队友之间可以直接通信。这点和普通多窗口不一样。普通多窗口是你自己做人肉总线，什么都要中转；Agent teams 是团队内可以互相协作，负责人不用做所有消息转发。

所以我更愿意把它看成一个轻量级的 AI 协作面板。负责人像 tech lead，队友像独立执行单元。你不是在“问一个更强的助手”，你是在编排一组会工作的会话。

会话团队示意

启用前先确认 3 个前提

先别急着试，先把门槛过了。不然你后面一顿操作，最后发现是版本不够。

第一，Claude Code 版本至少要 v2.1.32。先查版本：

claude --version

第二，Agent teams 默认是关闭的。这是实验性功能，不开就没有。

第三，要显式设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS。可以走环境变量，也可以走 settings.json。我自己的习惯是：想快速试一下就用环境变量，想长期保留就写配置。

环境变量方式：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

如果你是临时开一个 shell 会话，这个最省事。关掉终端就没了，适合先试错。

如果你要给团队机器或固定开发环境开，建议写到配置里。核心点只有一个：把实验开关打开。先确认这三步，再往下谈启动团队，不然都是白搭。

它不是更强的助手，而是新的协作组织方式

很多人看到多会话，第一反应是“更猛了”。我不这么看。Agent teams 强的不是单点能力，而是组织能力。

单会话的优点很明显：路径短、便宜、收敛快。你提一个问题，它一路做下去，没什么协调成本。只要任务不复杂，这就是最优解。

会话团队不一样。它的优势是分工明确、并行推进、上下文隔离。一个队友查资料，一个队友读现有实现，一个队友写测试策略，负责人最后合并。这种活，单会话也能做，但代价是上下文会越来越脏，切换成本越来越高。

这里有个前提：你得会拆任务。 不会拆，团队化只会把混乱放大。负责人的价值不是多打一份字，而是把任务边界切干净，让每个队友只待在自己的问题空间里。

所以这功能不是给“懒得思考”的人准备的，恰恰相反。你越会做任务编排，它越值钱。

什么时候该用：4 类任务最适合 Claude Code 会话团队

1）研究和审查

这类任务天然适合并行。比如我要评估一个模块重构值不值得做，我会让一个队友扫代码结构，一个队友查潜在风险点，一个队友整理依赖和影响面。

负责人最后要的不是三份流水账，而是一个汇总结论：改哪里、风险多大、先后顺序怎么排。这时候并行探索是真增益，不是形式主义。

2）新模块或新功能

新功能最怕一个会话什么都想管。前端状态流、后端接口、数据结构、测试方案，全塞一个上下文里，最后谁都不清楚。

会话团队适合把这些子任务分出去。前端队友看组件和交互，后端队友看接口和存储，测试队友准备用例和边界条件。负责人只盯接口契约和最终集成。

这种情况下，团队化最大的收益不是“更快写代码”，而是先把设计收敛清楚，避免后面返工。

3）竞争假设调试

这个场景我觉得特别值。一个 bug 卡住时，最怕大家都沿着同一条假设走到底。结果方向错了，还浪费很多时间。

我更推荐让不同队友分别验证不同假设。比如：
- 队友 A 查是不是缓存问题
- 队友 B 查是不是数据库延迟
- 队友 C 查是不是前端状态没刷新

最后负责人收敛证据链。这样能明显减少路径依赖。AI 最容易一本正经地沿错路狂奔，竞争假设正好能压这个问题。

4）跨前端、后端、测试的跨层协同

只要任务跨层，Agent teams 基本就开始发力了。因为跨层任务本来就不是一个脑回路能顺着跑完的，它需要不同视角同时推进。

这种任务里，负责人最重要的动作不是“指挥细节”，而是盯住共享目标：接口定义是否一致、验收标准是否一致、测试准备是否覆盖主路径。只要这三件事稳住，队友并行是有价值的。

与 Subagents 怎么选：关键不在强弱，而在协作路径

很多人会把 Agent teams 和 subagents 混着看，这样选型容易错。

Subagents 的本质是：运行在单个会话里，由主代理调度，最后统一向主代理汇报。这个模型很轻，特别适合“主任务下发—执行—回传”这种链路清楚的活。

Agent teams 不一样。它里面每个队友更独立，你可以直接和某个队友对话，队友之间也可以直接通信。它不是“主代理带几个临时工”，而更像一组可互动的协作单元。

我的选择标准很简单：

如果你的任务是这种模式：

主代理拆任务 -> 子代理执行 -> 主代理汇总

那就优先 subagents。够用，而且省 token。

如果你的任务是这种模式：

负责人定目标 -> 多队友并行探索 -> 中途互相校验/补信息 -> 负责人收敛

那就上 Agent teams。因为这时候你要的是协作，不是单向汇报。

一句话：subagents 适合执行链，Agent teams 适合协作链。

什么时候别用：这些场景单会话反而更高效

Agent teams 不是通用最优解，这点一定要说重一点。它有明显的协调开销，而且 token 消耗也比单会话高，乱用就是赔本买卖。

第一类，顺序任务别组队。前一步没结果，后一步根本做不了，这种并行没有意义。你硬拆，只会让负责人不停同步状态，效率更低。

第二类，同一文件密集编辑别组队。几个人围着同一段代码转，冲突是必然的。AI 不是 git miracle worker，最后你还是得自己收冲突和对齐改动意图。

第三类，依赖关系很重的任务别组队。如果 A 要等 B，B 又要等 C，负责人会变成消息中继站。理论上人多力量大，实际上是阻塞链更长。

这里我的判断很直接：能一条链走通的任务，就别搞团队。 单会话或者 subagents 往往更省、更稳。

为什么重要：它改变的是复杂任务的处理方式

这功能值得跟，不是因为它多了几个窗口，而是因为它提供了一个新的工作范式：拆分—并行—汇总。

以前复杂任务只能往一个长上下文里硬塞，塞到最后上下文污染、注意力分散、结论也不稳定。现在可以把不同问题空间拆开，让各自独立推进，再通过负责人收口。

这对开发者的要求也变了。你不再只是“会提问”就行，你得会设计团队结构：谁负责探索，谁负责验证，谁负责汇总，通信链路怎么走，什么时候中断，什么时候收敛。

对技术负责人来说，这玩意儿其实挺像一个轻量级 AI 编排台。不是项目管理工具那个味儿，而是更贴近研发现场：你直接在终端里做分工、盯进度、收结果。

分工协作模型

上手步骤：从启用实验功能到创建第一个 team

先给一套最短路径，别一上来就整复杂编排。

第一步：检查版本

先确认 claude 版本：

claude --version

只要低于 v2.1.32，后面不用试，先升级。

第二步：开启实验功能

临时启用：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

如果你习惯配文件，也可以在 settings.json 里加对应配置。重点不是写哪儿，重点是这个开关得打开。

第三步：直接用自然语言创建团队

这类功能没必要搞得像写 Terraform。最实用的方式就是直接发任务，让负责人开始拉团队。

比如你可以这样描述：

创建一个 agent team 来排查登录失败问题：
- 一个队友检查前端登录请求和状态管理
- 一个队友检查后端认证逻辑和日志
- 一个队友准备复现步骤和测试建议
最后汇总根因、修复方案和风险点

这类指令有三个关键元素：目标、分工、交付物。少一个都容易跑偏。

第四步：别让角色定义太虚

最容易犯的错，是把队友角色写成“帮我看一下”“研究一下”。这种等于没分工。

你应该明确到能落地的程度，比如：
- 读哪部分代码
- 验证哪条假设
- 输出什么结果
- 是否需要和其他队友同步

负责人不是召唤师，负责人是调度器。任务边界越清楚，后面越省心。

显示模式怎么选：in-process 还是 split panes

Agent teams 支持两种显示模式：in-process 和 split panes。

in-process 更像在一个主终端里统一管理。优点是干净、集中、干扰少。你如果刚开始用，我建议先从这个模式起步，因为认知负担低。

split panes 就更像真正的多工位协作。每个队友一个分割窗格，观察并行过程会更直观。缺点是屏幕信息量会陡增，不熟的时候容易眼花。

这里有个前提：split panes 需要 tmux 或 iTerm2。默认 teammateMode 是 auto，如果你运行在 tmux 里，通常会优先走分割窗格；否则一般回落到 in-process。

可以在 ～/.claude.json 里设置默认模式，也可以单次强制指定：

claude --teammate-mode in-process

我的建议很明确：
- 第一次试用：in-process
- 已经习惯并行观察：split panes
- 你在 tmux 重度工作流里：优先用 auto

cover_image

原创 Agent开发笔记 Agent开发笔记

内容效果不满意？点此反馈