Zetta [特殊字符]：一种自演化物理智能的高效闭环具身驾驭

硅谷秋水

326人浏览 · 2026-08-24 11:46:20

硅谷秋水 · 2026-08-24 11:46:20 发布

26年8月来自清华和Z- Brain的论文“Zetta 𝜁: An Efficient Closed-Loop Embodied Harness for Self-Evolving Physical Intelligence”。

具身智能体正日益被用于弥补端到端策略模型的不足。然而，智能体路径尚未在物理执行中实现闭环学习：现有的智能体平台大多仍是开环的，在部署过程中遵循固定的技能，仅在回合结束后才进行反思。这种事后反思无法在执行过程中进行有效控制，因为物理交互需要决策者以远超当前大型智能体模型的频率跟踪快速变化的机器人-环境状态。Zetta，一个闭环的具身智能体平台，它能够在保持基础策略冻结的同时，在线演化基于代码的运行时批评器和恢复技能。Zetta 通过三个时间尺度分离的循环，实现了动作频率控制、部署级别的批评器-恢复器建议以及验证门控的技能更新。 Zetta 与 Z-Infra（一种将智能体逻辑与异构执行资源解耦的部署基础设施）相结合，在当前的部署预算下，在 LIBERO-Pro 和 RoboCasa 上取得最先进的成功，准确率分别达到 90.8% 和 93.6%，推理速度提升了 11.1 倍；随着自主探索经验的积累，成功率持续提升；学习的技能可以零样本迁移，并且机器人能够清晰地展现出“顿悟时刻”。这些结果表明，闭环式自进化为可靠的物理智能开辟一条可扩展的路径。

如图1所示Zetta 具身自演化闭环：

这项工作的核心思想是引入基于代码的、可在线演化的闭环执行机制，根据动作和环境动态的变化来控制物理执行并触发智能体干预。基础策略模型被冻结，同时演化一个包含运行时执行机制的模型 𝐻 = {𝐶, 𝑅, 𝑇 }，以及相应的从部署中恢复的技能。具体而言，其提出三种不同时间尺度的循环来实现自我演化。首先，执行机制控制的动作循环以动作频率执行已学习的执行机制，并在必要时调用相应的恢复技能。其次，部署批量候选优化循环对每次迭代中的故障进行聚类和诊断，然后提出候选执行机制和恢复方案。由于技能和代码不提供梯度，其借鉴 SkillOpt 和 EmbodiSkill [46, 52] 来构建一个类似随机梯度下降 (SGD) 的优化过程，从而在代码空间中进行有界且稳定的更新。第三，验证门控技能更新循环仅允许那些能够提高成功率并在不同版本发布中泛化的候选技能和恢复技能，并将它们添加到技能内存中。第一个循环实现了闭环执行，而第二个和第三个循环则实现了自我演化。

1. 问题描述：双-智能体治理与演化架构

本文将长时程机器人操作任务形式化为一个受权限约束的治理与演化过程。该框架包含一个用于裁决的在线编排智能体和用于优化的离线演化智能体，从而在不改变底层策略参数的情况下实现闭环能力演化。

固定运行时组件

执行由两个核心实体驱动，它们的内部参数和逻辑在整个演化过程中保持不变：

动作策略 (𝜋)：给定观测值 𝑠_t 和目标 𝑔，它生成底层动作 𝑎_t = 𝜋(𝑠_t, 𝑔; 𝜃)，其中参数 𝜃 满足约束 ∇𝜃 = 0。
编排智能体 (A_𝑜𝑟𝑐h)：A_𝑜𝑟𝑐h 作为固定的多模态推理算子 [72–74]，充当高级指挥官，负责审核实时证据并批准模式转换。其决策逻辑在演化过程中保持不变。

可进化的驾驭（H）

驾驭H是进化过程的目标，它允许A_orch干预环境。

H ={𝐶,𝑅,T}

• 运行时评价器 (𝐶)：一组高频监控函数，持续扫描轨迹 𝜏_0:𝑡，生成结构化建议 𝑃_𝑡: 𝑃_t =𝐶(𝜏_0:t)=⟨𝑒_t,𝜎ˆ_t⟩，其中 𝑒_t 表示可审计的故障证据（例如，碰撞、停滞），𝜎ˆ_t 是建议的执行模式。
• 恢复手册 (𝑅)：一个结构化的策略库，映射到特定的故障机制，为裁决提供可操作的选项。
• 异构工具集 (T)：一组可执行工具和运算符（例如，规划器、抓取检测器、恢复模块）[75–77]，可在演化过程中生成、实例化、选择和优化。该工具集演化以满足评价器 𝐶 的监控需求和恢复手册 𝑅 的恢复逻辑，使系统能够获取并调整其执行能力，而不仅仅是调整预定义工具的参数。

权威层级：在线裁决逻辑

