26年7月来自美国西北大学的论文“SPINE: Bridging the Cyber-Physical Gap with Agentic AI”。

基础模型赋予机器人用于复杂决策的“大脑”，然而将这种智能部署到物理平台上，仍需依赖专家进行繁琐的校准工作。这种部署环节的鸿沟——即机器人的“脊髓”（Spine）——已成为实现可扩展具身智能（Embodied AI）的主要瓶颈。为此，提出 SPINE（Scalable Physical Integration with ageNtic Expertise，即“具备智体专长的可扩展物理集成”）：这是一个利用智体技术，让非专业人员也能系统性地调试并部署双臂机器人的框架。SPINE 驾驭（harness）包含两个协同运作的多智体工作流：一是构建机器人特定上下文信息的“配置构建器”（Profile Builder），二是循环执行诊断、修复和验证直至实现遥操作的“调试器”（Debugger）。在针对 DOBOT X-Trainer 机器人的七项调试任务中，使用 SPINE 的机器人技术新手表现优于仅依靠 Claude Code 和参考资料（但缺乏 SPINE 结构化工作流）的人类操作员：前者将部署成功率从 75% 提升至 100%，并将实现遥操作所需的平均时间从 16 分 45 秒缩短至 13 分 47 秒。在另一款基于 ROS/CAN 架构的双臂机器人 AgileX PiPER 上，SPINE 成功解决所有 10 个预设故障，而专家基准组解决 10 个中的 9 个，且两者耗时相当。这些结果表明，SPINE 能够跨不同双臂机器人平台应用，降低对专家校准的依赖，从而推动具身智能向可扩展的现实世界部署迈进。

---

具身智能（Embodied AI）通过结合大规模跨形态机器人数据集与视觉-语言-动作（VLA）模型，取得了显著进展，实现了跨机器人平台的语言条件推理与高层任务规划能力[1, 2, 14]。然而，将基于学习的策略部署到物理机器人上，仍需在硬件、驱动程序、中间件及安全系统之间进行大量的集成工作[5, 6, 4]。尽管机器人已具备日益复杂的推理与控制能力，但通往可靠物理执行的桥梁——即隐喻意义上的“脊髓（spine）”——依然高度依赖专家经验且集成难度极大。这种鸿沟贯穿了机器人平台的整个运行生命周期：部署一台新机器人时，研究人员往往需要手动解析零散的文档、解决驱动依赖、配置通信接口并设定安全边界——这一过程通常耗时数小时甚至数天。

即便机器人已成功部署，一旦某个组件发生故障，仍需专家介入：设备序列号绑定错误、环境路径失效、端口冲突、安全互锁装置锁定或通信端点配置错误等问题，都可能悄无声息地阻碍远程操作、数据采集或策略部署的进程。诊断此类故障难度极大；故障表象往往出现在与根源不同的层级，复合型错误相互掩盖，且所需的专业知识（如USB拓扑结构、固件规范及中间件配置）高度依赖于特定平台，非专业人员难以掌握。硬件故障尤为棘手：软件错误通常表现为堆栈跟踪或日志输出，而物理故障（如连接器松动、设备序列号错误或固件配置不当）在软件层面往往仅表现为隐蔽或具有误导性的下游错误，迫使操作员在缺乏明确切入点的情况下，在脑海中梳理整个软硬件架构。在异构实验室环境中，这一问题愈发严重：配置与调试经验往往难以在不同的硬件平台或软件架构间迁移。这些挑战共同构成了一个脆弱的集成层，制约了高性能机器人系统的初始部署与持续运行——这凸显了开发新方法以协助研究人员高效调试复杂机器人硬件的必要性。

近期的智体（agentic）系统将语言模型与工具使用、代码执行及迭代反馈相结合，以执行长周期的软件工程与科学分析任务[7, 8, 9, 10, 11]。这些系统超越了单纯的对话式辅助，能够与外部环境交互、根据反馈调整行动并协调多步骤工作流。这些能力与机器人启动（bring-up）及硬件调试的需求高度契合：智体系统在处理复杂软件任务时所需的长期推理与环境探测能力，正是贯通机器人软硬件架构、定位故障根源并实施针对性修复所必需的。

