蚂蚁集团基于Ray的分布式AI Agent框架

深度解析：蚂蚁集团基于 Ray 构建的分布式 AI Agent 框架 Ragent

本文为您全面解读蚂蚁集团基于 Ray 框架构建的 AI Agent 框架——Ragent。我们将从背景、设计动机、核心架构到业务落地，逐步剖析这个强大的分布式智能体框架，帮助您掌握如何将 Agent 应用从原型高效推向生产环境。

导读

本文分享蚂蚁集团最新的基于 Ray 的分布式 Agent 框架——Ragent。核心内容涵盖：

• Background（背景）
• Motivation（动机）
• Design & Impl.（设计与实现）

相信许多开发者都了解 Ray，它是 OpenAI 用于大模型训练的底层分布式计算框架。蚂蚁集团早在多年前便深度参与 Ray 开源社区，今年的 Ray 夏季发布会上，其 CEO 特别提到蚂蚁是首个正式使用并协作开发 Ray 的企业团队。我们贡献了超过 26% 的 Ray 核心代码，位居全球第二大贡献者。目前，蚂蚁集团在线上运营着超过 150 万 CPU 核心，集群规模极其庞大，同时我们也负责运营 Ray 在中国的技术社区。

Ray 在蚂蚁集团的发展背景

简要回顾 Ray 在蚂蚁集团内部的发展历程：

• 2017 年：正式组建 Ray 技术团队。
• 2018 年：推出首个业务场景——流图计算引擎 Geaflow。
• 2018～2022 年（大数据时代）：基于 Ray 研发了多个计算引擎，包括用于流计算和机器学习训练的 Realtime、Mobius 开源引擎，以及支持在线推理和科学计算的 Mars 引擎。同时，贡献了 Multi-Tenant 架构（Ray 社区近期才开始考虑该架构，而蚂蚁因线上集群规模庞大，早已着手多租户设计）。
• 2023～2024 年（大模型时代）：在美国完成了 Unified AI Serving 项目，将离线处理、在线推理与 AI 部署整合为统一框架，这也是蚂蚁 150 万内核集群的核心业务场景之一。

01 Background：LLM-based Agent 的核心模块

首先，我们来了解基于大语言模型的 Agent（LLM-based Agent）通常需要具备哪些核心组件。

• Profile 模块：定义 Agent 的个性化特征，即它扮演的角色。例如，它可以是一个温和的旅游助手，负责行程管理、数据分析等任务。
• Memory 模块：包含两个部分：
  • Knowledge：行业知识与先验经验。
  • Experience：记录 Agent 过去的对话、用户问题、思考过程及行动结果，帮助 Agent 持续优化后续行为，避免重复错误。
• Planning 模块：用于将复杂任务拆解为更易执行的子任务。常用算法包括 Chain of Thought 和 Tree of Thought，类似于程序设计中的流程图。
• Action 模块：根据经验和规划执行具体操作。其关键功能之一是 Function Calling，使模型能够调用外部工具，甚至与机械臂等物理设备进行交互。

上述四个模块构成了 Agent 的基础能力框架。

案例：基于 Agent 实现的 RAG 流程

接下来，我们看一个基于 Agent 实现的简单 RAG 流程。与传统计算图或工作流不同，该流程完全通过 Agent 驱动。

1. Agent 从用户处获取任务，例如用户要求学习某个文档中的知识，并提供了文档链接。
2. 模型进入思考阶段，决定如何推进任务。可利用 planning 模块中的算法（如 React 或 Chain of Thought）。在本示例中，我们采用 React 策略：每思考一步，执行一步。
3. 模型决定具体行动。对于 RAG 场景，可借助 LlamaIndex 或 LangChain 解析文档，或调用 Lucene 与 VectorDB 进行语义检索，甚至实时搜索。
4. 将初始思考、所选行动及其结果作为三元组（triplet）存入 Memory，用于指导后续流程。
5. 持续循环思考与执行，直至完成用户任务。

需要特别关注的是，右侧的工具可分为三类：

• 红色的 LlamaIndex：属于计算密集型任务（CPU/GPU）。
• 绿色的 DB 和 Lucene 访问：属于磁盘 I/O。
• 蓝色的网络访问：属于网络 I/O。

Agent 任务中往往混合了这三种不同类型的计算负载，传统模式多处理单一 CPU 或 CPU+IO 场景，而单一 Agent 任务可能涉及复杂的混合工作负载。

从原型到生产：遇到的挑战

在完成基础 RAG Agent 的实现后，接下来的步骤是部署上线。首先将程序封装为服务并放入 Docker 中，然后进行部署。目前 Agent 平台上已有约 500 个 Agent，开发者可在平台上通过画布构建并发布各自的 Agent。

初期做法较为简单，但很快收到大量用户反馈：应用或 Pod 崩溃原因不明、缺乏监控指标、工作负载监控缺失、流量无法控制等。此外，由于混合工作负载的存在，GPU 利用率普遍偏低。总结来看，这种简单模式显然不适合生产环境。因此，我们决定对 Agent 平台进行分布式改造，实现真正的生产化部署。

