Claude Code 新功能：一个人指挥一支 AI 「施工队」
最近 Claude Code 随着 Opus 4.6 一起上线了个实验性功能：Agent Teams。
试用了一下，感觉有点像从「单打独斗」升级到了「团队作战」。
它能干啥？
简单说，就是让多个 Claude 同时干活。
以前是你跟一个 Claude 对话，它帮你写代码。现在你可以组建一支「AI 施工队」，每个成员负责不同的活儿，同时开工。
比如你要审查一个 Pull Request：
传统方式： 一个 Claude 从头看到尾，可能会关注性能问题，也可能关注安全问题，但很难同时兼顾所有角度。
Agent Teams 方式： 直接说一句「创建一个团队审查这个 PR」，然后 Claude 会：
- 生成一个专看安全问题的成员
- 生成一个专看性能问题的成员
- 生成一个专看测试覆盖率的成员
三个 Claude 各司其职，同时审查，最后把发现汇总给你。
跟普通的「分身术」有什么不同？
Claude Code 之前就有 subagents（子代理）功能，但那更像是「打工仔」——干完活只能向老板汇报，相互之间不能交流。
Agent Teams 不一样：
| 对比项 | Subagents | Agent Teams |
|---|---|---|
| 通信 | 只能向主 Agent 报告 | 成员之间可以直接对话 |
| 上下文 | 共享同一个上下文窗口 | 每个成员有独立的上下文 |
| 协作 | 不能互相配合 | 可以挑战彼此的结论 |
| 控制 | 只能通过主 Agent 管理 | 你可以直接跟任何成员对话 |
用人话说：subagents 是「临时工」，Agent Teams 是「项目团队」。
怎么用？
功能默认是关闭的，需要手动开启。
方法1：设置环境变量
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
方法2：改配置文件
在 settings.json 里加上：
{
"experimental": {
"agentTeams": true
}
}
开启之后，用自然语言告诉 Claude 你想干什么就行。
示例提示词：
我要重构认证模块。创建一个 Agent Team：
- 一个成员负责重构代码
- 一个成员负责更新测试
- 一个成员负责检查安全漏洞
Claude 会自动生成团队、分配任务、协调工作。
它适合做什么？
根据官方文档和开发者反馈，这些场景特别合适：
1. 代码审查 一个人审查容易只关注某一类问题。三个 Claude 从不同角度看，能发现更多问题。
2. 调试复杂 Bug 让几个成员并行测试不同的假设，比单线程「试了这个不行再试那个」快得多。
3. 多模块开发 比如你要做一个功能，涉及前端、后端、数据库。每个成员负责一块，互不干扰。
4. 研究和探索 比如「帮我调研三个 OAuth 方案」，让三个成员分别研究 Google、GitHub、Auth0，最后对比结果。
哪些情况别用？
❌ 顺序任务 - 比如「先分析需求，再写代码，再写文档」，这种前后依赖的活儿，单 Agent 更合适。
❌ 改同一个文件 - 两个成员同时改一个文件会互相覆盖，容易出问题。
❌ 简单任务 - 「帮我改个变量名」这种事儿，开团队就是杀鸡用牛刀，token 成本不划算。
成本问题
每个成员都有独立的上下文窗口，意味着 token 用量会成倍增长。
数据对比：
- 单 Agent：通常用掉 80-90% 的上下文窗口
- Team 模式：每个成员约用 40% 上下文窗口，但成员数量多
什么时候值得： ✅ 研究、审查、新功能开发 - 并行探索带来的价值超过成本 ❌ 日常任务 - 还是单 Agent 更经济
实战技巧
1. 新手从「只读任务」开始 第一次用建议先试审查代码、调研资料这种不写代码的任务，降低翻车风险。
2. 任务边界要清晰 确保每个成员负责不同的文件或模块，别让他们打架。
3. 定期检查进度 别让团队跑太久不管，有时候方向错了要及时纠正。
4. 清理要规范 用完之后告诉主 Agent「关闭所有成员，清理团队」，别留下孤儿进程。
真实案例：用 16 个 Claude 写了个 C 编译器
Anthropic 官方拿这个功能做了个压力测试：用 16 个并行 Agent 从零写一个 C 编译器。
项目数据：
- 16 个 Agent 并行工作
- 近 2000 个 Claude Code 会话
- API 成本：$20,000
- 产出：10 万行 Rust 代码
- 能力：可以编译 Linux 6.9 内核
他们怎么做的：
- Git worktrees 隔离 - 每个 Agent 在独立分支干活，测试通过才合并
- 任务锁定机制 - 防止两个 Agent 重复做同一件事
- 持续集成 - 自动化测试确保新代码不破坏旧功能
- 上下文管理 - 维护详细的 README 和进度文件，新 Agent 启动时能快速定位
经验教训：
- 完全无人监督风险很大，人类定期检查很重要
- 测试报告要为 AI 优化，不是为人类
- 上下文管理是成败关键
显示模式选择
运行 Agent Team 有两种模式：
In-process（默认）
- 所有成员在一个终端里跑
- 用 Shift+上下箭头切换成员
- 兼容所有终端
Split-pane（分屏）
- 每个成员占一个窗格，同时看所有输出
- 需要 tmux 或 iTerm2
- 看起来更酷，但不是必需的
新手建议先用默认模式，熟悉之后再折腾分屏。
生态发展
这个功能刚出，已经有一些有意思的动向：
1. GitHub Agent HQ 集成 最新消息（2026年2月），GitHub 现在支持在仓库里直接用 Claude、Codex、Copilot 做 Agent。你可以把 Issue 同时分配给三个 Agent，对比结果。
2. 第三方工具面临挑战 之前有些第三方做多 Agent 编排的工具，现在官方原生支持了，他们需要重新定位。
3. 社区分享 已经有开发者在 Reddit 和 GitHub 上分享自己的 Agent 配置和工作流，生态正在快速成长。
行业趋势
Gartner 的数据挺有意思：
从 2024 Q1 到 2025 Q2，关于多 Agent 系统的咨询量激增了 1,445%。
他们预测到 2026 年底，40% 的企业应用会包含特定任务的 AI Agent。
这不是科幻，而是正在发生的事情。
我的看法
Agent Teams 不是万能药，但确实打开了一些新可能。
以前遇到复杂任务，要么自己拆解成小任务逐个完成，要么写个脚本自动化。现在多了个选项：组个 AI 团队并行处理。
值得尝试的点：
- 多角度审查代码
- 并行调试复杂问题
- 对比不同技术方案
需要注意的点：
- Token 成本会增加
- 任务拆解要合理
- 不是所有事情都需要团队
核心还是那句话：工具是死的，关键看怎么用。
使用建议：
如果你已经在用 Claude Code，可以试试这个功能：
- 从简单的代码审查开始
- 观察不同成员的协作效果
- 总结什么场景值得开团队
- 逐步扩展到更复杂的任务
如果还没用过 Claude Code，建议先熟悉单 Agent 工作流，再考虑 Agent Teams。
一步一步来，别急。
毕竟，工具再好，也得配合你的节奏才能发挥价值。