在执行过程中，最终的运行模式 𝜎（VLA 或 WAM 时 𝜎 = 0，专用工具时 𝜎 > 0）由裁决函数确定：

𝜎_𝑡 = A_𝑜𝑟𝑐h(𝑃_𝑡, 𝑅, T, K)，

其中 𝑃_t 是来自评价器 𝐶 的实时提议，K 代表任务知识上下文，包括预定义的里程碑、成功标准和环境约束。该协议强制执行证据驱动的决策：尽管评价器 𝐶 以高频率运行，但只有当证据 𝑒_t 被 A_orch 验证并接受时，才允许进行干预。

离线优化：进化智能体

为了优化 H，本文引入进化智能体 A_𝑒𝑣𝑜 作为离线改进的驱动力。A_𝑒𝑣𝑜 通过分析失败的部署数据 D_𝑓𝑎𝑖𝑙 来迭代地改进驾驭组件：

H^(𝑘+1) ← A_𝑒𝑣𝑜 (D^(𝑘)_fail, H^(𝑘))

A_𝑒𝑣𝑜 从失败证据提取因果机制，生成修复块，摘要局部经验进入版本化驾驭。其通过重建可行的感知（C）和动作（R，T）空间来修正A_orch 的运行时行为。

优化目标 Zetta 的最终目标是找到最优配置 H∗，使预期任务成功率 𝐽 最大化，同时保持 𝜋 和 A 不变。

如图 2 所示Zetta进化框架概览：
请添加图片描述

2. 系统挑战与设计原则

为了解决当前基于冻结视觉-语言-动作（VLA）策略的具身人工智能系统的局限性，提出三个核心挑战，这些挑战也正是 Zetta 框架设计背后的驱动力。

挑战 1：冻结基础模型中存在的开环语义-物理鸿沟。最先进的 VLA/WAM 模型虽然拥有强大的语义理解能力，但在推理过程中却以开环前馈策略的形式运行 [3, 4, 16, 78]。它们缺乏闭环感觉运动感知能力，无法实时纠正物理执行错误（例如，物体滑移、轻微碰撞）。因此，由于策略无法监控或调整自身的物理状态，轻微的干扰往往会引发任务的彻底失败。

Zetta 设计原则：高频状态治理。通过解耦的高频运行时评论器（C）来增强冻结的 VLA/WAM 模型。这些批评者运行速度高于行动策略的推理速度，持续监控物理执行状态，并在偏离标称分布的最早迹象出现时触发干预，从而将系统转变为闭环治理模式。

挑战 2：过度参数化修复的泛化陷阱。确定物理故障的根本原因非常复杂。临时调试通常会导致“过拟合”的修复——调整底层控制参数以强制修复特定故障实例[79-81]。虽然此类修改可以解决当前故障，但会破坏对 VLA 语义泛化至关重要的行动分布，导致未见过的保留种子出现严重的性能下降，从而牺牲全局泛化能力。

Zetta 设计原则：分层因果诊断以实现最小干预。其实现严格的自顶向下分层因果诊断逻辑。诊断智能体 A_diag 按优先级顺序遍历各层：从 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑖𝑜𝑛 → 𝐶𝑟𝑖𝑡𝑖𝑐 → 𝑆𝑡𝑎𝑡𝑒 → 𝑃𝑙𝑎𝑛𝑛𝑖𝑛𝑔 → 𝑅𝑒𝑐𝑜𝑣𝑒𝑟𝑦 → 𝑃𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟.[82–84] 遵循“如果高层逻辑解决了故障，就永远不要修改底层参数”的原则确保补丁应用于最小有效层，从而维护基础模型的完整性。

挑战 3：专家在环调试的可扩展性。依靠人类专家手动分析和修补长尾任务分布中的每个故障实例成本高昂，且根本无法扩展 [85–88]。这种方法无法应对通用操作中固有的无限初始条件变化。

Zetta 设计原则：自动化进化泛化。用全自动进化学习循环（循环 1-3）取代手动调试。进化智能体 A_𝑒𝑣𝑜 自动地将种子特定的故障抽象为基于任务不变量的通用驾驭（harness）。此外，强制执行的保留泛化协议在严格隔离的测试集上验证整合后的驾驭，从而实现稳健治理策略的自动化扩展。

3. 第一阶段：实证故障分析与基线建立（循环 1）

在演化周期的初始阶段，对预定义的开发种子集 D_dev 进行大规模的 Action 策略 𝜋 采样。目标是在不进行任何治理干预的情况下，通过纯粹的 VLA 闭环执行来建立性能基线。由此得到的原始语料库定义为 B_𝑟𝑎𝑤 ={𝜏^(𝑗) |𝑠𝑒𝑒𝑑_𝑗 ∈ D_𝑑𝑒𝑣}。

