当一个代码智能体面对大规模重构任务时，最常见的瓶颈不是模型能力，而是执行方式。开源项目 MyCodeAgent 曾尝试用一套名为 AgentTeams 的多智能体协作机制解决这个问题：让一个主 Agent 创建团队、分发子任务、等待并收集结果，再统一合并与验证。该机制最终被从稳定版本移除，但它留下的设计思路，仍指向了 AI 编程工具走向复杂工程任务时必须面对的问题。
从串行执行到并行协作：多 Agent 要解决什么问题
素材给出的典型场景是：让一个 Code Agent 把一个 5000 行的 Python 项目全部重构成 async 风格，同时补全单元测试，并运行一次 CI 验证。如果由单个 Agent 处理，它通常只能按顺序执行：逐个文件修改，再写测试，最后跑 CI。整个过程是串行的，中间还需要频繁读取文件、写入文件、调用模型。仅把所有文件过一遍，就可能消耗数万 token，并撑满上下文窗口。
更关键的是，重构文件和编写测试这两项工作在逻辑上可以同时推进，但单个 Agent 只有一个 ReAct 循环，同一时刻只能处理一件事。AgentTeams 正是针对这种限制设计的实验性多 Agent 协作系统。它提供了六个工具：TeamCreate、SendMessage、TeamStatus、TeamDelete、TeamFanout 和 TeamCollect，并支持三种执行模式：in-process、tmux 和 auto。
团队协作模型：任务拆分、并行执行、状态同步与结果合并
AgentTeams 把多 Agent 协作抽象成一个“团队”。团队由一个协调者和若干成员组成。协调者通常是创建团队的主 Agent，成员则是执行子任务的独立 Agent。成员之间不直接通信，所有消息都通过协调者中转。
在素材给出的流程示例中，主 Agent 会先调用 TeamCreate 创建团队，然后扫描项目，把 50 个 Python 文件分成 5 组，每组 10 个。随后，主 Agent 通过 TeamFanout 将 5 个“重构这 10 个文件”的任务分发给 5 个成员 Agent。每个成员 Agent 独立运行，拥有自己的上下文，只处理分配到的文件。主 Agent 在等待期间还可以继续完成其他工作，例如编写集成测试框架代码。
- TeamCreate：创建团队
- TeamFanout：把任务分发给多个成员
- TeamCollect：等待并收集所有成员的结果
- TeamDelete：任务完成后清理团队
- SendMessage、TeamStatus：用于消息传递和状态查询
当所有成员完成后，主 Agent 调用 TeamCollect 收集结果，随后进行合并、处理冲突，再运行 CI 验证，最后调用 TeamDelete 清理团队。这个结构把任务分解、并行执行、状态同步和结果合并放进了一个以协调者为中心的流程中。
多 Agent 不是简单多开模型，四类问题随之出现
素材指出，多 Agent 系统一旦引入，就会产生单 Agent 场景下不存在的问题。第一是上下文如何分配。每个成员 Agent 都有自己的上下文窗口，主 Agent 不能把完整对话历史复制给每个子 Agent，否则上下文会迅速膨胀。系统需要决定给每个子 Agent 多少上下文、哪些内容、以及以什么格式传递。
第二是结果如何合并。如果两个子 Agent 同时修改同一个文件，例如 utils.py，它们彼此并不知道对方的存在，完成后就需要由协调者判断如何合并，以及哪份结果更可用。
第三是失败如何处理。单 Agent 失败时可以重试当前任务；但如果多个子 Agent 并行运行，其中部分失败，就需要判断是重跑全部、只重跑失败部分，还是评估失败结果对其他成员输出的影响。
第四是谁来协调。如果由主 Agent 负责协调，它就必须掌握哪些子任务已完成、哪些仍在运行、哪些失败，并在合适时机合并结果。协调逻辑本身会变成一个复杂的状态机。
实验性方案被移除，但方向仍然重要
AgentTeams 的设计强调三点：上下文隔离、协调者拥有全局视角、不同执行模式对应不同场景。每个成员 Agent 保持独立上下文，可以减少无关信息干扰，缓解单 Agent 长任务中的上下文污染问题；成员之间不直接通信，则简化了状态管理；in-process 适合开发测试，tmux 更接近真正的并行运行，auto 则交由框架选择。
素材同时说明，AgentTeams 与稳定版本中的 Task 子 Agent 并不相同。Task 子 Agent 更接近“你去做，我等你”的模式；AgentTeams 则是“你们分头去做，我先干别的，你们做完了告诉我”。前者偏同步委派，后者偏并行协作。
不过，该系统的实现代码已从 MyCodeAgent 稳定版本移除，仅保存在 Git 历史中，对应 commit f497b172。设计痕迹可在 docs/research-archive.md 和 docs/plans/2026-07-12-lean-runtime/tasks/M2-03-remove-agent-teams.md 中查看。素材认为，理解它为什么被设计出来，又为什么被移除，比单纯学习工具用法更有价值。
从行业角度看，多 Agent 并行协作并不是一个新概念。LangGraph、AutoGen、CrewAI 等框架也在尝试解决类似问题，只是路径不同。AgentTeams 选择的是“团队 + 协调者”模型，更接近人类团队中的分工方式。它的退场说明多 Agent 系统在工程实现上仍有复杂度，但它提出的问题——任务如何拆分、上下文如何隔离、结果如何合并、失败如何恢复——仍然是 AI 编程工具走向大型工程任务时绕不开的基础问题。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dan-ge-agent-bu-gou-yong-de-shi-hou-chai-jie-mycodeagent
