随着HIL-SERL¹、RLT²和τ0-WM³等工作越来越获得具身领域的关注，强化Reinforcement学习 Learning - RL 正在成为具身智能落地的共识方法。然而，虽然在 LLM 时代，RLHF / RLAIF 已经被证明是把“人类偏好”规模化地灌进模型的最强武器。但放到具身智能里，这套打法缺困难重重：

• 监督成本根本不在一个量级。 LLM 的偏好标注可以众包、可以异步，几秒一条；具身的轨迹标注需要懂任务的人看几分钟甚至几十分钟的视频，而且常常要回头看上下文。
• 环境是异构且长尾的，评价做成了手工业。 同样叫“叠衣服”，在 UR5e 桌面臂上、Franka 移动操作上、双足人形上的轨迹长得完全不一样，reward function 手写一个废一个——所以现有工作普遍是“每个任务一个 reward / 每个模型一个 critic”，相当于把“评价”做成了手工业，永远 scale 不上去。
• “对”和“好”不是同一个问题。 仿真器可以告诉我们任务成没成，但“安全、流畅、可推广”是 reward function 很难写出来的部分，也正是具身智能规模化落地最缺的部分。

我的设想是：把“评价”从手工业做成一个独立的、专门被训练出来的子系统。它和 Policy 解耦、和 Env 解耦、和具体任务解耦，但同时又能接住来自真机的所有监督信号。这就是后面要讲的 Critic Agent——本质上是个“工具池 + 调度器”，SAM、YOLO、OpenCV、VLM 这些都能被它调用。核心靠遥操接管和失败数据回流让 Critic 自己变强，实现极少人在环的规模化训练。当这套闭环跑通，一个人就可以“喂养”起一整个具身 RL 训练工厂。

能Scalable的Critic范式

四个角色，各自被推到极致:

关键不变量:这套范式里，人的注意力是常数，Env 的数量、训练机数量、训练时长都可以 scale，只有 Critic 本身在变强。

Critic as an Agent

这是整个设想和现有工作最不一样的地方。

为什么 Critic 不应该是一个固定模型

Critic 不再是"单一模型"这件事，其实在 LLM 领域早就已经是共识了。

拿 Coding Agent 举例：一个完整的评价链路通常包含好几种机制⁴——Linter 做代码风格检查、单元测试执行器判断功能正确性、静态分析工具扫安全漏洞、LLM-as-Judge 做语义评分，甚至还有基于规则的测试通过率门控⁵。每一层都是不同的工具、不同的判断逻辑，没有谁会把它们合成一个网络去学⁶。更直接的一个例子是 SWE-bench⁷这类评测——模型写的代码能不能解决真实 GitHub Issue，核心判断来自 Docker 容器里跑 pytest，而不是来自一个训练出来的 reward model。这本质上就是——规则 + 执行环境作为 critic，和一个神经网络输出 V(s)完全不是一回事。

不过这些 Coding Agent 的实践虽然已经不用“单一模型”了，但它们仍然是按任务、按环境配一套的——Python 项目用 pytest，代码风格用 Linter，安全扫描用专用工具。如果今天换了一个新语言、新框架，这套工具链又要重新搭一遍。而且这套工具池是工程师手写的，不是学出来的。

我设想的 critic 往前走一步：工具池本身是开放的，但更重要的是，哪些工具该在什么时候用、怎么组合、输出之间怎么取舍——这整个调度决策本身是 critic 学出来的，而不是工程师手写死的。随着 critic 见过的轨迹越来越多，它会自己发现“这个场景下先跑安全扫描再让 LLM 判断比反过来更好”，这种经验是跨任务可积累的。

放到具身场景里，这个需求更迫切。因为具身任务的多样性和长尾程度远超 coding——UR5e 上的操作、Franka 上的移动操作、人形机器人的全身协调，每一种都需要不同的感知、规划和物理判断工具，但它们都需要同一个调度器来统一决定“当前这条轨迹该问谁”。

Critic 的内部结构：工具池 + 调度器

我设想的Critic Agent，不是简单几个固定 expert 拼起来，而是一个开放的工具Tool池Pool + 一个调度器(Dispatcher)。这个体系有点像现在很火的概念Harness，都是基于工具+调度，并且给模型提供反馈闭环。

这里Critic Agent有几个关键点：

