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和动作RT空间来修正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 描述的“健康”分布的第一个时间步。利用 _ 及其上下文包括第一个缺失里程碑 ∗、机器人-物体相对位姿和活动的工具 IDA_diag 将 M_fail 划分为互斥的簇 K {_1 , _2, . . . , _n}其中每个 K_i 包含具有相似故障特征的种子点。为了降低计算开销并提取机制不变量为每个簇选择一个中心点 seed_med。seed_med 定义为特征空间中距离簇中心最近的样本它作为深入因果诊断的主要对象。单视角接地的观察协议。为了消除多模态模型中的空间推理不一致和多视角幻觉[89–91]A_diag 遵循严格的单视角接地协议• 主视角选择智能体必须首先从可用的视频流中指定一个主视角该视角定义为能够最清晰地显示末端执行器、目标物体和关键接触界面的角度。• 证据一致性一旦确定了主视角诊断过程中的所有视觉推理都必须以此为基准。如果主视角提供的证据不足系统必须回退到内部模拟器状态、传感器轨迹和物理信号 _t 进行跨模态验证而不是切换视角从而确保空间逻辑一致性。自顶向下的分层因果诊断对于选定的 _medA_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将结果路由回。然后环境工作器执行环境步骤并返回结果从而完成整个流程而同一工作器上的其他会话则继续执行。1. 实验设置用配备 8 个 NVIDIA GeForce RTX 4090 GPU 的高性能集群在 LIBERO-Pro [1] 和 RoboCasa [2] 基准测试集上评估该框架从而实现并行部署和加速离线演化。在这些实验中用特定的预训练模型作为底层冻结的基础策略• LIBERO-Pro 基准测试采用 0.5 模型作为基础策略。• RoboCasa 基准测试采用 GR00T N1.5 [4] 模型作为基础策略。在所有实验中部署时的演化过程不涉及对这些基础 VLA 模型的权重进行微调。对于 RoboCasa 和 LIBERO-Pro遵循严格的泛化评估协议演化完成后最终的框架将在一个独立的、严格隔离的测试种子集上进行评估这些种子集在整个演化和开发过程中从未被演化智能体接触过。各基准测试的具体实现细节如下RoboCasa随机分布泛化。该测试评估框架在具有挑战性的长尾分布下的泛化能力开发和测试均采用随机采样的种子。设置对于每个任务随机采样 50 个环境种子用于开发和演化。演化和修复循环在每一轮中从这 50 个种子中收集故障轨迹并根据故障特征进行聚类。对于每个故障聚类选择代表性的中心点种子用于诊断和修复开发。最终评估保留集完成后在另一组严格隔离的 50 个 RoboCasa 环境种子与开发集不相交上进行最终评估以报告最终成功率。LIBERO-Pro开发-测试泛化。该测试评估框架从开发集泛化到完全未知的任务环境的能力。设置对于每个任务随机抽取 50 个开发种子父种子不包括种子 1-20用于进化。进化周期和修复基于 50 个开发种子的轨迹聚类针对失败率最高的聚类中的错误种子进行修复开发。迭代持续进行直到这些特定开发种子的成功率达到 ≥ 50%。最终评估保留完成后仅对严格隔离的种子 1 至 20 进行最终评估并报告其成功率 (SR)。2. 物理智能“顿悟”时刻为了验证 Z-Harness 是否通过物理智能而非额外的策略训练实现能力的断续提升分析各个外循环周期内的细粒度进化轨迹。实验展示“顿悟”时刻——系统通过识别和解决任务的真正物理瓶颈从停滞不前的性能过渡到高成功率的实例。通过追踪单个故障集群演化过程中选定的累积内部版本之间的成功率以经验方式定义“顿悟”时刻。这些检查点v0、v1、v2代表进化智能体在离线诊断和修复过程中进行的中间改进而非单独的外循环部署或额外的VLA训练。基础VLA策略始终保持不变。通过对RoboCasa和LIBERO-Pro代表性任务的案例研究证明了以下几点早期修复停滞不前早期修订通常只能带来微小的提升因为它们只针对局部症状或过度拟合特定的故障事件导致性能停滞不前。瓶颈识别真正的“顿悟”时刻发生在智能体识别出将VLA执行恢复到其域内区域所需的关键物理状态变量例如抓取保持、末端执行器重新校准或语义接近几何形状时。不连续扩展解决这一根本瓶颈可使成功率急剧、不连续地增加这表明该工具获得了可重用的具身智能而不是针对特定任务的轨迹调整。