@anyscalecompute：大多数 Agent 框架解决了编排问题，却在基础设施方面完全未予解决。最新博文：面向生产的 AI…

大多数智能体框架仅解决编排问题，而将基础设施管理完全遗留。新博客文章：基于 Ray Serve、MCP 和 A2A 构建生产级 AI 智能体，其中大语言模型（LLM）、工具和智能体可独立扩展。九项服务，一条命令即可部署。https://t.co/8iEpdp8bTj — # 基于 Ray Serve 的 AI 智能体：从单智能体到多智能体架构 | Anyscale 来源：https://www.anyscale.com/blog/ai-agents-on-ray-serve-single-to-multi-agent-architecture 大多数智能体框架解决了编排问题——提示词链式调用、工具调用、记忆机制——但未能解决基础设施管理问题。一旦从单进程原型过渡到生产环境，就会立刻暴露出三个问题：计算密集型的 LLM 与轻量级的智能体逻辑无法独立扩缩容；每增加一个新工具就必须重新部署智能体；组合多个智能体时会导致通过共享导入产生紧密耦合。其结果是脆弱的单体架构，在生产流量下极易崩溃。

该挑战位于我们 4 月 22 日发布的 Anyscale Agent Skills 所讨论内容的一层之下。虽然 Agent Skills 侧重于打包和复用智能体能力，但本文聚焦于大规模可靠运行这些智能体所需的生产级基础设施。本文介绍了一种基于 Ray Serve、MCP（Model Context Protocol）和 A2A（Agent-to-Agent）协议的微服务化 AI 智能体方案。文中详细阐述了两个参考实现——单个使用工具的代理和一个多智能体系统——每个组件（LLM、工具、智能体）均作为独立自动扩缩容的 Ray Serve 应用运行。

为什么智能体基础设施很难

构建一个原型智能体只需几分钟。但将其部署到生产环境意味着必须直面底层的基础设施复杂性——涵盖计算编排、状态管理、可观测性、容错性、安全性，以及限流和 Token 预算等 LLM 特定考量——这些问题贯穿所有组件。大多数此类要求是任何分布式系统的基石，但有三个瓶颈是当前智能体构建方式所独有的：

**扩缩容只能整体进行。**在单体部署中，GPU 密集型 LLM 推理与轻量级 CPU 编排作为一个整体进行扩缩容。在流量激增时，你要么为了处理简单的智能体逻辑而过量配置昂贵的 L4 GPU（推高成本），要么导致 LLM 算力不足。在多智能体系统中，这一问题会进一步加剧：三个智能体共享一个进程意味着某个缓慢的研究查询会阻塞天气数据的响应。

**工具集成高度耦合。**将工具函数硬编码到智能体中意味着每新增一个工具都必须修改代码并重新部署。当天气 API 新增 get_air_quality 端点时，你希望智能体能在运行时动态发现它，而不是等待下一个发布周期。

**智能体组合脆弱。**当一个智能体通过直接导入函数委托给另一个智能体时，下游智能体接口的任何变更都会破坏上游调用方。目前缺乏智能体发现、版本控制或可追踪的智能体间通信的标准。

生产级智能体基础设施需要什么

这三个瓶颈只是更大范围缺失的表象：智能体框架处理的是编排逻辑，但生产级部署需要一个完整的基础设施层。下表梳理了任何生产级智能体平台都必须解决的核心需求——涵盖计算、运维、安全和连接性：

AI 智能体架构

下文介绍的架构直接满足了上述多项需求——通过独立自动扩缩容实现弹性伸缩，借助 OpenAI 兼容 API 实现框架解耦，通过 Ray Dashboard 指标提供可观测性，并利用故障隔离服务保障韧性——而 Anyscale 平台则在此基础上补齐了安全访问控制、受管连接性以及生产级可用性等关键环节。

架构一：带有 MCP 工具的单个智能体

单智能体部署（可通过模板 langchain-agent-ray-serve 获取）由三个 Ray Serve 应用程序组成。该架构将每个组件拆分为独立的 Ray Serve 应用，拥有独立的扩缩容、路由和故障域：

集成 Agent、MCP 与天气服务的 LLM 工具调用工作流

将 LLM 作为服务运行

