从一个真实的困境说起
假设你让一个 code agent 做这件事：
"帮我把这个 5000 行的 Python 项目全部重构成 async 风格，同时补全单元测试，最后跑一次 CI 验证。"
单个 agent 接到这个任务会怎样？
它会一个文件一个文件地改，改完再去写测试，写完测试再跑 CI。整个过程串行进行，中间还要频繁读文件、写文件、调模型------光是把所有文件都过一遍，可能就要用掉好几万 token，把上下文窗口撑满。
更麻烦的是：重构文件和写测试这两件事，其实可以同时进行。但单个 agent 做不到并行，它只有一个 ReAct 循环，同一时刻只能干一件事。
这就是 AgentTeams 想解决的问题。
结论先说
AgentTeams 是 MyCodeAgent 的一个实验性多 agent 协作系统，它的核心设计思路是：
| 问题 | AgentTeams 的解法 |
|---|---|
| 任务太长，单 agent 上下文装不下 | 把任务拆给多个 agent，每个 agent 只看自己的那份上下文 |
| 需要并行处理多个子任务 | 多个 agent 同时运行，互相独立 |
| 结果需要汇总 | 协调者 agent 收集各子 agent 的输出，合并成最终答案 |
它提供了六个工具：TeamCreate、SendMessage、TeamStatus、TeamDelete、TeamFanout、TeamCollect，支持三种执行模式：in-process（进程内）、tmux（独立终端）、auto（自动选择）。
但这个系统最终被从稳定版本中移除了。理解它为什么被设计出来、又为什么被移除，比单纯学"怎么用"更有价值。
一、多 agent 系统真正难在哪里
很多人第一次听到"多 agent"，会觉得这很简单：不就是多启动几个模型实例嘛？
实际上，一旦你有了多个 agent，就立刻面临一系列在单 agent 里根本不存在的问题：
问题 1：上下文怎么给？
每个 agent 都有自己的上下文窗口。主 agent 不可能把整个对话历史复制一份给每个子 agent------那样上下文会爆炸。所以需要决定：给每个子 agent 多少上下文？哪些部分？格式是什么？
问题 2：结果怎么合并？
子 agent A 改了 utils.py，子 agent B 也改了 utils.py------它们互相不知道对方的存在，改完之后怎么合并？谁来决定哪份更准确？
问题 3：失败怎么处理？
单 agent 失败，就是当前任务失败，重试即可。但如果有 10 个子 agent 并行运行，其中 3 个失败了，怎么办？重跑全部？只重跑失败的？失败的部分对其他 agent 的结果有没有影响？
问题 4：谁来协调？
如果有一个主 agent 负责协调其他 agent，那主 agent 本身就变成了一个复杂的状态机------它需要知道哪些子任务完成了、哪些还在跑、哪些失败了，还要在合适的时机把所有结果合并起来。这个协调逻辑本身就非常复杂。
AgentTeams 的设计，就是在尝试回答这四个问题。
二、AgentTeams 的基本模型
AgentTeams 把多 agent 协作抽象成了一个团队（Team）的概念。
markdown
主 agent（协调者）
│
├── TeamCreate：创建一个团队
│
├── TeamFanout：把任务分发给多个成员
│ │
│ ├── 成员 agent 1 ← 独立运行，有自己的上下文
│ ├── 成员 agent 2 ← 独立运行，有自己的上下文
│ └── 成员 agent 3 ← 独立运行，有自己的上下文
│
├── TeamCollect：等待并收集所有成员的结果
│
└── TeamDelete：任务完成后清理团队每个团队有一个协调者 （通常是创建团队的主 agent）和若干成员（执行子任务的 agent）。成员之间互相独立，不直接通信------所有消息都通过协调者中转。
这个设计解决了"结果怎么合并"的问题：协调者是唯一知道全局状态的角色，由它来决定怎么合并。
成员 agent 的执行模式有三种：
in-process：在同一个 Python 进程里运行，轻量，但不能真正并行（受 GIL 限制）tmux：在独立的 tmux 窗格里运行，真正并行，但启动开销大auto：根据环境自动选择
三、一个具体的使用场景
用前面那个"重构 + 测试"的例子，AgentTeams 的工作流大概是这样的：
markdown
主 agent：
1. 调用 TeamCreate，创建一个团队
2. 扫描项目，把 50 个 Python 文件分成 5 组，每组 10 个
3. 调用 TeamFanout，把 5 个"重构这10个文件"的任务分发给 5 个成员 agent
4. 等待，同时自己开始写集成测试的框架代码
5. 调用 TeamCollect，收集 5 个成员的重构结果
6. 合并结果，处理冲突
7. 跑 CI 验证
8. 调用 TeamDelete，清理团队5 个成员 agent 同时工作，每个只处理 10 个文件，上下文窗口不会被整个项目撑满。主 agent 在等待的同时还能做其他事情。
这个流程在逻辑上是合理的。问题出在实现层面------这也是后面第 19 篇要讲的内容。
四、子 agent 和团队成员的区别
看到这里，你可能会问：这跟之前讲的 Task 子 agent（第 08 篇）有什么区别？
这是一个非常好的问题，答案也很关键：
Task 子 agent（稳定功能）：
- 主 agent 把一个具体任务委托给子 agent
- 子 agent 完成后，把结果返回给主 agent
- 整个过程是同步的：主 agent 等着，子 agent 做完再继续
- 适合"这件事我不擅长，让专家来做"的场景
AgentTeams 成员（实验功能）：
- 主 agent 把同类任务的多个实例分发给多个成员
- 成员并行运行，主 agent 不等它们完成，可以继续做其他事
- 最终由 TeamCollect 统一收集结果
- 适合"同样的事情要做很多次，可以并行做"的场景
简单说：Task 是"你去做，我等你"；AgentTeams 是"你们分头去做，我先干别的，你们做完了告诉我"。
五、为什么这个方向很重要
AgentTeams 虽然最终被移除了，但它代表的方向------多 agent 并行协作------在 AI agent 领域是一个真实且重要的需求。
目前几乎所有成熟的 agent 框架（LangGraph、AutoGen、CrewAI 等）都在尝试解决类似的问题，但解法各不相同：
- 有的用**图（DAG）**来描述 agent 之间的依赖关系
- 有的用角色扮演（role-playing）让不同 agent 扮演不同职位
- 有的用共享黑板（shared blackboard）让 agent 通过一个中央状态通信
AgentTeams 选择的是团队 + 协调者模型，这是最接近人类团队协作方式的设计。
理解了设计动机，下一篇我们来看消息是怎么在 agent 之间传递的------这是整个协作系统的血管。
设计亮点
1. 上下文隔离是第一原则
每个成员 agent 有自己的上下文，不会因为看到太多无关信息而"分心"。这解决了单 agent 做长任务时上下文污染的问题。
2. 协调者是唯一全局视角
成员之间不直接通信，所有协调都通过主 agent 进行。这简化了状态管理------你不需要处理 agent A 和 agent B 互相发消息、互相等待的复杂情况。
3. 三种执行模式对应三种场景
in-process 轻量快速，适合开发测试；tmux 真正并行，适合生产使用；auto 让框架决定，降低使用门槛。
小结
| 问题 | AgentTeams 的回答 |
|---|---|
| 为什么需要多 agent？ | 单 agent 上下文有限、不能并行 |
| 核心抽象是什么？ | 团队（Team）= 协调者 + 多个成员 |
| 成员怎么运行？ | in-process / tmux / auto 三种模式 |
| 和 Task 子 agent 的区别？ | Task 是同步委托，AgentTeams 是并行分发 |
| 最终命运？ | 实验性，已被移出稳定版本（原因见第 19 篇） |
关于本系列的源码
本系列所有分析均基于开源项目 MyCodeAgent。
AgentTeams 的实现代码已从稳定版本移除，保存于 Git 历史（commit f497b172）。你可以通过以下方式查看设计痕迹：docs/research-archive.md、docs/plans/2026-07-12-lean-runtime/tasks/M2-03-remove-agent-teams.md。
bash
git clone https://github.com/chendongqi/MyCodeAgent
cd MyCodeAgent
cp .env.example .env # 填入你的 LLM API key
uv sync
uv run python main.py欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页