Claude Code Agent Teams 深度解读：会互相对话的AI团队

从 Sub-agents 到 Agent Teams：两种截然不同的协作模型

很多人第一次听到 Claude Code 的 Agent Teams（代理团队）功能时，容易把它和已有的 Sub-agents（子代理）混为一谈。两者看起来相似——主代理都能派生出其他代理去干活——但底层的心智模型完全不同。

在 Sub-agents 模式下，主线程派生出一个或多个子代理，它们各自独立运行，互不通信。主线程唯一能看到的，只是子代理返回的最终结果。如果你同时跑多个并行子代理，它们之间是"沉默"的，谁也不知道对方在做什么。

这就带来一个经典问题：多个子代理并行写同一个文件时，很容易产生合并冲突（merge conflict）。因为它们没有协调机制，只能各自为战。

Sub-agents 的底层实现通常依赖"工具调用（tool use）"机制：主模型将子任务打包成一次函数调用，子代理在独立上下文窗口中执行后返回结果字符串。由于每个子代理拥有完全隔离的上下文，它们既看不到彼此的中间状态，也无法写入共享内存。这种设计在单一、边界清晰的任务上效率极高，但一旦涉及需要跨代理协调的工作（例如多个代理同时修改同一代码库），缺乏通信机制就会成为瓶颈——合并冲突只是其中最直观的症状之一。

Agent Teams 的核心差异：它们真的会"聊天"

Agent Teams 彻底改变了这一点。表面上，它依然是一个主代理在边上跑着一堆"队友（teammates）"，但这些队友不是被派生后就各干各的——它们会互相对话。

举个例子：你可以有一个代码审查员（code reviewer）代理，再配一个实现者（implementer）代理。审查员有时会说"我在等实现者的结果"，然后它们真的会彼此沟通、协调进度。这种交互在原来的子代理模式里是完全不存在的。

整个团队围绕一份**共享任务清单（shared task list）**运作，这份清单由主代理创建。队友们会反复核对清单的完成状态，只有当所有任务都完成时，团队才会结束工作。这里的主代理更像一个项目经理（PM），负责统筹而不是亲自下场。

这跟 Promise.all 有点像，但又本质不同。Promise 之间无法通信，而 Agent Teams 的价值恰恰来自"它们能通信"这件事本身。当你看到多个面板相互喊话、协同推进，最后汇聚出结果时，确实会有一种"AGI 时刻"的错觉——体验很爽，看着也很带感。

创建方式：队友是"即时生成"的

两种模式在工程层面还有一个关键区别。

Sub-agents 需要在代码库里有一个特定的 Markdown 文件来定义，它们属于项目的文件结构的一部分。而 Teammates 则是即时创建的——你只需要直接告诉 Claude Code："用五个代理组一个团队来做这件事"，它就会自动生成，比如一个 PR 代理、一个实现者代理、一个 UI/设计师代理。系统会自行理解每个队友应该配什么样的 system prompt。

换句话说，启用 Agent Teams 几乎没有门槛，一句话就能拉起一支临时团队。

验证与质控：别陷入"衔尾蛇"陷阱

一个很自然的疑问是：既然队友之间互相检查，那它们的输出到底由谁来验证？这不就成了一个"衔尾蛇（Ouroboros）"式的自我循环吗？难道再加一个代理去验证？那岂不是无限套娃、直到烧光 token？

答案并不在于叠加更多代理，而在于计划模式（plan mode）。

关键在于：确保你的计划是准确的，然后盯住那份共享任务清单。你是否认同这份清单，才是最核心的把关点——因为所有队友都会围绕它运行。至于输出本身的质量，其实和任何其他子代理或任务并无二致，它高度依赖于：

• 你在启动任务前给了多少上下文（context）
• 你在循环中加入了多少验证（verification）环节

比如做 UI 设计时，你是否提供了参考图？是否让它对照已有的测试用例去跑？验证这一步目前仍然是"手动"的，但只要你在循环里塞进更多验证机制，就能大幅提高成功率，再配合共享任务清单做核对。

此外，如果发现某个队友"跑偏"了，你随时可以单独把它停掉。有意思的是，团队负责人（team lead）有时会"慌"——当它发现某个队友进程退出时会察觉到，尽管它们并不在同一个进程里。某些情况下它还会主动把太闲的队友"裁掉"。看着这套机制运转，真的很像一支真实的团队。

Plan mode（计划模式）是 Claude Code 的一种工作流状态，在这种模式下，模型只输出执行计划而不立即采取行动，用户可以审阅、修改或拒绝计划后再触发执行。这与"先思考再行动"的 ReAct（Reasoning + Acting）范式类似，核心价值在于把人类的判断插入到不可逆操作之前。对于 Agent Teams 来说，在启动阶段确认共享任务清单的正确性，本质上就是在最高层级做了一次人工验证，后续队友的所有工作都在这个已确认的框架内展开，从而避免了"验证代理套验证代理"的无限递归问题。

QA 场景：Skills 比 Teams 更实用

谈到实际应用，很多开发者关心能不能做一个 QA 队友，专门负责"每次改动后确认一切仍正常工作"——尤其是写 Next.js 这类应用时，常常改了一处却悄悄弄坏另一处。

这里有个更接地气的建议：QA 恰恰是人们最常用 Skills（技能） 来解决的场景，而不是非得动用整个团队。因为 QA 流程本质上是分步骤的（step-based）——需要依次执行这一步、那一步。做一个 QA skill，并确保它在每次改动后被调用，效果非常好。如果流程足够固定，你甚至可以用更轻量的 Haiku 模型来跑，省成本又高效。

Skills（技能）在 Claude Code 中指的是可复用的、预定义的行为模板，通常以 Markdown 文件的形式存储在代码库中，描述某类任务的标准操作步骤。与 Agent Teams 的动态生成不同，Skills 是静态配置的，可以被主代理在需要时按需调用。Haiku 是 Anthropic 模型家族中成本最低、速度最快的版本，适合处理结构化、重复性高的任务。将固定的 QA 流程封装成 Skill 并用 Haiku 执行，既减少了上下文开销，也避免了每次都重新"理解"任务意图所带来的 token 消耗。

该不该用 Agent Teams？

结论相当务实：Agent Teams 很酷，但大多数情况下属于"杀鸡用牛刀"。

它会消耗大量 token，而在绝大多数任务里，一个好用的子代理就完全够了。它的真正魅力在于那种"团队协作的仪式感"——多个面板互相对话、协同收敛到结果，体验和观感都很出色。

但正如那句总结所言：有些时候你不需要一整支团队，你只需要一个好开发者，而那可以就是一个子代理。Agent Teams 是个精巧的小功能，用对场景才值得。