LLM 作为专用的 Ray Serve 应用运行，利用 Ray Serve LLM 的 build_openai_app，将 vLLM 封装在 OpenAI 兼容 API 之后：

from ray.serve.llm import LLMConfig, build_openai_app

llm_config = LLMConfig(
    model_loading_config=dict(
        model_id="Qwen/Qwen3-4B-Instruct-2507-FP8",
        model_source="Qwen/Qwen3-4B-Instruct-2507-FP8",
    ),
    accelerator_type="L4",
    engine_kwargs=dict(
        max_model_len=65536,
        trust_remote_code=True,
        gpu_memory_utilization=0.9,
        enable_auto_tool_choice=True,
        tool_call_parser="hermes",
    ),
)
app = build_openai_app({"llm_configs": [llm_config]})

有两个标志位对智能体工作负载至关重要：enable_auto_tool_choice=True 让模型自主决定何时调用工具，而 tool_call_parser="hermes" 则用于解析 Qwen 的原生函数调用格式（Qwen3 Instruct 生成的是 Hermes 风格的工具调用）。64K 上下文窗口（max_model_len=65536）为包含多轮工具调用的对话提供了充足的缓冲空间。

将工具作为 MCP 服务器运行

我们不再将工具硬编码到智能体中，而是将其暴露为 MCP 服务器——这是用于运行时工具发现的开放标准。每个工具服务器都是一个无状态、水平可扩展的 Ray Serve 部署：

from mcp.server.fastmcp import FastMCP
from ray import serve

