Agent Teams vs Subagents：Claude Code 从"单打独斗"到"团队协作"的进化之路

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 38篇，AI 编程最佳实战「2026」系列第 5篇 大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。 我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、Milvus 向量数据库的技术实践者与开源布道者！ Talk is cheap, let's explore。无界探索，有术而行。

Claude Agent Teams 核心架构概览

图 1：Claude Agent Teams 核心架构概览 - 四大组件、三大场景、选型指南

你在用 Claude Code 做复杂任务时，可能遇到过这些情况：

• 想让多个 AI 同时调查问题的不同方面，但它们只能串行工作
• 派出去的子任务之间完全隔离，无法互相交流
• 一个 AI 找到一个解释就停了，没人挑战它的结论

这些问题的根源是同一个：Subagents 只能向主代理报告，队友之间不能直接通信。

Claude Agent Teams 用一套全新的协作机制解决了这个问题——让多个 Claude Code 实例像真正的团队一样，可以互相发消息、共享任务列表、自我协调。

一、为什么需要 Agent Teams？（WHY）

Subagents 的局限性

Subagents 是 Claude Code 早期的委托机制，适合简单任务。但它的设计有一个硬性限制：所有子代理只能向主代理报告结果，彼此之间不能直接通信。

这就像一个经理派三个员工去调研，但要求他们只能向经理汇报，不能互相讨论。听起来没什么问题？看个真实场景。

假设你在审查一个 PR，想同时检查安全性、性能和测试覆盖。用 Subagents 的话：

1. 主 Agent 派 Subagent A 检查安全性 → 等待结果
2. 主 Agent 派 Subagent B 检查性能 → 等待结果
3. 主 Agent 派 Subagent C 检查测试 → 等待结果
4. 主 Agent 汇总三个结果

三个任务串行执行，而且 A 发现的线索无法传给 B，B 的发现也无法帮到 C。如果它们能并行且互相讨论呢？

并行协作的真实需求

有些任务天生需要协作，不是简单汇总就能搞定的。

场景一：竞争假设调查

用户反馈应用在发送一条消息后就退出了。可能的原因有五种：WebSocket 连接问题、认证 token 过期、消息处理崩溃、内存泄漏、前端 JS 报错。

如果用一个 Agent 顺序排查，它找到第一个"看起来合理"的解释就会停下来——这是人类也会犯的错误，叫锚定效应。

更好的做法是让五个 Agent 同时调查五种假设，而且要求它们互相挑战对方的结论。这就像科学辩论，能存活下来的理论更可能是真正的根因。

场景二：跨层协调开发

你要开发一个用户认证模块，涉及前端组件、后端 API、测试用例。如果让一个 Agent 全包，它很容易顾此失彼。

理想的做法是三个 Agent 并行开发三层，但需要它们协调接口契约。这需要队友间能直接通信，而不是事事都绕回主代理。

Agent Teams 的价值主张

Agent Teams 的核心改进只有一条，但足够关键：

队友之间可以直接发送消息，不需要通过主代理中转。

这个改动带来了几个连锁反应：

• 并行执行：多个任务可以同时跑，不用排队
• 信息共享：A 的发现可以实时同步给 B，不用等汇总
• 自我协调：共享任务列表让队友自己认领工作
• 直接交互：你可以直接跟任意队友对话，不必通过 Lead

当然，代价也是有的：令牌成本。每个队友都有独立的 context window，成本会随队友数量线性增长。后面会详细讲如何权衡。

锚定效应 vs 科学辩论

图 2：锚定效应 vs 科学辩论 - 单一视角容易陷入隧道视野，多视角并行辩论能找到更好答案

二、Agent Teams 是如何工作的？（HOW）

先看一张官方对比图，直观感受一下两种架构的区别：

Subagents vs Agent Teams

图：Subagents（左）只能向主代理报告，Agent Teams（右）队友可直接通信

与 Subagents 的详细对比

官方文档给出了一张详细的对比表，帮你快速理解两者的核心差异：

官方建议：当你需要快速、专注的工作人员报告结果时，使用 Subagents。当队友需要分享发现、相互质疑和自我协调时，使用 Agent Teams。

四大核心组件

Agent Teams 的架构由四个组件构成：

1. Team Lead（团队负责人）

这是主 Claude Code 会话，负责：

• 创建团队
• 生成队友
• 分配初始任务
• 综合最终结果

Lead 不是"老板"，更像是协调者。它不会 micromanage，而是让队友自己认领和完成任务。

2. Teammates（队友）

每个队友是一个独立的 Claude Code 实例，有自己独立的 context window。这意味着：

• 不会继承 Lead 的对话历史
• 需要在生成时给它足够的上下文
• 可以独立运行很长时间