然而，将智体调试应用于实体机器人时，必须应对传统软件工程中不存在的各种制约因素。诊断操作不得损坏待修系统；修复方案必须基于物理状态而非仅仅依据代码进行验证；知识必须跨会话持久保存，而不能每次都从零开始重新推导。这些制约因素促使构建一个专用框架，将智体推理能力与确定性安全边界及机器人专属的持久化记忆结合起来。

为此，推出 SPINE（Scalable Physical Integration with ageNtic Expertise，即“具备智体专业能力的物理集成”）框架，专用于实体机器人部署过程中的智体调试。SPINE 的核心功能在于诊断与修复：当机器人无法进入正常运行状态时，它能自主识别并解决导致问题的软硬件故障——例如摄像头序列号绑定错误、环境路径失效、端口冲突、急停开关锁定或线缆未插好等——且无需操作员预先判断具体是哪个子系统出了故障。为克服上述知识壁垒，SPINE 在系统搭建阶段会将机器人专属文档和硬件清单汇总为结构化配置信息，从而指导运行时的诊断决策。在运行期间，探测引擎会将故障表象映射为针对性的诊断序列，使智体能够跨越软硬件层级进行排查，即便故障根源所在的层级与表象呈现的层级不同，也能有效应对。此外，故障模式记忆模块会跨会话积累并结构化诊断结果，不断沉淀那些仅靠文档无法获取的平台专属知识。

既有的集成大语言模型（LLM）的机器人系统在代码生成 [12]、具身任务规划 [3] 以及端到端视觉运动控制 [13, 14] 方面已取得显著进展。然而，这些系统均未解决一个必须先行完成的步骤：即确保物理硬件处于能够支持这些系统运行的状态。SPINE 正是填补了这一空白。在此过程中，它也揭示了三种在软件工程中无害、但在物理硬件上却可能带来隐患的默认行为。若不加改进，通用智能体系统在每次会话开始时均缺乏上下文积累，将安全边界的把控权交由语言模型，并基于自我评估而非物理验证来判定问题解决。SPINE 通过三项架构设计原则分别应对了这些问题。

首先，调试知识在不同会话间得以持久保存：智体在处理新案例时，会利用既往尝试中已确立的信息，而非从零开始重新推导。这一点在物理领域至关重要，因为机器人的故障模式往往取决于其特定的硬件版本、固件版本及设备拓扑结构——这些信息通常缺乏完整文档记录，只能通过直接观测来确认。

其次，安全边界是确定性的，而非基于学习得出的：系统采用预执行过滤机制，直接拦截已知具有破坏性的 Shell 命令，从而消除了对语言模型在运行时进行拦截的依赖（因为这种拦截往往不可靠且难以验证）。与软件调试中错误命令可撤销不同，在物理机器人上执行不当的固件刷写或误用 rm -rf 命令，可能导致永久性的硬件损坏。

第三，案例结束的判定基于具体的探测操作，而非智体自身的成功声明：在将案例标记为已解决之前，必须先通过一项非运动类的远程操作探测。机器人可能拥有语法正确的配置文件，但同时存在摄像头序列号绑定错误、线缆脱落或急停开关被锁死等问题——这些状态在代码检查中无法察觉，却能通过实时探测立即显现。上述原则通过针对每台机器人的少量持久化文件以及一个运行时门控机制得以实现；图 1 展示了单次会话调试循环中各项原则的具体体现。

为了评估这些原则在实际应用中是否能带来可量化的成效，在两种机器人平台及三类复合故障场景下对 SPINE 进行了测试。在 DOBOT X-Trainer 平台上，一项包含七种场景的基准测试将 SPINE 与专家及新手操作员进行了对比，其中对照组使用的是相同的编码智能体（coding-agent）核心，但不包含 SPINE 的持久化状态或结构化诊断循环功能。在 AgileX PiPER（一款基于 ROS/CAN 架构的双臂机器人）上，展示了五组 SPINE 与专家操作的对比案例，涵盖了软件、硬件及混合型故障等各类问题。针对 DOBOT 的主要研究发现表明，SPINE 能同时提升操作效率与成功率，并降低操作员的感知压力；而针对 PiPER 的评估则旨在验证这些机制是否能迁移至不同的硬件与中间件技术栈中。

---

0 系统概述

