#Multi-agent 发展历程与最新进展深度调研：从 MAS / DAI 到 LLM Agent Society

#0. 一句话核心结论

Multi-agent 这条线真正追求的不是“让多个模型一起聊天”，而是：当单个智能体无法完整感知、完整规划、完整执行、完整自我验证时，如何通过“分工、通信、博弈、协作、竞争、记忆与环境反馈”构造一个更可靠、更可扩展、更能长期自治的智能系统。

从早期 Distributed AI / MAS 到今天的 LLM-based multi-agent systems，核心问题一直没变：如何把分布式智能从“看起来像协作”推进到“真的能在开放环境中稳定地产生能力增长”。

变化的是载体：早期是符号 agent、协议和组织；中期是博弈论、机制设计、群体智能和 MARL；今天是 LLM/VLM + tools + memory + code execution + browser/OS environments + RL/post-training。

#0.5 先把容易被一句话带过的代表工作拆开讲

这一节是给“第一次系统读 multi-agent 方向”的读者准备的。前面的长文按历史脉络写，很多论文/系统只能一句话点到；但如果不知道它们到底在干什么，就很容易只记住一堆名词。下面我把最容易造成理解断层的工作拆开讲：每个都尽量回答四个问题：它想解决什么问题？它怎么做？为什么重要？它留下了什么问题？

#0.5.1 HEARSAY-II / Blackboard Architecture：多个专家往同一块黑板上写中间结果

先用人话讲：

你可以把 HEARSAY-II 想象成一个会议室，中间有一块大白板。语音识别任务很复杂：有的人擅长识别音素，有的人擅长识别单词，有的人擅长语法，有的人擅长语义。每个“专家模块”看到白板上已有的信息后，就补充自己能判断的东西。最后系统通过不断读写这块白板，把低层声音信号逐渐拼成高层语言理解。

它想解决的问题：

早期 AI 常常像一个单体专家系统：所有知识和规则都塞进一个大系统里。但真实任务往往需要多种知识共同工作。语音理解就不是单靠声学、词典或语法任何一个模块能解决的。

它的核心方法：

Blackboard architecture 把问题拆成三个部分：

1. 一块共享工作区，也就是 blackboard；
2. 多个知识源，也就是不同专家模块；
3. 一个控制机制，决定哪个模块什么时候出手。

专家模块不一定直接互相通信，而是通过共享黑板间接协作。

为什么它重要：

它给 multi-agent 留下了一个非常核心的思想：协作不一定是 agent 之间互相聊天，也可以是围绕一个共享状态不断补全、修正和提升。 今天很多 agent 系统里的 shared memory、workspace、scratchpad、任务状态表，本质上都能看到 blackboard 的影子。

留下的问题：

黑板架构很依赖人工设计：谁能写什么、什么时候写、冲突如何解决，都要提前规定。它解决了“多个专家如何共享中间状态”，但没解决“多个自治智能体如何自己决定协作策略”。这就引向后来的 Contract Net、BDI、agent communication language。

#0.5.2 Contract Net Protocol：把任务分配变成“招标—投标”

先用人话讲：

如果一个 manager agent 有任务要做，它不直接指定谁做，而是像发招标一样广播：“我这里有个任务，谁能做？报价多少？多久完成？”其他 agent 根据自己的能力和成本投标。manager 比较投标后，把任务分给最合适的 agent。

它想解决的问题：

在多智能体系统里，任务不是只属于一个中心控制器。每个 agent 有自己的能力、资源和局部信息。问题变成：任务来了以后，怎么动态分配给合适的 agent？

它的核心方法：

Contract Net Protocol 通常包括：

1. task announcement：发布任务；
2. bid：候选 agent 报价/承诺；
3. award：manager 选择一个或多个 agent；
4. execution and report：执行并反馈结果。

这不是深度学习算法，而是一种协作协议。

为什么它重要：

今天的 LLM multi-agent 里，planner 把任务拆成子任务，然后分给 coder、tester、researcher、browser agent，本质上经常在做一种“隐式 Contract Net”。区别是现在分配过程常常写在 prompt 或 workflow 里，而不是严格协议。

留下的问题：

它假设 agent 能清楚描述自己的能力和成本。但 LLM agent 很多时候并不知道自己会不会做，甚至会自信地误报能力。所以今天的任务分配不能只靠“谁说自己能做”，还需要执行反馈、验证器和历史表现统计。

#0.5.3 BDI Agents：把 agent 拆成“我相信什么、我想要什么、我打算怎么做”

先用人话讲：

BDI 是 belief、desire、intention 的缩写：

• belief：我认为世界现在是什么样；
• desire：我想达成什么目标；
• intention：我已经承诺要执行的计划。

它试图让 agent 不只是一个函数，而像一个有内部心理状态的理性行动者。

它想解决的问题：

早期 agent 系统需要解释：为什么 agent 做出这个动作？它依据什么信息？它当前目标是什么？它为什么坚持某个计划而不是随便跳？

它的核心方法：

BDI 用显式状态表示 agent 的认知结构：

1. belief 存世界模型和已知事实；
2. desire 存候选目标；
3. intention 存已经选择并要执行的计划。

当环境变化时，agent 更新 belief，再决定是否改变 intention。

为什么它重要：

今天 LLM agent 的 memory、goal stack、plan、reflection，其实都在重新发明 BDI 的一部分。区别是 BDI 更强调结构化状态，而 LLM agent 往往把 belief/desire/intention 混在自然语言上下文里。

留下的问题：

BDI 的状态很清晰，但它依赖人工定义符号和规则。LLM agent 的状态更灵活，却更混乱、更不可控。一个值得研究的问题是：能不能把 BDI 的结构化优点和 LLM 的开放语义能力结合起来？

#0.5.4 KQML / FIPA ACL：早期的人们想给 agent 规定“说话语法”

先用人话讲：

如果多个 agent 要协作，它们不能只发一串文本，还要知道这句话的意图是什么。比如同样一句“文件在哪里”，可能是询问，也可能是请求搜索，也可能是命令。KQML 和 FIPA ACL 就像早期 agent 世界里的“外交语言”：规定消息类型，比如 ask、tell、request、propose、accept、reject。

它想解决的问题：

多 agent 通信不能只有内容，还要有 speech act，也就是“这句话在做什么动作”。否则 agent 很难判断对方是在提供事实、请求帮助、提出报价，还是做承诺。

它的核心方法：

通信消息通常包含：

• performative：这句话的动作类型，如 ask/tell/request；
• content：具体内容；
• sender/receiver：谁发给谁；
• ontology/language：内容所用的概念体系和语言。

为什么它重要：

今天 LLM agent 用自然语言聊天很方便，但也带来一个问题：消息语义太松。一个 agent 写了一段长解释，另一个 agent 不一定知道其中哪些是事实、哪些是建议、哪些是待验证假设。KQML/FIPA ACL 提醒我们：agent 通信不只是 token 传输，更是行动意图的传输。

留下的问题：

固定通信语法太硬，难覆盖开放任务；纯自然语言又太松，容易误解和污染上下文。今天更有前途的方向可能是二者结合：自然语言解释 + 结构化字段 + 可验证证据。

#0.5.5 Ant Colony / Particle Swarm：没有中心控制，也能靠局部规则形成群体智能

先用人话讲：

蚂蚁找路不是因为有一个总指挥，而是每只蚂蚁根据局部信息行动，并在环境里留下信息素。走得好的路径信息素更强，后来者更容易走这条路，于是群体逐渐找到好路径。粒子群也是类似：每个粒子记住自己见过的好位置，也参考群体见过的好位置，在搜索空间里移动。

它想解决的问题：

复杂系统能不能不靠中心规划，而靠很多简单个体的局部互动，涌现出全局解决方案？

它的核心方法：

这类方法强调：

1. 局部规则；
2. 间接通信，例如信息素或共享环境；
3. 群体搜索；
4. 正反馈与探索之间的平衡。

为什么它重要：

它说明 multi-agent 不一定是“多个聪明个体开会”。有时恰恰相反：每个个体很简单，但群体通过环境反馈形成智能。这对今天的 agent system 有启发：与其让多个 LLM 长篇讨论，不如让它们并行探索不同方案，然后通过测试、评分、环境反馈筛选。

留下的问题：

群体智能擅长搜索和优化，但不擅长复杂语义推理。LLM agent 则擅长语义推理但容易幻觉。一个自然结合点是：用 LLM 产生候选策略，用群体搜索/环境反馈筛选策略。

#0.5.6 MADDPG：多智能体强化学习为什么需要“训练时看全局，执行时看局部”

先用人话讲：

假设几个 agent 在同一个环境里学习。对其中一个 agent 来说，环境并不是稳定的，因为其他 agent 也在不断学习、不断改变策略。今天你学到“这样做能赢”，明天队友和对手都变了，这条经验可能就失效。这叫 multi-agent non-stationarity。

它想解决的问题：

单智能体 RL 通常假设环境动态相对稳定。但多智能体里，其他 agent 的策略也在变化，所以每个 agent 看到的是一个会变的环境。学习会变得很不稳定。

它的核心方法：

MADDPG 使用 centralized training, decentralized execution：

• 训练时 critic 可以看到更多全局信息，比如其他 agent 的观测和动作；
• 执行时每个 agent 仍然只根据自己的局部观测行动。

这样训练时更容易估计“这个动作好不好”，部署时又不要求所有信息都集中。

为什么它重要：

CTDE 后来成为 MARL 里非常核心的范式。对 LLM agent 也有启发：训练/分析阶段可以用完整轨迹、工具日志、其他 agent 消息做全局诊断；但实际运行时，每个 agent 未必都能看到所有信息。

留下的问题：

MADDPG 主要面向连续控制和相对封闭的环境。LLM agent 的动作是语言、代码、工具调用，状态巨大且语义复杂，不能直接套用。

#0.5.7 VDN / QMIX / COMA：团队成功后，怎么知道是谁贡献的？

先用人话讲：

足球队赢球了，奖励给全队。但训练时你想知道：是前锋射门重要，还是中场传球重要，还是后卫防守重要？如果所有人只拿同一个团队奖励，就很难知道每个人应该如何改进。这就是 multi-agent credit assignment。

#VDN：把团队价值拆成每个 agent 的价值

VDN 的想法很直观：团队总价值约等于每个 agent 价值的加和。这样团队奖励可以分解回个体。但这个假设太简单，因为很多协作不是线性相加的。

#QMIX：允许更复杂的团队价值组合，但要求单调性

