评估 PolySim 统一物理后端设计：UniLab 能借鉴什么、不该照搬什么

[TATP-233]

背景

PolySim（本地调研副本基于 HumanoidVerse/ASAP 二次开发，论文 arXiv:2510.01708）提出了一种"统一物理后端"设计，核心卖点是 multi-simulator dynamics randomization：单次训练 run 内同时从 IsaacGym / IsaacSim / Genesis 起并行环境，把"引擎差异"当作 domain randomization 的一个维度，以对抗 simulator inductive bias。本帖对照 UniLab 现有后端体系（src/unilab/base/backend/base.py 的 SimBackend + 5 个后端 + sim2sim 契约），评估其设计对 UniLab 的借鉴价值。

PolySim 设计要点（事实陈述）

• 薄抽象接口：BaseSimulator（humanoidverse/simulator/base_simulator/base_simulator.py，约 170 行），非 abc.ABC，以 raise NotImplementedError 表达约 15 个生命周期方法（setup / load_assets / create_envs / prepare_sim / refresh_sim_tensors / apply_torques_at_dof / simulate_at_each_physics_step 等）。
• 属性级隐式契约：比方法更实质的契约是一组 torch 张量属性（dof_pos / robot_root_states / contact_forces / _rigid_body_*，全部 (num_envs, ...)、四元数 xyzw），env 层直接读写这些属性（例如直接改 simulator.robot_root_states 再写回）。
• 数据布局：torch 张量跟随训练 device（通常 CUDA）；IsaacGym 用 gymtorch.wrap_tensor 零拷贝驻留 GPU；四元数序、link 顺序映射等转换逻辑内联在各后端的 refresh_sim_tensors。
• 控制抽象：唯一控制入口是纯力矩 apply_torques_at_dof；P/V/T 控制律（含 PD）在 env 层实现。
• 跨引擎组合：每个引擎一个 subprocess.Popen（各自独立 conda 环境，绕开引擎间 import 冲突）+ Torch RPC/TensorPipe；EnvClient 把多个 server 聚合为单个向量化 env——action 按 num_envs_list 切片并发下发，obs/reward 沿 batch 维 torch.cat 合并，info 按 env 数加权，对 PPO 完全透明。
• 后端选择：Hydra _target_ 直接实例化，无 registry；+simulator=isaacgym 切换。
• 资产：robot YAML 同时声明 urdf_file / usd_file / xml_file，config 是唯一事实源；仅 IsaacGym 后端在 load 后断言资产与 config 的 dof/body 名与限位一致，其余后端 fail-open。
• 一致性验证：无单元测试目录、无跨后端 parity 测试门禁；一致性靠人工对齐 config + sim2sim eval 工作流（论文式评测协议）；代码演进靠带日期的快照副本（如 genesis_0903.py）。

与 UniLab 现状的对照

维度	PolySim	UniLab
接口形态	~170 行薄接口 + 属性隐式契约	SimBackend（约 1100 行）：抽象方法 + fail-closed 可选方法 + 显式类型（BackendSensorView / DomainRandomizationCapabilities / BackendPlayCapabilities）
边界数据	torch on CUDA，直达 env 层	numpy at boundary（quat wxyz），torch 转换在 algo 层（ADR-0001 三段式零拷贝模型）
并行模型	后端内 batch + 跨引擎 RPC 进程级共训	后端内 batch；isaacgym 子进程 + shm（Python 3.8 解释器约束驱动，非共训驱动）
后端能力差异	无能力声明，fail-open	能力显式声明（DR capabilities、play capabilities），不支持即 NotImplementedError
跨后端一致性	人工对齐 + 单后端 assert + eval 协议	fail-closed：sim2sim.py DENYLIST 快照 + scripts/audit_sim2sim_contracts.py + conformance/AST 静态测试
演进方式	日期快照副本、无测试	ADR + 契约文档 + 测试门禁

评估

两者在解不同的问题。 PolySim 的目标是"异构引擎共训"（把引擎 inductive bias 当 DR 维度），UniLab 的目标是"后端可替换 + 跨后端 play 一致性"（sim2sim transfer）。接口形态差异是目标差异的后果，不是优劣本身。

值得借鉴的：

1. Multi-sim 共训这个概念本身。UniLab 已有 mujoco / motrix / mjwarp / isaacgym 多个训练后端，substrate 已存在；PolySim 证明了"引擎差异即 DR 维度"在 humanoid motion tracking 上有实证收益。
2. EnvClient 聚合模式：把多个异构 sim 进程呈现为单个向量化 env、对 algo 透明，这个分层与 UniLab 的 runner/collector 分层在概念上兼容（可视为 collector 的一种多源实现）。
3. 薄接口的接入成本：其 Genesis 后端仅约 430 行。说明当目标只是"能跑起来采数据"时，最小内核接口（root/dof state + contact + torque）确实够用。

不应照搬的：

1. 属性级隐式契约。env 层直接读写后端内部张量表示，等于把后端内部布局变成公共 API。UniLab 的 getter 方法 + BackendSensorView 校验虽然"重"，但换来可静态检查、可 fail-closed 的边界（由 tests/base/test_backend_conformance.py 的 AST 检查守护）。
2. fail-open 的一致性治理。PolySim 只有 IsaacGym 做资产↔config 断言，其余后端不校验；MuJoCo 后端的 PD 增益硬编码在物理步内，env 层出现对特定后端（maniskill）的特判——这正是 UniLab 明令禁止的 feature leakage，且在 PolySim 里没有制度性防线。
3. 每引擎一个 conda env + RPC 的运维形态。这是被 IsaacGym/IsaacSim 的 import 冲突逼出来的方案，不是主动设计。UniLab 的进程内 registry + owner YAML 路由对同进程可共存的后端（mujoco/motrix/mjwarp/drake）运维成本显著更低；isaacgym 的 subprocess + shm 已经覆盖了"解释器不兼容"这一真实约束。

如果 UniLab 要引入 multi-sim 共训，两条候选路径：

• 路径 A（runner 层聚合，推荐讨论）：参考 EnvClient，在 collector/runner 层把 N 个不同后端的 vec env 聚合为一个逻辑 batch。不动 SimBackend 契约，复用现有各后端能力声明；obs/reward 合并点集中在 runner。预计规模：新增一个 multi-backend collector + config 表达（约几百行 + 测试）。长期成本：跨后端 obs 对齐仍受 sim2sim DENYLIST 约束——这是好事，共训时 obs/action 契约本应 fail-closed。
• 路径 B（backend 层 hetero-batch）：让一个 SimBackend 实例内部承载异构引擎。会击穿现有"后端 = 单一引擎"的抽象，污染 DR/set_state 语义，不推荐。

无论哪条路径，前置工作都是把 sim2sim 契约从"play 时校验"扩展为"共训时 obs/reward/action 对齐校验"，并补跨后端 parity 的测试门禁（PolySim 的教训：没有门禁的约定一定会漂移）。

待 maintainer 决策的问题

1. Multi-sim 共训是否进入 roadmap？它定位为研究方向（验证引擎差异作为 DR 维度的收益）还是产品能力（常驻支持）？
2. 若进入，是否接受"仅 runner 层聚合、不动 backend 契约"作为边界？
3. 跨后端共训时，现有 DENYLIST 语义是否足够，还是需要新增"共训专用"的更严格契约集（例如 reward 尺度也必须一致）？