核心组件#

LlamaDeploy 由多个核心组件组成，这些组件充当服务，以提供多智能体应用程序运行和相互通信的环境。本节详细介绍了每个组件，并将帮助您浏览其余文档。

部署#

在 LlamaDeploy 中，每个工作流都封装在一个 服务 (Service) 对象中，不断处理以 任务 (Task) 对象形式传入的请求。每个服务都会从 消息队列 (Message Queue) 拉取和发布消息。一个名为 控制平面 (Control Plane) 的内部组件负责处理进行中的任务、管理内部状态、跟踪可用的服务，并使用另一个名为 协调器 (Orchestrator) 的内部组件来决定哪个服务应该处理任务的下一步。

这些组件的一个明确定义的集合称为 部署 (Deployment)。

部署可以使用 YAML 代码定义，例如

name: QuickStart

control-plane:
  port: 8000

default-service: dummy_workflow

services:
  dummy_workflow:
    name: Dummy Workflow
    source:
      type: local
      name: src
    path: workflow:echo_workflow

更多详情请参见部署 Config 对象的 API 参考。

API 服务器#

API 服务器是 LlamaDeploy 的核心组件，负责同时提供和管理多个部署。它暴露了一个 HTTP API，可用于管理目的以及查询已部署的服务。您可以通过 llamactl 或 Python SDK 与管理 API 进行交互。

更多详细信息请参阅Python API 参考，管理 API 的文档如下。

控制平面#

控制平面负责管理系统的状态，包括：

注册服务。
管理会话和任务。
处理服务完成。
启动控制平面服务器。

系统的状态被持久化在一个键值存储中，默认情况下是一个简单的内存映射。具体来说，状态存储包含：

注册服务的名称和定义。
活动的会话及其相关的任务和事件流。
Context，如果服务类型是 Workflow。

如果您需要更具可伸缩性的存储来存储系统状态，可以将控制平面配置中的 state_store_uri 字段设置为指向我们支持的其中一个数据库（更多详细信息请参阅Python API 参考）。在以下情况下，通常需要使用可伸缩的存储来存储全局状态：- 您希望水平扩展控制平面，并希望每个实例共享相同的全局状态。- 控制平面需要处理高流量（许多服务、会话和任务）。- 全局状态需要在重启后持久化（例如，工作流上下文存储在全局状态中）。

服务#

服务的一般结构如下：

服务有一个名称。
服务有一个服务定义。
服务使用消息队列发送/接收消息。
服务有一个处理循环，用于持续处理消息。
服务可以处理消息。
服务可以将消息发布到另一个服务。
服务可以在进程内启动。
服务可以作为服务器启动。
服务可以注册到控制平面。
服务可以注册到消息队列。

消息队列#

除了 SimpleMessageQueue 外，我们还提供了对各种消息队列提供商的集成，例如 RabbitMQ、Redis 等。这些消息队列的一般使用模式与 SimpleMessageQueue 相同，但是需要与 llama-deploy 一起安装相应的额外依赖。

例如，对于 RabbitMQMessageQueue，我们需要安装 "rabbitmq" 额外依赖：

# using pip install
pip install llama-agents[rabbitmq]

# using poetry
poetry add llama-agents -E "rabbitmq"

然后，使用 RabbitMQMessageQueue 的方式如下：

from llama_agents.message_queue.rabbitmq import (
    RabbitMQMessageQueueConfig,
    RabbitMQMessageQueue,
)

message_queue_config = (
    RabbitMQMessageQueueConfig()
)  # loads params from environment vars
message_queue = RabbitMQMessageQueue(**message_queue_config)

注意

RabbitMQMessageQueueConfig 可以从环境变量加载其参数。

投递策略#

目前，服务副本接收消息以运行任务的方式取决于消息队列的实现：

SimpleMessageQueue：消费者之间竞争，但顺序是不确定的，第一个成功获取主题消息的订阅者（在此例中是第一个服务）获胜，所有其他订阅者将持续尝试并永远不知道消息已发布。
RedisMessageQueue：默认情况下，所有服务都会接收消息并运行任务。如果您将 RedisMessageQueueConfig 类的 exclusive_mode 配置参数设置为 True，则服务将竞争消息，只有第一个到来的服务能够读取它。
RabbitMQMessageQueue：消费者之间竞争，使用轮询策略选择接收者。
KafkaMessageQueue：与 RabbitMQ 类似，因为消费者的 group_id 是硬编码的。
AWSMessageQueue：技术上类似于 Redis，但消费者会从队列中移除消息，因此实际上是非确定的。

编排器#

编排器的一般想法是管理服务之间的消息流。

给定一些状态和一个任务，确定要发布的下一条消息。然后，一旦消息处理完毕，用结果更新状态。

任务#

任务是一个对象，代表发送到服务的操作请求以及将要发送回的响应。有关详细信息，请查阅API 参考。