QMIX 比 VDN 更灵活。它用一个 mixing network 把各 agent 的价值合成团队价值，同时保持一种单调约束：如果某个 agent 的局部价值提高，团队价值不应该下降。这样既能表达非线性协作，又方便每个 agent 独立选动作。

#COMA：用反事实问“如果你不这么做，团队会怎样？”

COMA 更接近直觉里的贡献分析：某个 agent 做了动作 A 后团队得到奖励，那如果它当时做另一个动作，团队会不会更好？这种 counterfactual baseline 试图估计单个 agent 动作的边际贡献。

为什么它们重要：

它们都在解决同一个核心问题：团队结果如何分摊到个体决策。 今天 LLM multi-agent 里这个问题仍然很严重。一个 planner、一个 coder、一个 tester 合作修 bug，最后测试通过了，贡献到底来自谁？如果失败了，错在计划、实现、测试，还是上下文传递？

对 LLM Agent 的启发：

未来的 multi-agent code system 不能只记录“最后成功/失败”，还应该做：

• message ablation：删掉某条消息看结果是否变差；
• agent dropout：去掉某个 agent 看系统是否还能成功；
• counterfactual replay：让某个 agent 换一种回复重放轨迹；
• contribution scoring：给每个 agent/message 估计边际贡献。

这就是为什么 credit assignment 会成为长轨迹 multi-agent RL 的关键。

#0.5.8 MAPPO：为什么一个“看起来普通”的 PPO 能在多智能体里很强？

先用人话讲：

MAPPO 的重要性不在于它听起来多花哨，而在于它说明：在合作多智能体任务里，经过仔细调参和合适输入设计，PPO 这种相对稳定的 on-policy 方法也可以打得很好。

它想解决的问题：

MARL 里曾经有很多复杂算法，但很多结果难复现、对超参数敏感。研究者需要一个更稳、更简单、更强的 baseline。

它的核心方法：

MAPPO 仍然基于 PPO，但在多智能体场景中使用 centralized value function，并配合一些训练细节，比如 advantage normalization、value clipping、合理 batch 设置等。

为什么它重要：

它提醒我们：有时方向进展不来自“更复杂算法”，而来自把一个稳定基线在目标场景里认真调好。今天 LLM Agent RL 也类似：很多所谓新框架未必比一个扎实的 single-agent + verifier + retry baseline 更强。

留下的问题：

MAPPO 仍主要服务封闭环境下的 MARL；LLM agent 的轨迹更长、动作更稀疏、奖励更难定义，不能简单照搬。

#0.5.9 AlphaStar / OpenAI Five / Hide-and-Seek：self-play 为什么重要？

先用人话讲：

如果没有足够难的老师，可以让 agent 互相当老师。今天的自己打昨天的自己，赢了以后又产生更强版本，对手也随之变强。这样任务难度会随着能力提升自动增长，这叫 self-play 或 autocurriculum。

它想解决的问题：

复杂策略不可能靠人工标注一步步教出来。StarCraft、Dota、hide-and-seek 这种环境的策略空间巨大，需要系统自己产生越来越难的训练分布。

它的核心方法：

这些系统通常包括：

1. 大规模并行环境；
2. self-play 或 population-based training；
3. 对手/队友池；
4. 从胜负或任务结果中学习；
5. 有时会出现人类没直接设计的 emergent behavior。

Hide-and-Seek 里比较有名的现象是 agent 学会利用工具、卡漏洞、形成越来越复杂的追逐和躲藏策略。

为什么它重要：

它让人看到一种路径：智能不是只靠静态数据集训练出来，也可以靠持续交互和对抗产生。对 wenjun 关心的 agent 自演化，这非常关键：如果我们能设计一个环境，让 agent 的失败自动变成下一轮训练任务，系统就可能持续进化。

留下的问题：

游戏环境有清晰规则和奖励，而真实代码/科研/网页任务没有这么干净。如何把 self-play/autocurriculum 迁移到真实 LLM agent，是未解决问题。

#0.5.10 Generative Agents：LLM + 记忆 + 反思，为什么会像“社会模拟”？

先用人话讲：

Generative Agents 做了一个类似小镇的虚拟环境。每个角色都有日常活动、记忆和反思机制。比如一个 agent 记得自己昨天和谁聊天，反思后形成“某某对我很重要”的高层印象，之后再决定今天做什么。

它想解决的问题：

LLM 单次对话可以像人，但要模拟持续生活的个体，需要记住过去、总结经验、根据日程和关系行动。

它的核心方法：

系统通常包括：

1. memory stream：记录 agent 经历；
2. retrieval：根据当前情境取回相关记忆；
3. reflection：把低层事件总结成高层想法；
4. planning：生成日程和行为；
5. environment：多个 agent 在同一空间里互动。

为什么它重要：

它把 LLM 从“回答问题的模型”推向“有持续状态的社会角色”。今天很多 agent memory、reflection、persona、social simulation 都受它影响。

留下的问题：

它更像可信模拟，而不是强任务求解。也就是说，它能让 agent 行为看起来合理，但不保证在代码、网页、科研这种可验证任务上更强。

#0.5.11 CAMEL：角色扮演式 multi-agent 为什么流行，又为什么不够？

先用人话讲：

CAMEL 的核心是让两个或多个 LLM 扮演不同角色，例如“AI assistant”和“AI user”，通过角色设定让它们自动展开任务讨论。一个 agent 提需求，另一个执行或回答，形成多轮协作。

它想解决的问题：

如果只让一个 LLM 做任务，它可能缺少约束和互动。角色扮演可以把任务拆成多个视角，让对话自动推进。

它的核心方法：

给不同 agent 不同 system prompt / role prompt，让它们在特定任务框架下互相提问、回答、修正。

为什么它重要：

它让大家看到：LLM 自然语言能力很适合作为 agent 间通信界面。很多后来的 multi-agent demo 都沿用了 role-playing conversation。

留下的问题：

角色扮演很容易“看起来很热闹”，但不一定带来真实能力提升。两个同源 LLM 互相讨论，可能只是把同一个错误说得更自信。所以后来的研究开始强调 benchmark、工具反馈和 verifier。

#0.5.12 AutoGen：它不是一个神奇算法，而是一个多 agent 对话编排框架

先用人话讲：

AutoGen 更像一个搭建 agent workflow 的框架。你可以定义多个 agent：有的负责写代码，有的负责执行代码，有的负责人类确认，有的负责总结。它们通过消息互相调用，直到任务完成或达到终止条件。

它想解决的问题：

早期大家手写 agent loop 很乱：谁调用谁？什么时候停？工具执行结果怎么回传？人类怎么插入？AutoGen 把这些对话式协作抽象成框架。

它的核心方法：

AutoGen 提供 conversable agents：

• agent 可以接收和发送消息；
• agent 可以接工具或代码执行；
• 可以设定自动回复逻辑；
• 可以组织 group chat 或 manager；
• 可以加 human-in-the-loop。

为什么它重要：

它推动 multi-agent 从论文 demo 走向工程实践。很多人第一次真正搭 multi-agent system，接触的就是类似 AutoGen 的框架。

留下的问题：

框架本身不等于能力。一个系统用了 AutoGen，不代表 multi-agent 结构真的优于 single-agent。真正要证明的是：在固定 token、工具调用、时间预算下，它是否更可靠。

#0.5.13 MetaGPT / ChatDev：把软件公司流程搬进 agent 系统

先用人话讲：

MetaGPT 和 ChatDev 都像是在模拟一家小软件公司。有人当产品经理，有人当架构师，有人当程序员，有人当测试。需求进来后，agent 按软件工程流程产出需求文档、设计文档、代码和测试。

它们想解决的问题：

写软件不是只“生成一段代码”，还包括需求理解、设计、实现、测试、修改。单个 LLM 往往会跳步骤，导致代码和需求不一致。

核心方法：

这类系统把人类软件工程流程写进 agent 协作：

1. 需求分析；
2. 架构设计；
3. 任务拆分；
4. 编码；
5. 测试；
6. 文档生成；
7. 迭代修复。

MetaGPT 更强调 SOP，即 standard operating procedure；ChatDev 更强调角色化聊天模拟公司。

为什么重要：

它们证明了一个重要工程直觉：LLM agent 的能力不仅来自模型本身，也来自 workflow。 同一个模型，如果放进更合理的软件工程流程，输出会更稳定。

留下的问题：

问题也正出在这里：提升到底来自 multi-agent，还是来自更好的流程模板？如果把这些步骤交给一个 single-agent 顺序执行，是否也能接近？这就是 fixed-budget evaluation 要回答的问题。

#0.5.14 AgentVerse：动态组队的想法是什么？

先用人话讲：

AgentVerse 想表达的是：多 agent 不一定是固定几个人从头聊到尾，而可以根据任务动态选择参与者、组织协作，并观察是否出现 emergent behavior。

它想解决的问题：

固定角色系统太死。真实任务里，不同阶段需要不同专家：查资料时需要 researcher，写代码时需要 programmer，调 bug 时需要 debugger，评审时需要 critic。

核心方法：

AgentVerse 关注 agent group 的构建、协作、反馈和调整。它让 multi-agent system 更像一个可变组织，而不是固定 prompt 列表。

为什么重要：

它把问题从“设计几个角色”推进到“如何组织一个 agent society”。这对未来 agent marketplace、specialist routing、动态专家选择都很重要。

留下的问题：

动态组队需要知道谁真的擅长什么，但 LLM agent 的能力评估很难。没有可靠 profiling 和 verifier，动态组队可能只是更复杂的 prompt routing。

#0.5.15 Voyager：为什么它不像普通 Minecraft agent？

先用人话讲：

Voyager 在 Minecraft 里不是只完成一个任务，而是持续探索、写代码控制自己、把成功技能存进技能库，再在以后复用。比如它学会“挖木头”“做工具”“探索洞穴”，这些技能会变成可调用代码。

它想解决的问题：

很多 agent 每次任务都从零开始，无法积累长期经验。Voyager 想做 lifelong learning：越玩越会玩。

核心方法：

Voyager 包括几个关键部件：

1. automatic curriculum：自动提出下一步探索目标；
2. skill library：把成功代码保存成可复用技能；
3. iterative prompting：失败后根据环境反馈修改代码；
4. embodied environment：Minecraft 提供可交互世界和反馈。

为什么重要：

它非常接近“self-evolving agent”的原型：agent 不只是执行任务，还会沉淀技能。对 code agent 来说，类似思想就是把成功 debug 策略、repo 搜索策略、测试选择策略沉淀成可复用经验。