1. 工具池是开放的，不是预设好的。SAM、YOLO、OpenCV、VLM、子目标分解器、轨迹分段器、世界模型……只要能服务于“评价”这件事的工具都能塞进来。今天有人训了个新的桌面物体 affordance 预测器，明天就能注册到池子里被 critic 调用。这跟现在的 CLI 工具生态是一样的逻辑——别预设该有哪些命令，重要的是 dispatcher 能调度手头能用的工具。

2. 工具的“种类”不需要也不应该提前切清楚。可以按能力类型粗分（视觉/规划/时序/物理），也可以按评价对象切（动作/轨迹/整体），更可以按任务阶段切（感知/规划/执行）。这个分类是工具作者自己决定的，critic 不强加。

3. 调度器是 critic 真正在学的东西。同一个“叠衣服失败”case，有时候该先调 SAM 看看目标物体有没有被识别，有时候该先调 VLM 看看指令解析对不对，有时候该先调轨迹分段器看看是不是卡在某个子目标。这种“该先问谁”的能力，就是 critic 训练的核心目标。

4. 工具之间是协作关系，不是简单的投票。多个工具对同一段轨迹的判断可能冲突，dispatcher 要做的不是简单平均，而是基于历史表现、当前上下文做综合判断——必要时把“难例”路由给人。

Critic 的输出形态：不只是一个 scalar reward

critic 的输出不是单一标量 reward，而是结构化判断，至少包含：

• scalar_reward：用于驱动 RL 的核心信号
• progress_delta：相对上一步的进展（对应 process reward）
• done_signal：任务是否完成
• failure_attribution：失败时定位到“感知/规划/执行/外部”中的哪一类
• confidence：对自身判断的置信度
• human_routing_flag：是否需要把人拉进来（用于遥操接管的触发信号）

这种结构化输出，比单一 scalar 更能跟 process reward 的思路对齐，也更符合 LLM-as-judge 的范式。human_routing_flag 配合遥操接管，可以直接当作“什么时候需要人介入”的触发器——critic 自己拿不准的时候，主动喊人。

human_routing_flag 在多机场景下有更重要的角色——critic 实时看到所有机器的 rollout 流，不仅判断“是否需要人”，还要决定“接管哪台”。这个 routing 决策跟“评价轨迹好坏”是一对耦合的能力（详见后面“人在环”章节）。

其他组件：为什么这样配

多 Env：真机是锚，仿真负责吞吐

这一点我比较坚持:真机必须存在，这是具身的“物理锚”——所有的 reward、所有的 policy 评估，最终都要能回到真机上才有意义。仿真可以做三件事:

• 冒烟测试：在推真机前先用 sim 把明显坏的策略筛掉
• 反事实推演：用 world model 推“如果当时动作改了会怎样”
• 数据增广：对稀缺的真机场景做“语义级”的增广

但 sim 永远不能完全替代真机，尤其在接触丰富（contact-rich）、长尾物理（viscous、deformable）这些地方。这是我对纯 sim2real 路线的保留意见。

人在环：遥操接管是核心形式 + Critic 决定接管哪台

这是整个范式能不能 scale 的命门。最自然、最高质量的人机协作形式是遥操teleoperation接管takeover。

但要落地到多机场景，接管的触发不能靠人盯着屏幕挑——那样人的注意力马上就不够用了。应该是 critic 自己实时看到多机 rollout，自动识别出“哪台机器当前最难、最需要人介入”，然后把对应那台机械臂的控制权接回给人，人再来择机接管遥操。 整个过程是这样:

具体流程:

1. 多台真机并行 rollout 同一份 policy
2. critic 实时聚合每台机器的轨迹流，综合 confidence / progress_delta / 失败前兆 / 子目标停滞时间等信号
3. critic 输出带目标的多机路由信号:routing_target = Env_2 + reason: 卡在子目标 3 已 30s， 工具池子目标分解器判断与目标物体识别不一致
4. 调度系统把 Env_2 的控制权切给人(可能用半自动接管:先让机器臂 hold，人再接管)
5. 人开始遥操，接管过程本身产生两条高价值数据:
   1. 接管前的失败轨迹(policy 是怎么一步步走错的)
   2. 接管后的恢复/正确轨迹(人是怎么把它救回来的)

