Nautilus：从单一提示词到即插即用机器人学习

26年6月来自TU Darmstadt、卡尔斯鲁厄理工（KIT）、FZI 信息研究中心、Hessian.AI、德国机器人研究所和欧洲本田研究所的论文“Nautilus: From One Prompt to Plug-and-Play Robot Learning”。

机器人学习领域的研究分散在各种策略族、基准测试套件和真实机器人平台之间；各种实现方案在复杂的组合矩阵中相互交织，使得迁移其中任何单一要素都成为一项工程噩梦。通用的编码智体（coding agents）或许能偶尔连接特定的配置，但由于缺乏机器人研究工作流特有的程序化先验知识和验证实践，它们无法在大规模层面上弥合这一鸿沟。NAUTILUS，是一个开源“驾驭”（harness），能够将用户的单一指令（例如“使用基准 B 评估策略 A”）转化为可直接运行的复现、评估、微调及部署工作流。NAUTILUS 提供的：融合机器人研究领域提炼出的先验知识的即插即用型智体技能集；策略、仿真器/基准测试与真实机器人之间的类型化契约；统一的接口与执行环境；以及包含明确且自动化的里程碑式验证与测试的可信智体编码工作流。

NAUTILUS 不仅能为现有实现自动生成所需的适配器和容器，还能封装并接入新的或用户自定义的策略、仿真器/基准测试及机器人，并通过统一接口将它们互联。这无需编写繁琐的“胶水代码”即可扩展交叉验证的覆盖范围。正如鹦鹉螺通过增加腔室来生长，NAUTILUS 通过扩展“腔室”单元来实现规模化；它是一个支持可扩展性的研究“驾驭”（harness），而非人工维护的固定架构，旨在减轻在不断扩张的机器人学习生态系统中进行跨族群复现与评估的工程负担。

大语言模型（LLM）目前已广泛应用于代码生成和软件工程工作流中 [1, 2]。在机器人领域，LLM 已被探索用于任务级具身智能流程，涵盖策略代码生成和奖励函数设计等环节 [3, 4]。研究场景有所不同：关注的是作为机器人学习研究工作流“编排者”的智体编程系统（agentic coding systems），这些系统需跨越代码库、仿真器、基准测试集和硬件接口进行协调；然而，即便能力强大的编程智体，往往也难以实现端到端的复现结果 [5, 6]。这种持续存在的失败并非主要源于模型自身的能力局限，而是源于“驾驭”（harness）的问题。驾驭工程——即围绕 LLM 本身构建的所有要素的设计，包括任务编排、工具、验证协议、安全护栏、状态管理及程序化先验知识——已被公认为决定智体项目成败的关键因素 [5–8]。目前，机器人学习领域尚缺乏通用的研究驾驭。

机器人学习研究涵盖三个相对独立的维度：策略族 P（如视觉-语言-动作模型 (VLA)、模仿学习 (IL)、强化学习 (RL) 和世界动作模型 (WAM)）、基准测试集 B（如 LIBERO [9]、RoboCasa [10]、ManiSkill [11]、ALOHA [12] 等）以及机器人具身形态 R（如单臂、双臂、灵巧手、移动机器人、人形机器人等），其规模数量分别为 N、M 和 K。每一次涉及 (P, B, R) 组合的实质性交叉对比，通常都需要编写专门的集成层；因此，Docker 容器配置、观测适配器、冒烟测试及可信度验证流程等工作，往往在不同的论文、实验室和复现尝试中被重复开发。从整个领域来看，这导致了 Θ(N · M · K) 规模的驾驭构建成本，而若采用共享驾驭，则可将这一负担分摊至 Θ(N + M + K) 的水平。现有的系统仅解决部分问题。 LeRobot [13]、Isaac Lab [14] 和 robosuite [15] 等机器人学习框架整合通用工作流程，但往往与特定的策略（policies）和基准测试（benchmarks）紧密耦合；与此同时，Claude Code [16]、OpenHands [17] 和 SWE-agent [18] 等通用编程智体（coding agents）虽然提供智体运行循环（agent loop），却缺乏这些工作流程所需的机器人领域特定程序性知识。