留下的问题：

Voyager 主要依赖 GPT-4 生成代码和环境反馈，技能库也未必等价于模型参数里的能力增长。如何从外部技能库走向模型内化，是下一步关键。

#0.5.16 Reflexion / self-refine / critic loop：为什么“反思”有用但也危险？

先用人话讲：

反思类方法让 agent 做完后先别急着交卷，而是回看自己的答案或轨迹，找错误，写下经验，然后重试。就像做题后订正错题。

它想解决的问题：

LLM 第一遍生成经常有错。如果能根据失败反馈自我修正，就能提升长任务成功率。

核心方法：

典型循环是：

1. 生成答案/动作；
2. 执行或评估；
3. 得到错误反馈；
4. 生成 reflection；
5. 把 reflection 加进下一轮上下文；
6. 重试。

为什么重要：

它是很多 agent loop 的基础：planner-executor-critic、tester-fixer、reviewer-coder 都是反思思想的变体。

危险在哪里：

如果没有真实反馈，反思可能只是“自我安慰式幻觉”。模型会编一个看似合理的错误原因，然后带着错误继续走。所以反思最好绑定可验证信号：测试、编译、网页状态、数据库状态、环境 reward。

#0.5.17 SWE-agent / SWE-bench：为什么真实 GitHub issue 成为关键 benchmark？

先用人话讲：

HumanEval 这类代码题像考试小题；SWE-bench 更像真实工作：给你一个开源仓库和一个 GitHub issue，你要理解项目、定位 bug、改代码、跑测试，最后提交 patch。

SWE-bench 想解决的问题：

传统代码 benchmark 太短、太干净、太容易被污染，无法代表真实软件工程。真实 bug 修复需要跨文件理解、环境配置、测试选择和长期调试。

SWE-agent 的意义：

SWE-agent 不只是模型，而是一个 agent-computer interface：它让 LLM 能在 repo 里搜索、打开文件、编辑、运行测试、观察错误，再继续修改。

为什么重要：

这条线把 agent 研究从“会不会写函数”推向“能不能在真实工程环境里闭环完成任务”。它也让 multi-agent code system 有了更真实的试验场。

留下的问题：

SWE-bench 成功率容易受到污染、测试覆盖、repo 选择、prompt 工程、工具接口影响。并且很多 multi-agent coding 系统的提升，可能只是用了更多搜索、更多 retry、更多 token，而不一定是协作机制更好。

#0.5.18 AgentBench / WebArena / OSWorld / GAIA：这些 benchmark 分别在测什么？

这些名字经常被放在一起，但测的不是同一种能力。

关键理解：

这些 benchmark 的共同点是：它们把 LLM 从“回答文本”逼到“操作环境”。一旦有环境，就会出现计划、工具、反馈、记忆、错误恢复，也就自然出现 multi-agent 可能有用的空间。

但要小心：

benchmark 越复杂，越难判断提升来自哪里。是模型强？工具接口好？上下文长？多 agent 协作好？还是 retry 次数多？所以必须做固定预算比较。

#0.5.19 MultiAgentBench：专门问“多 agent 协作/竞争到底好不好”

先用人话讲：

很多 benchmark 只是让一个 agent 做任务；MultiAgentBench 更直接地问：多个 LLM agent 在协作或竞争环境里表现如何？不同通信拓扑，比如 star、chain、tree、graph，会不会影响结果？

它想解决的问题：

过去 multi-agent 论文常常展示很漂亮的协作对话，但缺少系统评测。MultiAgentBench 想把“协作质量”和“竞争表现”变成可测对象。

核心方法：

它通常会设计多种场景和指标，例如：

1. task completion：任务是否完成；
2. milestone achievement：关键中间里程碑是否达成；
3. collaboration / competition quality：协作或竞争过程质量；
4. topology comparison：比较 star、chain、tree、graph 等结构；
5. strategy comparison：比较 group discussion、planning 等协作方式。

为什么重要：

它开始把问题从“agent 能不能做任务”转向“agent 之间如何组织更有效”。这正是 multi-agent 作为研究方向必须面对的问题。

留下的问题：

即使有 MultiAgentBench，也还不够。因为真实代码、网页、科研任务里的协作很长、很脏、很依赖工具反馈。下一步 benchmark 需要更重视固定预算、因果归因和可复现轨迹。

#0.5.20 AgentGym / AgentGym-RL：从评测走向训练环境

先用人话讲：

如果 AgentBench、WebArena、SWE-bench 更像考试，那么 AgentGym 想更像训练馆。它不只是问 agent 能不能做任务，还希望提供一组环境，让 agent 可以在里面收集经验、训练、改进。

它想解决的问题：

LLM agent 不能只靠 prompt engineering。要真正变强，需要可交互环境、轨迹数据、反馈信号和训练循环。

核心方法：

这类工作通常会整理多个 agent 环境，统一接口和反馈，让模型可以在不同任务中执行 action、观察 observation、拿到 reward 或评价。

为什么重要：

它把 agent research 从 evaluation-only 推向 training-oriented。对 wenjun 关心的长轨迹 RL，这类环境基础设施非常关键。

留下的问题：

环境质量、reward 设计、任务分布、多轮 credit assignment 仍然很难。训练环境如果太玩具，学到的策略未必能迁移到真实任务。

#0.5.21 AI Agents That Matter：为什么它提醒我们不要被 demo 骗？

先用人话讲：

这类工作/观点强调：agent 论文很容易被 demo、长 prompt、复杂框架包装得很好看，但真实评测可能不严谨。一个 agent 系统声称提升，可能只是因为用了更强模型、更多 token、更多工具调用、更多人工调参。

它想解决的问题：

Agent 研究缺少严格实验控制。不同论文的 agent scaffold、模型、工具、环境、预算都不同，很难公平比较。

关键提醒：

评测 agent 时至少要控制：

• base model；
• token budget；
• tool-call budget；
• wall-clock time；
• retry 次数；
• human intervention；
• benchmark contamination；
• 成本和延迟。

为什么重要：

这直接影响 multi-agent 研究是否成立。如果 multi-agent 只是因为调用了 5 个 agent、花了 5 倍 token 才赢 single-agent，那它未必是机制进步。真正有价值的是：在相同预算下，因为更好的分工、通信、验证和状态建模而更强。

#0.5.22 读完这些工作后，应形成的主线理解

如果把上面所有工作串起来，可以得到一条更容易理解的主线：

1. Blackboard 解决“多个专家如何共享中间状态”；
2. Contract Net 解决“任务如何分配给合适 agent”；
3. BDI / ACL 解决“agent 内部状态和通信意图如何表达”；
4. Swarm intelligence 说明“没有中心也能靠局部规则形成群体搜索”；
5. MARL 解决“多个学习者如何在交互中学出协作策略”；
6. VDN/QMIX/COMA 把问题推进到“团队奖励如何分给个体贡献”；
7. Self-play systems 说明“环境和对手可以自动生成课程”；
8. Generative Agents / CAMEL 把 LLM 带入多角色互动；
9. AutoGen / MetaGPT / ChatDev 把 LLM multi-agent 工程化；
10. Voyager / Reflexion / SWE-agent 把 agent 推向环境反馈、技能积累和真实任务；
11. SWE-bench / WebArena / OSWorld / GAIA 让 agent 能力进入可验证环境；
12. MultiAgentBench / AI Agents That Matter 开始追问“多 agent 的真实收益到底来自哪里”。

所以，multi-agent 不是一个单独技巧，而是一组长期问题的汇合：共享状态、任务分配、通信协议、组织结构、学习机制、环境反馈、credit assignment 和评测科学。

对后续研究最重要的不是记住每个名字，而是抓住这几个问题：

• 多个 agent 什么时候真的比一个 agent 好？
• 通信应该传自然语言、结构化状态，还是 latent representation？
• 团队成功或失败后，怎么知道每个 agent/message 的贡献？
• 多 agent 能否从环境反馈中持续学习，而不是只靠 prompt 编排？
• 如何在固定预算下证明 multi-agent 的机制收益？

#1. 本次调研流程与查漏记录

本报告按三轮以上调研组织，不把论文机械罗列，而是用“问题链”解释 multi-agent 为什么一阶段接一阶段演化。

#第一轮：经典 Multi-Agent Systems / Distributed AI 脉络

检索重点：

• classical multi-agent systems
• distributed artificial intelligence
• blackboard systems / HEARSAY-II
• contract net protocol
• BDI agents
• agent communication languages: KQML, FIPA ACL
• negotiation, auctions, coalition formation, mechanism design

代表节点：

• HEARSAY-II / blackboard architecture：早期用共享黑板协调多个知识源。
• Contract Net Protocol, Smith 1980：把任务分配看成招标-投标。
• Distributed Artificial Intelligence / Multi-Agent Systems：从单体专家系统转向多个自治实体。
• BDI agents, Rao & Georgeff 1995：用 belief-desire-intention 描述可解释的理性 agent。
• KQML / FIPA ACL：试图标准化 agent 之间的通信行为。
• Rosenschein & Zlotkin, Rules of Encounter：博弈论和机制设计进入 MAS。
• Wooldridge, Jennings 等 MAS 综述与教材：奠定智能体、组织、协议、协作等概念。

第一轮后发现的缺口：

1. 经典 MAS 强调协议、理性、组织，但对真实开放环境中的学习和泛化处理不足。
2. 早期系统常假设 agent 的目标、能力、通信语义比较清楚；而 LLM agent 的能力边界、错误模式、目标漂移并不清楚。
3. 需要补充 swarm intelligence 和 MARL，因为它们分别代表“无中心组织”和“通过交互学习”的两条重要支线。

#第二轮：Swarm Intelligence / MARL / Game-Theoretic Learning

检索重点：

• swarm intelligence / ant colony / particle swarm / stigmergy
• game theory / mechanism design / auctions / negotiation / coalition formation
• independent learners
• CTDE: centralized training decentralized execution
• VDN, QMIX, MADDPG, COMA, MAPPO
• communication learning
• self-play, population-based training, open-endedness

代表节点：