这两条配对起来，本身就是 critic 提升的最强监督信号。

为什么“接管谁由 critic 决定”这么关键? 因为它把“人的注意力”这个最稀缺的资源，从“操作员要扫 N 个画面、做 N 个判断”变成了“critic 已经挑好了一台，人直接接过来救”。这才是规模化的人机协作，而不是“人形监控摄像头”。

遥操接管之外，人在环还有这些补充形式（优先级从高到低）:

1. 接管后的轨迹对 / 失败归因：人在接管后花几十秒标注“哪一步开始错、错在感知还是规划”
2. 少量新任务首次示范：人给一个新任务做一次演示，policy 后面照着 rollout，critic 拿着这个示范来校准
3. 批量 pairwise / rubric 标注：工程上仍然有，但不是核心，因为成本高、信息密度低

而且人在环这件事可以异步——遥操接管是强实时，但接管后的分析/标注是异步的；人不需要一直盯着屏幕，可以攒一批接管 case 在固定时段标注、看视频、归因。强实时的是 critic 路由，异步的是人分析。

接管的两种模式：控制权转移 vs 协助

把人机协作这件事想得更细一点，会发现“接管”其实有两种本质不同的模式，跟 robotaxi 领域的远程接管逻辑非常像:

在我设想的具身范式里，两种模式都要，critic 自己根据场景选择:

• 细粒度物理操作(插入、对位、力控)：走控制权转移，人直接接管机械臂
• 高层语义判断(目标识别、指令歧义、任务拆解)：走协助式，人只回答 critic 抛上来的问题

这个区分带来的工程价值:控制权转移要求低延迟、操作员训练成本高(萝卜快跑要求 1000+ 小时)，所以应该用得省、用得准；协助式便宜很多，可以更频繁触发。critic 调度器根据“错的层级”自动选择用哪种人机协作形式。

预判式接管：critic 给出失败概率才“丝滑”

有个关键点：接管要“丝滑”，critic 必须能“预判”——不是在 policy 已经崩了、动作已经开始发散的时候才喊人，而是在 confidence 还在掉、还没崩的时候就提前把控制权切给人。否则就会出现“人接过来时 policy 已经走远了，接管本身也救不回来”的尴尬。

主动权在 AI 这边，而不是被动等待崩溃——这个逻辑跟 robotaxi 远程接管完全一致。

Critic 自己怎么变强（最难的部分）

这是整个范式里最不成熟、也最值得深挖的一块。三条主要机制 + 两条次要机制:

主驱动一：人接管 + 接管轨迹反哺

人遥操接管产出的“失败轨迹 + 恢复轨迹”对，是 critic 训练数据的金标准:

• 失败轨迹的子片段 → critic 学“什么样的轨迹是错的、错在哪”
• 恢复轨迹的子片段 → critic 学“遇到这种错该怎么改、往哪走才对”

这种数据密度高、信息量大、单条价值大，远比众包偏好标注值钱。critic 自己的训练集里，接管类数据应该是占比最高、采样权重最高的那一类。

主驱动二：policy rollout 失败数据回流

policy 部署到真机后，日常 rollout 必然会产生大量失败 case。这些 case 直接回流到 critic 训练集:

• 多机 rollout 时各台机器的失败
• 在线部署时 policy 表现突然下滑的场景
• 旧 critic 给高 reward 但 policy 实际崩了 → 这是 critic 错估的强信号(reward hacking 防御)

这种数据量级大、覆盖长尾，是 critic 不断校准、避免“在训练集上看着很美、部署就崩”的关键。

主驱动三：离线 Dagger 风格的数据管道

在前两条之外，还可以专门搭一条离线数据生产管道，用 Dagger 思路主动生产“高质量失败问题分析”类数据:

• 故意让 policy 在各种 tricky 场景 rollout
• 系统自动识别失败点
• 自动调 critic 工具池里的工具做初判（SAM 圈物体、轨迹分段器切子目标）
• 人只在最后做归因和标注:这一步错在哪、期望的正确反应是什么

这种“半自动标注”是规模化 critic 训练数据的关键，光靠自然 rollout 太稀疏，光靠人全标又太贵。怎么用上这种数据，可以参考HIL-SERL：同时维护演示 buffer(高成功率、人工标注)+ RL buffer(自然 rollout，可能含失败)。

