Matrix：点对点多智能体合成数据生成框架

论文信息

标题: Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework

作者: Dong Wang, Yang Li, Ansong Ni, et al.

发布日期: 2025-11-26

arXiv ID: 2511.21686v1

PDF 链接: 下载 PDF

3 分钟速览

研究问题：现有多智能体合成数据框架依赖中心化协调器，导致可扩展性瓶颈；或针对特定领域硬编码，难以灵活适配多变的生成需求。
核心方法：设计去中心化的「点对点」架构 Matrix，将控制流和数据流都序列化为消息，通过分布式队列传递，轻量级 Agent 推动任务，重型计算由独立服务完成，整体基于 Ray 构建。
关键结果：在相同硬件资源下，Matrix 的数据生成吞吐量达到现有方案的 2–15 倍，且未牺牲输出质量（见论文摘要）。
主要局限：框架强依赖 Ray 运行时；消息序列化在极高并发下可能引入开销；目前仅在三类合成场景中验证（多智能体对话、网页推理数据提取、客服工具使用轨迹生成）。
适合读者：从事大规模合成数据生成、多智能体系统、LLM 数据增强的工程师和研究者，尤其是分布式系统与人工智能交叉的人员。

论文背景和研究动机

合成数据在训练大语言模型（LLM）中的作用日益重要。当真实数据稀缺、昂贵或涉及隐私时，高质量合成数据成为关键的替代品。许多生成任务需要多智能体协作：多个专业化 Agent 各自贡献不同的技能或视角，共同产出更高质量、更多样、结构更丰富的数据。例如，一个对话数据集可能需要提问者、回答者和评价者三类 Agent 共同完成一条多轮对话；工具使用轨迹数据则需要规划 Agent 与执行 Agent 配合生成完整的推理链。

然而，现有的多智能体合成框架普遍存在两大问题。第一，大多数系统依赖一个中心化协调器（centralized orchestrator），由它统一调度各 Agent 的交互顺序和数据传递。这种主从架构在任务量激增时，协调器容易成为可扩展性的单点瓶颈，难以线性扩展至数万并发工作流。第二，很多框架的实现与特定领域深度绑定，例如专门为代码生成或特定任务对话设计，工作流硬编码在源码中，更换场景时需要重写大量逻辑，灵活性不足。

针对这些痛点，论文提出了 Matrix，一种去中心化的点对点多智能体合成数据框架。其核心思想是摒弃中央协调器，让每个任务实例通过分布式消息传递独立推进，从而实现水平扩展和高度模块化，适配多种数据生成流水线。

核心方法和技术细节

Matrix 的设计将合成数据生成过程抽象为一个状态机驱动的消息传递系统。整个框架由四类组件构成：

轻量级 Agent：每个任务（如合成一条对话）对应一个轻量的 Agent 实例。Agent 本身不执行重型计算，它仅维护任务的状态机，根据当前状态决定下一步需要调用哪个服务，并生成相应的请求消息。状态机定义了任务从初始化、逐步生成到完成的完整生命周期。
分布式队列：控制消息和数据消息都被序列化为标准格式，通过分布式队列在 Agent 与服务之间以及 Agent 与 Agent 之间传递。所有消息都是显式的、可序列化的，这保证了任务状态可以在任何节点上恢复或迁移。队列本身实现了点对点通信的抽象，彻底去除了集中式协调器。
重计算服务：LLM 推理、代码执行、网页渲染等资源密集型操作被封装为独立的分布式服务。这些服务监听队列中的请求消息，处理完成后将结果消息发回。一个服务可以同时为成千上万个活跃的 Agent 提供并发支持，且服务实例可以根据负载动态伸缩。
Ray 运行时：Matrix 直接建立在 Ray 分布式计算框架上，利用 Ray 的 Actor 模型和分布式对象存储来实现轻量 Agent 的创建、服务的部署以及消息队列的高效传输。Ray 提供的细粒度调度和分布式内存使 Matrix 能够轻松扩展到数万个并发 Agent 工作流，并保证低延迟的消息投递。

实际工作流程是：当一个数据生成任务启动时，Matrix 创建一个对应的 Agent，并分配一个全局唯一的消息通道。Agent 从初始状态开始，向某个服务发送请求消息（例如 “请生成一段客服对话的开场白”）。该消息进入队列后被服务消费。服务完成推理后将结果以响应消息发回给该 Agent。Agent 收到消息后更新自身状态，然后根据状态机决定下一步动作（例如转而请求另一个服务，或向其他协作 Agent 发送中间数据）。如此循环，直至任务结束。整个过程完全基于消息驱动，没有任何中央调度器介入，因此每个任务的推进速度只受自身状态转换和队列延迟的影响，系统整体吞吐量可以随节点增加近乎线性提升。

此外，Matrix 通过模块化配置来支持不同场景。用户只需定义一组 Agent 可用的 “消息契约” 和相应的状态机模板，并注册所需的服务，即可快速构建新的生成流水线，无需修改框架核心代码。