• Ant Colony Optimization, Dorigo 1990s：蚂蚁通过信息素形成路径搜索。
• Particle Swarm Optimization, Kennedy & Eberhart 1995：群体粒子通过局部和全局经验搜索。
• MADDPG, 2017：multi-agent actor-critic，应对多智能体非平稳性。
• VDN, 2017：把团队价值分解成个体价值。
• QMIX, 2018：通过 monotonic value factorization 解决合作 MARL 的 credit assignment。
• COMA, 2017/2018：counterfactual baseline，尝试回答“某个 agent 对团队奖励贡献了什么”。
• MAPPO, 2021：证明 PPO 在合作多智能体游戏中意外有效。
• AlphaStar / OpenAI Five：self-play、population-based training 和大规模训练把 multi-agent 推向复杂游戏。
• OpenAI hide-and-seek, 2019：多智能体竞争产生 autocurriculum 和 emergent tool use。

第二轮后发现的缺口：

1. MARL 解决了“通过交互学习协作策略”的问题，但大多依赖封闭环境、明确 reward、有限 action space。
2. 它对真实软件工程、网页操作、科研任务等开放任务不够适配，因为这些任务 reward 稀疏、状态巨大、动作语义复杂。
3. 需要补 LLM agent 最新系统，因为 LLM 把自然语言、代码、工具调用、计划分解统一成了新的 agent substrate。

#第三轮：LLM-based Agents / Multi-Agent Frameworks / Benchmarks

检索重点：

• AutoGen, CAMEL, MetaGPT, ChatDev, AgentVerse
• Generative Agents, Voyager
• Reflexion, CodeAct, SWE-agent / Devin-style agents
• AgentBench, WebArena, SWE-bench, GAIA, OSWorld, MLE-bench, AgentGym, AgentBoard
• 2024-2026 agent evaluation, safety, long-horizon RL, computer-use agents
• Agent benchmark rigor / AI Agents That Matter
• SWE-bench Live, SWE-bench variants, OSWorld-Human / OSWorld-MCP, AgentGym-RL

代表节点：

• Generative Agents, 2023：LLM + memory + reflection 产生可信社会行为模拟。
• CAMEL, 2023：role-playing multi-agent conversation。
• AutoGen, 2023：多 agent conversation framework。
• MetaGPT, 2023：把人类软件工程流程编码进 agent 协作。
• ChatDev, 2023：用角色化聊天模拟软件公司。
• AgentVerse, 2023：动态组队和 multi-agent collaboration。
• Voyager, 2023：Minecraft 中自动课程、技能库、代码执行，接近 lifelong agent。
• AgentBench, 2023：多环境评估 LLM-as-agent。
• WebArena, 2023：真实网站环境。
• SWE-bench, 2023：真实 GitHub issue 修复。
• GAIA, 2023：通用 AI assistant benchmark。
• AgentBoard, 2024：多轮 agent 分析评测面板。
• OSWorld, 2024：真实电脑环境中的 multimodal computer-use agent。
• AgentGym, 2024 / AgentGym-RL, 2025：多环境 self-evolving / RL agent training。
• MLE-bench, 2024：机器学习工程任务。
• SWE-bench Live, 2025：动态更新 issue，缓解 benchmark contamination。
• OSWorld-Human, 2025：关注 computer-use agents 的效率，而不只是成功率。
• MCP-AgentBench, 2025：围绕 Model Context Protocol 的工具调用能力评测。
• SWE-ABS, 2026：对 SWE-bench 类 benchmark 做 adversarial strengthening，暴露 inflated success rates。

第三轮后发现的缺口：

1. LLM multi-agent 很多工作是 framework engineering，真实提升来自哪里并不总是清楚：是模型更强、prompt 更长、工具更好、还是 multi-agent 结构本身？
2. Agent benchmark 正在从“能不能做”转向“是否可复现、是否被污染、成本如何、是否真的反映现实任务”。
3. 2024-2026 的主线不只是 multi-agent conversation，而是 long-horizon tool-use agent 的训练、评测和自我改进。

#2. 这条线真正要解决的问题是什么？

Multi-agent 的根问题可以分成五层。

#2.1 单个智能体能力有限

一个 agent 即使很强，也会遇到：

• 感知不完整：partial observability。
• 知识不完整：不知道某个领域细节。
• 计算不够：无法穷举计划。
• 执行不稳定：长任务容易中途偏离。
• 自我验证弱：会相信自己的错误。
• 目标不清晰：真实任务常常需要解释、协商、修正。

Multi-agent 的第一动机是：把一个大问题拆成多个角色、多个视角、多个局部决策。

#2.2 多个智能体引入新问题

但多个 agent 不是免费午餐。它会带来：

• 通信开销。
• 协调失败。
• 目标冲突。
• 责任归因困难。
• 重复劳动。
• 群体幻觉。
• 错误级联。
• 更大的安全攻击面。

所以 multi-agent 的研究重点并不是“agent 越多越好”，而是：什么任务真的需要多个 agent？多个 agent 如何组织才不互相放大错误？

#2.3 真实世界任务具有长链条结构

软件工程、网页操作、科研实验、机器人任务都不是一步预测，而是：

1. 理解目标；
2. 搜索信息；
3. 形成计划；
4. 调用工具；
5. 观察反馈；
6. 修改计划；
7. 执行子任务；
8. 验证结果；
9. 处理异常；
10. 形成可复用经验。

这天然适合 multi-agent，但也要求 agent 具备：

• 长期记忆；
• 分层规划；
• 环境建模；
• 自我纠错；
• 工具使用；
• reward credit assignment；
• 对失败轨迹的学习能力。

这也是为什么 wenjun 关注的 长轨迹 agent RL、model-based RL、latent-space reasoning、self-evolving code agent、agent 数据分布塑造能力 会成为下一阶段核心。

#3. 发展阶段：从符号协议到 LLM agent society

#阶段一：Distributed AI / Blackboard Systems

#关键词：共享状态、专家模块、黑板架构

#前一阶段解决了什么？

早期 AI 多是单体专家系统：一个系统内嵌规则、知识库、推理机。问题是复杂任务往往不是一个专家能解决的，例如语音理解、诊断、规划。

#这个阶段引入了什么？

Blackboard systems 把多个知识源放在一个共享工作区上：

不同模块看到黑板上的中间结果后，选择是否贡献新信息。

代表工作：

• HEARSAY-II speech understanding system：经典 blackboard architecture。
• 后来的 distributed problem solving 系统继承了“多个专家贡献局部解”的思想。

#之前的问题

单体系统难以扩展，知识模块之间耦合严重。

#解决方法

用共享黑板作为协调介质，让多个模块异步读写中间状态。

#新问题

黑板系统依赖中心共享状态，模块何时行动、谁来仲裁、如何避免冲突仍然需要手工设计。

#如何推动下一阶段

它提出了 multi-agent 的第一个核心问题：

如果多个智能组件都能行动，系统如何分配任务和协调行为？

这直接引向 Contract Net、Distributed AI 和 MAS。

#阶段二：Contract Net / Distributed Artificial Intelligence

#关键词：任务分配、自治 agent、协议

代表工作：

• Reid G. Smith, “The Contract Net Protocol”, 1980
• Distributed Artificial Intelligence, 1980s-1990s
• Multi-Agent Systems 早期研究

#前一阶段解决了什么？

Blackboard 能让多个模块共享信息，但“谁做什么”仍然不清楚。

#这个阶段引入了什么？

Contract Net Protocol 把任务分配类比成市场：

1. manager 发布任务；
2. contractors 投标；
3. manager 选择；
4. contractor 执行并返回结果。

这很像今天 agent orchestration 中的 planner-worker 架构。

#之前的问题

多个模块之间缺少明确的任务分配机制。

#解决方法

用协议组织 agent 之间的任务发布、竞标和执行。

#新问题

Contract Net 假设任务可描述、agent 能力可评估、投标可信。真实环境中这些假设经常不成立。

#如何推动下一阶段

它把 multi-agent 从“共享状态”推进到“交互协议”，也暴露了新问题：

agent 不只是工具模块，它们可能有自己的信念、目标、偏好和策略。

这推动了 BDI、agent communication language 和博弈论机制设计。

#阶段三：BDI Agents / Agent Communication Languages

#关键词：belief, desire, intention；通信语义；理性 agent

代表工作：

• Rao & Georgeff, BDI Agents, 1995
• KQML
• FIPA ACL
• Wooldridge & Jennings, Intelligent Agents / MAS

#前一阶段解决了什么？

Contract Net 能分配任务，但没有很好解释 agent 的内部状态：

它为什么这样行动？它知道什么？它想要什么？它承诺了什么？

#这个阶段引入了什么？

BDI 框架：

• Belief：agent 对世界的信念；
• Desire：希望达成的目标；
• Intention：已经承诺执行的计划。

Agent Communication Languages 试图把通信标准化：

不是只传字符串，而是传“请求、告知、承诺、询问”等 speech act。

#之前的问题

agent 行为难解释，通信缺少语义。

#解决方法

用认知状态和通信行为建模 agent。

#新问题

BDI 和 ACL 很优雅，但工程上重、对开放环境的学习能力弱。

agent 的 belief 和 intention 通常由人设计，而不是从经验中学出来。

#如何推动下一阶段

它留下了两个问题：

1. 如果 agent 有不同目标，如何保证合作？
2. 如果环境变化，agent 如何学习？

前者走向 game theory / mechanism design；后者走向 MARL。

#阶段四：Game Theory / Mechanism Design / Negotiation

#关键词：激励、拍卖、协商、联盟、机制

代表方向：

• mechanism design
• auctions
• automated negotiation
• coalition formation
• social choice
• game-theoretic MAS

代表作品：

• Rosenschein & Zlotkin, Rules of Encounter
• Shoham & Leyton-Brown, Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations
• 拍卖、协商、联盟形成相关 MAS 工作

#前一阶段解决了什么？

BDI 解释了 agent 的信念和意图，但如果 agent 目标不一致，光靠通信语义不够。

#这个阶段引入了什么？

把 multi-agent 看成博弈：

• agent 有效用函数；
• 行为有策略性；
• 系统设计者需要设计机制，使个体理性导致整体可接受结果。

#之前的问题

agent 可能撒谎、搭便车、策略性操纵协议。

#解决方法

用拍卖、合同、协商、激励相容机制来约束行为。

#新问题

机制设计通常要求效用函数清楚、理性假设明确、参与者可建模。

但 LLM agent 和真实人类-机器混合系统里，效用、能力和错误模式都不稳定。

#如何推动下一阶段

它留下了一个至今仍关键的问题：

multi-agent 系统不是只要会说话，还要有激励结构和验证机制。

今天 LLM agent 的“debate / critic / reviewer / executor”本质上也在做一种简化机制设计，只是很多时候没有显式建模 incentives。