确定性调度与执行协议。为了确保实证的严谨性和可复现性，循环 1 通过以下两个确定性维度来实施严格的基础设施管理：
• 确定性路由：所有部署任务均通过集中式资源调度器进行调度。调度器根据计算节点（例如，4090 GPU 池）的实时负载和内存阈值来路由任务。此机制确保批次内的所有部署都在相同的软件容器、模拟器版本和硬件配置下运行，从而消除环境异构性带来的观测噪声。
• 有效性确定和隔离：系统明确区分基础设施故障和策略故障。其定义一个有效性函数 Valid(𝑠𝑒𝑒𝑑_𝑗) ∈ {𝑇𝑟𝑢𝑒, 𝐹𝑎𝑙𝑠𝑒}。只有当部署完成并包含完整的传感器数据和视频证据时，该部署才会被包含在有效部署集 V 中：V = {𝑠𝑒𝑒𝑑𝑗 ∈ D_𝑑𝑒𝑣 | Valid(𝑠𝑒𝑒𝑑_𝑗) = 𝑇𝑟𝑢𝑒}。对于基础设施无效的尝试（例如，网络波动、模拟器崩溃），将使用原始逻辑种子强制执行重新运行策略，直到生成有效轨迹为止，以确保 V 的统计分布不会因非策略因素而漂移。

多维证据采集：对于每个有效的展开 𝜏^(𝑗) ∈ V，系统采用仅追加（append-only）模式来保留完整的观测流。完整的轨迹实例 𝜏^(𝑗) 表示为多模态时间序列：

𝜏^(𝑗) ={(𝑠_t,𝑎_t,𝜇_t,𝜙_t)}^𝑇,

其中 𝜇_t 表示特定任务语义里程碑的完成状态，𝜙_t 捕获生理辅助信号，例如碰撞强度和接触力矢量。

分类与索引：生成的语料库被处理成两个核心存储库，用于进化智能体 A_evo：

成功参考索引 (𝐼_𝑠𝑢𝑐𝑐)：成功轨迹 V_𝑠𝑢𝑐𝑐 ⊂ V 按里程碑聚合。该索引揭示了任务成功的“正太分布”，可作为识别偏差的基准。
失败种子清单 (M_𝑓𝑎𝑖𝑙) 和第一个缺失里程碑 (𝑚∗)：所有不成功的样本及其证据链被编译成清单。为了定位失败发生的任务阶段，引入第一个缺失里程碑 (𝑚∗)。给定一个有序的语义里程碑序列 𝑀 = ⟨𝑚_1, 𝑚_2, . . . , 𝑚_𝑔𝑜𝑎𝑙⟩，𝑚∗ 定义为序列中第一个在轨迹历史中未观察到的元素。引入 𝑚∗ 有两个目的：为失败事件提供粗粒度的聚类准则，并通过将 A_diag 的重点放在从 𝑚∗ − 1 到 𝑚∗ 过渡期间的证据上，来缩小因果诊断的搜索空间。

演化环：从数据到应用。基于对演化智能体的形式化描述，其运行逻辑通过三部分流程实现：诊断 (A_diag)、修复 (A_repr) 和泛化 (A_gen)。该结构确保从原始故障数据集 M_fail 中系统地提取因果知识。作为流程的起点，A_diag 的首要任务是识别故障的根本原因机制。

4. 第二阶段-第一步：故障聚类和因果诊断

机制级故障聚类和中心点种子选择

诊断首先对循环 1 中产生的故障种子清单 M_fail 进行结构分析。

A_diag 不采用基于最终结果的表面分类，而是基于最早可观测发散 (EOD) 对种子进行聚类。将 𝑡_EOD 定义为轨迹 𝜏 ∈ M_fail 中状态分布偏离由 𝐼_succ 描述的“健康”分布的第一个时间步。利用 𝑡_𝐸𝑂𝐷 及其上下文（包括第一个缺失里程碑 𝑚∗、机器人-物体相对位姿和活动的工具 ID），A_diag 将 M_fail 划分为互斥的簇 K = {𝐾_1 , 𝐾_2, . . . , 𝐾 _n}，其中每个 K_i 包含具有相似故障特征的种子点。为了降低计算开销并提取机制不变量，为每个簇选择一个中心点 seed_med。seed_med 定义为特征空间中距离簇中心最近的样本，它作为深入因果诊断的主要对象。

单视角接地的观察协议。为了消除多模态模型中的空间推理不一致和多视角幻觉[89–91]，A_diag 遵循严格的单视角接地协议：
• 主视角选择：智能体必须首先从可用的视频流中指定一个主视角，该视角定义为能够最清晰地显示末端执行器、目标物体和关键接触界面的角度。
• 证据一致性：一旦确定了主视角，诊断过程中的所有视觉推理都必须以此为基准。如果主视角提供的证据不足，系统必须回退到内部模拟器状态、传感器轨迹和物理信号 𝜙_t 进行跨模态验证，而不是切换视角，从而确保空间逻辑一致性。

