💻 computer science

Nautilus: From One Prompt to Plug-and-Play Robot Learning

本文介绍了 NAUTILUS，这是一个开源框架，通过提供即插即用的智能体技能、统一接口以及可扩展的分舱执行机制，将单一提示转化为经过验证的自动化机器人学习工作流，从而消除当前阻碍跨家族策略复现与评估的工程碎片化问题。

原作者： Yufeng Jin, Jianfei Guo, Xiaogang Jia, Yu Deng, Zechu Li, Han Liu, Weiran Liao, Vignesh Prasad, Mathias Franzius, Gerhard Neumann, Georgia Chalvatzaki

发布于 2026-05-13

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Yufeng Jin, Jianfei Guo, Xiaogang Jia, Yu Deng, Zechu Li, Han Liu, Weiran Liao, Vignesh Prasad, Mathias Franzius, Gerhard Neumann, Georgia Chalvatzaki

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，机器人学习的世界就像一个巨大而混乱的建筑工地。在一边，有建筑师在设计新的机器人“大脑”（称为“策略”）；在另一边，有测试赛道（基准测试），机器人在这上面学习行走或抓取物体；在第三边，则是实际的机器人本身，从简单的机械臂到人形行走机器人不等。

根据这篇论文，问题在于：将任意一位建筑师、任意一条测试赛道和任意一台机器人连接起来，简直是一场噩梦。每当研究人员想要在一台新机器人上、用一条新赛道测试一个新“大脑”时，他们都必须从头搭建一座定制桥梁。他们必须编写“粘合代码”以匹配语言、修复冲突的软件版本，并确保机器人不会崩溃。这就像试图将一个烤面包机插进汽车引擎、插进宇宙飞船、再插进一艘船——每次你都必须发明一个新的适配器。

Nautilus 登场了。

作者提出 Nautilus 作为一个通用的“即插即用” harness（ harness 可译为“ harness 系统”或“ harness 框架”，此处保留其作为核心组件的意象，译为“ harness 系统”更贴切）。把它想象成整个机器人学习行业的智能、魔法般的适配器站。

以下是它的工作原理，使用简单的类比：

1. “万能电源排插”（类型化契约）

目前，每台机器人和每个“大脑”都说着不同的语言。Nautilus 引入了一个标准化的电源排插。

类比： 想象一下，如果你家里的所有电器（烤面包机、台灯、电视）都必须重新布线才能适配墙上的插座。Nautilus 说：“不再需要重新布线。”它强制每个机器人“大脑”和每条测试赛道就插头的单一严格形状达成一致（称为“类型化契约”）。
结果： 一旦机器人“大脑”插入这个标准接口，它就能立即连接到任何测试赛道或机器人，而无需定制适配器。

2. “隔音舱”（分舱执行）

机器人软件很混乱。一台机器人可能需要特定版本的视频游戏引擎，而另一台需要不同版本的物理模拟器。如果将它们在同一台计算机上运行，它们会互相冲突并导致崩溃。

类比： Nautilus 为实验的每个部分建造了隔音舱（容器）。机器人“大脑”住在一个舱里，测试赛道住在另一个舱里，而机器人本身住在第三个舱里。它们可以通过一个安全的窗口互相交流，但它们内部混乱的工具永远不会发生冲突。
结果： 你可以随意组合任何搭配，而无需担心软件冲突。

3. “智能项目经理”（代理）

该论文使用大型语言模型（一种 AI 程序员）来承担繁重的工作。但通常，AI 程序员在机器人领域会失败，因为它们不了解该领域的“不成文规则”。

类比： Nautilus 为 AI 程序员提供了一本规则手册和一份检查清单（称为“指南”和“传感器”）。
- 指南： 在 AI 编写代码之前，规则手册会告诉它：“嘿，机器人在启动前需要重置，并且你必须检查电池是否安全。”
- 传感器： 在 AI 编写代码之后，一名安全检查员会检查它。“你真的测试了机器人是否移动了吗？你检查了数据格式了吗？”如果答案是否定的，AI 必须在继续之前修复它。
结果： AI 不再只是猜测；它遵循研究人员每天使用的经过验证的安全工作流程。

4. “鹦鹉螺壳”（可扩展性）