mcp = FastMCP("weather", stateless_http=True)

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Fetch a multi-period weather forecast for given coordinates."""
    # Calls the National Weather Service API
    ...

fastapi_app = mcp.streamable_http_app()

@serve.deployment(
    autoscaling_config={
        "min_replicas": 1,
        "max_replicas": 20,
        "target_ongoing_requests": 5,
    },
    ray_actor_options={"num_cpus": 0.2},
)
@serve.ingress(fastapi_app)
class WeatherMCP:
    pass

autoscaling_config 将部署的副本数在 1 到 20 之间进行扩展，目标是为每个副本维持 5 个并发请求。Fractional CPU 资源（num_cpus=0.2）允许调度器将大量 MCP 副本紧凑地放置在单个节点上，因为这些工作是 I/O 密集型而非 CPU 密集型。

智能体：LangChain 与动态工具发现

智能体使用 LangChain v1 的 create_agent，并通过 MultiServerMCPClient 在运行时从 MCP 服务器动态发现工具：

from langchain.agents import create_agent
from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.checkpoint.memory import MemorySaver

async def build_agent():
    mcp_client = MultiServerMCPClient({
        "weather": {
            "url": urljoin(WEATHER_MCP_BASE_URL, "mcp"),
            "transport": "streamable_http",
        }
    })
    tools = await mcp_client.get_tools()
    memory = MemorySaver()
    return create_agent(llm, tools, system_prompt=PROMPT, checkpointer=memory)

**注意：**此示例出于简洁使用了 LangGraph 的内存版 MemorySaver。生产环境应将其替换为持久化的 LangGraph 检查点保存器（如 PostgresSaver、SqliteSaver 或基于 Redis 的等效方案），以便对话状态能够耐受 Ray Serve 副本的重启。向 MCP 服务器添加新的 get_air_quality 工具后，智能体将在下次执行 build_agent() 时（例如在副本启动时）自动加载它——无需修改智能体代码。智能体本身被封装在一个 Ray Serve 部署中，并提供 /chat SSE 流式端点。

架构二：基于 A2A 协议的多智能体系统

多智能体系统（可通过模板 multi_agent_a2a 获取）在单智能体模式的基础上进行了扩展，包含三个通过 A2A 协议进行通信的专业化智能体：

• **Weather Agent：**通过天气 MCP 工具回答天气相关问题
• **Research Agent：**通过 Web Search MCP 工具（brave_search、fetch_url）执行网页研究
• **Travel Agent：**通过 A2A 协议编排上述两个智能体，创建结合天气信息的旅行计划

结合 Ray Serve 与 Anyscale 的多智能体 A2A 架构

为何选择 A2A 而非直接导入

当 Travel Agent 需要天气数据时，本可以直接导入 Weather Agent。但这会造成紧密耦合。A2A 通过 HTTP 边界和标准化发现机制解决了这一问题：

每个启用 A2A 的智能体都通过 AgentCard（在 GET /.well-known/agent-card.json 处提供服务）来声明其能力，并通过 REST 传输层的 POST /v1/message:send 端点接收任务（JSON-RPC 传输层则在根端点暴露等效的 message/send 方法）。Travel Agent 发现 Weather Agent 的能力后进行任务委托——全部通过标准 HTTP 完成。

数据流：一次旅行规划请求

当用户询问“规划为期两天的西雅图之旅”时，流程如下：

用户 → POST /travel-agent/chat “规划为期两天的西雅图之旅”
│
▼
Travel Agent (LLM 推理)
├─ “我需要天气数据和本地信息”
│   ├──→ a2a_research("西雅图景点、餐厅")
│   │   │
│   ▼
│   Research Agent (通过 A2A POST /a2a-research/v1/message:send)
│   ├──→ brave_search("西雅图热门景点") [Web Search MCP]
│   ├──→ fetch_url("https://...") [Web Search MCP]
│   └──→ 返回：摘要结果 + 来源 URL
│   ├──→ a2a_weather("西雅图本周天气预报")
│   │   │
│   ▼
│   Weather Agent (通过 A2A POST /a2a-weather/v1/message:send)
│   ├──→ get_forecast(47.6062, -122.3321) [Weather MCP]
│   └──→ 返回：预报数据
└──→ Travel Agent 综合两项回复
返回：结合天气建议的结构化行程单 + 来源

当 LLM 在同一轮助手回复中同时发出两个工具调用（并行工具调用，Qwen3 Instruct 及大多数现代函数调用模型均支持）时，create_agent 会使用 asyncio.gather 并发分发它们。每个下游智能体独立调用其 MCP 工具，这些工具进而调用外部 API。Travel Agent 并不了解 MCP、天气 API 或 Brave Search——它只知道自身挂载了两个工具：a2a_research 和 a2a_weather。

A2A 工具：将智能体视为工具调用

从 LLM 的角度来看，调用另一个智能体不过是一次普通的工具调用。Travel Agent 定义了两个基于 A2A 的工具：

from langchain_core.tools import tool
from protocols.a2a_client import a2a_execute_text

@tool
async def a2a_research(query: str) -> str:
    """Call the Research agent over A2A to gather up-to-date info and sources."""
    return await a2a_execute_text(RESEARCH_A2A_BASE_URL, query, timeout_s=360)

@tool
async def a2a_weather(query: str) -> str:
    """Call the Weather agent over A2A to get weather/forecast guidance."""
    return await a2a_execute_text(WEATHER_A2A_BASE_URL, query, timeout_s=360)

a2a_execute_text 辅助函数使用官方的 a2a-sdk REST 传输层发送阻塞消息并提取文本响应。360 秒的超时时间为下游智能体预留了充足的处理时间，因为它们可能在回复前需要执行多次工具调用（如研究查询、API 查找）。

智能体运行时：多智能体的工厂模式

由于三个智能体共享相同的样板代码（LLM 配置、MCP 发现、MemorySaver、Ray Serve 部署），多智能体代码库采用了一个带有工厂函数的共享智能体运行时：

# Weather agent: a few lines of unique code
async def build_agent():
    return await build_mcp_agent(
        system_prompt=PROMPT,
        mcp_endpoints=[_weather_mcp_endpoint()],
    )

agent_runtime/agent_builder.py 中的 build_mcp_agent 和 build_tool_agent 工厂函数集中处理 LLM 构建、MCP 工具发现和智能体创建。部署模块中的 create_serve_deployment 和 create_a2a_deployment 工厂函数负责 Ray Serve 的封装包装。各个智能体仅需专注于自身独特的逻辑：系统提示词和工具来源。

部署：一个 YAML，九项服务

单个 serve_multi_config.yaml 文件即可部署全部九项服务——1 个 LLM、2 个 MCP 服务器、3 个 SSE 智能体和 3 个 A2A 智能体——每项服务均配有独立的路由前缀、环境变量和扩缩容配置：