Agent 团队：像真实团队一样协作

本章摘要：

Agent Teams 让多个 Agent 持续在线、互相通信——核心是"水平通信"。与协调器模式不同，Agent Teams 不是限制自由度，而是增加协调层——Lead 想亲力亲为时随时可以动手。队友通过文件收件箱通信，权限冒泡让队友没有自己的终端，避免用户在多个 teammate 之间来回切换。

Subagent 系统让 Agent 能把任务拆分给多个子 Agent 并行执行。但子 Agent 有一个根本限制：只能汇报结果，不能持续对话。叫来、干完、走人——像临时工。这带来了几个核心问题：

• 信息漏斗，多次传递导致信息丢失： Subagents 之间是“老死不相往来”的。它们只能单线向主代理汇报，无法互相沟通对齐，效率极低，信息容易被过滤，不同 agent 之间容易产生认知冲突而"左右互搏"。

• 上下文污染与能力受限： 因为 Subagents 依然高度依附于主会话的生命周期和逻辑，随着主会话越来越长，单模型同时承担研究、架构、编码、测试等多个角色，注意力被严重分散，输出质量随上下文膨胀而剧烈下滑。

Agent Teams 的推出让多个 Agent 不仅能并行工作，还能互相通信、共享状态、协调行动。它解决的是同一个 Agent 难以同时承担多个并行视角的协作问题。

子 Agent 与队友：两种并行模式

	子 Agent	队友（Teammate）
生命周期	一次性，任务完成即销毁	持续在线，空闲时等待而不是退出
通信方式	只回传最终结果	随时通过邮箱收发消息
角色关系	主 Agent 的下属	Lead 的平级队友（可以互发消息）
典型场景	"帮我查一下这个文件"	"我们三个一起审查这个 PR"

子 Agent 适合"调完就忘"的委托任务，队友适合需要持续协调的协作任务。

团队如何被创建

Lead 决定"用多个 Agent 一起做这件事"时，会调用一个团队创建工具。这个工具做三件事：

1. 写入团队配置文件（记录团队名称、Lead 标识、初始成员列表）
2. 创建任务目录（初始化共享任务看板）
3. 更新运行时状态（在内存中记录团队信息）

这三步都是后台操作，对 LLM 来说不可见。LLM 能看到的是工具返回的 JSON 结果——这条结果作为消息注入到 Lead 的对话历史中，成为 Lead"知道自己创建了团队"的唯一线索。

接下来 Lead 创建队友——生成唯一名字避免重名、创建独立执行上下文、在队友的系统提示词末尾追加通信协议：

重要提示：你正在作为团队中的 Agent 运行。要与团队中的任何人通信：
- 使用 SendMessage 工具，设置 to: "<队友名称>" 向特定队友发送消息
- 使用 SendMessage 工具，设置 to: "*" 谨慎地进行团队广播

直接输出文本回复对团队中的其他人是不可见的——你必须使用 SendMessage 工具。

如果队友不知道自己在团队中，它会像普通 Agent 一样直接输出文本——但这些文本对其他队友是不可见的。通信协议的存在是队友获得"团队成员"身份的关键。

一个精巧的设计

Lead 的系统提示词始终不变，所有关于团队的认知都只来源于工具调用。

Lead 不需要被"告知"自己是团队管理者——它通过工具的 description 获得工作流程指导，通过工具执行结果获得团队状态，通过邮箱消息感知队友动态。工具本身就是最好的指导。

这与协调器模式完全不同——协调器会替换系统提示词并缩减工具集，而 Agent Teams 只是在原有基础上增加协调层。Lead 想亲力亲为时随时可以动手。

团队的四大组件

一个 Agent Team 由四个核心组件构成（所有内容都会持久化到本地文件系统）：

• Lead（队长）是用户对话的主线程，负责创建团队、分配任务、综合结果
• Teammates（队友）是独立的实例，各有自己的上下文窗口和工具集
• 共享任务列表让所有 Agent 看到同一份任务看板
• 邮箱系统是 Agent 之间的异步通信通道

文件邮箱：为什么不用内存队列

团队通信的核心是邮箱系统。所有 Agent 有一个收件箱文件，发送消息就是往对方的文件里追加一条 JSON 记录，接收消息就是读取并清空自己的文件。

这个设计看起来很原始——为什么不用内存中的消息队列？

答案在于跨进程通信。Agent Teams 支持队友运行在独立的终端分屏中（不同进程），内存队列无法跨进程共享，而文件系统是所有进程都能访问的自然共享层。

但文件系统有并发问题——两个 Agent 同时写入同一个收件箱时，可能出现数据丢失。解决方案是加锁：每次写入前获取文件锁，"读取 → 追加 → 写回"在锁的保护下保持原子性。

消息有结构化分类

邮箱里不只是普通文本消息，团队协议定义了多种结构化消息类型：

• 通信类：队友之间的日常对话
• 生命周期类：队友完成一轮工作后通知 Lead "我闲了"、关机握手协议（"你可以休息了"，"好的，那我去休息"，"我还没搞定，还不能休息"）
• 权限类：请求网络访问，请求权限变更等，队友的权限请求统一冒泡到 Lead
• 任务类：Lead 分配任务给队友

每种消息都有结构验证，通过 <teammate-message> 标签包装后注入到 Agent 的对话历史中。

队友的生命周期

一个队友从创建到退出，经历四个阶段：