这个名字来源于鹦鹉螺壳，它通过增加新的腔室来生长。

类比： Nautilus 不是构建一个巨大的、僵化的框架（当你添加新机器人时它会破裂），而是通过添加新腔室来生长。如果研究人员添加了一台新机器人（比如一种新型机械手），他们只需向系统添加一个新的“腔室”。系统的其余部分无需重建。
结果： 系统变得更大、更有用，而不会变得更复杂。

他们实际证明了什么？

该论文并没有声称 Nautilus 发明了一种新的机器人“大脑”，或者它让机器人比以前更聪明了。相反，他们证明了：

它作为一个翻译器有效： 他们使用 Nautilus 将现有的机器人“大脑”在现有的基准测试上进行测试，结果与原始作者声称的结果一致。
它节省了时间： 他们表明，使用 Nautilus 将新的机器人“大脑”连接到新的测试赛道，比手动操作要快得多且成本更低。它将工作量从为每一对组合搭建一座桥梁，减少为只为整个系统搭建一座桥梁。
它在真实机器人上有效： 他们成功地将一个在模拟环境中训练的机器人“大脑”包裹在 Nautilus 中，并将其部署到两台截然不同的真实机器人上（一台 Franka 机械臂和一台 Unitree H1 人形机器人），而无需更改“大脑”的代码。

简而言之： Nautilus 不是一个新的机器人“大脑”；它是通用翻译器和安全检查员，让不同的机器人“大脑”、测试赛道和机器人最终能够互相交流，而无需每次都要有一支工程师团队来搭建定制桥梁。

技术摘要：Nautilus：从单一提示到即插即用的机器人学习

1. 问题陈述

机器人学习研究目前分散在三个相对独立的轴线上：策略族（ $P$ ，例如 IL、RL、VLA、WAM）、基准测试套件（ $B$ ，例如 LIBERO、ManiSkill）和机器人实体（ $R$ ，例如 Franka、Unitree H1）。集成任意特定的三元组 $(P, B, R)$ 通常需要一个独特的、手工编写的集成层，涉及 Docker 设置、观测适配器以及信任验证程序。

这种碎片化造成了“集成鸿沟”（harness gap）。虽然大语言模型（LLMs）在代码生成方面取得了进展，但由于缺乏机器人学研究工作流特有的过程先验（procedural priors）和验证实践，它们往往无法生成可端到端复现的机器人学结果。工程负担按 $\Theta(N \cdot M \cdot K)$ 的比例增长，其中 $N, M, K$ 分别代表策略、基准测试和机器人的数量。现有框架（如 LeRobot、Isaac Lab）通常与固定组件耦合，而通用编程代理则缺乏导航复杂依赖冲突和接口不匹配所需的领域特定脚手架。

2. 方法论：NAUTILUS 集成框架

作者提出了NAUTILUS，这是一个面向代理的开源集成框架，旨在将单一自然语言提示（例如“使用基准测试 B 评估策略 A"）转化为即用的复现、评估、微调和部署工作流。NAUTILUS 分为两层：基底（substrate）和内容层（content layer）。

2.1 基底（工程不变量）

基底为代理提供了一个稳定的推理表面，将集成复杂度从 $\Theta(N \cdot M \cdot K)$ 降低到 $\Theta(N + M + K)$ 。它依赖于三个不变量：

类型化接口契约：策略、基准测试和机器人通过固定的、机器可读的模式（schema）公开（例如 infer(obs) -> actions、reset(seed)、apply_action）。这些契约隐藏了特定于实现的机制（例如 CUDA 堆栈、ROS 2 驱动程序），并定义了集成单元。
隔离执行：生成的工件在一次性、隔离的容器中运行。这防止了依赖故障（例如冲突的 CUDA 版本）在不同模块间泄露。从代理的角度来看，策略容器、基准测试容器和硬件容器占据相同的架构槽位。
统一的模块间通信：
- 第 1 层（机器人本地）：高带宽传感和控制保留在原生机器人堆栈中（例如 ROS 2、共享内存）。
- 第 2 层（机器人外部）：代理仅看到一个轻量级的WebSocket协议，该协议将策略容器连接到基准测试或真实机器人端点。这确保了模拟端点和真实机器人端点共享单一的观测/动作模式。