自顶向下的分层因果诊断

对于选定的 𝑠𝑒𝑒𝑑_med，A_diag 在诊断层空间 L = {𝐿_𝑒𝑣𝑎𝑙, 𝐿_𝑐𝑟𝑖𝑡, 𝐿_𝑠𝑡𝑎𝑡𝑒, 𝐿_𝑝𝑙𝑎𝑛, 𝐿_𝑟𝑒𝑐𝑣, 𝐿_𝑝𝑎𝑟𝑎𝑚} 上执行系统的自顶向下检查逻辑。任务是通过找到优先级最高的层 𝐿∗ 来定位根本原因，使得：

𝐿∗ = argmax_𝐿∈L { IsRootCause(𝐿) | 来自 𝜏 的证据，主视角}

检查顺序遵循以下层级优先级：

评估层 (𝐿_𝑒𝑣𝑎𝑙)：检查成功标准或里程碑进度逻辑中是否存在错误。
评判层 (𝐿_𝑐𝑟𝑖𝑡)：确定运行时评判器 𝐶 是否存在漏报或误报。
状态表示层 (𝐿_𝑠𝑡𝑎𝑡𝑒)：验证对象姿态或接触信息是否与物理真实值存在偏差。
规划/控制层 (𝐿_𝑝𝑙𝑎𝑛)：分析 VLA 策略或工具是否在状态正确的情况下未能处理物理约束。
恢复层 (𝐿_𝑟𝑒𝑐𝑣)：如果故障发生在恢复期间，则检查剧本逻辑是否存在缺陷。
参数层 (𝐿_𝑝𝑎𝑟𝑎𝑚)：检查特定的控制增益或动作阈值。

集群一致性和修复规范。在确定 𝑠𝑒𝑒𝑑_med 的 𝐿∗ 后，A_diag 会验证该机制在 𝐾_i 的其他成员中的一致性。最后，智能体会为每个已验证的机制输出一个修复候选规范，详细说明局部层、因果证据链以及更新线束组件（C、R、T）的功能要求。

5. 第二阶段-第二步：基于评论家的框架修复与验证

此阶段由修复智能体 A_repr 主导，其目标是实现一个最小驾驭补丁 H_𝑝𝑎𝑡𝑐h = {𝐶∗, 𝑅∗, T∗}，以解决诊断过程中识别出的特定根层 𝐿∗，同时严格保持基础操作策略 𝜋 的完整性。

驾驭组件实例化和重入逻辑

A_repr 首先实例化诊断规范中规定的必要治理组件。这涉及对驾驭进行有针对性的更新：
• 评论家增强 (𝐶∗)：开发或改进高频监控功能，旨在检测故障的特定先兆条件，并在出现偏差时生成结构化建议𝑃_t。
• 恢复方案制定 (𝑅∗) 和工具调整 (T∗)：定义可操作的恢复方案，并调整或综合可执行工具以解决根本故障机制。

至关重要的是，为了确保安全无缝的集成，A_repr 在 R* 和 T* 的恢复逻辑中嵌入一个严格的 VLA 重入合约。该合约定义逻辑谓词 Ψ(𝑠_𝑡)，它决定何时将控制权交还给基础策略 𝜋_VLA。只有当原始故障证据 𝑒_t 被明确清除且物理状态已达到平衡状态（由稳定的接触力定义）时，才允许进行控制权交接。此谓词定义为：

Ψ(𝑠_𝑡) = 𝟙(FailureCleared) ∧ 𝟙(Stability(𝑠_𝑡) > 𝛾)

其中，FailureCleared 项是一个布尔函数，用于验证构成证据 𝑒_t 的特定条件（例如，碰撞风险或姿态偏差）是否已通过恢复操作完全解决。同时，“稳定接触”项评估生理辅助信号 𝜙_t，以确保机器人与物体之间的连接达到物理平衡。具体而言，稳定性(𝑠_𝑡)测量接触扭矩振荡和抓取力的大小，而 𝛾是一个稳定性阈值，确保VLA安全接管，防止瞬态动态效应导致的二次故障。该合约作为一项关键保障措施，防止策略恢复时因不稳定性触发二次故障。

闭环验证协议和成功标准

实现后，补丁 H_patch 在原始中心点种子上进行严格的两步闭环验证。首先，诊断回放确认增强的判别器 𝐶∗ 现在能够正确识别发散点 t_EOD。其次，从初始状态执行新的闭环展开。只有当任务达到目标里程碑，且所有干预措施均由 A_orch 正确裁决，并符合重入协议时，修复补丁才被视为已验证并成功通过：