NAUTILUS，是个专用于机器人学习研究的域特定驾驭（harness）。与传统的机器人学习框架不同，NAUTILUS 是一个面向智体的驾驭，它构建于类型化的策略、基准测试和机器人模块之上，同时将底层的编程智体循环视为可替换组件。NAUTILUS 包含两个层级。第一层是构建在三个工程不变性（engineering invariants）之上的基础层：类型化接口契约、舱室化执行（chambered execution）以及统一的模块间传输机制。该基础层是必要前提：若缺乏类型化契约和舱室化隔离，智体将无法获得稳定的推理基础，且必须针对每一组新的 (P, B, R) 三元组重新学习项目特有的粘合代码（glue code）。在此基础层之上是内容层，该层实例化了驾驭工程中的“引导与感知（Guides+Sensors）”框架 [5]，并引入了“状态（State）”概念加以扩展。在架构中，“引导（Guides）”在代码生成前塑造智体的行为，“感知（Sensors）”在生成后验证其输出，而“状态（State）”——即一个由 MCP 服务并经 JSON Schema 验证的契约注册表——则充当模块间的协调中介，从而将 (P × B) 组合的集成成本从 Θ(N · M) 降低至 Θ(N + M)。图 1 展示机器人学习领域中驾驭的缺失问题，以及 NAUTILUS 如何弥补这一缺口。

NAUTILUS 是一个 Claude Code 插件，能够将关于机器人学习的自然语言请求转化为可执行的工作流，涵盖复现、评估、微调及部署等环节。其设计包含两个层级：第一层是基于三大工程不变性（即类型化接口契约、舱室化执行机制以及统一的模块间传输机制）构建的底层架构；第二层则是包含机器人领域专用组件（如引导器、传感器、状态及工作空间工件）的内容层。

1 运行示例：在 LIBERO 上运行 π0

贯穿使用一个运行示例：研究人员用自然语言表达“我想在 LIBERO 基准测试上运行并评估 π0”。编排器（orchestrator）无需研究人员去查找正确的代码库入口点、配置依赖项或编写用于评估的胶水代码，而是直接解析该请求并将其路由至> /nautilus:eval policy=pi0 benchmark=libero。由此产生的运行过程如图 2 所示：编排器分发任务，状态管理器（State）检查注册表，策略（policy）和基准测试（benchmark）模块并行生成，系统比对它们的契约（contracts），执行 WebSocket 冒烟测试，并记录可复现性凭证。

2 底层架构（Substrate）

NAUTILUS 为智体（agent）提供一个固定的构建底层架构。该架构具有三个不变特性：类型化接口契约（通过固定模式使策略、基准测试和机器人变得可理解）；舱室化执行（隔离生成的工件，防止依赖项故障在模块间蔓延）；以及统一的模块间通信（确保模拟端点和真实机器人端点拥有智体可见的相同观测/动作传输机制）。

类型化接口契约。机器人学习实验由三个类型化接口表示：策略、机器人具身（embodiment）以及基准测试/环境。策略接口公开infer(obs) → actions方法（以及可选的reset方法）。机器人接口公开reset、get_observation、apply_action和safe_stop方法。基准测试/环境接口公开reset(seed)和step(action)方法，以及任务定义、成功标准和确定性随机种子（用于已发布基准比对检查）。这些契约是集成的基本单元：添加新的策略、基准测试或机器人时，只需满足相应的契约，而无需修改框架的其他部分。因此，在图 2 中，智体通过“策略”和“基准测试/环境”契约将 π0 与 LIBERO 连接起来；对于硬件实验，“机器人”契约也发挥同样的作用。

舱室化执行。策略推理、模拟器运行和真实机器人控制往往依赖于互不兼容的 CUDA、PyTorch、MuJoCo/Isaac/SAPIEN 和 ROS 2 软件栈。因此，NAUTILUS 在可丢弃的“舱室”（chambers）中运行生成的工件：每个舱室维护其独立的依赖环境，同时对外公开相同的接口契约。策略容器用于执行模型推理，而基准测试/环境容器则承载仿真器或任务套件；从智体（agent）的角度来看，真实硬件占据相同的架构位置。在 π0–LIBERO 示例中，“隔离舱”（chambering）机制允许策略模块和基准测试模块并行构建，从而避免了模块间的依赖冲突问题。

统一的模块间通信。尽管“契约”（contracts）和“隔离舱”定义了各模块对外暴露的接口，但模块之间仍需交换观测数据和动作指令。NAUTILUS 将模块间通信分为两个层级。第一层级（机器人本地）将高带宽的感知与控制任务保留在机器人原生技术栈（如 ROS 2 或共享内存）中。第二层级（机器人外部）则是智体唯一可见的传输通道：即策略容器与基准测试或真实环境端点之间轻量级的 WebSocket 连接。因此，仿真器和机器人共享一套对智体可见的观测/动作数据模式（schema），而 ROS 2、共享内存及其他机器人本地通信机制则处于智体边界之下。在 π0–LIBERO 示例中，WebSocket 冒烟测试（smoke test）针对的是这一共享的第二层级接口，而非特定于某对模块的通信路径。

