最近我在升级 [[Claude Code]] 的时候，翻 changelog 注意到一个一直被标着 experimental 的功能开始稳定下来，那就是 teammate，官方文档里叫 Agent Teams，社区里很多人习惯叫它 Teammate Mode，也就是队友模式。说实话，第一次看到这个名字我是有点警惕的，因为这一两年里 AI 工具圈最不缺的就是各种听起来很唬人、用起来很鸡肋的”多智能体协作”概念。但真正把它打开用了几天之后，我发现这次是真的不太一样，它解决的是一个我自己每天都会撞上的实际问题，所以想专门写一篇文章把它讲清楚。
这篇文章主要讲的是 Claude Code 命令行里的这个队友功能。需要先说明一点，Anthropic 在 2026 年 6 月还发布了一个叫 Claude Tag 的 Slack 产品，营销文案里也用了 “AI teammate” 这个说法，那是另外一回事，是面向团队和企业版用户的、常驻在 Slack 频道里的共享 AI。两者名字里都带 teammate，很容易混淆，但本文聊的是终端里这个开发者天天能用到的功能。
它到底是什么
简单来说，Teammate Mode 让你能在一个终端会话里协调多个 Claude Code 实例一起干活。原来你启动一个 Claude Code，它就是一个孤独的智能体，所有事情都得它一个人排着队做。现在不一样了，你的这个会话会变成团队的 lead，也就是队长，它可以派生出若干个 teammate，每个队友都是一个独立的 Claude Code 实例，各自拥有完全独立的上下文窗口，彼此之间还能直接对话。
这个设计跟之前就有的子智能体（subagent）是有本质区别的，这一点我觉得是理解整个功能的关键，后面会专门展开讲。从版本演进上看，teammate 相关的改动大概从 2026 年 5 月中旬开始密集出现在 changelog 里，到 6 月 15 号那个版本做了一次重要的架构简化，把原来需要手动创建和销毁团队的 TeamCreate、TeamDelete 工具直接删掉了，改成每个会话只要打开了功能开关就隐含拥有一个团队，用起来心智负担小了很多。
队友和子智能体到底差在哪
这是我觉得最值得花笔墨说清楚的地方，因为如果你已经用惯了 [[Claude Code]] 的子智能体（subagent），很可能会问一句：我都能派子智能体了，为什么还需要队友？
子智能体的工作模式本质上是委托加汇报。主智能体把一个明确的任务丢给子智能体，子智能体闷头做完，把结果一股脑返回给主智能体，然后就消失了。这个模式最大的问题有两个。一个是子智能体跑完返回的那一大坨结果，会直接灌进主智能体的上下文里，任务一多上下文就被撑爆了。另一个是子智能体之间没法互相说话，它们都只对主智能体负责，像是一群互不认识的临时工，谁也不知道隔壁那位在干嘛。
队友模式则完全是另一套逻辑。每个队友是独立的完整实例，有自己隔离的上下文窗口，所以它们干的活不会污染队长的上下文。更关键的是，队友之间可以通过一个共享的邮箱机制直接点名互发消息，A 队友可以问 B 队友进度，可以把自己的发现同步给对方，甚至可以互相质疑和交叉验证。这就让它从单纯的并行加速，变成了真正意义上的协作。我自己的体感是，子智能体适合那种一次性的、边界清晰的小任务，而队友适合那种需要讨论、需要多视角、需要在过程中互相纠偏的复杂工作。
当然代价也是实打实的。多个独立实例同时跑，Token 消耗几乎是随队友数量线性增长的，所以这不是一个可以无脑滥用的功能，下面聊使用技巧的时候我会再强调这一点。
怎么开启它
到我写这篇文章为止，这个功能还是靠实验性的环境变量开关来控制的。你需要在 settings.json 里加上一行配置：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
加完之后重启会话，队友功能就激活了。我自己的环境里其实早就把这个开关打开了，所以一度没意识到它需要手动开启，如果你发现派不出队友，第一件事就是去检查这个环境变量。
怎么用它干活
开启之后用起来非常符合直觉，你不需要去记一堆命令，直接用自然语言描述你想要的协作方式就行。比如我想从三个不同角度审视一个方案，可以直接说：
派三个队友：一个负责 UX，一个负责架构，一个当反方唱反调。
队长会据此创建出对应的队友。如果你想精确控制数量和模型，也可以明确指定，比如让四个队友并行重构、每个都用 Sonnet 模型来省点钱。这里有个我踩过的坑要提醒一下，队友默认是不会继承队长的模型的，你可以在 /config 里设置默认的队友模型，或者每次派生的时候显式指定，否则可能会出现你以为大家都在用便宜模型、结果账单超出预期的情况。
协作的核心是一个共享任务列表，它存在 ~/.claude/tasks/ 下面对应团队的目录里，带依赖关系追踪。队友们会自己去认领任务、完成任务、解除阻塞，文件锁机制保证它们不会抢同一个任务打架。这个共享任务列表的好处是它在会话恢复后还能保留，所以即便你中途退出，任务进度不会丢。
显示模式也值得说一下，由 teammateMode 这个设置或者 --teammate-mode 命令行参数控制。默认是 in-process 模式，所有队友都挤在同一个终端里，你用方向键切换查看。如果你用的是 tmux 或者 iTerm2，可以选 auto 或者 tmux 模式，它会把队友拆分到不同的分屏窗格里，这样能同时盯着每个队友的进展，体验好很多。需要注意的是，VS Code 内置终端、Windows Terminal 和 Ghostty 目前还不支持分屏。
除此之外它还有几个我觉得设计得不错的细节。一个是计划审批门，你可以要求某个队友先以只读模式做出计划，由队长批准之后再动手实现，这对那种你不太放心让它直接改代码的任务很有用。另一个是它复用了子智能体的角色定义，你可以在派生队友的时候引用一个已命名的子智能体，直接给这个队友套上预设好的角色、工具白名单和模型。还有就是配套的几个 hook 事件，TeammateIdle 在队友空闲时触发、TaskCreated 在任务创建时触发、TaskCompleted 在任务完成时触发，你可以用退出码去拦截或者让队友继续干活，这给自动化留了不少空间。
实际用下来的感受
抛开功能清单，说点真实体验。我目前用得最顺手的场景是代码审查加反方质疑这种组合。让一个队友按正常思路审查改动，再派一个队友专门挑刺、唱反调，这种对抗式的设置经常能逼出单个智能体容易自我满足时漏掉的问题，比我一个人对着 diff 反复看要可靠。
另一个适合的场景是那种天然可以拆分的并行工作，比如把一个大重构按模块拆开，几个队友各管一块同时推进。因为每个队友上下文隔离，互不干扰，整体的墙上时间确实能压下来。但这里要诚实地说，它现在还有不少毛病。任务状态有时候会滞后，队友偶尔会忘记把任务标记成已完成，需要你盯一眼。in-process 模式下还不支持会话恢复，/resume 和 /rewind 没法把队友恢复回来。而且一个会话只能有一个团队，不能嵌套，队长也是固定的，没法中途换人。这些都说明它确实还在 experimental 阶段，别指望它像核心功能那样稳。
最需要警惕的还是成本。我前面说过 Token 消耗随队友数量线性增长，几个 Opus 队友同时跑起来烧钱速度是相当可观的。所以我的建议是，只有当一个任务真的能从多视角或者并行中获益的时候才动用队友，纯粹线性的、一个智能体就能搞定的活，老老实实用单会话或者子智能体就好，没必要为了用而用。
最后
Teammate Mode 对我来说真正的价值，不在于它能并行加速多少，而在于它把 AI 辅助编程从一个人闷头干，变成了一支可以互相讨论、互相验证的小团队。这种从单兵到协作的转变，配合上下文隔离和队友间直接通信的设计，让它跟那些只是把任务拆开并行跑的伪多智能体方案拉开了差距。它确实戳中了我每天都会遇到的痛点：复杂问题需要多个视角，而单个上下文窗口装不下所有东西。
当然它现在还很糙，实验性的开关、滞后的任务状态、不能恢复的会话、还有那个让人心疼的账单，都提醒着你这是个半成品。但方向我是认可的，而且 Anthropic 迭代的速度很快，从五月到六月这一个多月里架构就简化了一大轮。如果你也是 [[Claude Code]] 的重度用户，我建议你把那个环境变量打开，找一个适合多视角的任务试一次，亲自感受一下让几个 AI 在你的终端里组队干活是什么体验。等它再成熟一些，我相信这会成为很多人日常工作流里离不开的一部分。