Uni-Agent Gateway 重构 Agent 强化学习训练链路，黑盒系统也能无改造接入

在 Agentic RL 训练中，如何让不同形态的 Agent 系统统一进入强化学习训练循环，正在成为基础设施层的关键问题。VERL 生态近期出现的 Uni-Agent Gateway，正是围绕这一问题给出的工程化答案。该组件源于 VERL RFC #5790「Agent Abstractions and Trajectory Gateway for VERL」，其核心思路是在 Agent 与 RL 训练器之间加入一个 Token 级转换层，把 OpenAI 兼容的聊天 API 调用映射为带有精确 loss mask 的 token 轨迹，使 Agent 只需处理自身业务逻辑，不必感知底层训练对 token 级数据的约束。

从耦合到拆分：Gateway 解决旧架构的三类问题

在引入 Gateway 之前，VERL 的 Agent 训练主要依赖 AgentLoopManager 到 AgentLoopBase 的路径。RFC #5790 指出，这套旧架构把三类不同职责耦合在同一个组件中：LLM 基础设施管理、Agent 生命周期管理，以及轨迹采集。其结果是，每接入一个新的 Agent 框架，都需要在 agent loop 中编写专门的适配代码；轨迹采集逻辑也嵌入在 agent loop 内部，难以复用；框架原生只支持协程式 Agent，子进程和远程 Agent 只能依赖临时集成方式。

更深层的问题在于，VERL 原生支持的协程式 Agent 属于白盒场景，框架可以直接持有运行时状态；但面对黑盒 Agent，例如外部 CLI 子进程或远程 HTTP 服务，框架无法进入 Agent 内部采集 token 级轨迹。这样一来，白盒 Agent 与黑盒 Agent 实际上需要走两条完全不同的集成路径。

Gateway 的核心目标，就是用同一个 OpenAI 兼容 HTTP 接口统一这两类 Agent。RFC 的表述是，让任何 OpenAI 兼容的 Agent 系统都能接入 VERL 训练循环，而无需修改 Agent 代码。Uni-Agent 官方材料也将其概括为「Unified Gateway (Application), Plug in Any Agent Harness for RL Training」，即把任意 Agent Harness 接入 RL 训练。

两个新抽象：AgentFramework 与 AgentGateway 分离职责

RFC #5790 给出的方案，是把原有耦合结构拆成两个相互独立的新抽象：AgentFramework 与 AgentGateway。

• AgentFramework 是训练器侧的批处理编排器，负责 Agent 生命周期管理、批量编排、奖励计算和 DataProto 组装。它接收一批 prompts，为每个 sample 创建 Gateway session，驱动 Agent Runner 完成多轮对话，再从 Gateway 收回轨迹列表，交给 RewardLoopWorker 评分，最终写入 TransferQueue 供同步训练消费。
• AgentGateway 是 Agent 与推理后端之间的双协议桥。它既是可跨节点调用的 Ray actor，也是由 FastAPI 与 uvicorn 启动的 HTTP server，负责会话管理、token 编码、轨迹组装以及与推理后端交互。

这种拆分带来的关键效果，是 Gateway 不再隶属于 Framework，而是作为 serving runtime 的一部分存在。它不是简单增加一层适配器，而是重新划分了 trainer、serving 与 agent 三层之间的责任边界。Framework 不了解 Gateway 内部的轨迹组装逻辑，Gateway 也不关心当前调用它的是哪种 Framework，二者仅通过 Session API 交互。

素材显示，2026 年 6 月 1 日，经与 VERL 维护者讨论后决定，gateway 与 framework 模块不放入 VERL 主仓，而是落到 Uni-Agent 仓库，并通过 PR #25 合入。这意味着 Uni-Agent Gateway 可被视为该 RFC 的具体实现。

面向训练工程：拦截推理请求、维护会话状态、支持多后端

从工程实现看，Gateway 主要解决四类训练场景中的具体问题。

第一，保留 token 级轨迹。如果 Agent Runner 直接对接 vLLM、SGLang 等底层推理引擎，训练所需的 token 级轨迹数据可能丢失。Gateway 会在中间层拦截每次推理请求，在返回 OpenAI 兼容响应的同时，记录完整 token 轨迹，为后续训练提供必要数据。

第二，处理多轮会话状态。Agent 场景通常是多轮的：模型生成 tool_calls 后执行工具，工具结果再追加到 messages 中，继续下一轮推理。Gateway 会维护会话级状态，包括 message_history、active_trajectory、tool_schemas 等。当新请求的 messages 是历史 messages 的前缀时，Gateway 只编码增量部分，并复用已缓存的 token 序列，从而降低重复编码开销。

第三，支持黑盒 Agent 零改造接入。黑盒 Agent 的子进程在每轮对话中向 Gateway 发送完整 messages 列表，Gateway 通过前缀检测识别增量部分，只对新增消息进行 tokenize。这样既节省计算资源，也保证轨迹连续性。Agent 侧依旧按照 OpenAI API 规范发送请求，无需修改代码。每个 session 还拥有独立 URL 命名空间，例如 /sessions/{session_id}/v1/chat/completions 用于聊天推理，/sessions/{session_id}/reward_info 用于奖励元数据注入。黑盒 Agent 只需设置 OPENAI_BASE_URL，即可在不知情的情况下与 Gateway 通信。

第四，支持并发调度与推理后端解耦。训练场景下可能同时运行成百上千个 Agent Session，Gateway 通过 GatewayManager 在多个 GatewayActor 之间做最小负载调度，将 session 分散到不同节点，避免单点瓶颈。Gateway 也不绑定具体推理引擎，而是通过 VERL 提供的 LLMServerClient 抽象与后端交互，输入是 token_ids 与 sampling_params，输出是 token_ids、log_probs 与 stop_reason，使同一套 Gateway 代码可以适配不同推理后端。

对 Agent 训练基础设施的意义

Uni-Agent Gateway 的价值，不在于新增一个接口层，而在于把 Agent 强化学习训练中的责任边界重新划清。过去，Agent 框架适配、轨迹采集和推理基础设施常常混在同一套训练循环代码中，导致扩展成本高、黑盒系统难接入、轨迹逻辑难复用。Gateway 通过统一 OpenAI 兼容入口，把训练侧要求封装在 Agent 之外，让 Agent 开发者可以继续围绕业务逻辑构建系统，而不必为了接入 RL 训练改造内部实现。

对于希望构建 Agent 训练基础设施的团队而言，这种设计提供了一种更清晰的工程路径：训练器负责批量编排与奖励计算，serving runtime 负责推理请求转换与轨迹采集，Agent 本身只暴露标准接口。随着 Agent 系统形态日益多样，这类中间层可能会成为 Agentic RL 训练平台中的常见组件。