Evolve as a Team: Collaborative Self-Evolution for LLM-based Multi-Agent Systems
论文阅读：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 的三层演化思想，在附录 D 中进一步给出较紧凑的实现管线。整体来看，Meta-Team 的实现重点不是新增一个中心化“反思器”，而是把 MAS 本身设计成一个可被任务经验持续修改的团队 scaffold：任务执行时动态招募智能体，任务结束后保留局部轨迹和跨智能体事件，再把这些经验分别写回个体、交互和团队三个层级。
6.1 可演化的团队 scaffold
Meta-Team 使用 open-roster orchestration，即开放成员池式编排。系统维护一个固定候选智能体池 A*，但每个任务真正运行时只从中招募一个活跃子集。共享团队 scaffold 可以写成：
S = (A*, C)
其中，A* 是候选成员池，C 是 team constitution，也就是团队宪章。团队宪章规定所有成员共同可见的目标、协作原则和决策规则。
每个智能体也不是一个固定 prompt，而是一个可编辑 scaffold。论文将单个 agent scaffold 表示为：
si = (πi, Δi, Ki, Φi, Ri)
各部分含义如下：
| 组件 | 含义 | 在演化中的作用 |
|---|---|---|
πi |
基础角色 prompt | 定义智能体原始职责和行为边界 |
Δi |
behavioral patches | 保存任务后形成的行为修正 |
Ki |
skill library | 保存该智能体可复用的技能 |
Φi |
teammate profiles | 记录该智能体对队友能力、局限和依赖方式的理解 |
Ri |
pairwise collaboration notes | 保存成对协作中的交接经验和注意事项 |
附录 D 还说明了这些组件在实现中的存放方式：每个智能体对应一个可编辑目录，prompt.md 保存角色 prompt，config.yaml 保存底层模型和可用工具；演化产生的 behavioral patches、teammate profiles、collaboration notes 等以文本文件形式放在 evolution/ 下。技能文件则放在 skills/<name>/SKILL.md，并通过 progressive disclosure 加载：默认只展示技能名称和描述，需要时再读取完整技能内容。
这说明 Meta-Team 的“进化”不是把一大段反思总结追加到系统 prompt 后面，而是把不同类型的经验写回不同位置。个体行为问题进入 Δi，可复用能力进入 Ki，队友认知进入 Φi，成对协作经验进入 Ri，团队级规则则进入 C 或候选成员池。
6.2 执行阶段：动态招募与消息总线
任务执行阶段，Meta-Team 通过一组小型编排原语管理团队运行：
| 原语 | 作用 |
|---|---|
LISTPOOL |
查看候选智能体池 |
STARTAGENT |
招募某个候选智能体进入当前任务 |
STOPAGENT |
停止某个智能体 |
FINALIZE |
提交最终结果 |
TERMINATE |
结束执行 |
每个 episode 开始时，系统先通过 LISTPOOL 让当前团队看到候选成员池；当任务需要额外能力时，可以用 STARTAGENT 招募新的智能体；当某个智能体认为任务已经完成时，通过 FINALIZE 提交最终 deliverable。
智能体之间的通信由 append-only message bus 处理。也就是说，消息事件以追加方式记录到消息总线中，并被投递到接收方 mailbox。每个智能体运行自己的循环：有任务时调用底层 LLM 和工具继续工作，空闲时等待新消息。
因此，一次任务结束后，系统得到的不是单条线性轨迹，而是三类信息交织而成的经验：
- 每个智能体自己的局部执行轨迹；
- 智能体之间的消息、交接和共享产物；
- 最终提交结果及其评估反馈。
这与论文前面对 MAS 经验的定义一致：多智能体轨迹本质上是多个局部执行链与跨智能体事件的交织。Meta-Team 后续演化正是围绕这种分布式经验结构展开。
6.3 任务后冻结经验：先评估，再更新
给定第 k 个任务 xk，Meta-Team 先用当前 MAS 执行任务，得到活跃智能体集合、轨迹和最终提交结果：
(A, τk, r̂) ← RUN(M; xk)
随后，外部 evaluator V 对提交结果 r̂ 进行评估，得到任务结果 rk，并冻结成本次经验：
ek = (xk, τk, rk)
这里需要注意：V 只提供任务级反馈，例如最终结果是否正确、得分如何，并不负责三层演化中的具体归因和修改。真正的反思和更新发生在后续 L1、L2、L3 三个阶段。
这种“先冻结经验，再演化”的流程可以让更新依据更清楚。系统不会在任务执行中边做边改规则，而是在任务完成后，用完整轨迹、跨智能体事件和最终反馈来判断哪些 scaffold 需要被修改。
6.4 三层更新：从个体、交互到团队
冻结经验后，Meta-Team 依次执行三层更新。
第一层是 Agent-Level Evolution。对本次任务中每个活跃智能体 ai，系统基于它自己的局部轨迹 τi、任务反馈 rk，以及与它直接相关的跨智能体证据，更新该智能体自身 scaffold：
(Δi, Ki, ui) ← ΩL1(si, τi, rk)
其中，Δi 是行为补丁，Ki 是技能库更新，ui 是该智能体对本次经验的局部总结。这个阶段回答的是：某个智能体以后应该怎样观察、验证、报告或避免某类行为。
第二层是 Interaction-Level Evolution。它只针对任务中实际发生过交互的智能体对 (ai, aj)。系统回看双方协作历史，更新两边的 teammate profiles 和 collaboration notes：
(Φi, Ri, Φj, Rj) ← ΩL2(si, sj, τk, rk)
这一层不是简单决定两个智能体以后“要不要通信”，而是记录它们应该如何通信、如何理解彼此能力、如何交接中间结果，以及如何校准依赖关系。例如，某个智能体是否需要给队友更明确的输入格式，某个队友的输出是否需要额外验证，这些都属于 L2 的更新范围。
第三层是 Team-Level Evolution。它聚合前两层产生的短摘要 {ui}、选定证据、完整任务反馈和共享团队 scaffold，更新团队级组织：
S ← ΩL3(S, {ui}, τk, rk)
这一层处理的是组织级问题，例如是否缺少某类角色、是否存在冗余职责、是否需要调整协调规则、是否需要修改 team constitution。与 L1 和 L2 相比，L3 不再只修补某个智能体或某对智能体之间的关系，而是修改整个团队的运行机制。
这三层更新可以概括如下：
| 层级 | 主要反思者 | 更新对象 | 解决的问题 |
|---|---|---|---|
| L1 Agent-Level | 每个活跃智能体，结合自身轨迹和相关跨智能体证据 | Δi, Ki, ui |
个体行为、技能和任务策略如何改进 |
| L2 Interaction-Level | 实际交互过的智能体对 | Φi, Ri, Φj, Rj |
队友之间如何理解、查询、依赖和交接 |
| L3 Team-Level | 团队基于局部摘要和选定证据进行集体修订 | S=(A*, C) |
团队成员、组织结构和共享规则如何调整 |
6.5 提交更新：校验后写回可复用团队
三层更新完成后，Meta-Team 不会无条件提交修改。论文说明，提交前会检查角色一致性、工具可用性、格式有效性和预算约束。如果演化过程中请求 retry，只有在剩余预算允许时才会重新执行当前任务，并且重试成本会计入 evolution budget。
通过校验后，更新会写回可复用团队 scaffold。也就是说，当前任务产生的经验会影响下一轮任务中的 MAS：个体智能体带着新的行为补丁和技能进入后续执行，智能体之间带着更新后的队友画像和协作笔记继续协作，团队整体也可能带着新的成员池、组织结构或宪章运行。
因此，Meta-Team 的实现流程服务于论文的核心主张：MAS 在执行时通过分布式协作降低单智能体负担，那么在任务后自进化时，也应保留这种分布式结构。它不是让一个中心分析器读取完整轨迹后统一改 prompt，而是让局部轨迹、跨智能体证据和团队级摘要分别在合适的层级发挥作用，最终转化为 agent、interaction 和 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
浙公网安备 33010602011771号