#阶段五：Swarm Intelligence

#关键词：无中心协作、局部规则、涌现、stigmergy

代表工作：

• Ant Colony Optimization, Dorigo
• Particle Swarm Optimization, Kennedy & Eberhart, 1995
• Stigmergy：通过环境留下痕迹间接通信

#前一阶段解决了什么？

Game-theoretic MAS 关注理性主体和机制，但很多群体智能不需要复杂理性。蚂蚁、鸟群、鱼群没有中央计划，却能形成路径、聚集、搜索。

#这个阶段引入了什么？

Swarm intelligence 强调：

• 单体规则简单；
• 通信局部；
• 控制去中心化；
• 全局模式涌现。

#之前的问题

复杂协议和理性建模成本高。

#解决方法

用简单局部规则和环境反馈形成全局行为。

#新问题

涌现行为难解释、难保证、难迁移。

它能搜索，但不一定能抽象推理；能形成模式，但不一定能遵守复杂目标。

#如何推动下一阶段

Swarm intelligence 给 MARL 和 open-ended agents 一个重要启发：

复杂行为可以从交互和环境反馈中产生，而不是完全由人手写。

这直接连接 self-play、autocurriculum 和 open-endedness。

#阶段六：Multi-Agent Reinforcement Learning

#关键词：非平稳性、credit assignment、CTDE、self-play

MARL 是 multi-agent 发展中的关键转折：

它不再主要靠人设计协议，而是希望 agent 通过交互学习策略。

#6.1 Independent Learners：最朴素但不稳定

#之前的问题

人工协议难以覆盖复杂环境。

#解决方法

每个 agent 把其他 agent 当成环境的一部分，独立学习。

#新问题

从单个 agent 视角看，环境是非平稳的，因为其他 agent 也在学习。

这会破坏普通 RL 的稳定性假设。

#6.2 MADDPG：集中 critic，应对非平稳

代表工作：

• Multi-Agent Actor-Critic for Mixed Cooperative-Competitive Environments, Lowe et al., 2017

arXiv: https://arxiv.org/abs/1706.02275

#之前的问题

独立学习中，每个 agent 看到的环境不断变化。

#解决方法

训练时使用 centralized critic，能看到其他 agent 的信息；执行时每个 agent 分散行动。

这就是后来非常重要的 CTDE：centralized training, decentralized execution。

#新问题

集中 critic 随 agent 数量增长会变复杂，而且 credit assignment 仍然困难。

#如何推动下一阶段

推动了 value decomposition：

既然团队 reward 很难分配，那能不能把全局价值函数分解成个体价值？

#6.3 VDN / QMIX：合作 MARL 的价值分解

代表工作：

• Value-Decomposition Networks, 2017

arXiv: https://arxiv.org/abs/1706.05296

• QMIX: Monotonic Value Function Factorisation, 2018

arXiv: https://arxiv.org/abs/1803.11485

#之前的问题

团队奖励无法告诉每个 agent 自己贡献了什么。

#解决方法

VDN：把全局 Q 值拆成个体 Q 值之和。

QMIX：用 monotonic mixing network 表示更灵活的联合价值，同时保证 decentralized argmax 可行。

#新问题

单调分解限制表达能力；复杂协作中个体贡献不一定是单调可加的。

#如何推动下一阶段

推动更复杂的 credit assignment、communication learning、attention-based MARL 和 transformer MARL。

#6.4 COMA：反事实 credit assignment

代表方向：

• Counterfactual Multi-Agent Policy Gradients

#之前的问题

团队 reward 下，很难知道某个 agent 行动是否关键。

#解决方法

用 counterfactual baseline：

比较“该 agent 实际动作”与“其他可能动作”的差异，估计其贡献。

#新问题

计算成本高，对复杂动作空间和长轨迹仍然困难。

#如何推动下一阶段

把 credit assignment 变成 MARL 核心问题之一。

这对今天 LLM multi-agent 也非常关键：多个 agent 协作完成代码修复时，到底 planner、coder、critic、tester 谁有贡献？

#6.5 MAPPO：简单 on-policy 方法的回归

代表工作：

• The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games, 2021

arXiv: https://arxiv.org/abs/2103.01955

#之前的问题

复杂 off-policy MARL 方法工程不稳定，调参困难。

#解决方法

认真调优 PPO，在 cooperative MARL 中获得强结果。

#新问题

样本效率和长任务泛化仍然有限。

#如何推动下一阶段

说明 multi-agent training 不一定总靠复杂结构，稳定训练 recipe 很重要。

这与今天 LLM agent RL 的趋势高度一致：很多进展来自训练流程、数据分布、环境设计，而不只是新模型结构。

#6.6 Self-play / Population-based Training / Open-endedness

代表工作：

• AlphaZero, 2017：self-play + search。
• OpenAI Five, 2018/2019：Dota 2 大规模 self-play。
• AlphaStar, 2019：StarCraft II，league training / population。
• Emergent Tool Use from Multi-Agent Autocurricula, 2019

arXiv: https://arxiv.org/abs/1909.07528

#之前的问题

人工课程有限，agent 容易过拟合静态任务。

#解决方法

让 agent 通过自我博弈或群体竞争产生课程。

对手不断变强，任务自动变难。

#新问题

自博弈可能走向狭窄策略空间；开放性难以控制；评测困难；安全风险增加。

#如何推动下一阶段

它把 multi-agent 推向一个重要思想：

环境 + 对手 + 群体分布 可以成为能力增长的发动机。

这正是今天 self-evolving agents、code agents、AI scientists 想借鉴的东西。

#4. LLM-based Multi-Agent Systems：为什么 2023 以后爆发？

LLM 出现后，multi-agent 突然被重新激活，原因不是“聊天好玩”，而是 LLM 改变了 agent 的接口。

以前一个 agent 要手工定义：

• 状态表示；
• 动作空间；
• 通信协议；
• 任务分解；
• domain knowledge；
• planner；
• executor。

LLM 让这些变成自然语言和代码：

• 状态可以是文本上下文；
• 动作可以是 tool call / code / browser action；
• 通信可以是自然语言；
• 计划可以由 LLM 生成；
• 领域知识来自预训练；
• 多 agent 可以通过角色 prompt 快速构造。

这大幅降低了构建 multi-agent system 的门槛，但也引入了幻觉、不可控、评测污染和长轨迹失败等问题。

#5. LLM Multi-Agent 代表工作的问题链

#5.1 Generative Agents：从任务求解到社会模拟

代表工作：

• Generative Agents: Interactive Simulacra of Human Behavior, 2023

arXiv / HF: https://huggingface.co/papers/2304.03442

#之前的问题

传统 NPC 或模拟 agent 行为机械，缺少记忆、反思和社会互动。

#解决方法

Generative Agents 提出：

• memory stream；
• reflection；
• planning；
• natural language interaction。

多个 agent 在 sandbox town 中形成日程、对话、传播信息等社会行为。

#新问题

这种行为“可信”不等于“可验证正确”。

它更像 social simulation，不是可靠任务执行系统。

#如何推动下一阶段

它证明了 LLM 可以作为 agent cognition 的核心，推动了 memory / reflection / planning 架构。

#5.2 CAMEL：role-playing 让 agent 自主对话协作

代表工作：

• CAMEL: Communicative Agents for “Mind” Exploration of Large Scale Language Model Society, 2023

arXiv / HF: https://huggingface.co/papers/2303.17760

#之前的问题

LLM 通常需要人持续引导，难以自主展开协作。

#解决方法

CAMEL 用 role-playing 设定两个或多个角色，让它们围绕任务自主交流。

#新问题

角色设定能产生长对话，但不保证任务真实完成。

agent 可能陷入礼貌互夸、虚假共识或循环讨论。

#如何推动下一阶段

推动了“角色分工式 multi-agent”框架，如 AutoGen、MetaGPT、ChatDev。

#5.3 AutoGen：multi-agent conversation 变成工程框架

代表工作：

• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, 2023

arXiv: https://arxiv.org/abs/2308.08155

#之前的问题

研究原型很多，但搭建 multi-agent workflow 成本高。

#解决方法

AutoGen 提供 conversable agents：

• assistant agent；
• user proxy agent；
• tool/code execution；
• human-in-the-loop；
• 多 agent conversation orchestration。

#新问题

框架降低了开发门槛，但 agent 编排质量仍依赖人工设计。

多 agent 不自动等于更强，经常只是把 prompt engineering 分散到多个角色。

#如何推动下一阶段

使 LLM multi-agent 从 paper demo 进入应用开发，并推动了可组合 agent framework 的生态。

#5.4 MetaGPT：把人类工作流编码成 agent 组织

代表工作：

• MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, 2023

arXiv: https://arxiv.org/abs/2308.00352

#之前的问题

简单对话式 multi-agent 容易产生混乱，尤其在软件工程这类复杂任务中。

#解决方法

MetaGPT 把软件公司流程显式编码：

• product manager；
• architect；
• engineer；
• QA；
• structured documents；
• SOP-like workflow。

#新问题

流程强约束提高稳定性，但降低灵活性。

如果任务不符合预设流程，系统可能僵硬。

#如何推动下一阶段

它说明：

multi-agent 的有效性往往来自组织结构，而不是 agent 数量。

这对未来 agent pretraining / workflow data 很重要：模型需要学习高质量组织过程，而不是只学习单轮答案。

#5.5 ChatDev：软件开发中的角色化协作

代表工作：

• ChatDev: Communicative Agents for Software Development, 2023

arXiv: https://arxiv.org/abs/2307.07924

#之前的问题

软件开发涉及需求、设计、编码、测试，单一 LLM 容易遗漏环节。

#解决方法

ChatDev 把软件开发模拟成虚拟公司，通过多角色对话完成项目。

#新问题

对小型任务有效，但真实 repo 级 issue 修复需要代码搜索、测试运行、环境依赖、版本管理、长期记忆。

#如何推动下一阶段

推动 code agent 从“生成项目”转向“真实代码库维护”，也就是 SWE-bench / SWE-agent / Devin-style agents 的方向。

#5.6 AgentVerse：动态组队和涌现行为

代表工作：

• AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors, 2023

arXiv: https://arxiv.org/abs/2308.10848

#之前的问题

固定 agent 角色不一定适配不同任务。

#解决方法

AgentVerse 尝试动态组织 agent 群体，探索不同 agent 组合的协作效果。

#新问题

动态组队需要评价机制：谁该加入？谁该退出？如何判断贡献？