SPINE 是一个具备自主智体（agentic）能力的框架，旨在仅需极少的人类专业知识，即可将机器人调整至可供操作员进行远程操作的状态（图 1所示）。SPINE 由两个协同工作的工作流构成：配置构建器（profile builder）和运行时调试器（runtime debugger）。在设置阶段，配置构建器将技术手册、操作员反馈、可选设置说明以及已知的良好系统快照，转化为针对特定机器人的类别配置（category profile）；该配置涵盖元数据、组件、接口、软件、配置、操作流程、安全规范、诊断信息及远程操作验证能力。专门的子智体利用无损证据包草拟配置，随后经由策展（curator）、裁决（adjudicator）和配置修正（profile-doctor）阶段处理，以解决配置中的缺失或冲突，最终完成配置的定稿（封存）。

在运行时，调试器加载已定稿的配置、精简的故障记录、可复用的技能模块及结构化工具，并循环执行目标规划、证据收集、优先级评估（triage）、修复及重新验证等步骤。SPINE 将配置中定义的实时远程操作管线（pipeline）及隐就绪状态探针作为主要证据来源。当故障原因不明时，只读诊断子智体会分别评估终端证据、软件契约偏差、硬件可见性及就绪范围，随后调试器从结构化操作手册中选择软件修改方案或针对操作员的单一硬件操作指令。SPINE 将故障事件、故障模式、验证过程及结案状态记录在针对每台机器人的持久化存储中。确定性安全运行层（safe-runner layer）负责执行配置中定义的检查并记录验证证据；结案关卡（closeout gate）仅在远程操作验证通过后才将案例标记为已解决，否则 SPINE 会将该案例记录为“已诊断”状态，以供后续会话参考。由于针对特定机器人的知识存储于配置和记忆中，而非硬编码在提示词（prompts）里，因此将 SPINE 移植到新平台时，主要工作仅在于构建新的配置，而技能、工具及调试循环逻辑均可跨平台复用。

1 机器人

所有“Compounded-bug”实验均在 DOBOT X-Trainer（轻量级底座版）上进行，这是一个由深圳市越疆科技（Dobot）开发的双臂遥操作平台。该平台包含两个从动臂、两个主动臂、三个 RGB-D 相机、一个电控柜、一个三色指示灯以及紧急停止按钮（按下时可制动两个从动臂）。从动臂的驱动依赖于 DOBOT Nova 2 机械臂（控制器固件版本 ≥ 3.5.7），每台机械臂配备一个最大行程为 95 毫米的平行夹爪；它们通过专用以太网链路与控制工作站通信，并为每个机械臂分配静态 IP 地址。主动臂为 6 自由度（6-DOF）的主控 USB 串口设备；在会话开始时完成同步后，它们将关节配置和夹爪指令传输给从动臂。视觉感知由三个 Intel RealSense D405 RGB-D 相机负责：一个全局俯视相机，以及安装在每个从动臂腕部的相机。控制工作站运行 Ubuntu Linux 系统，使用 Anaconda 部署厂商 SDK，并利用 CUDA/cuDNN 进行策略推理。机器人图像见图 3。

AgileX 实验使用的是 AgileX PiPER，这是一个基于 ROS/CAN 的双臂遥操作平台，由松灵机器人（Songling Robot Co., Limited，隶属于 AgileX Robotics 品牌）制造，由四支 PiPER 6 自由度机械臂构成。两个主动臂和两个从动臂构成了运动学核心，并辅以三个 Intel RealSense D435i RGB-D 相机、一台工业 PC、电源与通信线缆以及 USB 转 CAN 适配器。每支 PiPER 机械臂集成有独立控制器，负载能力为 1.5 kg，通过 CAN 总线通信；从动臂配备了开合范围为 0–70 毫米的双指夹爪。cobot_magic 控制代码库运行于 Ubuntu 20.04 和 ROS Noetic 环境下：CAN 启动配置将左右 SocketCAN 接口（left_piper 和 right_piper）的速率设为 1 Mbps；遥操作启动双 PiPER ROS 节点图（graph）；验证过程则检查四个主动/从动关节话题（topic）以​​及三个相机图像话题。该平台未配备物理急停按钮；操作员可通过触发上位机急停、终止 ROS/Python 进程或切断机械臂电源来停止系统。机器人图像见图 4。

2 SPINE 架构

SPINE 将机器人代码库存储在默认路径，并将 SPINE_code/ 放置于其旁。该框架由两大工作流支撑：一是“配置文件构建器”（profile builder），负责将机器人文档和干净的源码快照转换为结构化的机器人上下文；二是“调试器”（debugger），针对该上下文执行“诊断-修复-验证”循环。一份简短的父级 CLAUDE.md 文件会指示智体优先使用 SPINE 技能、MCP 工具、已编译配置文件及结构化内存，而非临时的手动读取或对代码库进行全量扫描。

