论文阅读：Evolve as a Team——面向 LLM 多智能体系统的协作式自进化
论文标题：Evolve as a Team: Collaborative Self-Evolution for LLM-based Multi-Agent Systems
作者：Zhezheng Hao, Tianfu Wang, Huanshuo Dong, Ziyan Liu, Hong Wang, Xiankun Lin, Qiang Lin, Can Wang, Hande Dong, Jiawei Chen
发表位置：arXiv preprint
arXiv 编号：2605.29790v1
原文链接：https://arxiv.org/abs/2605.29790
代码链接：https://github.com/zz-haooo/Meta-Team
主题：LLM 多智能体系统、经验驱动自进化、失败归因、协作反思
核心问题：多智能体系统在执行复杂长程任务后，如何利用自身分布式执行经验，可靠地改进个体行为、智能体交互和团队组织。
1. 论文要解决什么问题？
近年来，基于大语言模型的智能体已经被用于软件工程、网页任务、工具调用和开放式研究等长程任务。但单智能体系统在这类任务中会遇到两个主要瓶颈：一是上下文窗口有限，难以承载长任务中累积的大量信息；二是长程推理和操作会给单个智能体带来很重的认知负担。
多智能体系统（MAS）试图通过“分而治之”缓解这个问题：把任务拆成多个子任务，让不同智能体承担不同角色，并通过通信、交接和协作完成整体任务。例如，一个软件修复任务可以被拆成规划、开发、审查等角色；一个网页研究任务可以被拆成搜索、整理、验证、汇总等角色。
但论文指出，MAS 本身也不是天然可靠的。实际执行中经常会出现多种失败模式，例如：
- 智能体之间传递的信息不完整或不准确；
- 某个智能体偏离了自己的角色；
- 一个早期小错误在后续交接中被放大，形成级联失败；
- 团队结构、角色分工或共享规则本身不适合当前任务。
这些问题往往只有在真实执行之后才暴露出来，不能完全靠设计阶段的 prompt、工作流和规则提前消除。因此，论文关注的是一种“经验驱动的 MAS 自进化”：系统在完成任务后，根据自己的执行轨迹、通信记录和最终结果，自动总结哪里需要改进，并把改进固化到后续任务中。
2. 现有 MAS 进化方法的核心瓶颈
论文把已有的自动 MAS 生成与进化方法大致分成几类。
第一类是性能驱动的方法。它们把 MAS 看成一个可搜索的配置空间，例如搜索 prompt、模块、工作流或通信图，然后根据最终任务得分选择更好的配置。这类方法的问题是反馈比较粗粒度：最终得分只能说明结果好坏，但很难说明具体是哪一步、哪个角色或哪种协作方式出了问题。
第二类是记忆驱动的方法。它们把历史轨迹、交互片段或成功经验存起来，在新任务中检索复用。这类方法能利用历史经验，但同样不一定能解释失败原因，也不一定能把经验转化成有针对性的系统改进。
第三类是集中式分析器方法。它们让一个中心 LLM 分析整个多智能体执行轨迹，找出失败点，并提出修改建议。论文认为，这种方法看似有全局视野，但存在一个结构性矛盾：MAS 在执行阶段之所以有效，是因为它把任务信息分散到多个智能体局部上下文中；而集中式进化却把所有人的执行轨迹重新压平成一个超长上下文，交给单个分析器处理。这相当于在进化阶段重新引入了单智能体长上下文瓶颈。
论文把这个矛盾称为 MAS 经验驱动进化中的“架构不匹配”：执行是分布式的，进化却是集中式的。
3. 预备定义：MAS 与经验驱动自进化
论文先形式化了一个 LLM 多智能体系统。一个 MAS 可以写作：
M = (A, O)
其中，A 是智能体集合，O 是编排机制。每个智能体包含一个基础 LLM 和自己的 agent scaffold，也就是角色说明、任务策略、工具和记忆机制等。编排机制 O 又可以拆成两部分：
O = (P, S)
其中，P 表示智能体之间的交互协议，例如什么时候通信、如何交接中间结果；S 表示团队级共享 scaffold，例如团队成员表、组织结构和全局协作规则。
一次任务执行产生的经验可以写作：
e = (x, τ, r)
其中，x 是任务，τ 是多智能体轨迹，r 是最终结果或评估分数。关键在于，多智能体轨迹不是一条单线执行链，而是多个智能体局部执行链、消息传递和共享产物交织而成的复杂结构。
论文将完整轨迹写成：
τ = Interleave(τ1, ..., τN, B)
其中，τi 是第 i 个智能体的局部执行链，B 是跨智能体事件，例如消息、交接和共享文件。这个定义说明，MAS 经验天然具有分布式结构：每个智能体都掌握一部分局部上下文，而完整结果又依赖这些局部上下文之间的交互。
4. 从 Global / Local 到 Collaborative：为什么要“像团队一样进化”
论文在方法部分先比较了三种组织 MAS 执行经验的方式。
| 方案 | 做法 | 优点 | 问题 |
|---|---|---|---|
| Global Scheme | 把完整团队轨迹压平成一个上下文，交给单个分析器 | 有全局视野 | 长轨迹下上下文和推理负担过重 |
| Local Scheme | 每个智能体只分析自己的局部轨迹 | 减少单个分析器负担，保留局部细节 | 缺少跨智能体视角，难以判断局部行为如何影响整体结果 |
| Collaborative Scheme | 每个智能体保留自己的局部执行上下文，同时通过事后通信交换证据 | 同时保留局部细节和跨智能体意识 | 需要设计协作式反思与更新机制 |
【Figure 1。该图左侧对比 Global、Local、Collaborative 三种经验组织方式，右侧给出失败归因实验中 Agent Accuracy 和 Step Accuracy 的对比。】
论文用 TraceElephant 失败归因基准验证了这个判断。该基准包含真实 MAS 失败轨迹，目标是识别出导致失败的智能体和关键步骤。结果显示：
| 轨迹长度 | 方案 | Agent Accuracy | Step Accuracy |
|---|---|---|---|
| ≤128K | Global | 72.5 | 43.3 |
| ≤128K | Local | 64.1 | 35.0 |
| ≤128K | Collaborative | 77.5 | 45.0 |
| >128K | Global | 43.1 | 9.8 |
| >128K | Local | 58.2 | 17.6 |
| >128K | Collaborative | 60.8 | 19.6 |
这个实验有一个重要前提：所有轨迹都在基础 LLM 的 1M token 上下文限制内，因此 Global Scheme 的性能下降不是因为轨迹被截断，而是因为长程交错轨迹本身给单个分析器带来了严重的理解和归因负担。
论文由此提出核心原则：MAS 不仅应该像团队一样执行任务，也应该像团队一样进化。也就是说，进化阶段不应该把所有经验压给一个中心分析器，而应该让执行过任务的智能体带着自己的局部上下文参与反思，并通过沟通补齐跨智能体证据。
5. Meta-Team：多尺度协作式自进化框架
基于上述原则，论文提出了 Meta-Team。它的核心思想是：每次任务结束后，团队保留各个智能体的局部执行上下文，让智能体通过事后沟通交换证据，然后把这些证据转化成三个层级的可复用改进：
- 智能体层面的行为改进；
- 交互层面的协作改进；
- 团队层面的组织和规则改进。
【Figure 2。该图展示 Meta-Team 从任务执行到 Agent-Level、Interaction-Level、Team-Level 三个演化阶段的整体流程。】
5.1 Agent-Level Evolution：改进单个智能体的行为 scaffold
在智能体层级，Meta-Team 的目标是更新某个智能体自己的 scaffold。这里的关键点是：虽然更新发生在单个智能体身上，但更新依据并不只来自它自己的局部轨迹。
每个智能体会回顾自己的执行链，检查自己在任务中观察了什么、判断了什么、输出了什么、遗漏了什么。同时，它还会主动从其他智能体那里获取证据，确认自己的中间产物是否影响了后续执行。例如，一个 Planner 给出的任务拆解是否让 Developer 误解了修复范围；一个 Reviewer 的验证意见是否真正帮助发现了问题；一个搜索智能体提供的信息是否让汇总智能体做出了错误结论。
因此，Agent-Level Evolution 不是简单的“自我反思”，而是带有跨智能体反馈的个体行为修正。它可以更新智能体未来应该注意什么、验证什么、报告什么，以及避免什么。
5.2 Interaction-Level Evolution：改进智能体之间的协作方式
在交互层级，Meta-Team 关注的是智能体之间的信息流和依赖关系。论文没有把重点放在优化一个二值通信图上，而是引入 teammate profiles，即“队友画像”。
队友画像记录的是一个智能体如何理解、查询和依赖另一个智能体。比如，某个智能体擅长做代码修改但不擅长范围判断，另一个智能体擅长审查 diff 但需要更明确的测试指令。通过更新这些画像，系统可以让智能体在后续任务中更准确地知道什么时候该联系谁、应该问什么、应该怎样解释自己的中间结果。
这种设计针对的是 MAS 中常见的协作问题：失败不一定来自某个智能体能力不足，也可能来自交接方式不清楚、信任边界不明确或信息传递粒度不合适。
5.3 Team-Level Evolution：改进团队组织与共享规则
在团队层级，Meta-Team 更新的是共享团队 scaffold，包括候选成员池、团队组织结构和 team constitution。这里的 constitution 可以理解为所有成员都可见的全局规则，它规定共同目标、协作原则和决策规则。
团队层级演化会根据多个智能体的观察，判断当前团队是否存在系统性问题。例如：
- 是否缺少某种角色；
- 是否有冗余角色；
- 是否需要调整组织结构；
- 是否需要改变谁负责决策、谁负责验证、谁负责汇总；
- 是否需要修改共享协作规则。
这个层级的意义在于，很多 MAS 失败不是单个智能体的小错误，而是团队结构本身不合适。只更新个体 prompt 或局部交互，不一定能解决组织级问题。
6. Meta-Team 的实现流程
论文附录给出了 Meta-Team 的紧凑实现流程。Meta-Team 使用开放成员池机制：系统维护一个候选智能体池，每个任务运行时从池中动态招募活跃成员。共享团队 scaffold 包含候选成员表和 team constitution。
每个智能体以可编辑目录的形式存在，其中角色 prompt、模型配置、允许工具、行为补丁、队友画像、协作笔记等都可以被更新。执行过程中，系统记录每个智能体的局部轨迹，也记录跨智能体消息、交接和共享产物。
任务结束后，Meta-Team 进行三层更新：
| 层级 | 输入 | 更新对象 | 作用 |
|---|---|---|---|
| L1 Agent-Level | 智能体局部轨迹 + 相关跨智能体证据 | 行为补丁、技能、个体 scaffold | 改进行为习惯和任务策略 |
| L2 Interaction-Level | 发生过交互的智能体对及其通信历史 | 队友画像、协作笔记 | 改进信息流、依赖关系和交接方式 |
| L3 Team-Level | 前两层摘要和选定证据 | 团队 constitution、组织规则、候选成员池 | 改进团队结构和共享协调机制 |
一个重要实现点是：Meta-Team 避免把完整轨迹发送给一个中心分析器。它保留局部轨迹，只交换与归因和更新相关的证据，并在团队层面使用简短摘要和选定证据来做组织级修订。提交更新前，系统还会检查角色一致性、工具可用性、格式有效性和预算约束。
7. 实验设置
论文在六类长程智能体基准上评估 Meta-Team：
| 基准 | 任务类型 |
|---|---|
| SWE-bench Pro | 真实软件工程任务，包括多文件 bug 修复或功能实现 |
| BeyondSWE | 超越单仓库 bug 修复的软件工程任务 |
| LOCA-Bench | 长上下文生产力助手任务，包含 MCP 风格工具 |
| GAIA | 多步开放网页推理 |
| LoCoBench | 长上下文、仓库级代码任务 |
| ResearchRubrics | 开放式研究评估任务 |
对比方法包括三类：
- 手工设计的单智能体或多智能体系统，例如 SA、MAS、AggAgent、OWL、AOrchestra；
- 性能驱动搜索方法，例如 AgentSquare；
- 经验驱动 MAS 进化方法，例如 ReCreate、AgentNet、MASFly。
实验中，进化方法只使用每个基准中保留的 evolution set 进行进化，然后在不重叠的 held-out evaluation split 上评估。除非特别说明，基础模型使用 Claude Sonnet 4.6，结果以 avg@3 报告。
8. 主实验结果
论文的主结果显示，Meta-Team 在所有评估列上都取得了最高结果。
| Method | SWE-Pro Ansible | SWE-Pro Qute. | BeyondSWE DepMig. | BeyondSWE CrossR. | LOCA Val | GAIA Val | LoCo Feat. | LoCo Refact. | ResRub. All | Avg. |
|---|---|---|---|---|---|---|---|---|---|---|
| SA | 44.7 | 62.7 | 43.5 | 41.7 | 78.3 | 70.0 | 64.5 | 62.0 | 43.9 | 56.8 |
| MAS | 40.8 | 61.0 | 37.6 | 40.4 | 82.1 | 74.7 | 57.6 | 60.9 | 49.5 | 56.1 |
| AggAgent | 49.6 | 57.7 | 42.8 | 40.6 | 80.4 | 70.3 | 60.2 | 54.7 | 47.2 | 55.9 |
| OWL | 39.5 | 60.1 | 36.7 | 36.9 | 72.9 | 64.0 | 53.8 | 56.2 | 47.9 | 52.0 |
| AOrchestra | 44.7 | 54.0 | 44.1 | 42.0 | 82.9 | 73.3 | 62.0 | 65.5 | 51.5 | 57.8 |
| AgentSquare | 39.0 | 56.3 | 38.4 | 37.4 | 68.3 | 65.0 | 56.2 | 55.9 | 41.9 | 50.9 |
| ReCreate | 42.5 | 59.6 | 41.6 | 39.1 | 74.6 | 69.0 | 58.9 | 62.0 | 45.9 | 54.8 |
| AgentNet | 40.8 | 58.7 | 44.3 | 39.6 | 69.6 | 67.3 | 57.0 | 56.9 | 40.3 | 52.7 |
| MASFly | 43.4 | 62.9 | 39.7 | 39.4 | 75.8 | 71.0 | 60.1 | 64.5 | 50.8 | 56.4 |
| Meta-Team | 53.9 | 66.2 | 45.6 | 43.3 | 87.9 | 77.3 | 67.1 | 67.0 | 55.8 | 62.7 |
有几个结果值得按论文逻辑理解。
首先，初始手工 MAS 并不总是强于单智能体 SA。表中 MAS 在 9 个评估列中的 6 个低于 SA，说明“把系统做成多智能体”本身并不自动带来收益。如果团队组织、角色分工或交互方式不合适，多智能体反而可能引入额外协作成本。
其次，Meta-Team 相对初始 MAS 的平均提升是 6.6 分，相对最强 MAS 进化基线 MASFly 的平均提升是 6.3 分。这说明论文的重点不是“使用历史经验”本身，而是“如何组织历史经验”。如果把分布式执行经验重新压平成单个分析器的输入，仍然会遇到长上下文归因瓶颈；而保留局部上下文并让智能体协作交换证据，更适合 MAS 的经验结构。
9. 消融实验：协作经验组织与多尺度演化是否必要？
论文做了两组消融实验。
第一组考察经验组织方式。结果如下：
| Experience Scheme | Ansible | ResearchRubrics |
|---|---|---|
| No evolution (MAS) | 40.8 | 49.5 |
| Centralized experience | 49.8 | 52.9 |
| Partitioned experience | 44.5 | 51.0 |
| Collaborative experience | 53.9 | 55.8 |
Centralized experience 把整个团队轨迹交给一个中心分析器，Partitioned experience 让每个智能体只分析自己的局部经验，不做跨智能体信息交换。两者都比完全不进化更好，但都低于 Collaborative experience。这与前面失败归因实验的结论一致：协作式经验组织更能同时保留局部证据和跨智能体关系，因此能产生更可靠的改进目标。
第二组消融考察三种演化尺度。结果如下：
| Variant | Ansible | ResearchRubrics |
|---|---|---|
| Full Meta-Team | 53.9 | 55.8 |
| w/o L1 agent | 48.5 | 47.9 |
| w/o L2 interaction | 50.7 | 54.4 |
| w/o L3 team | 51.9 | 52.1 |
去掉任一层都会降低性能，说明三个层级是互补的。其中，去掉 L1 智能体层演化带来的下降最大，说明直接改进个体行为 scaffold 是 MAS 改进中非常重要的一环。L2 和 L3 的作用具有任务依赖性：结构化软件任务更依赖精确协作，因此 L2 更重要；开放式研究评估更依赖团队组织，因此 L3 更重要。
10. 可扩展性、泛化与受限预算实验
论文进一步考察了 Meta-Team 是否只是在进化集上“记住”了某些模式，还是能学到更可复用的协作行为。
【Figure 3。该图展示 LOCA-Bench 不同上下文长度下的性能变化，以及 LoCoBench 从 Python 进化到 C、C++、Java 任务的跨语言泛化结果。】
在 LOCA-Bench 上，Meta-Team 只在 96K token 的样本上进化，然后在 8K 到 256K 的不同上下文规模上评估。结果显示，随着上下文增长，单智能体基线明显下降，固定 MAS 更稳定但仍低于 Meta-Team。Meta-Team 在除 8K 外的所有上下文长度上表现最好。论文解释说，Meta-Team 在 96K 上进化时引入了两个额外 worker，这使它在 256K 这种更长上下文场景中特别有效。
在 LoCoBench 上，Meta-Team 在 Python 任务上进化，然后评估到 C、C++、Java 任务。它在 Feature Implementation 和 Cross-File Refactoring 两个任务类型上都优于单智能体和固定 MAS。论文认为，这说明 Meta-Team 学到的不是某种语言特定技巧，而是更通用的协作行为，例如任务拆解、交接和验证。
【Figure 4。该图展示在受限预算下，Meta-Team 相比其他进化方法的性能—成本权衡。】
在受限预算实验中，所有进化方法只使用主设置三分之一的进化预算，然后冻结产物并评估。结果显示，Meta-Team 在四个设置上都取得了更好的性能—成本权衡。论文将这一点归因于 Meta-Team 能够利用 evolution set 中的 timeout 反馈来调整团队系统，从而在受限预算下学习更节约成本的团队行为。
11. 相关工作脉络
论文把相关工作分成两部分。
第一部分是 LLM 多智能体系统。已有系统通过角色专门化、通信协议和工作流组织来提升复杂任务处理能力，例如 CAMEL、ChatDev、MetaGPT、AutoGen、Magentic-One、OWL 等。这些工作主要关注智能体在执行阶段如何组织，而 Meta-Team 关注的是执行之后如何根据经验更新组织。
第二部分是自动 MAS 生成与进化。已有方法包括性能驱动搜索、工作流优化、通信图优化、经验记忆和中心化分析器修订等。Meta-Team 属于经验驱动方向，但它的区别在于按照 MAS 的分布式结构来组织进化过程：保留智能体局部上下文，通过协作通信交换证据，再做多尺度更新。
12. 论文指出的局限性
论文明确指出了两个主要局限。
第一，Meta-Team 关注的是 scaffold 和组织层面的演化，包括智能体行为、协作模式和团队级协调规则。它并不自动改造底层执行基础设施，例如工具 API、环境 harness、验证器或记忆后端。这些部分通常仍需要针对具体任务做工程设计。
第二，Meta-Team 不更新底层 LLM 的参数。它依赖任务后反思和显式 scaffold 更新，因此具有可解释性和模型无关性，但也限制了系统把长期重复出现的团队行为内化到基础模型中的能力。论文认为，将协作式自进化与微调或强化学习结合，是一个有前景的未来方向。
13. 总结
这篇论文围绕一个清晰问题展开：多智能体系统既然通过分布式执行缓解了单智能体的长上下文和长程推理压力，那么它在利用经验自我改进时，也不应该退回到单个中心分析器处理完整轨迹的模式。
Meta-Team 的核心设计可以概括为三点：
- 保留每个智能体的局部执行上下文，而不是把完整轨迹简单压平；
- 通过任务后的跨智能体通信交换证据，使局部反思具备全局意识；
- 将经验转化为 agent、interaction、team 三个尺度上的可复用更新。
实验表明，在六类长程智能体基准上，Meta-Team 相比单智能体、手工 MAS 和已有 MAS 进化方法都取得了更好的表现。消融实验进一步说明，性能提升来自两个关键因素：协作式经验组织，以及多尺度演化机制。论文最后也强调，Meta-Team 当前主要更新 scaffold 和组织规则，不涉及底层工具基础设施和模型参数更新，这限定了它的适用范围，也给后续工作留下了结合 fine-tuning 或 reinforcement learning 的方向。
参考
- 原文：Evolve as a Team: Collaborative Self-Evolution for LLM-based Multi-Agent Systems
- arXiv：https://arxiv.org/abs/2605.29790
- PDF：https://arxiv.org/pdf/2605.29790
- Code：https://github.com/zz-haooo/Meta-Team