这又回到 multi-agent credit assignment。

#如何推动下一阶段

推动从静态 prompt role-play 走向 adaptive agent organization。

#5.7 Voyager：LLM agent 的长期技能积累

代表工作：

• Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023

arXiv: https://arxiv.org/abs/2305.16291

#之前的问题

LLM agent 常常只解决一次性任务，缺少 lifelong learning。

#解决方法

Voyager 在 Minecraft 中结合：

• automatic curriculum；
• skill library；
• executable code as action；
• iterative prompting and feedback。

#新问题

技能库主要是外部记忆和代码积累，不是模型权重层面的能力更新。

泛化到更开放真实世界仍困难。

#如何推动下一阶段

它非常重要，因为它把 LLM agent 推向：

• self-evolving agent；
• code-as-action；
• experience replay；
• skill library；
• open-ended exploration。

这与 wenjun 关注的 self-evolving code agent 直接相关。

#5.8 Reflexion：不用更新权重的“语言强化学习”

代表工作：

• Reflexion: Language Agents with Verbal Reinforcement Learning, 2023

arXiv / HF: https://huggingface.co/papers/2303.11366

#之前的问题

传统 RL 需要大量样本和权重更新，LLM agent 在线 fine-tune 成本高。

#解决方法

失败后让 agent 生成文字反思，存入 episodic memory，下次作为上下文使用。

#新问题

反思可能是错的；自我批评能力不可靠。

后续工作如 Can Large Language Models Really Improve by Self-critiquing Their Own Plans? 指出 LLM 自我验证常出现 false positive，需要外部 verifier。

#如何推动下一阶段

推动了 reflection / critique / memory 机制，但也让社区意识到：

LLM 自己说“我错了”不等于真的学会了。

#5.9 CodeAct / SWE-agent / Devin-style：代码成为 agent action space

代表工作：

• Executable Code Actions Elicit Better LLM Agents, 2024

arXiv / HF: https://huggingface.co/papers/2402.01030

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, 2023

arXiv / HF: https://huggingface.co/papers/2310.06770

• AutoDev: Automated AI-Driven Development, 2024

arXiv / HF: https://huggingface.co/papers/2403.08299

#之前的问题

自然语言动作不够精确，真实任务需要执行、测试、调试。

#解决方法

让 agent 用代码、shell、browser、IDE 操作作为动作。

这比“说计划”更接近真实执行。

#新问题

代码 agent 可能：

• 过拟合测试；
• 修改错误文件；
• 引入隐藏 bug；
• 消耗大量 token 和计算；
• 在长任务中失去目标。

#如何推动下一阶段

推动 agent evaluation 从聊天任务转向真实 repo、真实 OS、真实网页和真实 ML 工程。

#6. 2024-2026 最新进展：LLM Multi-Agent 的主线变化

2024-2026 的关键变化是：

领域从“搭框架”转向“真实环境、长期任务、可验证执行、训练 agent、评测可信度和安全”。

#6.1 Frameworks：从 role-play 到 workflow / tool orchestration

#代表系统

• AutoGen
• MetaGPT
• ChatDev
• AgentVerse
• LangGraph / CrewAI 等工程框架
• MCP-based tool ecosystems

#最新趋势

早期框架主要回答：

“如何让多个 LLM agent 互相说话？”

现在的问题变成：

“如何让多个 agent 在工具、环境、状态、记忆和权限约束下可靠完成任务？”

也就是说，multi-agent framework 正在从 conversation graph 变成 execution graph。

#判断

有价值的是：

• 显式状态机；
• 可恢复执行；
• tool sandbox；
• memory management；
• evaluator / verifier；
• human-in-the-loop；
• 失败轨迹记录；
• agent contribution tracing。

价值较低的是：

• 简单多角色 prompt；
• 无评测的 agent swarm；
• 用更多 agent 掩盖单 agent 能力不足。

#6.2 应用：代码、网页、OS、科研成为主战场

#代码 agent

代表 benchmark / work：

• SWE-bench, 2023
• SWE-bench Live, 2025

arXiv: https://arxiv.org/abs/2505.23419

• SWE-bench+, 2024
• Multi-SWE-bench, 2025
• SWE-Bench-CL, 2025
• SWE-ABS, 2026

arXiv: https://arxiv.org/abs/2603.00520

核心转变：

• 从 HumanEval 式单函数生成；
• 到真实 GitHub issue；
• 再到动态 issue、跨语言、持续学习和 adversarial benchmark strengthening。

这说明代码 agent 的核心瓶颈不再是“会不会写代码”，而是：

• repo understanding；
• long-context retrieval；
• build/test/debug loop；
• patch minimality；
• hidden test generalization；
• continual maintenance；
• anti-overfitting。

#网页 agent

代表工作：

• WebArena: A Realistic Web Environment for Building Autonomous Agents, 2023

arXiv: https://arxiv.org/abs/2307.13854

• VisualWebArena
• WorkArena
• BrowserGym

核心问题：

网页任务要求 agent：

• 读页面；
• 操作表单；
• 理解视觉布局；
• 处理登录/状态；
• 多步导航；
• 避免不可逆操作。

单纯文本推理不够，VLM、browser state、DOM、工具调用都重要。

#OS / computer-use agent

代表工作：

• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments, 2024

arXiv: https://arxiv.org/abs/2404.07972

• OSWorld-Human, 2025
• OSWorld-MCP, 2025

核心问题：

OS 任务比网页更难，因为它包含：

• GUI；
• 文件系统；
• 多应用；
• 系统状态；
• 长时间操作；
• 不可逆副作用。

2025 的 OSWorld-Human 特别强调效率：

agent 不能只看成功率，还要看操作步数、时间、成本和人类可用性。

#科研 / ML engineering agent

代表工作：

• MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering, 2024

arXiv: https://arxiv.org/abs/2410.07095

• AI Scientist, 2024

arXiv / HF: https://huggingface.co/papers/2408.06292

• AI research agents for MLE-bench, 2025

核心问题：

科研 agent 不只是写代码，还要：

• 选题；
• 读文献；
• 提假设；
• 设计实验；
• 运行训练；
• 分析结果；
• 写论文；
• 判断 novelty。

这类任务最接近 long-horizon autonomous agent，也最容易暴露当前 agent 的问题：

它们经常能生成“像研究”的文本，但很难稳定产生真正可复现、可验证、有价值的新发现。

#6.3 Benchmark：从静态 QA 到真实交互环境

#代表 benchmark

#6.4 安全与对齐：multi-agent 会放大风险

Multi-agent agentic systems 的风险比单模型更复杂：

1. 错误级联：一个 agent 的错误被其他 agent 当作事实。
2. 虚假共识：多个 agent 互相赞同，给人“更可信”的错觉。
3. 权限扩散：多个 agent 调用工具时，权限边界更难控制。
4. 责任归因困难：出了错，不知道是 planner、executor、critic、tool 还是 memory 的问题。
5. benchmark gaming：agent 学会利用测试，而不是真解决任务。
6. 成本不可控：多 agent 长链条运行 token、工具、时间成本爆炸。
7. prompt injection / tool injection：web/OS agent 尤其容易受环境恶意文本影响。

2024-2026 的评测趋势明显开始关注这些问题：

• benchmark contamination；
• hidden tests；
• live benchmark；
• adversarial strengthening；
• efficiency metrics；
• reproducibility；
• sandbox safety；
• tool permissions；
• process logging。

#7. 技术分类表

#7.1 协作机制

#7.2 通信机制

#7.3 规划与记忆

#7.4 训练方式

#7.5 评测方式

#8. 当前瓶颈与开放问题

#8.1 多 agent 是否真的比单 agent 强？

这是最基础但经常被回避的问题。

很多 LLM multi-agent paper 的增益可能来自：

• 更长上下文；
• 更多采样；
• 更复杂 prompt；
• 更强 base model；
• 更多工具调用；
• 人工 workflow；
• hidden human prior。

而不是 multi-agent 本身。

未来需要更严格 ablation：

• 同 token budget 下 multi-agent vs single-agent；
• 同工具调用次数下比较；
• 同模型、同采样数、同上下文长度；
• 统计不同任务类型是否真的需要 multi-agent。

判断：

multi-agent 真正有优势的任务通常满足：

1. 可自然分解；
2. 子任务之间需要不同技能；
3. 有外部验证；
4. 错误可局部隔离；
5. 多视角审查能降低风险；
6. 并行搜索有价值。

如果任务只是单轮推理，多 agent 往往只是昂贵包装。

#8.2 Credit assignment：谁贡献了成功？

MARL 里 credit assignment 已经很难；LLM multi-agent 更难。

例如一个 code agent 系统中：

• planner 提了方向；
• retriever 找到文件；
• coder 写 patch；
• tester 运行测试；
• critic 指出问题；
• finalizer 清理代码。

如果最终成功，应该奖励谁？

如果失败，又是谁的问题？

当前很多系统只看最终 success rate，缺少过程级 attribution。

开放问题：

• 能否为 LLM agent 设计 counterfactual evaluation？
• 能否自动移除某个 agent 看性能变化？
• 能否学习 agent routing policy？
• 能否把 multi-agent trace 转成训练数据并分配 credit？

这与 wenjun 关注的 长轨迹 agent RL 直接相关。

#8.3 Long-horizon planning：长任务不是多说几轮就能解决

LLM agents 的常见失败：

• 前几步正确，后面目标漂移；
• 反复尝试同一错误；
• 忽视环境反馈；
• 过早相信自己完成；
• 计划太粗；
• 子任务依赖关系混乱；
• 无法恢复中断状态。

这不是简单加 memory 就能解决的。

更根本的问题是：

agent 需要可执行的、可验证的、可恢复的层级计划表示。

未来方向：

• hierarchical task graph；
• plan-state alignment；
• latent plan representation；
• environment-grounded verifier；
• failure recovery policy；
• subgoal reward modeling。

这连接 model-based RL：

如果 agent 能在隐空间模拟“下一步行动可能导致什么”，它就不必完全依赖试错。

#8.4 Model-based RL 与 LLM agent 还没有真正融合

传统 model-based RL 如 Dreamer、MuZero 等强调：

• 学世界模型；
• 在模型中规划；
• 用 imagined rollouts 提高样本效率。

LLM agent 也在做“想象”，但多数是语言层面的：

• “我接下来应该……”
• “如果这样做可能……”
• “让我反思一下……”

问题是这些语言想象未必 grounded。

开放问题：