3. Task List（共享任务列表）

这是协调的核心。任务列表是共享的，所有队友都能看到。两种认领方式：

• Lead 显式分配：Security Reviewer，你去检查 token 处理
• 队友自我认领：看到未认领的任务，主动接手

任务还有依赖关系管理——任务 B 依赖任务 A 的话，会等 A 完成再执行。另外还有文件锁定机制，防止两个队友同时编辑同一个文件。

4. Mailbox（消息邮箱）

队友之间的通信系统，支持两种模式：

• message：给特定队友发消息
• broadcast：广播给所有队友

队友完成自己的任务后会自动通知 Lead，不需要你手动检查进度。

通信机制详解

Agent Teams 的通信是双向的、点对点的。

Lead ↔ Teammate 1 ↔ Teammate 2 ↔ Teammate 3
                ↕           ↕
            共享任务列表 + 消息邮箱

对比一下 Subagents：

Lead → Subagent 1 → Lead
Lead → Subagent 2 → Lead
Lead → Subagent 3 → Lead
（Subagent 之间无连接）

这个区别在实际使用中体现得很明显。比如竞争假设调查场景：

"Spawn 5 agent teammates to investigate different hypotheses. Have them talk to each other to try to disprove each other's theories, like a scientific debate."

Lead 只需要说一句"像科学辩论一样互相挑战"，五个队友就会自己发起辩论、交换证据、推翻彼此的假设。Lead 不需要作为中转站。

显示模式：怎么看到队友在干什么

Agent Teams 提供两种显示模式：

In-process 模式（默认）

所有队友在主终端内运行。你看到的是 Lead 的界面，但可以用 Shift+Down 循环查看每个队友的实时输出。

优点：不需要额外工具，开箱即用。 缺点：不能同时看到多个队友，需要手动切换。

Split panes 模式

每个队友获得自己的终端窗格，可以同时看到所有人的工作状态。

要求：需要 tmux 或 iTerm2。 注意：VS Code 集成终端、Windows Terminal、Ghostty 不支持这个模式。

如何启用

Agent Teams 目前是实验性功能，需要手动开启。

在项目根目录的 .claude/settings.json 中添加：

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

或者设置环境变量：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

启用后，在 Claude Code 里直接用自然语言创建团队就行，不需要额外的命令。

启动你的第一个 Agent Team

启用 Agent Teams 后，用自然语言描述你想要的任务和团队结构即可。Claude 会自动创建团队、生成队友并根据你的提示协调工作。

官方给了一个很好的示例，三个角色是独立的，可以在不相互等待的情况下探索问题：

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

执行流程：

1. Claude 创建一个具有共享任务列表的团队
2. 为每个角度生成队友（UX 研究者、架构研究者、反对者）
3. 让他们并行探索问题
4. Lead 综合发现
5. 完成后清理团队

如何与队友交互：

• In-process 模式：负责人的终端列出所有队友及其正在处理的工作。使用 Shift+Down 循环浏览队友并直接向他们发送消息。在最后一个队友之后，Shift+Down 会回到负责人。
• Split panes 模式：如果你想同时看到所有人的工作状态，可以切换到分割窗格模式（需要 tmux 或 iTerm2）。

一些实用技巧：

• 可以直接与任意队友对话，提供额外指示或改变方法
• 队友完成后会自动通知负责人
• 完成后记得清理团队：Clean up the team

三、Agent Teams 能做什么？（WHAT）

经典实践案例

案例一：并行代码审查

这是官方推荐的入门场景。单个审查者容易有"隧道视野"，一次只关注一类问题。用 Agent Teams 可以让多个队友同时从不同角度审查。

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

执行过程：

• Security Reviewer：检查 token 处理、会话管理、输入验证
• Performance Reviewer：检查响应时间、内存使用、可扩展性
• Test Coverage Reviewer：检查单元测试、集成测试、边界情况

三个队友并行工作，最后 Lead 综合三份报告。

案例二：竞争假设调查

前面提到的诊断场景。让多个队友同时调查不同的假设，并要求它们互相挑战。

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

五个队友分别调查：

1. WebSocket 连接问题
2. 认证 token 过期
3. 消息处理崩溃
4. 内存泄漏
5. 前端 JS 错误

它们不仅调查自己的假设，还会主动挑战其他人的结论。最后，能经受住辩论的假设就是最可能的根因。

案例三：跨层协调开发

开发一个新功能，涉及前端、后端、测试三层。让每个队友负责一层：

• Frontend Teammate：UI 组件、表单验证、状态管理
• Backend Teammate：API endpoints、数据模型、业务逻辑
• Test Teammate：单元测试、集成测试、E2E 测试

关键点：每个队友拥有不同的文件集，避免冲突。