Success(H_𝑝𝑎𝑡𝑐h) = 𝟙(𝜇_𝑇,𝑛𝑒𝑤 = 𝑚_𝑔𝑜𝑎𝑙 ∧ ∀𝑡 ∈ Intv, Adjudicated by A_𝑜𝑟𝑐h)

其中 𝜇_T,new 是新轨迹的最终里程碑，Intv 代表干预间隔。已验证的补丁及其证据随后将提交给 A_gen 进行多种子整合。

6. 第三阶段：框架整合、打包和泛化

在演化周期的最后阶段，泛化智能体A_gen 将经过验证的、特定于种子的补丁转换为一个稳健的、统一的治理框架。其目标是将局部修复抽象为机制级的不变式，从而能够解决整个故障集群 K_i，最终形成一个版本化的合并驾驭 H_mereged。

机制整合与工具打包

A_gen 执行跨种子分析，将异构补丁 H_patch,j（对于 𝑠𝑒𝑒𝑑_j ∈ 𝐾_j）整合为一个单一的、一致的配置 H_𝑚𝑒𝑟𝑔𝑒𝑑 ={𝐶_𝑚𝑒𝑟𝑔𝑒𝑑, 𝑅_𝑚𝑒𝑟𝑔𝑒𝑑, T_𝑚𝑒𝑟𝑔𝑒𝑑}。此过程将治理逻辑从特定实例提升为通用机制，并将其封装到可移植的标准化文件结构中。

整合算子将局部经验抽象为任务不变量：
• 批判者统一：将各个监控功能抽象为统一的批判者 𝐶_merged。通过对触发条件应用逻辑 OR 运算并动态调整噪声阈值，𝐶_merged 确保在集群中各种初始条件下都能可靠地检测故障。
• 恢复集成：将种子特定的恢复手册抽象为 𝑅_merged，它概括操作序列以处理相同故障模式的不同形态，并标准化 VLA 再入合约 Ψ(𝑠_𝑡)。
• 工具集扩展：扩展异构工具集 T_merged，使其不仅包含经过调整的现有算子，还包含新合成的工具。这些可执行脚本封装在维修阶段生成的专门物理技能（例如，高精度阻抗控制），以解决超出基础 VLA 能力范围的限制。

从数学角度来看，这种整合被定义为：

H_𝑚𝑒𝑟𝑔𝑒𝑑 = Consolidate ( {H_𝑝𝑎𝑡𝑐h, 𝑗 | 𝑠𝑒𝑒𝑑_𝑗 ∈ 𝐾_𝑖 } )

为了确保这些演进功能的可移植性和版本控制，A_gen 将治理逻辑外化到一个独立的包中，并将组件映射到不同的目录：
• 𝑆𝐾𝐼𝐿𝐿.𝑚𝑑：声明了高级治理逻辑，包括已定义的里程碑 𝑀、编排器裁决规则和广义重入谓词 Ψ(𝑠_𝑡)。
• 𝑡𝑜𝑜𝑙𝑠 /: 包含演化后的批评家 𝐶_merged 和工具集 T_merged 的可执行实现和脚本。
• 𝑝𝑙𝑎𝑛𝑠 /: 存储通用恢复策略 𝑅_merged，将特定证据映射到结构化的干预策略。
• 𝑝𝑎𝑟𝑎𝑚𝑠 /: 保存定义运行时执行的通用数值边界和阈值的配置文件。

严格的泛化验证和过渡协议

最终验证驾驭 H_𝑚𝑒𝑟𝑔𝑒𝑑 必须通过双重评估协议满足严格的性能标准，以确认其真正的泛化能力。

历史回归和预留数据集评估。首先，该驾驭需要进行历史回归测试，要求其以100%的成功率成功解决源集群𝐾_i内所有失败的部署：

∀𝑠𝑒𝑒𝑑_𝑗 ∈ 𝐾_𝑖, Success(𝑠𝑒𝑒𝑑_𝑗 | H_𝑚𝑒𝑟𝑔𝑒𝑑) = 1

其次，为了验证其更广泛的适用性，该驾驭在严格隔离的数据集D_held-out上进行预留数据集评估。演化的有效性通过相对于基准 VLA 策略的成功率增量 Δ𝑆𝑅 来量化：

Δ𝑆𝑅 = 𝑆𝑅(D_h𝑒𝑙𝑑−𝑜𝑢𝑡 | H_𝑚𝑒𝑟𝑔𝑒𝑑) − 𝑆𝑅(D_h𝑒𝑙𝑑−𝑜𝑢𝑡 | 𝜋_𝑉𝐿𝐴)