1. LLM agent 的 world model 应该是文本、代码、状态图，还是 latent vector？
2. 网页/OS/code 环境能否学习可预测的 transition model？
3. 能否在 latent-space 中做 planning，再映射到 tool actions？
4. 能否用 execution feedback 校正语言模型的世界模型？
5. 多 agent 是否可以分工学习不同局部 dynamics？

这可能是下一代 agent research 的关键：

从 prompt planning 走向 learned environment modeling。

#8.5 Latent-space reasoning：自然语言推理太慢、太显式、太容易污染

当前 LLM multi-agent 大量依赖显式语言对话。

优点是可读，缺点是：

• token 成本高；
• 中间推理可能被污染；
• agent 之间互相诱导错误；
• 隐含不确定性无法表达；
• 很难做连续优化。

latent-space reasoning 的潜力在于：

• 压缩长轨迹状态；
• 表示不确定性；
• 支持快速 rollouts；
• 用 learned verifier 评估计划；
• 多 agent 在 latent belief space 中协调。

但挑战是可解释性和可控性。

未来可能出现混合范式：

• latent planner；
• language interface；
• tool-grounded verifier；
• memory compression；
• trajectory-level RL。

#8.6 Self-evolving code agent：目前更多是经验积累，不是真进化

Voyager、Reflexion、AgentGym 等方向都在探索 self-evolving agents。

但今天很多“自进化”其实是：

• 存 prompt；
• 存反思；
• 存代码片段；
• 存 workflow；
• 下次检索再用。

这不是坏事，但它不是完整学习。

真正的 self-evolving code agent 至少需要：

1. 从失败 issue 中提取可复用技能；
2. 判断技能是否真的有效；
3. 避免错误经验污染记忆；
4. 将经验压缩成可泛化 policy；
5. 在新 repo / 新语言 / 新框架中迁移；
6. 持续更新而不灾难性遗忘；
7. 形成自己的 benchmark curriculum；
8. 能自动生成训练数据和验证任务。

这与 code agent pretraining / post-training 数据分布高度相关。

#8.7 Agent 预训练数据如何塑造能力？

当前 foundation model 预训练大多不是为 agent 优化的。

模型看过大量文本和代码，但不一定看过高质量的 agent trajectories。

Agent 能力需要的数据可能包括：

• multi-step tool-use traces；
• debugging trajectories；
• failed attempts and recovery；
• human expert workflows；
• code review conversations；
• issue discussion → patch → test → merge；
• browser task trajectories；
• OS operation traces；
• experiment logs；
• research notebooks；
• planner-executor-critic traces；
• long-horizon task decompositions；
• verifier feedback。

关键不是“更多数据”，而是数据分布中是否包含：

1. 行动；
2. 观察；
3. 失败；
4. 修正；
5. 验证；
6. 长期目标保持；
7. 多角色协作；
8. 环境反馈。

研究判断：

未来 agent 模型的差距，很可能来自是否拥有高质量 long-horizon interaction data，而不是只来自参数规模。

#8.8 Benchmark 污染、过拟合与“看起来进步”

2024-2026 的 benchmark 发展已经暴露一个问题：

• 静态 benchmark 容易被训练集污染；
• agent 可以利用测试漏洞；
• 成功率不代表真实可用；
• 成本和效率常被忽略；
• 人工选择任务会偏向 demo-friendly cases。

相关工作：

• AI Agents That Matter, 2024 指出 agent benchmark 过度关注 accuracy，忽视成本、复杂性和现实效用。

arXiv / HF: https://huggingface.co/papers/2407.01502

• SWE-bench Live, 2025 用动态 issue 缓解污染。
• SWE-ABS, 2026 通过 adversarial benchmark strengthening 暴露 inflated success rates。
• OSWorld-Human, 2025 强调效率，而不只是成功率。

开放问题：

• 如何做 live benchmark 的同时保证可复现？
• 如何评估 agent 的长期维护能力？
• 如何评估 agent 是否真正理解 repo，而不是 patch hacking？
• 如何评估 agent 的安全边界？
• 如何把 benchmark 从 leaderboard 变成训练环境？

#9. 研究机会判断：哪些值得做，哪些只是工程堆叠？

#9.1 值得做的问题一：长轨迹 Agent RL 的 credit assignment

#为什么重要？

LLM agent 终于进入真实环境，但训练仍然弱。

单纯 SFT expert trajectories 只能模仿成功路径，无法很好处理失败恢复。

#关键问题

• 多轮工具调用中的 reward 如何分配？
• 中间步骤如何定义 value？
• 对失败轨迹如何学习？
• 多 agent trace 中如何分配 credit？
• 能否训练一个 critic 评估 partial progress？

#可能方向

• trajectory-level process reward model；
• counterfactual agent ablation；
• subgoal-level reward decomposition；
• code/test/browser feedback as dense reward；
• multi-agent critic；
• hindsight relabeling for agent tasks。

这是一个非常有研究价值的方向，不只是工程。

#9.2 值得做的问题二：agent 的 model-based / world-model learning

#为什么重要？

长任务靠 trial-and-error 太贵。

如果 agent 能预测工具调用、代码修改、网页操作的后果，就能更高效规划。

#可能方向

• repo-level world model：预测 patch 对测试和依赖的影响；
• browser world model：预测点击/输入后的页面状态；
• OS world model：预测 GUI action 后状态；
• research world model：预测实验设置对结果的影响；
• multi-agent world model：预测其他 agent 的行为和可靠性。

#难点

• 状态巨大；
• transition 部分可观测；
• stochastic；
• action 语义复杂；
• 需要结合 symbolic state 和 latent state。

但这正是有价值的地方。

#9.3 值得做的问题三：latent-space planning + language/tool grounding

#为什么重要？

纯语言 planning 太慢、太不稳定；纯 latent planning 又不可解释。

未来可能需要两者结合。

#可能方向

• latent task graph；
• compressed memory state；
• differentiable verifier；
• latent rollout + textual rationale；
• language-to-latent action abstraction；
• agent trajectory representation learning。

#与 multi-agent 的关系

不同 agent 可以共享 latent task state，而不是只通过冗长自然语言通信。

这可能显著降低通信成本并减少误解。

#9.4 值得做的问题四：self-evolving code agent 的经验压缩

#为什么重要？

代码 agent 天然有外部 verifier：测试、编译、lint、CI。

这是训练 self-evolving agent 最好的环境之一。

#关键问题

• 如何从一次 bug fix 中抽象出可复用 skill？
• 如何判断 skill 是否泛化？
• 如何自动构造 curriculum？
• 如何防止 memory bloat 和错误经验污染？
• 如何把外部 memory 转成模型内部能力？

#可能实验平台

• SWE-bench / SWE-bench Live；
• Multi-SWE-bench；
• SWE-Bench-CL；
• real repo issue streams；
• synthetic repo evolution environments。

这是 wenjun 关注方向中最值得长期投入的方向之一。

#9.5 值得做的问题五：agent pretraining data 的结构化塑造

#为什么重要？

如果 base model 没见过高质量 long-horizon agent traces，后训练很难补。

#可能数据类型

• issue → reasoning → code search → patch → test → revision；
• browser task → observation → action → error recovery；
• ML experiment logs；
• multi-agent design review；
• code review and CI failure traces；
• human debugging screen recordings转文本/动作；
• synthetic but verified tool-use trajectories。

#研究问题

• 什么样的 trajectory 数据最能提升 agent？
• 成功轨迹和失败轨迹比例多少合适？
• 是否需要 pretraining 阶段加入 action-observation format？
• midtraining 是否可以桥接 text pretraining 和 agent post-training？
• agent 数据是否会损害普通语言能力？
• 如何 decontaminate benchmark tasks？

这和 foundation model training recipe 直接相关。

#9.6 值得做的问题六：multi-agent evaluation 的因果化

#为什么重要？

现在很多 multi-agent 系统只报告整体成功率，不知道结构是否真的有效。

#可能方向

• agent knockout test：移除某个 agent 看性能变化；
• role permutation test：交换角色看是否仍有效；
• communication bottleneck test：限制通信看性能；
• adversarial agent test：插入错误 agent 看鲁棒性；
• cost-normalized score；
• process trace causal attribution。

这能把 multi-agent 从 demo science 变成可解释工程和科学研究。

#9.7 相对不值得投入的方向

#1. 无评测的“更多 agent 更智能”

如果没有严格 budget control 和 ablation，只是堆 agent，很难产生科学价值。

#2. 纯角色扮演式 agent society

除非用于社会模拟或数据生成，否则对真实任务帮助有限。

#3. 只换 prompt 名字的 framework

框架很多，但如果没有新的执行语义、训练机制或评测洞见，价值有限。

#4. 没有 verifier 的 reflection

自我反思如果没有外部 grounding，很容易变成漂亮但错误的解释。

#5. 静态 benchmark leaderboard chasing

尤其是已污染或可 hack 的 benchmark，不应作为核心研究目标。

#10. 一条清晰的发展主线总结

可以把 multi-agent 的历史理解成一条连续问题链：

#10.1 第一问：多个专家如何共享信息？

答案：Blackboard systems。

新问题：谁负责分配任务？

#10.2 第二问：多个 agent 如何分配任务？

答案：Contract Net / task allocation。

新问题：agent 有自己的状态和目标，如何建模？

#10.3 第三问：agent 如何表达信念、目标和意图？

答案：BDI / ACL。

新问题：目标不一致时如何协作？

#10.4 第四问：自利 agent 如何形成系统级好结果？

答案：game theory / mechanism design。

新问题：真实环境太复杂，手写机制不够。

#10.5 第五问：简单个体能否通过局部规则形成全局智能？

答案：swarm intelligence。

新问题：涌现行为难控制、难泛化。

#10.6 第六问：agent 能否通过交互学习协作策略？

答案：MARL / CTDE / self-play。

新问题：封闭环境、reward 明确、动作空间有限，难迁移到真实任务。

#10.7 第七问：LLM 能否让 agent 用自然语言、代码和工具执行真实任务？

答案：LLM agents / AutoGen / MetaGPT / ChatDev / Voyager。

新问题：长任务不稳定、幻觉、评测污染、成本高。

#10.8 第八问：如何训练、评测和安全部署长期自治 agent？

答案正在形成：

AgentGym-RL、SWE-bench Live、OSWorld、MLE-bench、MCP-AgentBench、process reward、tool-grounded RL、self-evolving memory、live environments。

但这还没有真正解决。

#11. 面向 wenjun 的最终研究判断