02 Motivation：为什么选择 Ray？

相较于传统计算或服务型应用，Agent 应用具有高度的创造性和创新性，不断涌现颠覆性创意。每个创意都需要快速且低成本地验证。一旦 PoC 验证成功，便希望迅速上线，但这一过程充满挑战。上线应用涉及服务、数据库、数据源、分布式框架等多个模块，对大公司而言需要多团队协作，小公司则需掌握全部技术栈。因此，从 PoC 到上线的流程既繁琐又漫长。

在将 Ray 用于分布式 Agent 生产化的过程中，我们对比了三个技术层级：

• 底层 Kubernetes（K8S）
  • 优势：底层 API 灵活，可编写各类 CRD、整合多种硬件，提供完整的资源控制能力。
  • 缺点：从零开发 AI 应用复杂度高，多数机器学习工程师对 K8S 不够熟悉；AI 生态支持相对薄弱。
• 上层算法库 LangChain
  • 优势：功能丰富、易用性高，可一站式开发 Agent 或大模型应用。
  • 缺点：仅限于单机 API，面临诸多生产化挑战。
• 中间层 Ray
  • 优势：
    • 提供一站式工具箱，全面支持 AI 工作负载的数据处理、训练与推理。
    • 轻松将本地代码转换为分布式代码（仅需添加简单注解即可实现远程进程）。
    • 异构资源调度表现出色，尤其在 CPU 与 GPU 混合数据处理方面优于 Spark。
    • 不绑定特定计算范式，采用纯分布式面向对象编程，具备高度灵活性。
  • 不足：
    • 资源管控灵活度略低于 K8S（在 K8S 之上增加了一层抽象）。
    • 目前缺乏针对大模型的专用 API，部分外部组件需额外封装。

综合考虑后，我们最终选择了 Ray。此外，Ray 还具备以下加分项：

• RuntimeEnv 功能：提供运行时沙箱，可利用容器执行用户代码，非常适合大模型场景中的代码解释器，能直接启动 Docker 容器。
• 面向对象编程模式与 Agent 的工作方式高度吻合：Agent 的个性与配置可视为对象的静态资源，操作为成员函数，记忆则为运行时状态，Agent 本身就像一个对象。

确定使用 Ray 后，我们着手开发基于 Ray 的 Agent 框架——Ragent。主要设计考量如下：

1. 提供标准化的 Agent API。
2. 利用 Ray 实现从本地代码到支持异构资源的分布式扩展。
3. 在多 Agent 场景下，每个 Agent 作为一个分布式进程，需要框架统一协调这些进程（即 environment）。
4. 兼容不同 Agent 库（如 MetaGPT、AutoGen）。
5. 充分利用 Ray 的沙箱、批处理以及跨源调度能力。

03 Design & Impl.：Ragent 框架的设计与实现

在软件技术栈中，使用 Ray 可分为以下几个层级：

• 业务层：开发者已编写的 Agent 应用。
• Agent Crafting Platform：开发者构建 Agent 的可视化平台。
• 算法库层：如 LangChain、MetaGPT，提供与大模型相关的算法及文档解析能力（不在 Ragent 框架实现范围内）。
• Ragent：提供分布式 Agent SDK 和执行层，支持工具管理、记忆存储、环境管理、分布式通信及部署。Ragent 不实现具体算法，而是将用户代码分布式化，依赖 Ray 的核心概念如 Task、Actor 和 Object，利用 Ray 的编程原语实现分布式面向对象编程。
• Ray Data：用于批处理任务（如统一清洗和解析用户文档）。
• Reserve：Agent 的服务化部署。
• K8S：底层资源管理与调度平台。

使用 Ragent 编写一个 Agent

Ragent 将 Agent 定义为一个具备 Failover 能力的基础单元，内置消息队列与 Memory。由于存在多种 Planning 策略，Ragent 内置了 ReAct 算法，用于重复的思考与行动循环。如上图的简化代码所示，通过一个 while True 循环，每次先进行 reasoning（思考），获取 thought 和预期执行的 action，然后实际调用 action，持续在循环中执行。

Agent 的核心能力来源于其拥有的工具。要为 Agent 定制、加载或注册一个 tool，可通过注解实现。例如，在 Python 代码中，对 index_doc 函数输入文档，使用 Ray Data 和 LangChain 进行处理。通过 tool 注解 将该函数注册到 Agent 中，使 Agent 能够理解和调用。注册时需用自然语言清晰描述功能、输入输出及用途（类似于代码中的 doc string）。每个注册的 tool 会作为 prompt 的一部分输入到大模型，整个 Agent 本质上相当于一个 Ray Actor。

小提示：在注册 tool 时，请务必提供清晰、准确的自然语言描述。这能帮助大模型正确理解每个工具的功能，从而在 planning 阶段做出精准的工具调用决策。

实现一个简易的 RAG Agent