次要：World model 反事实 + 调度器难例挖掘

这两条是锦上添花，不是主驱动:

• World model 反事实：对一段真实轨迹做“如果动作改一下会怎样”，用 world model 输出构造 self-supervised 偏好对(τ0-WM、Genie Envisioner 这类工作能直接接进来)。能用，但其质量受限于 world model 自身。
• 调度器难例挖掘：多个工具对同一段轨迹判断冲突时，这个 case 对 dispatcher 的训练价值很高。攒起来重训 dispatcher。

跟已有工作的对比

按路线把现有工作分成 6 类，各自和我的关系如下：

• VLA 基础模型：π0⁸、Redwood VLA⁹ 等解决的是 policy 本身怎么变强，评价隐含在预训练质量里。它们是我的上游——我提供 critic 子系统，它们提供被评价的 policy。
• 在线 RL / 人在环 RL：RLT²、HIL-SERL¹ 等解决的是 policy 怎么用 RL 训，但默认每任务每机器自己训 critic。HIL-SERL 是最直接对应的工作（视觉基 HIL-RL + 在线接管，1-2.5 小时训出近 100% 成功率），我把它扩到多机多任务共享 critic。Hi-ORS¹⁰ 等提供了 RLPD 算法骨架，RL-VLA 算法族¹¹提供 policy 端更新但不解决评价共享。
• 显式 Critic 模型：VLAC¹²、GRAPE¹³ 等跟我最近，但都是单模型 + 单任务的 critic——我的差异是工具池 + 调度器 + 多机共享。
• 中间层 / 实时接管：RTOT¹⁴ 用自动状态识别触发操作员接管，是最直接对应的单机版；我把人介入独立成 critic 的调用接口，不再绑死在 VLA 推理路径上。
• World Model：τ0-WM³ 等用世界模型做 implicit reward；在我的范式里 WM 只是 critic 工具池里的一个候选工具，且主要价值在训练时而非推理时。
• 工程范式借鉴：Robotaxi 远程接管¹⁵提供了人车比工程实践，但我由 critic 决定“接管谁”；多机分布式 RL¹⁶ 假设现成 reward function，我的核心差异是 reward 本身也是可训练的子系统。

一句话总结：现有工作把 critic 当辅助模块；我把它提升为独立子系统——有自己的工具池、调度器和训练数据流，所有 policy 在多机上分布式训练时都向它“借”评价。

为什么这套范式是 “scalable” 的

最后回到标题:Scalable 在哪?

• 横向 scale：加 Env、加训练机不需要重新训 Critic。Critic 是“评价标准”，是固定成本；Env 和训练机是“被评价的对象”，是边际成本。
• 纵向 scale：Critic 自己越训越强，人对单条轨迹的“价值”被 Critic 蒸馏后，可以扩展到无数条没有人在看的轨迹上。这是 LLM RLHF 已经被证明过的事，只是搬到具身上。
• 代际 scale：Critic 可以被打包成“具身领域的 Critic 基座”，未来新任务、新本体的 policy 训练直接复用。
• 能力 scale：工具池是开放的，新工具随时注册，dispatcher 学一下什么时候该用就行。

终极状态:这套范式跑顺之后，具身 RL 训练系统对人的依赖，从“每个人都要看每条轨迹”降到“一个人维护 Critic，偶尔接管最有信息量的 case”。

写在最后

这不是一篇“我们已经做到了”的文章，这是一篇“我想把这件事做成”的文章。现有工作在各自的局部问题上都已经做得很深——我设想的范式，是把它们的“局部最优”串成一个可以长期迭代的飞轮:

多 Env 产生 rollout → policy 在多机分布式训练中消耗 rollout → 共享 critic 评价 rollout → 失败 case 回流 / 遥操接管反哺 critic → critic 变强让 policy 训练更稳 → policy 变强让 rollout 更有信息量 → 回到第一步。

如果这件事能做出来，具身 RL 的“评价瓶颈”就能被系统性地解决。

The ease of training AI to solve a task is proportional to how verifiable the task is.

― Jason Wei, Asymmetry of Verification and Verifier's Law

Critic Agent 要做的，正是让具身 RL 的任务变得可验证——一旦可验证，就可训练；一旦可训练，就终将被解决。欢迎讨论。