如果把 multi-agent 和 wenjun 关注的方向连接起来，我会给出以下判断。

#11.1 Multi-agent 的下一阶段不是“更多 agent”，而是“可学习的 agent organization”

现在很多系统的组织结构是人手写的：

• planner；
• coder；
• reviewer；
• tester；
• manager。

未来更重要的是让系统学会：

• 什么时候需要几个 agent；
• 每个 agent 应该承担什么角色；
• 是否需要 debate；
• 是否需要 external verifier；
• 什么时候停止；
• 谁的建议可信；
• 失败后如何重组。

这可以看成 agent organization policy learning。

#11.2 Long-horizon Agent RL 是核心，但不能直接套传统 RL

传统 RL 的状态、动作、reward 相对清楚。

LLM agent 的状态是长上下文、工具输出、文件系统、网页、历史轨迹；动作是文本、代码、API、GUI；reward 往往稀疏且延迟。

所以更现实的路线是：

1. 从可验证环境开始：code、web、OS、ML engineering。
2. 构造过程奖励：测试进展、错误减少、subgoal 完成。
3. 训练 critic / verifier。
4. 做 trajectory-level RL。
5. 再引入 multi-agent credit assignment。
6. 最后走向 self-evolving curriculum。

#11.3 Model-based RL 可以成为 agent 研究的差异化突破口

当前 LLM agent 大多是 reactive：

• 观察；
• 想一步；
• 调工具；
• 再观察。

真正强的 agent 应该能：

• 在内部模拟多个可能行动；
• 估计失败风险；
• 选择信息增益最高的动作；
• 计划回滚路径；
• 复用过去环境模型。

这与 MuZero / Dreamer 的思想一致，但需要改造到文本-代码-工具环境。

一个有潜力的问题：

能否为 code agent 学一个 repo dynamics model，用于预测 patch、test failure、dependency breakage 和 hidden bug 风险？

这比单纯堆 prompt 更有研究深度。

#11.4 Latent-space reasoning 是降低长轨迹成本的关键

多 agent 自然语言对话成本高，而且容易互相污染。

未来可能需要：

• latent belief state；
• latent task graph；
• latent memory compression；
• latent plan rollout；
• language only for interface and explanation；
• tool execution for grounding。

这会把 agent 从“聊天式协作”推进到“内部状态协作”。

#11.5 Self-evolving code agent 是最值得落地的试验场

代码环境有三个优势：

1. 动作可执行；
2. 反馈相对客观；
3. 数据和任务源源不断。

因此，self-evolving code agent 可以作为研究平台，探索：

• 自动课程；
• failure mining；
• skill abstraction；
• memory-to-weight distillation；
• multi-agent credit assignment；
• live benchmark；
• continual learning；
• tool-use RL。

如果要选一个方向长期做，我会优先选：

基于真实 repo issue streams 的 self-evolving code agent：结合 multi-agent workflow、tool-grounded process reward、经验压缩和 continual RL。

#11.6 Agent 数据分布可能比 agent 框架更重要

很多 agent framework 只是把 base model 能力重新包装。

真正决定上限的是模型是否在训练中见过：

• 长任务；
• 工具反馈；
• 失败恢复；
• 多角色协作；
• 环境状态转移；
• 代码执行；
• 测试失败；
• 真实人类工程流程。

所以一个很有价值的问题是：

什么样的 agent trajectory data 能最有效提升 long-horizon tool-use capability？

这可以和 foundation model midtraining / post-training recipe 结合起来做。

#12. 关键来源与代表链接

以下列出报告中用到的主要代表工作，便于后续追踪。

#Classical MAS / DAI

• Reid G. Smith, The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, 1980.
• Rao & Georgeff, BDI Agents: From Theory to Practice, 1995.
• Wooldridge & Jennings, Intelligent Agents: Theory and Practice, 1995.
• Shoham & Leyton-Brown, Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations, 2009.
• KQML / FIPA ACL agent communication language literature.
• HEARSAY-II blackboard architecture.

#Swarm / Game / Mechanism

• Dorigo et al., Ant Colony Optimization.
• Kennedy & Eberhart, Particle Swarm Optimization, 1995.
• Rosenschein & Zlotkin, Rules of Encounter.
• Coalition formation / auctions / automated negotiation MAS literature.

#MARL

• Lowe et al., Multi-Agent Actor-Critic for Mixed Cooperative-Competitive Environments, 2017.

https://arxiv.org/abs/1706.02275

• Sunehag et al., Value-Decomposition Networks For Cooperative Multi-Agent Learning, 2017.

https://arxiv.org/abs/1706.05296

• Rashid et al., QMIX: Monotonic Value Function Factorisation for Deep Multi-Agent Reinforcement Learning, 2018.

https://arxiv.org/abs/1803.11485

• Yu et al., The Surprising Effectiveness of PPO in Cooperative, Multi-Agent Games, 2021.

https://arxiv.org/abs/2103.01955

• Baker et al., Emergent Tool Use From Multi-Agent Autocurricula, 2019.

https://arxiv.org/abs/1909.07528

• AlphaZero, OpenAI Five, AlphaStar self-play / population training literature.

#LLM Agents / Multi-Agent

• Park et al., Generative Agents: Interactive Simulacra of Human Behavior, 2023.

https://huggingface.co/papers/2304.03442

• Li et al., CAMEL: Communicative Agents for “Mind” Exploration of Large Scale Language Model Society, 2023.

https://huggingface.co/papers/2303.17760

• Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, 2023.

https://arxiv.org/abs/2308.08155

• Hong et al., MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, 2023.

https://arxiv.org/abs/2308.00352

• Qian et al., ChatDev: Communicative Agents for Software Development, 2023.

https://arxiv.org/abs/2307.07924

• Chen et al., AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors, 2023.

https://arxiv.org/abs/2308.10848

• Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023.

https://arxiv.org/abs/2305.16291

• Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023.

https://huggingface.co/papers/2303.11366

• Executable Code Actions Elicit Better LLM Agents, 2024.

https://huggingface.co/papers/2402.01030

• AutoDev: Automated AI-Driven Development, 2024.

https://huggingface.co/papers/2403.08299

#Benchmarks / Evaluation

• AgentBench: Evaluating LLMs as Agents, 2023.

https://arxiv.org/abs/2308.03688

• WebArena: A Realistic Web Environment for Building Autonomous Agents, 2023.

https://arxiv.org/abs/2307.13854

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, 2023.

https://huggingface.co/papers/2310.06770

• GAIA: a benchmark for General AI Assistants, 2023.

https://huggingface.co/papers/2311.12983

• AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents, 2024.

https://arxiv.org/abs/2401.13178

• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments, 2024.

https://arxiv.org/abs/2404.07972

• AgentGym: Evolving Large Language Model-based Agents across Diverse Environments, 2024.

https://arxiv.org/abs/2406.04151

• AI Agents That Matter, 2024.

https://huggingface.co/papers/2407.01502

• MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering, 2024.

https://arxiv.org/abs/2410.07095

• The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery, 2024.

https://huggingface.co/papers/2408.06292

• SWE-bench Goes Live!, 2025.

https://arxiv.org/abs/2505.23419

• AgentGym-RL: Training LLM Agents for Long-Horizon Decision Making through Multi-Turn Reinforcement Learning, 2025.

https://arxiv.org/abs/2509.08755

• MCP-AgentBench, 2025.

https://arxiv.org/abs/2509.09734

• SWE-ABS: Adversarial Benchmark Strengthening Exposes Inflated Success Rates on Test-based Benchmark, 2026.

https://arxiv.org/abs/2603.00520

#13. 自审修改记录

#问题 1：初稿容易变成论文列表

修改：

把报告重构为“问题链”：每个阶段都写“之前的问题—解决方法—新问题—如何推动下一阶段”，避免平铺论文。

#问题 2：LLM multi-agent 容易和传统 MAS 割裂

修改：

增加从 blackboard、Contract Net、BDI、ACL、机制设计到 AutoGen/MetaGPT 的连续线索，指出今天 planner-worker、role-play、tool orchestration 与早期 MAS 的继承关系。

#问题 3：容易过度吹捧 multi-agent

修改：

加入“multi-agent 是否真的比 single-agent 强”的专门讨论，强调 budget-controlled ablation、cost-normalized evaluation 和 agent contribution tracing。

#问题 4：MARL 与 LLM agent 的连接不足

修改：

专门加入 credit assignment、CTDE、self-play、population training 与 LLM agent long-horizon RL 的对应关系。

#问题 5：2024-2026 最新进展可能只列 benchmark

修改：

把最新进展按 framework、应用、评测、安全、长期自治几个维度组织，并指出 benchmark 从静态任务转向 live、OS、ML engineering、MCP 和 adversarial strengthening。

#问题 6：没有充分连接 wenjun 关注点

修改：

单独写研究机会判断，重点连接：

• 长轨迹 agent RL；
• model-based RL；
• latent-space reasoning；
• self-evolving code agent；
• agent 预训练数据分布；
• multi-agent evaluation 因果化。

#问题 7：安全和评测可信度不足

修改：

加入 benchmark contamination、test overfitting、虚假共识、权限扩散、prompt/tool injection、成本效率等问题，并引用 AI Agents That Matter、SWE-bench Live、SWE-ABS、OSWorld-Human 等趋势。

#14. 最终 takeaway

Multi-agent 的历史不是一串 buzzword，而是一条连续的难题链：

单体智能不够 → 多模块共享 → 任务分配 → 通信语义 → 激励机制 → 群体涌现 → 多智能体学习 → LLM 工具化 agent → 长期自治与自我进化。

今天 LLM multi-agent 最大的机会不在“多放几个角色聊天”，而在：

1. 让 agent organization 可学习；
2. 让长轨迹执行可训练；
3. 让环境反馈成为 reward；
4. 让 self-evolving memory 变成可验证能力增长；
5. 让 model-based / latent reasoning 支撑长程规划；
6. 让 benchmark 从静态 leaderboard 变成真实训练与验证环境。

如果要选最值得深入的研究方向，我会选：

面向真实代码库和工具环境的 self-evolving multi-agent code system：用 live issue streams 构造持续任务分布，用测试/CI/代码审查作为 grounded verifier，用 process reward 和 counterfactual credit assignment 训练长轨迹 agent policy，并研究如何把经验记忆压缩进模型能力。

这条线既承接 multi-agent 的历史核心问题，也最接近下一代 agentic foundation model 的真正瓶颈。