动态过渡协议。只有当 H_𝑚𝑒𝑟𝑔𝑒𝑑 在先前未见过的数据上表现出稳健的性能时，演化迭代才被认为是完成的。如果对 D_held-out 的评估揭示新故障机制，从而触发对 H_merged 的修改，则系统将强制执行严格的数据隔离策略。原始的保留种子将被重新分类为开发种子 (D_𝑑𝑒𝑣 ← D_𝑑𝑒𝑣 ∪ {𝑠𝑒𝑒𝑑_𝑓𝑎𝑖𝑙𝑒𝑑 })，并且必须选择一个全新的、之前未见过的数据集进行最终验证，然后才能结束迭代。

闭环机制能够充分利用自我探索带来的学习效果。这种学习过程也使得部署吞吐量成为智能扩展的速率限制因素：环境是学习数据的来源，因此更快的部署速度能够带来更快的演化。为此，其提出并实现 Z-Infra，一个专为自演化具身智能体设计的部署基础设施。它通过独立的环境和模型工作池、批量推理、模型分区和异步调度，将智能体逻辑与异构执行资源解耦。这种设计使得同一智能体能够在不同的机器、加速器、模型和环境中扩展，而无需将其逻辑绑定到特定的硬件配置。

1. 概述

部署基础设施是上述自演化具身智能体的执行骨干。其主要职责是在异构计算资源上高效地执行大规模并行部署（完整的智能体-环境交互过程），同时为上层智能体逻辑提供一个简洁统一的接口。

单个部署过程如下：智能体首先请求一个会话，该会话会在合适的仿真环境中配置一个隔离的环境实例，然后发出重置调用来初始化一个交互过程。主执行循环迭代：智能体观察环境状态，并调用 policy_step 来查询策略模型以获取动作，或根据需要调用感知模型和基本操作。此循环持续进行，直至终止（成功、失败或超时），此时会话被释放。

自演化智能体并发运行多个此类部署，探索不同的任务，测试已学习的技能，并收集经验以进行反思，因此高效地复用共享计算资源至关重要。尽管这项工作主要考虑了 LIBERO [6] 和 RoboCasa [2] 使用的以 CPU 为中心的 MuJoCo [92]/robosuite [93] 协议栈，但具身模拟也包括 GPU 并行 MuJoCo 后端，例如 MJX [94] 和 MJLab [95]，以及基于 PhysX 的协议栈，例如 SAPIEN/ManiSkill [96, 97] 和 Isaac Sim/Isaac Lab [98, 99]。

部署接口旨在适应这些后端差异，同时向智能体呈现相同的会话级交互模型。

2 挑战和关键思想

上述智能体部署工作负载带来了两个根本性的基础设施挑战：

资源异构性。单个部署同时需要多种计算资源。对于以 CPU 为中心的模拟，MuJoCo/robosuite 环境维护每个会话的模拟状态，并在环境步进期间消耗主机 CPU 和内存，而它们传统的渲染管线通常使用 GPU。 GPU并行仿真后端则在加速器上批量推进环境，对状态布局、重置语义、渲染和设备内存的要求各不相同。策略模型需要GPU加速器进行自回归或基于扩散的动作生成，并需要GPU内存来存储计算特征[100, 107, 125, 126]。轻量级感知模型[59, 60, 76, 77, 101–104]可以共享GPU资源，但对延迟的要求不同。基本操作（坐标变换、碰撞检测）是纯CPU计算，延迟预期在微秒级。这些工作负载对工作线程和调度的要求各不相同，因此没有单一的资源池或调度策略能够适用于所有这些工作负载类型。

执行动态性。与具有可预测数据并行模式的训练流水线不同，智能体部署展现出本质上不可预测的执行特性。智能体会根据运行时观察结果动态选择要调用的工具。一个时间步可能只需要一次策略调用，而下一个时间步则可能需要将感知、规划和多个基本操作串联起来。智能体在探索任务、反思失败并使用修改后的策略重试时，会以不规则的时间间隔创建、暂停和销毁会话。这导致 GPU 推理需求呈突发性，批处理大小和到达间隔时间变化很大，使得静态资源分配和请求调度效率低下。

核心思想：解耦抽象层。通过引入一个抽象层来应对这些挑战，该抽象层将智体逻辑与硬件资源管理完全解耦。智能体仅与虚拟部署接口交互——指定要执行的内容（哪个模型、哪个环境、哪个操作），而无需关心执行发生的位置或方式。该基础设施独立处理工作节点分配、请求路由、批处理形成和硬件映射，从而能够在多节点、多 GPU 集群上实现透明扩展，而无需更改智能体代码。这种职责分离使得每一层都能独立优化：智能体开发人员专注于任务逻辑和技能组合，而基础设施工程师则优化调度、批处理和硬件利用率。

3 系统架构