在 Ragent 框架中，实现一个简易 RAG Agent 只需几行代码：

1. 引入必要库后，在 main 函数中初始化一个 Agent，使用内置的 ReAct 算法，并指定大模型为 Qwen。
2. 在 profile 中赋予静态资源后，为 Agent 注册多个工具，例如 Apache Lucene 和 LlamaIndex。
3. 注册的 action 包括：使用 LlamaIndex 进行文档索引，Lucene 用于 Elasticsearch，以及 DB 进行语义搜索。这些工具共同构成一个简单的 RAG 系统。

完成初始化和注册后，Agent 即可与用户交互。用户首次请求可能是从 Ray 文档中学习最新功能，此时 Agent 会调用工具，将用户提供的文档索引到 DB 中作为知识储备。工具使用 Ray Data 实现，因此 Agent 将其作为 Ray Data 作业提交，批处理输出到 DB。随后，用户可对文档提问（例如询问 Ray 最新版本的 Ray Data 功能），Agent 从 DB 中进行字符和语义检索，经大模型处理后返回结果。整个流程仅需少量代码即可完成一个功能完整的 RAG Agent。

小提示：在实际生产中，建议为每个 Agent 设置合理的 Memory 大小和 Failover 策略，以应对复杂推理任务中的偶发错误。Ragent 内置的消息队列可帮助处理并发请求，提升系统吞吐量。

Multi-agent 示例：MetaGPT 分布式化

接下来看一个多 Agent 的实例。左图展示了 MetaGPT 的实现，演示如何利用多个 Agent 构建一个虚拟软件公司。每个 Agent 承担不同角色，如产品经理、架构师、代码工程师和测试工程师。对于编写贪吃蛇程序的任务，Agent 按顺序协作。产品经理借助工具生成设计图并交给架构师，架构师再创建技术架构图。工程师根据需求编写接口和实现代码，然后交给测试进行 UT，直至程序完成。

在 Ragent 框架中，我们实现了 environment 组件，用于 task 追踪，包含用户任务及每个 Agent 的子任务。它构建 workflow，通过 message queue 与 Agent 通信，并保存对话历史。每个 Agent 作为远程进程，由 Agent handler 管理。在代码中，我们先初始化 environment，然后初始化架构师、产品经理和 coder 等 agent，并对 MetaGPT 代码进行适配。初始化四个 Agent 后，将其加入 environment。每个 Agent 的功能已在 profile 和 system prompt 中定义，注册后 environment 知晓各 Agent 职责。目前仍需手动指定 Agent 交互顺序。加入后，环境运行应用，例如编写 FlappyBird 或贪吃蛇程序。实践中，GPT-4 表现较好，能构建设计图和部分可运行代码。

常见问题 1：在多 Agent 场景中，如何保证不同 Agent 之间通信的可靠性？

答：Ragent 通过内置的 environment 组件和 message queue（消息队列）来管理 Agent 间的通信。每个 Agent 作为独立的 Ray Actor 运行，采用异步消息传递模式。框架自动处理消息的顺序与持久化，确保在高并发或节点故障情况下通信的可靠性，同时支持日志记录与重试机制。

常见问题 2：Ragent 框架是否支持与其他 Agent 框架（如 AutoGen）集成？

答：是的。Ragent 的设计目标之一就是兼容不同 Agent 库。您可以通过适配器模式将 AutoGen、MetaGPT 等框架的 Agent 封装为 Ragent 的 Actor，并利用 environment 组件进行编排。框架提供了标准化接口（如 Agent Protocol），方便第三方框架的集成。具体实现可参考 Ragent 的示例代码，对外部 Agent 的创建与注册流程进行适配。

未来工作

以下是我们的后续规划：

• Agent Mesh：目前 Agent 框架众多，但缺乏统一的通信与流程标准。我们希望通过 Agent Protocol 项目制定统一协议，整合不同框架，构建类似服务网格的通信环境。
• 离在线一体架构：由于底层执行层均基于 Ray，在线与离线场景的技术栈一致，无需单独定制。在 Agent 场景中，文档处理等纯离线操作通过 Ray Data 实现，第一步可用 Ray Data pipeline 完成离线工作。对于单 Agent 或多 Agent 的二三步，可实现服务化，每个进程通过 Agent Protocol 封装，实现互相通信。该功能正在规划中。
• 底层硬件支持：目前对 GPU 需求不高，但已有厂商和开源社区希望支持更多 GPU 类型，如 NPU。以上即为我们的工作计划。

结语

Ragent 框架依托 Ray 的分布式能力，为 AI Agent 应用提供了从原型到生产的端到端解决方案。它显著降低了开发者构建分布式 Agent 的门槛，同时有效解决了生产环境中的资源管理、故障转移、混合负载等核心难题。通过本文的讲解，您已经全面了解了 Agent 的核心模块、Ragent 的设计动机以及具体的实现案例。希望对您构建自己的分布式 Agent 应用有所启发和帮助。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：蚂蚁集团基于Ray的分布式AI Agent框架要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题