2.2 内容层（指南、传感器、状态）

构建在基底之上，该层将机器人学研究工作流提炼为显式的、可重用的组件：

指南（Guides）：预生成指令，用于引导代理的行为，在编写代码之前提供路由规则、子代理角色和验证协议。
传感器（Sensors）：后生成验证器，根据六个标准（例如预动作过滤、接口验证、规范比较、冒烟测试）检查工件。如果违反契约，传感器可以触发本地修正或阻止运行。
状态（State）：一个持久的、经 JSON 模式验证的注册表，存储类型化契约和固定的工件（源代码提交、Docker 镜像）。这使得代理能够重用已验证的模块知识，而不是从头开始重新发现仓库布局。
工作区工件：仅追加的日志和复现收据，记录每次运行的源代码提交、环境选择和决策。

2.3 执行流程

当用户发出提示（例如“在 LIBERO 上运行 $\pi_0$ "）时，编排器将请求路由到特定的子代理工作流。系统检查状态注册表中是否存在已验证条目。如果缺失，则并行生成策略和基准测试模块，比较它们的类型化规范（例如观测键、动作形状），执行 WebSocket 冒烟测试，并编写复现收据。

3. 主要贡献

模块化基底：一个基于类型化契约、隔离执行和统一传输的系统，降低了跨家族机器人学习的集成成本。
提炼的过程先验：将隐式的机器人工作流知识转化为显式的指南和传感器，将代理的“黑盒”生成转变为经过验证的、逐步的过程。
开源平台：发布 NAUTILUS，其结构化工作流支持四个策略族（IL、VLA、RL、WAM）、六个基准测试套件和四类机器人实体。其中包括nautilus-collect，这是一个数据收集平台，能够在异构硬件（Franka 和 Unitree H1）上验证相同的机器人契约。
可扩展注册表：一个社区平台，新的策略、基准测试或机器人可以通过 3–5 个类型化方法契约进行接入，无需修改框架代码，前提是它们通过信任验证协议。

4. 实验结果

本文通过三项研究评估了 NAUTILUS：

基准信任验证：该系统复现了公共策略（Diffusion Policy、 $\pi_0$ 、OpenVLA 等）在 LIBERO、ManiSkill、RoboTwin、ALOHA 和 RoboCasa 上的参考结果。生成的适配器忠实地复现了参考分数，偏差很小（例如 $\Delta \approx \pm 2\%$ ），证实了适配器保留了预期的评估协议。
可扩展性消融实验：在“留一基准测试”测试床中，将 NAUTILUS 与原生编程代理进行了比较。
- 成功率：NAUTILUS 实现了 100% 的封装成功率和高任务成功率（在 Claude Opus 4.7 上为 98.7%）。
- 成本效率：移除类型化模板（基底）导致封装成功率降至 55.3%，令牌使用量增加两倍（4170 万令牌），这表明基底防止了代理重新学习粘合代码。
- 模型扩展：该集成框架在较弱模型（Claude Sonnet 4.6）上提供了更大的相对收益，与原生代理相比，交互轮数减少了约 27%，成本降低了约 8%。
真实机器人部署：该系统成功在 Franka 机械臂上部署了 VLA 操作检查点（ $\pi_0.5$ ），并在 Unitree H1 上部署了 RL 运动策略。在这两种情况下，为模拟封装的同一策略工件仅通过交换硬件容器就转移到了硬件上，无需更改策略代码或平台侧容器。

5. 意义与主张

本文认为，机器人学习中代理自动化的主要限制并非 LLM 模型的能力，而是其周围的集成工程。NAUTILUS 证明，通过提供具有显式验证的稳定、基于契约的基底，可以大幅降低跨家族复现和评估的工程负担。

作者声称，NAUTILUS 将碎片化的研究工作流转变为结构化的代理程序。通过使领域专业知识（契约、验证协议、状态管理）可执行、可重用和可检查，该系统使研究人员能够在不针对每个新的 $(P, B, R)$ 组合手工策划粘合代码的情况下扩展其工作流。这项工作将 NAUTILUS 定位为不仅是一个自动化工具，更是迈向未来的重要一步：在该未来中，专家构建的集成框架将使模型能够在整个机器人学习生态系统中扩展领域专业知识。