（来源：PaperWeekly）

© PaperWeekly 原创 · 作者 | 陈逸群

单位 | 中国人民大学博士生

研究方向 | 多智能体强化学习

UnityMAS-O 面向 Multi-Agent System（MAS，多智能体系统）提出一个通用强化学习优化框架：用户仍然可以自由定义角色、工作流、模型映射和奖励，但系统不再只停留在提示词工程和手工编排，而是对 MAS 内所有 Agent 进行联合 RL 优化。

https://arxiv.org/pdf/2605.26646

https://github.com/chenyiqun/UnityMAS-O

LLM 多智能体系统正在从单一模型调用，走向由 planner、searcher、coder、verifier、reflector 等角色协作完成复杂任务。

今天的很多 MAS 已经能通过提示词、工具和控制流跑起来，但优化方式仍然很原始。

角色由人手工设计，工作流由规则编排，训练时往往又退回到单模型、单策略或单个最终答案。系统看起来像一支队伍，优化接口却没有真正把 " 队伍 " 作为对象。

UnityMAS-O 针对的正是这个缺口。它的定位很明确：一个面向通用多智能体系统的强化学习优化框架。

它不是再提出一个固定的 agent workflow，而是尝试回答一个更底层的问题：只要用户能定义一个多智能体系统，能不能把它转化为可执行、可归因、可训练的多智能体强化学习问题？

换句话说，UnityMAS-O 希望让 MAS 不再只是提示词工程和手工编排，而是进入 " 工作流级优化 " 的阶段。

〓 图 1：UnityMAS-O 的框架抽象。用户可以自由定义角色、role-LLM 映射、工作流与奖励，并在同一接口下比较全共享、部分共享和全独立参数设置。

第一层核心思想来自框架抽象：UnityMAS-O 把 MAS 的自由度显式保留下来。

用户可以任意定义角色，例如规划、检索、证据抽取、求解、验证、反思；可以任意定义 role-LLM 映射，让多个角色共享一个模型、部分角色共享模型，或每个角色使用独立模型。

可以任意定义静态或动态 workflow，包括顺序、并行、分支、循环以及混合图结构；也可以任意定义 reward，在节点级、回合级或完整轨迹级给出稀疏、密集、延迟或边际改进奖励。

这套抽象里最重要的一点，是把 " 逻辑角色 " 和 " 物理参数 " 解耦。一个 searcher 或 verifier 是工作流中的逻辑节点，它有自己的输入输出、工具权限、停止条件和奖励含义；它背后由哪个 LLM 服务，则由 role-LLM 映射决定。

因此，同一个 MAS 可以在全参数共享、部分共享和全独立参数之间切换，而不需要重写工作流本身。这为研究专业化、协作、成本和训练稳定性之间的关系提供了统一入口。

奖励接口也被放在同一个框架中。检索问答里，上游 query decomposition、evidence extraction 和最终 answerer 可以共享最终 F1，同时叠加格式约束。

迭代搜索里，搜索、摘要和更新角色可以根据答案 F1 的边际提升获得奖励；代码任务里，planner 和 coder 因初始程序质量获得奖励，reflector 以及后续 planner/coder 则因验证分数的增量改进获得奖励。

这样，最终结果不再只是给最后一个回答者打分，而能回到真正影响结果的角色和回合。

〓 图 2：UnityMAS-O 的系统设计。中心控制器负责任务调度、轨迹记录和奖励组装，模型本地 worker group 负责生成、缓存、优势计算和策略更新。

第二层核心思想来自系统实现：为了让上述 " 任意性 " 真正跑起来，UnityMAS-O 采用了中心控制器加模型本地 worker group 的星型架构。

中心控制器维护全局工作流状态，负责调度角色调用、执行动态控制流、调用工具或环境、记录图结构轨迹，并在合适时机组装奖励。

每个 LLM worker group 只负责自己服务的物理模型，处理生成、token 级 rollout 张量缓存、advantage 计算和 PPO 风格更新。

这种设计背后的原则是：thin data 放在控制器，fat data 留在模型本地。控制器需要知道哪个角色在什么状态下被调用、产生了什么输出、获得了什么奖励。

但 log-prob、value、attention mask、token buffer 等重数据不必在系统中反复搬运，而是留在对应 worker group 中直接构造成训练 batch。

agent-LLM mapping 同时也是路由规则：角色映射到哪个模型，它的生成请求、奖励和训练片段就进入哪个 worker group。

基于这套运行时，UnityMAS-O 可以支持异步 rollout、动态 workflow 调度、模型本地 buffer、延迟奖励对齐、优势估计、策略更新以及权重同步。

它继承了 verl 的分布式 RL 训练能力，又在其上补上 MAS 需要的角色身份、图结构轨迹、奖励归因和参数共享机制。

也正因为这层系统设计存在，前面的任意角色、任意映射、任意 workflow、任意 reward 才不是概念描述，而是可以落到训练流程里的接口。

为了验证框架的有效性，我们在检索增强问答和反思式代码生成上进行了初步实验。QA 部分覆盖 Natural Questions 与 HotpotQA，并包含并行检索、检索 - 证据抽取 - 回答、M-ASK 迭代搜索三类 workflow。

结果显示，在所有评测的 QA 工作流和模型规模上，多智能体 RL 训练后的验证 F1 均优于训练前。

小模型收益尤其明显，例如 QD-Retrieve-Answer 在 NQ 上使用 0.5B agents 时从 0.022 提升到 0.445，在 HotpotQA 上从 0.032 提升到 0.397。

〓 图 3：问答和多轮搜索任务中的训练前后对比。多智能体 RL 在不同数据集、工作流和模型规模上带来稳定提升，小模型提升尤其明显。

参数共享实验给出了另一个关键结论。在 HotpotQA 的 M-ASK 设置中，3B 共享参数模型与 4x3B 独立模型从几乎相同的起点出发。

独立设置收敛更快，并在 step 1350 达到 0.529 F1；共享设置在 step 1400 达到 0.522 F1，step 1800 仍保持 0.520。

也就是说，共享参数会带来一定训练速度代价，但能接近独立多模型方案的最终效果，为资源受限场景提供了更现实的折中。

代码实验则展示了 planner-coder-verifier-reflector 闭环的优化效果。该 workflow 最多三轮，若提前通过测试则停止。

以 held-out test all-passed rate 衡量，3xQwen3-4B 从 0.255 提升到 0.686，3xQwen3-8B 从 0.290 提升到 0.738。

同时，模型并不是靠消耗更多验证轮次换准确率：两个设置训练前平均接近 2.5 轮，训练后最低分别降至约 1.76 与 1.68 轮。

〓 图 4：迭代式代码生成的训练曲线。UnityMAS-O 在严格的 held-out all-passed 指标上显著提升，并展示出可持续的训练收益。

这些初步结果说明，UnityMAS-O 的价值不只在于 " 能训练某个 workflow"，而在于提供了一个可复用的多智能体系统强化学习优化底座。

它把用户自定义 MAS 中最关键的四个自由度保留下来，又通过中心控制、模型本地数据所有权和角色级奖励归因把它们接入实际 RL 训练。

对于已经能通过提示词和工具编排跑通的多智能体系统，下一步问题将不只是 " 怎么设计 agent"，而是 " 怎么把整个 MAS 作为系统持续优化 "。

作者团队来自中国人民大学、小红书、上海人工智能实验室、中国科学院自动化所、清华大学、南加州大学等。项目由中国人民大学的陈逸群发起并主导，工作完成于陈逸群在小红书实习期间。