配置文件输入。对于每个新机器人，操作员需提供厂商手册、可选参考文件以及一个状态良好的干净代码库或源码快照（支持本地路径或远程 SSH 访问）。当从 SPINE_code_untouched_scaffold 运行程序时，生成的各种状态数据会被存放在该脚手架目录之外的 .spine_generated/SPINE_code_untouched_scaffold/ 路径下；而专用的 SPINE 实例则使用其文件夹内的 robot_input_files/、robot_profiles/ 和 memory/ 目录，除非 SPINE_GENERATED_ROOT 环境变量指定了其他位置。构建器从干净代码库中复制一份经过筛选的快照，并提取相关信息，包括相对源码路径、内容哈希值、命令接口、配置模式（schema）、入口点角色、运行时适配器以及静态一致性检查项——这些信息在运行时无需依赖原始的干净代码库。

由子智体驱动的配置文件构建器。标准的配置文件构建器为 spine-profile-build。它整合手册、提供的源码、操作员的回答以及干净代码库中的文本，生成一个无损的证据包（evidence bundle）。在第一阶段，系统将配置文件构建任务分配给八个类别子智体以及一个遥操作流水线子智体。类别子智体负责起草关于元数据、组件、接口、软件、配置、操作流程、安全性和诊断信息的各项事实；遥操作流水线子智体则负责识别设置、启动、摄像头、状态监控及最终验证相关的命令。随后，策展子智体（curator subagents）审查这些草案，配置文件仲裁者（profile adjudicator）决定接受、拒绝或推迟拟议的修正，最后由确定性构建器配合“配置文件医生”（profile doctor）模块验证并最终确定覆盖范围。
配置文件表示形式。每个汇总生成的配置文件均包含一份清单（manifest）和八个类别的 JSON 文件：元数据、组件、接口、软件、配置、规程、安全及诊断。每项事实都附带其来源信息、可变性、冲突处理策略、状态、源、置信度以及相关事实 ID；清单记录源列表、源哈希值、事实数量、生成状态及遥操作验证摘要；最后的“印章”（seal）则锁定各类别文件的哈希值以及“配置文件诊断报告”（profile-doctor report）。实例级事实（如摄像头序列号、CAN 接口名称、IP 地址和 USB 路径）存储在各自所属的类别文件中，而非单独的动态硬件制品内。

调试器工作流。Spine-debug 启动由代码驱动的调试编排器，该编排器首先加载类别配置文件，确立操作员目标，收集原始故障证据或运行配置文件中定义的遥操作（teleoperation）流水线，规划验证步骤，并执行隐式就绪状态检查。若目标为“遥操作”，则只有完整的实时遥操作流水线成功运行才能结案——静态启动检查不符合结案标准。在进入下一阶段前，每一次软件修改或确认的硬件操作都会触发新一轮的实时遥操作验证及隐式就绪状态检查。

诊断。在发布任何软件修改、硬件操作或宣布成功之前，SPINE 会将每个验证周期引导至四个只读子智体进行处理：终端证据智体（原始终端输出及故障序列）、软件契约智体（对比配置文件与“干净”仓库软件契约的“脏”仓库行为）、硬件可见性智体（设备可见性及人工可修复的硬件故障证据）以及就绪范围智体（判断隐式就绪故障是否影响当前的遥操作图）。编排器为这些子智体编写工作包，收集 JSON 报告，判定分析结果，随后才选择修复方案或发布操作员指令。

记忆。每个机器人的记忆数据存储在其记忆目录下的“仅追加”式 JSONL 文件中：事件日志记录调试结果，故障模式日志存储经筛选的典型故障模式，验证运行日志则捕获验证证据。系统还会同步生成一个紧凑的常见故障模式检索视图。在运行时，工具会优先查询紧凑型记忆数据，将过往事件视为调试先验信息，且仅在验证运行通过后才将案例标记为已解决。