Teammate 1 负责：src/auth/login.*
Teammate 2 负责：src/auth/register.*
Teammate 3 负责：tests/auth/*

Agent Teams 三大应用场景

图 3：Agent Teams 三大应用场景 - 并行代码审查、竞争假设调查、跨层协调开发

最佳实践清单

官方文档给出了七条建议，我挑最重要的几条展开。

1. 给队友足够的 context

队友不会继承 Lead 的对话历史，所以生成时要给足上下文。

❌ 太简略：

Spawn a teammate to fix the bug.

✅ 明确具体：

Spawn a security reviewer teammate with the prompt: "Review the authentication 
module at src/auth/ for security vulnerabilities. Focus on token handling, 
session management, and input validation. The app uses JWT tokens stored in 
httpOnly cookies. Report any issues with severity ratings."

2. 选择适当的团队规模

经验法则：每个队友 5-6 个任务，3-5 个队友是最佳起点。

3. 从研究和审查开始

新手建议的进阶路径：

第 1 周：代码审查（不写代码）
    ↓
第 2 周：Bug 调查（只读操作）
    ↓
第 3 周：文档研究（信息收集）
    ↓
第 4 周：开始并行实现

先从只读任务开始，熟悉机制后再做写操作。

4. 等待队友完成

Lead 不要自己动手实施任务。说清楚"等队友完成后再继续"，让 Lead 专注于协调。

已知限制

Agent Teams 目前是实验性功能，有一些已知限制需要知道：

• In-process 队友没有会话恢复：/resume 和 /rewind 不会恢复 in-process 队友
• 每个会话一个团队：Lead 一次只能管理一个团队
• 没有嵌套团队：队友不能生成自己的团队或队友
• Lead 是固定的：不能把队友提升为 Lead
• 权限在生成时设置：不能为每个队友单独设置权限模式

这些限制意味着 Agent Teams 目前更适合中小型任务，不适合超大规模的层级化协作。

四、实战指南

如何选择：Subagents vs Agent Teams

用一张表说清楚：

一句话判断：如果队友之间需要讨论，用 Agent Teams；如果只需要各自干活然后汇总，用 Subagents。

Subagents vs Agent Teams 选择指南

图 4：Subagents vs Agent Teams 选择指南 - 快速决策流程与对比表

令牌成本和性能优化

Agent Teams 的令牌成本明显更高，因为每个队友都有独立的 context window。

成本对比：

优化策略：

1. 动态调整团队规模：从 3 个队友开始，需要再加，不需要就减少
2. 选择适当的模型：简单任务用 Haiku 降低成本，复杂任务用 Sonnet/Opus
3. 精确的上下文：生成队友时给足但不过量的上下文
4. 及时关闭空闲队友：完成任务的队友及时关闭，减少不必要的消耗

常见问题排查

问题一：队友没出现

可能原因：

• In-process 模式下队友已运行但不可见
• tmux 未安装（split panes 模式）

解决方法：

# 检查 tmux
which tmux

# In-process 模式用 Shift+Down 循环查看

问题二：权限提示过多

原因：队友的权限请求会冒泡到 Lead

解决方法：

• 预先批准常见操作
• 在 settings.json 中配置权限

问题三：队友遇到错误停止

解决方法：

• In-process 模式：Shift+Down 查看队友输出，给予额外指令
• Split panes 模式：点击队友窗格直接交互
• 如果无法恢复：Spawn replacement teammate

问题四：孤立 tmux 会话

如果团队异常退出，可能留下孤立的 tmux 会话：

# 列出会话
tmux ls

# 终止特定会话
tmux kill-session -t <session-name>

五、总结

Claude Agent Teams 是 Claude Code 迈向多智能体协作的重要一步。它解决了一个核心问题：让多个 AI 不只是并行工作，而是像真正的团队一样协作。

核心价值：

• 队友间直接通信，不需要绕回主代理
• 共享任务列表实现自我协调
• 适合并行探索、竞争假设、跨层协作

适用场景：

• 研究和审查任务
• 需要多角度调查的问题
• 跨层协调的开发工作

使用建议：

• 从 3-5 个队友开始
• 先用研究和审查任务练手
• 注意令牌成本，及时关闭空闲队友

已知局限：

• 实验性功能，接口可能变化
• 不支持会话恢复
• 每会话一个团队

如果你已经在用 Claude Code，试试用它来做下一次代码审查或问题调查。你会发现，多个 AI 协作的效果，远比单个 AI 重复运行要好得多。

相关资源

Claude Code 官方文档：https://code.claude.com/docs/en/agent-teams

Agent Teams 对比图：https://mintcdn.com/claude-code/nsvRFSDNfpSU5nT7/images/subagents-vs-agent-teams-light.png

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！