SPINE：用智能体AI弥合虚实鸿沟

# SPINE：弥合信息物理鸿沟的智能体AI
来源：https://arxiv.org/html/2607.13049
Minkyu Ham1,\*，Dongho Kim1,\*，Chan Lee1,\*，Jiayi Wang2,\*，Min Jun Kim1，Yixi Zhang2，Guo Ye2，Jihai Zhao2，Soyeon Park1，Han Liu1,2,† 1西北大学统计与数据科学系 2西北大学计算机科学系 \*这些作者对本文贡献相同，按姓氏字母顺序排列。†通讯作者：[email protected]

###### 摘要

基础模型为机器人提供了进行复杂决策的智能大脑，但要将这种智能部署到物理平台上，仍需要繁琐且依赖专家经验的校准工作。这种部署鸿沟——机器人的“脊髓”——仍然是可扩展具身AI的主要瓶颈。为此，我们提出了SPINE（可扩展物理集成与智能体专业知识）：一个用于系统化调试和部署双臂机器人的智能体框架，且几乎不需要机器人专业知识。SPINE的“马具”包含两个编排好的多智能体工作流：一个配置文件构建器，用于创建机器人特定上下文；以及一个调试器，通过诊断、修复和验证循环，直到遥操作正常工作。在七个DOBOT X-Trainer调试场景中，使用SPINE的机器人新手操作员，在使用相同参考材料但未使用SPINE结构化工作流的条件下，其表现优于使用Claude Code的人类操作员：将可运行成功率从75%提升至100%，并将平均遥操作准备时间从16分45秒缩短至13分47秒。在AgileX PiPER（一款独特的基于ROS/CAN的双臂机器人）上，SPINE解决了全部10个植入的错误，而专家基线解决了9个，且所用时间几乎相同。这些结果共同表明，SPINE能够跨双臂平台迁移，减少对专家校准的依赖，推动具身AI向可扩展的现实世界部署迈进。

## 1 引言