Spawn（创建）
  │  写入 team config
  │  创建独立上下文
  │
Work（工作）
  │  执行 Lead 分配的任务
  │  每 1 秒检查收件箱，有消息就提交为新的对话轮次
  │
Idle（空闲）
  │  LLM 返回非工具调用 → 说明任务结束 → 发送 Idle 通知给 Lead
  │  不退出，而是轮询收件箱等待新消息
  │
Shutdown（关机）
  Lead 发关机请求 → 队友确认收尾 → 同意关机
  系统清理窗格、移除任务、从配置中删除成员

关键设计是 idle 状态。子 Agent 完成任务就销毁，但队友不会——它进入 idle 状态，停止主动执行，但保持收件箱监听。Lead 随时可以通过邮箱给它发送新任务，队友收到消息后被重新激活，继续工作。

这个"停止-恢复"模式的设计动机是资源经济性。如果 Lead 发现某个队友的调研结果还需要补充，直接给该队友追加指令即可——队友在已有上下文的基础上继续分析，不需要从头开始，比重新创建一个子 Agent 节省大量 token。

权限冒泡：队友没有自己的终端

Agent Teams 不允许队友直接弹窗向用户确认权限（否则用户需要在多个 teammate 之间来回切换），而是采用权限冒泡——把权限请求从队友"冒泡"到 Lead 的终端，用户只需关注一个交互入口。

队友遇到需要审批的操作
  ↓
发送权限请求到 Lead 的收件箱
  ↓
Lead 的收件箱轮询器检测到请求
  ↓
在 Lead 的终端显示审批对话框
  ↓
用户审批 → Lead 发送响应回队友

整个流程的设计哲学是**"单一交互入口"**——无论团队里有几个队友，用户始终只面对 Lead 一个终端。这避免了"在多个 teammate 之间来回切换"的认知负担。

实践中可以通过预配置权限白名单来减少冒泡次数——预先批准常见操作，队友就不必频繁请求审批。

共享任务列表

团队的第四个组件是共享任务列表。任务有三种状态：待认领、进行中、已完成。任务的认领有两种方式：

• Lead 分配：Lead 明确指定"这个任务给 Alice"
• 队友自认领：空闲的队友查看任务看板，找到未分配、未阻塞的任务，自己认领

自认领使用文件锁防止竞争条件——如果 Alice 和 Bob 同时尝试认领同一个任务，只有一个会成功。

与协调器模式的对比

两种模式解决的是不同问题，不要混用。

Agent Teams 和协调器模式都涉及多 Agent，但设计哲学截然相反：

维度	Agent Teams	协调器模式
架构形态	相对平等的网状协作	严格的上下级层级
信息流动	队友之间可以直接通信、互相质询	Worker 彼此孤立，只能向协调器单线汇报
执行者生命周期	持续在线，idle 时等待新任务	一次性，任务完成即销毁
系统提示词	Lead 不变，队友追加通信协议	完全替换为协调器专用提示词
工具集	不缩减	缩减为 4 个

核心区别是"增加协调层" vs "限制自由度"：

• Agent Teams 是增加协调层：Lead 保持完整能力，只是在原有基础上增加了团队管理工具和通信协议
• 协调器模式是限制自由度：剥夺 Lead 的所有执行能力，迫使它专注于综合和编排

选择依据

选 Agent Teams：

• 跨模块并行开发：前端、后端、测试三个模块同时开发，各自有独立上下文
• 多假设发散性探索：怀疑三个地方导致内存泄漏，3 个队友各自排查一个方向
• 大规模重复性并行任务：为几十个模块补写测试

选协调器模式：

• 强顺序依赖的任务：步骤 B 极度依赖步骤 A 的结果
• 动态决策多且需要强审计：每一步都需根据上一步结果重新规划路线

代价与限制

Agent Teams 目前仍处于实验阶段，会带来一些限制：

Token 成本线性增长。每个队友是一个独立的实例，有自己的上下文窗口，3 个队友意味着 3 倍的 token 消耗。对于研究、审查等需要多视角的任务，额外成本通常值得；对于简单任务，单个会话或子 Agent 更经济。

不能嵌套。队友不能再创建自己的团队或队友，只有 Lead 能管理团队。这避免了递归爆炸。

Lead 不可替换。创建团队的会话就是 Lead，整个团队生命周期内固定不变。

文件冲突。两个队友编辑同一个文件会导致覆盖。任务分配时需要确保每个队友操作不同的文件集。

上下文压缩后的团队认知丢失。Lead 的团队认知依赖对话历史中的工具执行结果和邮箱消息。当对话过长触发上下文压缩时，这些信息被摘要化——如果队友恰好沉默，Lead 可能"忘记"自己在管理一个团队。

通往 AGI 的一步

多 Agent 协作是 AGI 路径上的关键一步——不是因为技术酷，而是因为现实任务本身就是分布式的、需要多视角的、需要持续协调的。

Agent Teams 探索了"水平协作"的模式：多个 Agent 像团队成员一样持续在线、互相通信、共同推进一个目标。这种模式比"一个超级 Agent 包打天下"更接近现实中的工作方式——我们人类解决问题时，也很少一个人单干，而是组成团队、分工协作、随时对齐。

从这个角度看，Agent Teams 不只是一个工程优化，它代表了 Agent 系统设计的一种新范式——从"一个强大的 Agent"走向"一群协作的 Agent"，从"任务执行单元"走向"工作团队"。