技能与 MCP 工具。该项目包含十四项位于 .claude/skills/ 目录下的技能：包括面向用户的技能（spine-profile-build、spine-debug、spine-check、spine-closeout 和 spine-init），以及涵盖症状分级、调试规划、硬件完整性检查、中间件启动、运行时启动差异分析、软件根本原因分析、遥操作路径追踪及记忆更新等功能的辅助技能。robot-profile-compiler 保留作为当前类别 JSON
配置文件构建器的旧版别名。 MCP 服务器公开 26 种带类型的方法，用于配置文件的显示与构建、会话验证、检查规划与执行、操作员检查清单处理、目标与验证规划、验证记录与状态查询、问题分级（triage）、硬件诊断与推进、调试运行遥测数据采集，以及错误相关的内存搜索与日志记录。

安全运行器（Safe runner）与闭环规则。所有确定性探针和验证任务均通过安全运行器和配置文件执行器进行处理；该执行器仅运行配置文件中声明的检查项，并拒绝任何包含不安全指令（如 sudo、apt、apt-get、pip install、pip uninstall、conda install、conda remove、rm -rf、chmod、chown 或 /etc/）的命令。验证规划器根据请求的目标、隐式就绪性要求、遥操作要求以及可选的“无运动策略”预检步骤，组装成一个执行包。只有当选定的验证目标通过且 spine.validation.record 记录了成功的 validation_run_id 时，案例才会被标记为“已解决”并关闭；否则，案例将被记录为“已诊断”。

骨干语言模型。本研究使用 Claude Sonnet 4.6 作为推理骨干模型，设置温度参数（temperature）为 0，且不进行微调。

3 实验设计

错误植入流程。针对每种复合错误场景，实验人员通过 SSH 登录 DOBOT（或 AgileX）工作站进行操作，而人类操作员则在外部等待，以确保其预先不知道植入了哪些错误或植入了多少个错误。实验人员从原始代码仓库之外的一个全新工作空间路径开始，复制一份功能正常的 DOBOT/AgileX 代码仓库，并按照预定义的场景特定流程植入错误组合：软件错误通过植入脚本写入；硬件错误则在稳定条件下通过引导式物理干预引入，同时保持无关组件不受影响。错误植入经确认无误后，操作员返回并开始试验。

调试流程。当机器人恢复到完全可操作状态或达到 30 分钟时限时，试验结束。两种实验条件——即由​​新手操作 SPINE，以及人类操作员配合通用大语言模型（LLM）编码智体——均在相同的初始条件下开始：双方接收相同的初始提示词，其中仅描述操作员可见的症状。在两种条件下，参与者均不被告知故障的性质或数量——即根本原因是软件还是硬件问题，或者植入多少个错误。

基线对比。SPINE 将自身与当前实验室调试工作中的主流模式进行对比：即由一名研究人员配合一个通用型 LLM 编程智体（coding agent）进行工作。作为基线的智体采用 Claude Sonnet 4.6 [15] 模型，运行于高投入（high-effort）模式并具备 Shell 工具访问权限，但未配置 SPINE 所特有的持久化知识库、安全监控机制或结构化诊断循环。两名研究生参与者担任 DOBOT 平台的人工基准操作员，针对所有三类故障中的每种复合故障场景各完成一次试验。其中一名研究生参与者完成了针对五种 AgileX PiPER 案例的专家级基准试验。这两名参与者的选择旨在涵盖操作经验的不同水平：专家组参与者是一名机器人技术专业的研究生，具备双臂操作、ROS 和实验室现场调试的实践经验；新手组参与者是一名数据科学专业的研究生，此前没有任何机器人操作实践经验，仅在首次试验前接受了关于机器人基本操作和结构的简要讲解。研究结果针对每位参与者分别报告，以便在经验水平的两个极端上评估 SPINE 的性能优势。

两种条件下均使用相同的 Claude Sonnet 4.6 基础模型，因此观察的任何性能差异均反映 SPINE 架构的特性，而非底层语言模型的影响。两种条件下的推理过程均设定温度参数（temperature）为 0。试验顺序上，先进行 SPINE 试验；在所有人工基准试验完成之前，SPINE 的诊断和修复结果均未向人工基准操作员公开。SPINE 试验由第三位参与者（不同于上述两名基准操作员）执行，该参与者符合“新手”特征：无机器人操作实践经验，但对大语言模型（LLM）编程智体有常规了解。这种安排确保 SPINE 操作员同样对预设故障不知情。因此，SPINE 与新手在 OPS 指标上的对比，属于新手群体内部的主题间（between-subject）对比。