具身AI通过将大规模、跨具身的机器人数据集与视觉-语言-动作模型相结合，取得了显著进展，实现了语言条件推理和可跨机器人平台迁移的高级任务规划[1 (https://arxiv.org/html/2607.13049#bib.bib1),2 (https://arxiv.org/html/2607.13049#bib.bib2),14 (https://arxiv.org/html/2607.13049#bib.bib14)]。然而，在物理机器人上部署基于学习的策略仍需要在硬件、驱动程序、中间件和安全系统之间进行大量集成[5 (https://arxiv.org/html/2607.13049#bib.bib5),6 (https://arxiv.org/html/2607.13049#bib.bib6),4 (https://arxiv.org/html/2607.13049#bib.bib4)]。即使机器人能够进行日益复杂的推理和控制，通往可靠物理执行的桥梁——比喻意义上的“脊髓”——仍然依赖大量集成工作和专家经验。这一鸿沟贯穿机器人平台的整个运行生命周期：让一台新机器人上线，仍然需要研究人员手动解析碎片化的文档、解决驱动程序依赖问题、配置通信接口并建立安全边界——这一过程通常耗费数小时甚至数天。

除了初始化，即使在成功部署后，一旦单个组件发生故障，仍需要专家干预：绑定错误的设备序列号、过时的环境路径、端口冲突、锁定的安全互锁或配置错误的通信端点，都可能悄然阻碍遥操作、数据收集或策略部署的进展。诊断此类故障本质上是困难的；故障症状通常出现在与其根本原因不同的层面，复合错误相互掩盖，而所需的知识（包括USB拓扑、固件约定和中间件配置）高度依赖特定平台，非专家难以获取。硬件故障尤其不宽容：软件错误会表现为堆栈跟踪或日志输出，而物理故障（如连接器松动、设备序列号错误或固件配置错误）仅在软件中表现为静默或误导性的下游错误，迫使操作员在没有明确起点的情况下，在整体硬件-软件栈中思考。在异构实验室环境中，这一问题更加严重：配置和调试知识很少能在不同的硬件平台或软件栈之间迁移。总之，这些挑战形成了一个脆弱的集成层，限制了强大机器人系统的初始部署和持续可运行性——突显了需要新方法来帮助研究人员高效调试复杂机器人硬件。

最近的智能体系统将语言模型与工具、代码执行和迭代反馈相结合，执行长程软件工程和科学分析任务[7 (https://arxiv.org/html/2607.13049#bib.bib7),8 (https://arxiv.org/html/2607.13049#bib.bib8),9 (https://arxiv.org/html/2607.13049#bib.bib9),10 (https://arxiv.org/html/2607.13049#bib.bib10),11 (https://arxiv.org/html/2607.13049#bib.bib11)]。这些系统超越了会话式辅助，与外部环境交互、根据反馈修正动作并协调多步骤工作流。这些能力直接映射到机器人启动和硬件调试的需求上：使智能体系统能够驾驭复杂软件任务的相同长程推理和环境探测能力，正是遍历机器人软硬件栈、隔离故障根本原因并应用针对性修复所需的能力。

然而，应用于物理机器人时，智能体调试必须应对传统软件工程中不存在的约束。诊断动作不得损坏正在修复的系统。修复必须根据物理状态而非仅代码进行验证，且知识必须在会话之间持久化，而不是每次都从头重新推导。这些约束共同催生了一个专门构建的框架，该框架结合了智能体推理、确定性的安全边界和持久的机器人特定记忆。

在此，我们提出SPINE（可扩展物理集成与智能体专业知识），一个用于物理机器人部署中的智能体调试框架。SPINE的主要功能是诊断和修复：给定一个无法达到可运行状态的机器人，它能自主识别并解决负责的软件和硬件错误——例如绑定错误的摄像头序列号、过时的环境路径、端口冲突、锁定的急停按钮或未插紧的线缆——而无需操作员首先确定哪个子系统损坏。为了解决上述知识障碍，SPINE在设置时将机器人特定的文档和硬件清单编译成结构化配置文件，为运行时诊断决策提供信息。在运行时，探测引擎将故障症状映射到目标明确的诊断序列，使智能体即使当故障的根本原因位于与其可见症状不同的层面时，也能遍历软硬件栈。故障模式记忆会跨会话积累并结构化诊断结果，积累仅靠文档无法恢复的平台特定知识。

先前集成LLM的机器人系统在代码生成[12 (https://arxiv.org/html/2607.13049#bib.bib12)]、基于基础的任务规划[3 (https://arxiv.org/html/2607.13049#bib.bib3)]和端到端视觉运动控制[13 (https://arxiv.org/html/2607.13049#bib.bib13),14 (https://arxiv.org/html/2607.13049#bib.bib14)]方面取得了重大进展。然而，这些系统都未能解决其工作前必须完成的一步：将物理硬件带到这些系统能够正常运行的初始状态。SPINE填补了这一空白。在此过程中，它还暴露了三个在软件工程中无害、但在物理硬件上会成为风险的默认行为。未经修改的通用智能体系统，每次会话都从零开始，没有累积的上下文，将安全边界交由语言模型自行判断，并基于自我评估而非物理验证来声明问题解决。SPINE的三个架构承诺分别应对这三个问题。

首先，调试知识在会话间持久化：智能体每次处理新案例时，都带着先前尝试已经建立的知识，而不是从头推导。这在物理领域尤为重要，因为机器人的故障模式由其特定的硬件版本、固件版本和设备拓扑所决定——这些事实很少被完整记录，只能通过直接观察来建立。其次，安全边界是确定性的，而非学习得来的：一个固定的预执行过滤器会拒绝已知在系统层面具有破坏性的Shell命令，从而消除对语言模型在运行时主动拒绝这些命令的依赖——因为语言模型的拒绝行为是不一致且不可验证的。与软件调试不同，一个错误命令是可恢复的，而在物理机器人上过早的固件刷写或错误的`rm -rf`命令可能导致永久性硬件损坏。第三，案例的结案锚定于具体的探测，而非智能体自己的成功声明：一个非运动的遥操作探测必须通过，案例才会被记录为已解决。机器人可以有语法上正确的配置文件，但摄像头序列号可能绑定错误、线缆可能未插紧或急停按钮可能锁死——这些状态对代码检查不可见，但立即被实况探测所揭示。这些承诺通过少量持久化的每机器人文件和运行时门控实现；图1 (https://arxiv.org/html/2607.13049#S2.F1) 展示了每个承诺在每次会话的单个调试循环中的应用。

为了评估这些承诺在实践中是否带来可衡量的改进，我们在两个机器人平台和三个复合错误类别上测试了SPINE。在DOBOT X-Trainer上，一个包含七个场景的基准测试将SPINE与使用相同编码智能体骨干但不具备SPINE持久状态或结构化诊断循环的专家和新手操作员进行了比较。在AgileX PiPER——一款独特的基于ROS/CAN的双臂机器人上，我们报告了五个配对的SPINE/专家案例，涵盖了相同的软件、硬件和混合错误类别。DOBOT上的主要发现是SPINE同时提高了效率、可运行成功率和操作员感知压力；PiPER的评估测试了相同的类别级机制是否能够迁移到不同的硬件和中间件栈。该框架已作为开源项目发布；更广泛的含义、局限性和扩展内容在讨论部分阐述。

## 2 结果

在本节中，我们首先概述SPINE的架构。然后，报告在DOBOT X-Trainer和AgileX PiPER上的复合错误评估协议和结果。

参见图注

图1：SPINE系统架构。a，设置阶段将机器人输入编译成持久化配置文件和就绪检查。b，调试会话阶段检索配置文件和已保存的修复方案，提出修复建议，并通过安全检查和验证。c，安全检查将可以在机器人上运行的命令与需要用户审查的风险命令分开。d，验证器仅在选定的运行测试通过时才结案。

### 2.1 系统概述

SPINE是一个智能体框架，旨在以最少的人类专业知识将机器人带到操作员可用的遥操作状态（图1 (https://arxiv.org/html/2607.13049#S2.F1)）。SPINE围绕两个编排好的工作流组织：一个配置文件构建器和一个运行时调试器。在设置时，配置文件构建器将手册、操作员回答、可选的设置说明以及已知良好的仓库快照，转换为机器人特定的类别配置文件，涵盖元数据、组件、接口、软件、配置、流程、安全、诊断和遥操作验证能力。专门的子智能体根据无损证据包起草配置文件，而策划者、裁决者和配置文件医生阶段在密封配置文件之前协调解决空白或冲突。

在运行时，调试器加载密封的配置文件、紧凑的事件记忆、可重用的技能和结构化工具，然后迭代进行目标规划、证据收集、分诊、修复和重新验证。SPINE使用配置文件声明的实时遥操作管道和隐藏就绪探测作为主要证据。当故障仍不明确时，只读诊断子智能体在调试器选择软件编辑或从结构化剧本中选择单个面向操作员的硬件操作之前，分别评估终端证据、软件合同漂移、硬件可见性和就绪范围。SPINE将事件、故障模式、验证运行和结案状态记录在持久的每机器人记忆中。一个确定性的安全运行器层执行配置文件声明的检查并记录验证证据，而结案门控仅在遥操作验证通过后才将案例标记为已解决；否则，SPINE将该案例记录为已诊断以供未来会话使用。由于机器人特定知识存储在配置文件和记忆中，而非提示词中，迁移SPINE主要需要构建新的配置文件，而技能、工具和调试循环可在各平台间复用。

### 2.2 案例研究

我们在两个平台上评估了SPINE的复合机器人调试案例。DOBOT X-Trainer作为三条件配对基准测试，而AgileX PiPER在一个基于ROS和CAN的双臂机器人上提供了五个案例的配对评估。当一个案例包含两个或多个产生重叠症状的错误，使得一个故障可能掩盖另一个，或多个故障表现为同一个操作员可见的故障时，该案例称为*复合*案例。

我们将这些案例分为三类：*复合软件*（所有错误都是软件故障）、*复合硬件*（所有错误都是硬件故障）和*复合混合*（错误跨越软件和硬件两层）。在每个场景中，植入的组件错误数量报告为OSS分母nn，因此OSS = X/n = X/n，其中X是正确识别并解决的错误数量。

每个案例遵循*盲*协议：指定的植入者将故障注入到试验工作区，而调试器事先不知道植入的内容或有多少个故障。DOBOT基准测试包含七个场景：两个软件案例、三个硬件案例和两个软硬件混合案例。每个场景由*新手*（统计与数据科学研究生）使用SPINE评估一次，并在人类基线条件下评估两次。人类基线由同一位新手和一位领域*专家*（机器人学研究生）组成，每人配备Claude Sonnet 4.6，但未使用SPINE的结构化知识或智能体循环，共计21次DOBOT试验。AgileX PiPER遵循相同的错误类别，包括五个配对的SPINE/专家案例，但省略了DOBOT中使用的新手基线条件。在两个平台上，我们评估三个指标：可运行成功率（OSS）、操作准备时间（TTO）和操作员感知压力（OPS），在可用时。

#### 复合软件错误

复合软件错误评估调试器是否能区分多个通过相同启动、遥操作或数据收集症状表现的配置故障。在DOBOT基准测试中，这些故障源于SDK路径、版本门控、摄像头角色绑定和本地服务端点。在AgileX PiPER上，类似的故障源于ROS启动文件、CAN适配器绑定和Python导入优先级。表1 (https://arxiv.org/html/2607.13049#S2.T1) 定义了植入的案例，表2 (https://arxiv.org/html/2607.13049#S2.T2) 报告了相应的结果。

表1：植入的复合纯软件案例。在DOBOT纯软件基准测试中，SPINE达到了遥操作