基础设施分为三层（如图 3所示），每一层都负责执行流程中的一个不同环节。“控制平面”作为所有智能体交互的单一入口点，提供统一的 API，该 API 抽象了后端异构性，并处理请求路由和资源分配。“环境工作层”管理跨不同系列仿真环境的生命周期和执行，包括会话配置、环境步进和观测数据捕获。“部署工作层”为 VLA/WAM 策略和感知模型提供 GPU 驻留模型服务，采用动态调度实现批量推理，以在可变请求模式下最大化吞吐量。这些层通过有界异步通道进行通信，从而强制执行反压机制，并支持跨多节点 GPU 集群的透明扩展。

请添加图片描述

控制平面

控制平面作为基础设施的协调中心，将智能体逻辑与分布式资源管理解耦。它公开了一个统一的 API，根据请求类型（环境操作或模型推理）和资源需求（环境系列、模型类型）将每个请求路由到相应的工作节点池。网关维护一个全局会话注册表，跟踪会话与环境工作节点等级之间的绑定关系，从而实现高效的请求分发，而无需智能体管理工作节点拓扑。工作节点的健康状况通过定期心跳进行监控：当环境工作节点发生故障时，网关会检测到超时，将受影响的会话标记为“丢失”，并将故障通知返回给智能体，智能体随后可以在健康的工作节点上重新创建会话。

环境工作节点

环境工作节点层旨在解决大规模管理异构仿真环境的挑战，同时保持会话隔离并最大化资源利用率。每个环境工作节点都是一个分布式 Actor，托管多个环境槽位，每个槽位绑定到一个活动会话并维护其自身的执行状态。该层必须支持具有不同 API（重置签名、观察结构、动作格式）和执行模型（CPU 子进程与 GPU 批处理模拟）的多样化环境族，同时向控制平面提供统一的接口。

基于会话的生命周期管理。引入会话抽象来支持长时间的智能体-环境交互。每个会话封装了一个独立的执行上下文，绑定到 Env Worker 上的特定环境槽位，并经历一个定义明确的生命周期：创建 → 运行 → 终止。创建时，网关会根据资源可用性和环境族兼容性选择合适的 Env Worker，分配一个槽位，并将会话句柄返回给智能体。

网关维护的会话注册表实现了高效的资源统计和准入控制。系统始终能够准确了解每个环境族有多少个活跃会话，它们在各个工作节点上的分布情况以及剩余的租约期限。当工作节点达到饱和时，系统会通过反压信号拒绝新的会话请求，从而防止级联过载。

为了引入新的环境系列，开发者通过声明式注册框架实现四个基本操作：(i) init——根据配置字典构建环境；(ii) reset——根据任务特定参数重置为初始状态；(iii) step——执行动作并返回观测值、奖励和终止标志；(iv) obs_schema——声明观测值的结构和编码。一个归一化层将特定于环境系列的观测值转换为规范格式（包含已声明形状和数据类型的命名张量字典），从而确保上层代码与环境系列无关。

资源共享组。对于使用基于 MuJoCo 的环境（例如 LIBERO [6]、RoboCasa [2]）的并行基准测试部署，实现一种资源共享优化，该优化将模型编译和渲染上下文设置的成本分摊到多个会话中。资源共享组是具有相同环境结构和配置的会话的执行单元。该组将环境模型编译成一个 ModelTemplate，其中包含可重用的只读 mjModel 表示以及初始模拟状态。每个槽位都通过从该模板创建 fork 原语进行初始化，从而允许该组重用不可变的模型资源，同时每个槽位维护其自身的 mjData 和 episode 状态。这使得共享的模型结构与可变的模拟状态分离：重置或单步执行一个槽位不会修改组中任何其他槽位的状态。

该组还拥有槽位所需的执行资源。每个槽位都被分配给一个带有线程本地渲染上下文的固定工作线程，而这些上下文属于一个共享的渲染上下文组，从而允许兼容的 GPU 渲染资源在槽位之间重用，而不会发生跨线程上下文冲突。为了使这种资源共享在多线程执行下有效，环境步进例程使用高性能 C++ 控制器重新实现，该控制器结合了控制执行、动作插值、物理子步和渲染，同时最大限度地减少了 Python 端的开销。在关键路径上释放 GIL 后，多个槽位可以在同一个工作进程中并行推进其物理和渲染工作负载。

推演工作者

推演工作者（Rollout Worker）层旨在应对在动态、突发性请求模式下服务各种神经网络模型的挑战，同时最大限度地利用 GPU。每个推演工作者都是一个驻留在 GPU 上的 Actor，它执行批量推理并异步返回结果。Worker 被组织成专门的池：策略模型占用专用的高内存 GPU，而轻量级感知模型则位于共享 GPU 上。该层必须在吞吐量（更大的批次可以分摊 GPU 内核开销）和延迟（请求不应无限期等待）之间取得平衡，同时还要处理兼容性约束（只有模型类型、输入模态和张量形状匹配的请求才能一起批处理）。