3 内容层

在底层架构之上，内容层提供了机器人技术特有的操作流程。采用驾驭工程（harness engineering）中的“引导（Guides）+ 传感器（Sensors）”抽象模型 [5]：引导机制在生成任务前指导工作方向，而传感器机制则在生成后验证输出结果。NAUTILUS 引入“状态（State）”概念，以便在多次运行间持久化存储类型化契约，并利用“工作空间工件（workspace artefacts）”记录每次运行的情况，从而实现可复现的任务交接。在操作层面，L1 是基础智体循环，L2 负责路由用户意图，L3 执行特定任务的子智体，L4 验证工件并维护状态，L5 提供领域参考信息，L6 则记录执行结果（回执）。

引导（Guides）。引导机制在智体编写代码之前告知其如何行动。智体无需从各个代码仓库中推断机器人学习的惯例，而是直接获取相关的路由规则、子智体角色、数据模式及验证协议。这些引导机制体现在三个层级中：L2 将请求路由至脚本或子智体工作流；L3 运行针对策略服务器、基准测试封装器、训练脚手架及机器人集成模块的子智能体；L5 提供供上述组件查阅的共享参考库。在示例中，> /nautilus:eval policy=pi0 benchmark=libero的含义是：“生成 policy 和 benchmark 模块，并在启动前比较它们的注册表规范（registry specs）。”所谓“规范”，是指带类型契约（typed contract）在注册表侧的机器可读形式。

传感器。传感器验证智体生成的内容。在 L4 边界，NAUTILUS 运行六项检查——预操作过滤、渲染时审核、接口验证、规格比较、分层冒烟测试和交叉运行验证——每一项检查要么触发本地校正，要么阻止运行。在图 2 中，关键的传感器是规格比较。它在启动之前根据 LIBERO 基准/环境规范检查 π0 策略规范，在任何重量级运行之前发现观察键或操作形状不匹配的情况。注册管理机构升级由管理门单独处理。

状态。 State 是 L4 持久注册表，让 NAUTILUS 在运行中重用经过验证的模块知识。智体不会从头开始重新发现存储库布局、环境约束和策略/基准/机器人接口，而是检索将固定代码和环境工件绑定到类型化规范的注册表项。这些规范描述模块边界：观察/操作模式、控制模式和基准标准。在 π0–LIBERO 迹线中，布线后立即检查状态。经过验证的条目支持发布前的重用和兼容性检查；未经验证的模块是根据相同的规范格式生成的，并且可以稍后进入管理。这将策略基准集成从 θ(N·M ) 手写适配器转变为 θ(N+M ) 机器可读规范和共享调度协议。

工作区文物。 L6工作区层记录单次运行的证据；它本身不是经过验证的注册表项。流程日志是目标存储库中的仅附加注释，而收据是存储库根目录中重新生成的摘要。它们一起记录源提交、映像 ID、环境选择、基准协议、关键决策和重新运行配方。对于 LIBERO 上的 π0，收据使以后的用户可以重现运行，并为可能的注册表提交提供证据。

4 注册表维护与硬件支持

该注册表是一个包含可复现条目的共享索引，而非中心化服务。每个条目都锁定（pin）了源代码及环境相关构件，确保任何用户都能复现相同的策略、基准测试或机器人配置。“已验证”状态仅适用于基准测试条目，因为相比策略配置，基准测试协议的数量要少得多，且演进速度也较慢。只有当基准测试条目获得跨策略证据支持时，才会将其标记为“已验证”：即多个已发布的策略在通过同一封装器（wrapper）并使用各自官方检查点（checkpoint）运行时，能够复现其已发表的参考结果，且结果偏差透明可见，而非仅依据统一的“通过/失败”阈值进行判定。此标准应用于首批已验证条目。

硬件方面也采用相同的底层架构。nautilus-collect 是一个模块化的数据采集平台，它实现“机器人类型化契约”（Robot typed contract）并提供统一的传输接口。因此，任何经 NAUTILUS 封装的策略，都可以从基准测试环境无缝迁移至真实的机器人端点进行部署。该平台涵盖机器人数据采集、训练交接及部署的全过程。通过在单臂 Franka 机器人上进行的 VLA 操作任务部署，以及在 Unitree H1 机器人上进行的 RL 运动任务部署，验证这一流程。