创新点和贡献

Matrix 的核心创新在于用分布式消息传递彻底替代中心化协调，这为大规模合成数据系统带来了三个显著贡献：

水平扩展性：因为不存在单点协调器，系统的瓶颈被分散到各个分布式队列和服务节点上。通过增加 Ray 集群的工作节点，可以几乎线性地提升并发处理能力。论文实验表明，即使在工作流数量达到数万规模时，吞吐量依然保持稳定增长。
领域无关的灵活性：将控制流和数据流都显式序列化为消息，使得不同领域的生成流程都可以通过组合相同的通信原语来实现。这种设计类似于 “微服务架构” 在数据生成领域的应用，Agent 的智能调度被解耦为独立的消息路由，极大降低了适配新任务的成本。
性能与质量的平衡：与现有集中式框架相比，Matrix 不仅带来了 2–15 倍的吞吐量提升，还强调了 “未牺牲输出质量”。这是由于生成过程本身仍由相同的 LLM 和逻辑驱动，Matrix 只是改变了流程编排的拓扑结构，并未改变模型推理的语义，从而在加速的同时保证了数据质量的等同性。

实验结果分析

论文在三个差异显著的场景中评估了 Matrix 的性能与通用性：

多智能体协同对话：需要多个角色 Agent（如客户、客服、监督员）交替生成多轮对话，对话长度和角色切换频繁，对状态管理的实时性要求很高。
网页推理数据提取：涉及从浏览器渲染内容中提取结构化的推理链，需要 LLM 推理与容器化浏览器服务紧密配合，计算负载波动大。
客服环境工具使用轨迹生成：模拟客服使用工具（如查询订单、退款）的过程，要求 Agent 根据工具返回的动态结果决定后续操作，轨迹长度可变，通常伴随复杂的条件分支。

在所有测试中，Matrix 与基于中心化协调器的基线方案使用相同的硬件资源进行对比。结果显示，Matrix 生成相同数量数据条目的吞吐量提高了 2 到 15 倍（见论文摘要）。这一提升幅度因场景的通信复杂度和计算密度而异。在通信和计算高度并行的场景下，Matrix 的性能优势更为突出，因为集中式协调器在调度密集的消息转发时极易成为瓶颈。

关于生成数据的质量，论文明确指出 Matrix 的输出质量与基线方案不分伯仲。这验证了去中心化架构没有引入信息丢失或流程偏差，只是单纯提高了生成过程的效率。需要说明的是，论文并未提供具体的质量评估指标（如 BLEU、人工评分等），但从描述可知实验确保了对比的公平性。

实践建议

Matrix 的去中心化设计为构建大规模合成数据管道提供了清晰的工程范本。对于希望在自身系统中复制类似架构的团队，可以从以下几个方面入手：

任务粒度的划分与消息化 将每条数据生成任务封装为一个独立的状态机，明确任务推进所需的所有中间步骤。把每一步的触发条件和产生的中间数据都定义为可序列化的消息。推荐使用 Protocol Buffers 或 Apache Arrow 等高效序列化格式，在保证跨语言兼容的同时降低序列化开销。
轻量 Agent 与重型服务分离 Agent 只负责维护状态和路由消息，不应直接执行 LLM 推理或执行第三方工具。将推理、代码执行等重型计算部署为 Ray Actor 或独立的微服务，由 Agent 通过异步消息调用。这样可以实现计算资源的经济调度，例如在低负载时缩减推理服务实例，高峰时自动扩展。
基于 Ray 的分布式队列实现 可以直接利用 Ray 的 Actor 信箱、分布式对象存储或集成 Kafka 等外部消息系统作为消息总线。关键是保证消息的可靠投递和顺序性（尤其是在同一任务内需保持因果顺序的场景）。论文中的队列设计可能利用了 Ray 的零拷贝共享内存传递，减少数据拷贝，这也是吞吐量提升的重要来源。
监控与弹性扩展 在真实生产环境中，应建立队列深度、Agent 处理延迟、服务实例负载等指标的可视化监控。当队列堆积超过阈值时，自动扩展服务副本；当 Agent 任务数量激增时，通过 Ray 弹性伸缩集群。同时考虑消息重试与死信队列机制，避免单个任务失败阻塞整体流水线（论文未详细描述容错，实践中需自行补充）。
场景适配的模块化策略 将不同场景抽象为可配置的「消息契约集合」和「状态机图谱」。可以先在小规模上验证消息协议的通用性，再逐步推广到全量任务。初期可选择与 Matrix 类似的合成对话或工具使用场景作为试金石，逐步积累可复用的 Agent 模板库。

总体而言，Matrix 提出了一条清晰的路径：通过去中心化、消息驱动的方式，让合成数据生成系统从 “集中调度” 走向 “自主协作”，从而在保持数据质量的前提下获得接近线性的吞吐量增长。对于正在面临数据供给瓶颈的 LLM 研发团队，这一架构思路极具落地价值。