调度器。推演工作者的调度器管理推理请求从到达到结果交付的整个生命周期，并跨 GPU 驻留 Worker 池进行管理。收到推理请求后，调度器首先根据模型标识、输入模态和张量形状将其分类到相应的兼容性组，然后将其放入每个组对应的请求队列中。调度器监控工作进程的负载，并以先到先得 (FCFS) 的方式将批量请求分派给可用的工作进程，以确保较高的整体资源利用率，同时保持较低的单次请求延迟。当一个 Rollout 工作进程完成一个批次时，它会使用路由令牌标记每个结果，并将其发布到共享结果通道；发起请求的环境工作进程通过令牌匹配检索结果，从而实现完全异步的请求-响应模式，避免阻塞。

模型划分。现代 VLA/WAM 架构（例如，π0.5 [3]）由两个功能不同的阶段组成：视觉语言模型 (VLM) 将观察结果和指令编码为潜表示，以及动作专家 (AE) 通过扩散或自回归生成将这些表示解码为运动指令。这两个阶段具有显著不同的计算特性。利用这些不同的特性，将 VLM 和 AE 作为具有独立调度策略的独立进程进行部署。 VLM 的中间激活值通过 CUDA IPC 在 VLM 和 AE 进程之间传输，以避免昂贵的传输开销。对于用 PyTorch 实现的 π0.5 模型，与单体部署相比，这种分区策略将平均推理延迟降低了 53%，并将吞吐量（在 200 毫秒 SLO 下）提高了 2.4 倍。

量化运行时。为了提高策略推理吞吐量和 GPU 内存效率，引入量化（例如 W8A8、W4A16、W4A8）作为推演工作者的可选插件。与常见的 LLM 服务框架 [105, 106] 中的模型级量化不同，其对策略模型中的不同模块进行单独量化，这与模型分区协同设计，旨在平衡策略的成功率和推理效率。对于 RTX 4090 上的 π0.5，目前对计算密集型的 MLP 前缀模块应用 W8A8 量化，同时将其他模块保持在 BF16 以避免额外开销，从而在 LIBERO 上实现了 1.18 倍至 1.32 倍的推理速度提升，且未降低成功率。

实现

该基础设施基于 Ray [108] 构建，用于分布式执行。每个环境工作者和推演工作者都是一个 Ray Actor，封装了各自的运行时逻辑，并通过放置策略声明资源注解。用 Ray 的放置策略将每个 Worker 绑定到一个专用的 GPU/CPU。例如，声明 placement: “0-7” 会分配 8 个 rank，每个 rank 映射到一个 GPU（例如，单个节点上的 8 个 A100，或者在多节点设置中分布在多个节点上）。每个 rollout rank 加载模型的独立副本，从而实现跨 rank 池的数据并行推理。

跨三层的通信围绕五个有界Ray通道构建，这些通道划分了控制流和数据流。命令和控制通道将生命周期操作和优先级信号从网关路由到环境工作节点，而结果通道则反向返回步骤结果。

推理请求从环境工作节点流向一个共享通道，所有滚动工作节点均可竞争性地使用这些请求，从而实现负载-觉察分发；响应通过嵌入式token路由回网关。

4. 编程支持

该基础架构提供一个分层编程模型，旨在最大限度地减少智能体开发人员的认知负担，同时保留对高级用例的充分灵活性。该模型围绕以下三个核心抽象构建：会话代表具有受管理生命周期的长期环境实例；回合在会话中从重置到终止运行；步骤在回合中执行单个操作。智能体通过简洁的 API 进行交互，该 API 透明地处理批处理、异步推理和资源管理——开发人员指定他们想要的功能（例如，“在这些环境中执行此策略”），基础架构则确定如何高效地调度工作进程、批处理请求和路由结果。

API 概述。表 1 总结向上层智能体公开的核心 API，分为五个类别：会话管理处理环境生命周期（创建、续订、关闭）；观察与状态提供环境内省；底层控制执行电机命令（笛卡尔伺服、夹爪控制）；策略执行集成模型服务（policy_step 用于原子性的观察-推理-步骤操作，run_episode 用于自主执行）；感知与规划提供高级服务（分割、抓取生成、运动规划）。所有 API 都支持跨多个会话的透明批处理。
请添加图片描述

执行流程。清单 1 展示跨越三个基础架构层的 policy_step 调用。从智体的角度来看，交互很简单：创建一个会话，重置 episode，然后循环执行 policy_step。在内部，网关将每个步骤路由到会话的环境工作器 (Env Worker)，该工作器将推理请求与路由token打包，并将其提交到共享通道，然后让出服务于其他会话。滚动工作器 (Rollout Worker) 拉取请求，执行批处理推理，并通过token将结果路由回。然后，环境工作器执行环境步骤并返回结果，从而完成整个流程，而同一工作器上的其他会话则继续执行。
请添加图片描述