我让 2 个手下吵了一架，结果 bug 自己被修好了

Claude Code 前段时间推出的 Agent Teams，并不是对子代理（subagent）的简单升级，而是一次执行模型的重构。

它引入了一种全新的方式：让多个独立的 Claude Code 实例，在同一个项目中协作、通信、共享状态，并围绕任务系统进行协调。

如果你只把它当成“更强的子代理”，那基本会错过它真正的价值。

大纲

• 一、核心变化：从“孤立执行”到“协作系统”

• • 旧模型：子代理（Subagent）

  • 新模型：Agent Teams

• 二、底层机制：五个关键工具

• • 1. TeamCreate

  • 2. TaskCreate

  • 3. Task（升级版）

  • 4. taskUpdate

  • 5. sendMessage（最关键）

• 三、生命周期控制：可控的协作过程

• • 关闭流程：

• 四、Agent Teams 什么时候真正有价值？

• • 典型案例：深度调试

  • 使用子代理的方式：

  • 使用 Agent Teams：

• 五、如何启用 Agent Teams

• • 步骤 1：升级 Claude Code

  • 步骤 2：开启实验功能

  • 步骤 3：触发 Team 模式

• 六、最佳实践：可视化协作过程

• • 使用 tmux

  • 使用 iTerm2（macOS）

• 七、本质总结：Agent Teams 改变了什么？

一、核心变化：从“孤立执行”到“协作系统”

旧模型：子代理（Subagent）

传统模式下的工作流程是：

1. 主代理调用 Task 工具

2. 启动一个子代理

3. 子代理独立执行任务

4. 会话结束

5. 返回一个摘要结果

这个模型的问题很明显：

• 子代理之间完全隔离

• 无法共享上下文

• 没有实时协作

• 更像“并行执行器”，而不是“团队”

---

新模型：Agent Teams

Agent Teams 引入了完全不同的机制：

• 所有代理共享一个任务系统

• 代理之间可以直接通信

• 支持显式生命周期（启动 / 关闭）

• 可以实时协作、讨论甚至相互反驳

这意味着：

多个 Agent 不再是“工具调用”，而是“协作成员”

---

二、底层机制：五个关键工具

Agent Teams 的实现依赖一组新的内部工具，它们共同构成了这个协作系统。

---

1. TeamCreate

用于创建团队结构。

执行后会在本地生成目录：

.claude/teams/<team_id>/

这个目录是整个团队的运行基础。

---

2. TaskCreate

用于创建任务（以 JSON 形式存储）。

每个任务包含：

• 状态（pending / in_progress / completed）

• 所有者（agent）

• 依赖关系

• 执行记录

这与旧的 Task 工具完全不同：

它不只是“触发执行”，而是“任务系统的持久化表示”。

---

3. Task（升级版）

仍然用于启动代理，但现在支持：

• name

• team_name

当传入 team_name 时：

系统会进入 Team 模式，而不是传统子代理模式。

---

4. taskUpdate

代理通过这个工具来：

• 认领任务

• 更新状态

• 标记完成

这使得任务状态成为团队共享的“单一事实源”。

---

5. sendMessage（最关键）

这是 Agent Teams 的核心能力。

支持两种通信方式：

1）点对点消息

一个代理 → 另一个代理

2）广播消息

一个代理 → 全体队友

---

所有消息会被写入：

.claude/teams/<team_id>/inbox/

并以如下形式注入上下文：

<teammate-message teammate_id="...">

这意味着：

代理可以“看到彼此的思考过程”，而不仅仅是结果。

---

三、生命周期控制：可控的协作过程

Agent Teams 支持显式的生命周期管理。

关闭流程：

1. 团队负责人发送：

shutdown_request

1. 各个代理返回：

shutdown_response

1. 所有会话干净结束

---

相比子代理：

• 不再是“自动结束”

• 而是“可控终止”

---

四、Agent Teams 什么时候真正有价值？

并不是所有场景都需要 Agent Teams。

目前最适合的场景是：

多假设、复杂推理、需要协作验证的问题

---

典型案例：深度调试

问题：

应用在接收一条消息后就退出，而不是保持连接

---

使用子代理的方式：

• 启动多个子代理

• 每个给出一个结论

• 主代理整合

问题在于：

• 无法互相验证

• 没有“反驳机制”

• 容易产生错误结论

---

使用 Agent Teams：

创建多个代理：

• Agent A：假设是连接管理问题

• Agent B：怀疑是事件循环问题

• Agent C：检查资源释放

• Agent D：专门反驳其他人

• Agent E：汇总结论

然后：

• 代理之间互相讨论

• 提出证据

• 否定错误假设

• 收敛到一致结论

这种模式本质上接近：

科学研究中的“同行评审 + 交叉验证”

---

五、如何启用 Agent Teams

步骤 1：升级 Claude Code

确保使用最新版本。

---

步骤 2：开启实验功能

编辑配置文件：

~/.claude/settings.json

加入：

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

保存并重启终端。

---

步骤 3：触发 Team 模式

在 prompt 中明确要求创建团队，例如：

我正在设计一个 CLI 工具，用于跟踪代码中的 TODO。
创建一个 Agent 团队：
- 一个负责 UX
- 一个负责技术架构
- 一个负责提出反对意见

关键点在于：

必须显式要求“团队”而不是单个任务

---

六、最佳实践：可视化协作过程

Agent Teams 的价值，在“可观察性”上非常明显。

推荐使用终端分屏工具：

---

使用 tmux

启动：

claude --teammate-mode tmux

效果：

• 每个 Agent 一个 pane

• 实时查看执行过程

• 可手动干预

---

使用 iTerm2（macOS）

配置：

1. 安装 iTerm2

2. 打开设置 → General → Magic

3. 启用 Python API

4. 重启

然后使用同样的命令启动。

---

这种模式下，你可以：

• 同时观察多个 Agent

• 实时看到他们的推理

• 手动给某个 Agent 发消息

---

七、本质总结：Agent Teams 改变了什么？

Agent Teams 的意义不在于：

• 提升一点代码生成能力

• 或者多开几个子任务

而在于：

把 AI 从“执行单元”变成“协作系统”

---

对比可以总结为：

• 子代理：并行执行

• Agent Teams：协作推理

---

它引入了三个关键能力：

1. 共享状态（任务系统）

2. 实时通信（消息机制）

3. 可控生命周期

---

最终带来的变化是：

AI 不再只是回答问题，而是参与问题的“求解过程”

---

如果你只用它来“多开几个任务”，那它的价值只发挥了 10%。

真正的威力，在于：

让多个 Agent 互相挑战彼此的结论，并在冲突中逼近正确答案。

学习更多干货，欢迎关注转发！

---

玩转cpp小项目星球3周年了！