Robotic Embodied Intelligence - From Zero to Hero

10.1.1 高层策略（VLA）与低层控制器之间的接口

这一小节的核心问题是：“大脑”（VLA 模型）怎么跟“肌肉”（伺服控制器、电机驱动）说话？ 如果接口设计不好，要么 VLA 决策很聪明但落不了地，要么控制很稳定但能力被严重浪费。

在本书前面，第 6 章已经介绍过机器人运动学和控制基础，这里默认读者已经理解关节空间 / 笛卡尔空间、位置 / 速度 / 力矩控制等概念，本节重点放在系统层面的“约定与协作” 。

10.1.1.1 接口定义

从工程角度看，“接口”就是一份清晰的契约，约定：

• VLA 输出什么格式的命令；
• 低层控制器接受什么、如何解释；
• 双方在坐标系、单位、频率、约束上的共同假设。

可以把接口分成几类维度来理解。

（1）命令空间：控制“什么”

典型选择包括：

• 关节空间命令
  • 目标关节位置：q_target（位置模式）
  • 关节速度：dq_target（速度模式）
  • 关节力矩 / 电流：τ_target（力矩模式）
• 末端空间命令
  • 绝对位姿：T_target（齐次变换或 position + orientation）
  • 增量位姿：ΔT（Delta Pose）
  • 末端速度 / 扭矩：twist_target（线速度 + 角速度）

在 VLA 场景中，最常见的是“增量式”命令（Δ pose / Δ joint）和** 末端速度命令**： 高层每一帧给出“往桌子中心再移动一点”“手爪再向下 1 cm”，低层控制在高频率下把这些增量平滑跟踪。

（2）坐标系与单位：防止“说的不是一个世界”

接口必须明确：

• 坐标系：
  • 世界坐标系（map / world）
  • 机器人基座坐标系（base）
  • 工具坐标系（TCP / end-effector）
• 单位：
  • 位置（m / mm）、角度（rad / degree）、速度（m/s、rad/s）、力矩（N·m）
• 方向约定：
  • 右手坐标系，旋转正方向的定义等

实际工程中，许多“莫名其妙”的事故（机械臂猛然乱动）都来自单位或坐标系搞错。 因此接口规范里通常会明确列出：

“所有角度使用弧度制；位置在 base 坐标系下，以米为单位；姿态采用四元数 \((w, x, y, z)\) 表示。”

（3）命令约束与安全边界

接口还要规定 VLA 绝对不能越界的范围：

• 最大关节速度 / 加速度 / 力矩
• 允许的工作空间（例如机械臂末端在某个立方体范围内）
• 力 / 速度安全阈值（用于人机协作）

低层控制器通常在 500 Hz–1 kHz 的频率下运行闭环控制，这样可以对约束做非常快的监控与裁剪。(Robotics Stack Exchange) VLA 在接口层面不必实现全部安全逻辑，但必须承认 这些约束，接受低层“削减命令”的权利。

（4）接口形式：消息结构与调用方式

在 ROS/ROS2 等系统中，接口往往体现为：

• 一条“动作命令”话题（Topic）或 Action：
  • 消息中包含：时间戳、机器人 ID、目标位姿 / 增量、手爪开合状态等；
• 一条“状态反馈”话题（见 10.1.1.3）；
• 可选服务 / Action：执行复杂技能（如“抓取”原语）。

此处不再重复第 6.4 章中对 ROS 节点 / 话题的概念，而更强调：VLA 作为一个“高层节点”，只要完全遵守这份契约，就可以在不同机器人上复用。

【图 10-1 占位： “VLA–控制器接口契约示意图”。 左侧是 VLA 模型（输入视觉与语言），输出一个结构化动作消息；右侧是控制器堆栈（轨迹生成器 + 伺服 + 驱动），中间用一条“动作命令”消息通道连接，并在旁边标注坐标系、单位、约束等。】

10.1.1.2 时序协调

高层策略与低层控制最大的不一致在于时间尺度：

• 低层伺服：
  • 控制周期典型为 0.5–1 ms（1–2 kHz），对控制稳定性和安全性负责。(Robotics Stack Exchange)
• 运动规划 / MPC：
  • 运行频率常在 10–100 Hz 之间，受限于规划 / 优化计算开销。(Taylor & Francis Online)
• VLA 决策：
  • 受限于深度模型推理，在边缘 GPU 上通常 5–20 Hz（50–200 ms 一次前向），复杂模型在 CPU 或云端可能更低。

因此，接口必须解决两个问题：

1. 命令插值与保持（hold）
   • VLA 每隔 100 ms 输出一条“末端速度 / 增量位姿”；
   • 中间 99 个伺服周期怎么办？
   • 常见做法：
     • 低层控制器对高层给出的目标轨迹做时间插值，生成更高频率的中间参考点；
     • 如果高层暂时没更新，就保持上一条命令（zero-order hold），但要设定超时机制，超时后自动减速或停车。
2. 异步与实时性
   • VLA 通常运行在非实时操作系统或 GPU 上，推理时间存在抖动；
   • 低层控制必须在硬实时线程中运行，以保证周期固定。(Open Robotics Discourse)
   • 典型工程做法：
     • 使用共享内存或无锁环形缓冲区 传递 VLA 输出；
     • 低层在每个伺服周期读取“最新一条合法命令”，避免受上层抖动影响；
     • VLA 线程则尽可能在软实时约束下完成前向推理。

一个简单的时间线心智模型：

• t = 0 ms：相机采集图像，关节状态打上时间戳；
• t = 5–10 ms：预处理完成，送入 VLA；
• t = 15–80 ms：VLA 推理完成，写入共享缓冲；
• t = 80–100+ ms：低层控制周期读取该命令，插值并输出力矩；
• 下一帧图像再开始新一轮推理。

接口定义中往往会明确两个参数：

• 高层决策周期 T_policy（如 100 ms）；
• 低层控制周期 T_control（如 1 ms）；

设计目标：在 T_policy 这一时间尺度上，系统仍然“像一个闭环控制系统”那样稳定。

10.1.1.3 状态反馈

高层策略要实现闭环，必须获得足够的状态反馈 。 但不需要把所有传感器原始数据都推给 VLA，否则带宽和推理负担都无法承受。

可以按“层级”来组织状态反馈：

（1）底层反馈：供控制与安全使用

• 关节级：q, dq, τ
• 末端位姿：T_ee
• 触觉 / 力觉：末端力 / 力矩
• 安全信号：急停状态、碰撞触发标志

这类反馈在 100–1000 Hz 下被低层控制器使用，VLA 一般只看到被下采样 或摘要化 后的结果，例如每 100 ms 读取一次当前关节角和末端位姿。

（2）高层反馈：供策略与语义决策使用

• 场景级：当前图像 / 语义分割 / 物体检测结果；
• 任务级：
  • 当前是否已抓住目标物体；
  • 当前子任务完成度（例如“已清理 4/5 个碗”）；
• 机器人内部状态：
  • 当前执行的子技能名称（grasp / move / place）；
  • VLA 上一次输出动作的执行结果（成功 / 被裁剪 / 因碰撞中止等）。

从接口的角度，常见设计是：

• 输出接口：ActionCommand（高层 → 低层）；
• 输入接口：Observation（低层 + 感知 → 高层）；
• 二者保持结构上的对称性：
  • Observation 中也包含与 VLA 动作空间相同的坐标系与单位。

在实现中，Observation 通常会统一打包为 VLA 模型的输入张量（如 stacked images + 状态向量），细节在第 8 章架构部分已经展开；本节更强调一点：Observation 不是“随便往里堆数据”，而是由接口契约约束的、与动作空间配套的反馈。

【图 10-2 占位： “闭环接口与状态反馈示意图”。 画出 VLA、低层控制器、机器人本体三个模块，VLA → Controller 为 ActionCommand 箭头，Controller + Robot 回到 VLA 为 Observation 箭头，其中 Observation 分为“高频硬件反馈”与“低频抽象反馈”两层。】

10.1.2 在线推理框架：从传感器到动作命令的数据流

这一节从“流水线”的角度看 VLA 部署： 一帧图像从相机出来，到机器人真的动起来，中间到底发生了什么？

我们可以把整个在线推理过程拆成三段：

1. 感知输入管道；
2. 模型推理；
3. 执行输出与闭环。

10.1.2.1 感知输入管道

感知输入管道是从物理世界 → 数字表示 的过程，目标是为 VLA 提供时间对齐、格式统一、噪声可控 的观测。

（1）数据采集与时间戳

• 摄像头：RGB / RGB-D 图像，分辨率与帧率根据任务选择（如 640×480 @ 30 FPS）；
• 机器人状态：关节角、末端位姿、手爪状态等；
• 其他传感器：力矩传感器、激光雷达等（若参与决策）。

关键是：所有数据必须带有时间戳，以便在后端进行对齐。 在 ROS2 等中间件里，这通常通过统一时钟（/use_sim_time / 系统时钟）实现。(Open Robotics Discourse)

（2）预处理与同步

预处理常见步骤：

• 几何校正：去畸变、裁剪无用区域；
• 尺度调整：缩放到模型接受的分辨率（如 224×224）；
• 归一化：减均值 / 除方差、通道换序 (HWC → CHW)；
• 传感器融合：如相机 + 深度图对齐，拼到同一坐标系中。

时间同步通常有两种方式：

• 硬同步：硬件触发多个传感器同时采样；
• 软同步：在软件层根据时间戳在附近时间窗口内找“最近帧匹配”。

对于 VLA 来说，最关键的不是毫秒级同步，而是语义上的一致： 同一 Observation 中的图像与状态，应对应同一物理时刻，这样 VLA 才能把语言目标、视觉场景和机器人的身体状态联系起来。

（3）数据裁剪与带宽控制

在第 7 章我们讨论了数据采集与存储，这里强调在线推理时，还要考虑：

• 不必把全分辨率图像 送入模型，可以先做 ROI 裁剪（例如只截取桌面区域）；
• 对于云端推理场景，可以在本地做部分编码（JPEG、H.264）或特征提取，再上传；
• 通过合理压缩减少网络带宽占用。(Medium)

【图 10-3 占位： “感知输入管道数据流示意图”。 从左到右：Camera / Joint States / Force Sensor → 时间戳标注 → 预处理模块（校正、缩放、裁剪）→ 构造 Observation 张量 → 输入到 VLA。】

10.1.2.2 模型推理

这一部分是 VLA 的“前向过程”，但在部署场景下，需要额外关注资源、时间预算和并发 。

（1）推理拓扑

常见设计是：

• 一个前端进程 负责接收感知数据、构造模型输入；
• 一个推理进程 / 线程 负责加载模型权重，在 GPU / NPU 上执行前向；
• 中间用队列或共享内存传递 batch。

为了降低延迟，在线 VLA 推理一般采用：

• batch size = 1（单样本推理），减少排队等待；
• 固定图像分辨率与张量尺寸，避免频繁重新分配内存。(arXiv)

（2）时间预算与监控

在线控制场景中，每一步决策都有严格的时间上限，例如：

• 规划 / MPC：50 Hz，即 20 ms 内必须完成一次优化；(Taylor & Francis Online)
• VLA 决策：假设设定为 10 Hz（100 ms 一次），则必须保证**“图像进来 → 动作输出”** 整体在 100 ms 内完成，并留出裕度。

工程上通常会：

• 记录每次前向推理耗时，统计平均值、最大值；
• 设定超时策略：
  • 如果单次推理超时，则放弃当前输出，用上一帧动作；
  • 若连续多次超时，系统进入降级模式（减速、停止等），参见 10.3 节安全性讨论。

（3）模型版本与热更新

在实际系统中，VLA 模型可能在云端持续改进，需要热更新 到机器人上：

• 接口约定保持稳定（动作 / 状态格式不变）；
• 使用版本号标记 VLA 模型（v1, v2…）；
• 更新流程：先在仿真 / 数字孪生环境验证，再灰度部署到少量机器人，最后全量更新。(PMC)

这里不展开 MLOps 细节，读者可结合第 9.4 节一起理解。

10.1.2.3 执行输出

VLA 输出的是抽象动作（token 序列 / 连续向量），要变成电机电流，至少还要经过三层处理：

1. 动作解码与约束裁剪
2. 轨迹生成与平滑
3. 发送命令与结果反馈

（1）动作解码与约束裁剪

在第 8.3 节我们讨论了动作 token 的设计，这里从系统角度看：

• 将模型输出的 token 序列还原为：
  • 末端位姿增量 ΔT；
  • 或关节增量 Δq / 速度命令；
• 对结果进行：
  • 数值裁剪（clip 到物理允许范围）；
  • 安全检查：若某一维度超出设定阈值（例如瞬时速度过大），可直接拒绝并记录日志。

（2）轨迹生成与平滑

直接执行“阶跃命令”容易导致机器人动作生硬甚至振荡，需要在接口下游加入轨迹生成模块：

• 使用插值（线性、三次样条）在两个高层命令之间生成平滑轨迹；
• 结合动力学约束（最大速度、加速度、jerk）优化轨迹，例如使用 MPC 或时间缩放方法。(arXiv)

轨迹生成模块很像一个“传统规划器的缩小版”，主要目标是把 VLA 的高层意图转化为可执行的、物理可行的微小动作 。

（3）命令发送与执行结果回流

最后一步是：

• 将轨迹（或当前目标点）封装为机器人控制器的原生命令：
  • 如 ROS 中的 FollowJointTrajectory / Twist 命令；
• 底层控制器执行后，每个周期更新当前状态；
• VLA 模块在下一次前向时，将“上一条命令的实际执行结果”作为 Observation 的一部分，形成真正的闭环（而不是假设输出动作一定被成功执行）。

【图 10-4 占位： “在线推理完整数据流：从传感器到动作命令”。 左侧多源传感器，经预处理后进入 VLA；中间为 VLA 推理模块；右侧是“动作解码 → 轨迹生成 → 控制器 → 机器人”的执行链路，整个流程形成闭环箭头。】

10.1.3 本地推理 vs 云端推理、延迟与带宽问题

在较大的 VLA 模型出现后，“模型放哪里跑”变成一个系统架构的核心设计问题。

• 本地推理（on-board / edge）：部署在机器人自身或附近的边缘计算节点；
• 云端推理（cloud）：部署在数据中心 GPU 集群；
• 混合模式（hybrid）：高频 / 安全关键逻辑本地，低频 / 重计算逻辑云端。

边缘计算和云机器人（cloud robotics）的文献已经系统讨论过这一问题： 边缘侧提供低延迟和更好的隐私与带宽利用，而云侧提供大规模算力与集中学习能力。(MDPI)

10.1.3.1 本地推理

优势：

1. 低延迟、低抖动
   • 数据在本地采集、本地推理，本地执行，链路仅包括设备内部总线和局域通信；
   • 避免公网不稳定带来的长尾延迟，对于抓取、避障等闭环控制至关重要。(MDPI)
2. 安全性与可用性
   • 即使断网，机器人仍可执行基础功能；
   • 敏感数据（室内环境、人员信息）可以不出本地网络，降低隐私风险。(Medium)
3. 简化带宽需求
   • 不需要持续上传高分辨率视频流，只在必要时上传摘要或统计信息。

劣势：

• 算力受限：嵌入式 GPU / NPU 的功耗和算力与数据中心差距较大；
• 模型大小受约束：需要在第 10.4 节中所说的压缩、量化和蒸馏后才能部署；(promwad.com)
• 维护复杂：大量机器人各自部署模型，版本管理、更新和监控的工程成本较高。

适用场景：

• 高速移动机器人（无人机、移动底盘）需要 50–100 Hz 以上的决策；(科学直通车)
• 人机协作、与人近距离接触的机械臂，要求可预测、可控的反应时间；
• 网络质量不可保证（工厂、家庭 Wi-Fi 环境）的场景。

10.1.3.2 云端推理

优势：

1. 强大算力与模型规模
   • 云端可以部署百亿甚至千亿参数的综合 VLA / 多模态模型，提供更强的推理与规划能力；(ResearchGate)
   • 支持复杂的长时规划、多机器人协同调度等。
2. 集中管理与协同学习
   • 多台机器人共享云端模型与经验，云端可根据海量日志持续训练 / 微调模型，再统一下发更新；(ResearchGate)
   • 支持跨机器人联合学习、联邦学习等机制。
3. 运维便利
   • 模型部署、版本回滚在云端统一进行，对终端设备影响较小。

劣势：

1. 延迟与抖动
   • 端到端延迟包括上传数据、队列排队、推理、下行返回；
   • 在复杂网络环境下，延迟和抖动难以控制，很难用在 20 Hz 以上的硬实时控制。(伯克利自动化)
2. 网络依赖与故障模式
   • 一旦网络中断或拥塞，云端推理不可用，需要本地有应急策略；
   • 安全关键任务不能完全依赖云端决策。
3. 隐私与带宽成本
   • 持续上传高分辨率视频与传感数据消耗大量带宽，并带来隐私与安全风险。(Medium)

适用场景：

• 决策频率可较低的任务，如高层任务规划、策略生成、任务解释；
• 机器人队列规模较大，希望在云端做全局调度和优化；
• 对模型能力要求极高，而本地算力不足以运行完整大模型。

10.1.3.3 混合模式

实际工程中，越来越多系统采用云–边–端的混合架构：

• 端（robot）：机器人本体及其嵌入式控制器；
• 边（edge）：靠近机器人部署的边缘服务器 / 网关；
• 云（cloud）：远端数据中心。

FogROS2、混合机器人平台等系统都强调：让低延迟、安全关键决策留在边 / 端，高层策略和学习放在云侧 。(伯克利自动化)

典型分工模式：

1. 端：基础控制 + 安全保护
   • 1 kHz 伺服控制、碰撞检测、急停逻辑；
   • 简单的动作原语执行（如固定抓取、固定放置）；
   • 网络断开时的降级策略（缓慢停止、原地等待）。
2. 边：中等规模 VLA 推理 + 局部规划
   • 在边缘 GPU 上运行压缩版 VLA 模型（10–100M 参数级）；
   • 执行视觉感知 + 短期动作决策，如“抓起桌上的杯子”；
   • 与端设备通过有线或局域网通信，延迟可控制在 10–20 ms 级别。
3. 云：大模型推理 + 全局优化 + 持续学习
   • 接收略下采样的感知数据和执行日志；
   • 给出长期任务分解、策略建议或新模型版本；
   • 不直接参与闭环控制，而是作为策略更新与知识源 。

【图 10-5 占位： “云–边–端混合架构示意图”。 底部是机器人本体（servo + safety），中间是边缘计算节点（运行轻量 VLA、局部规划），顶部是云端（大模型、策略学习）。箭头标注高频低延迟数据流与低频高层策略流。】

10.1.4 模块化系统：感知、规划、控制与 VLA 的关系

在传统机器人软件架构中，已形成比较成熟的模块划分：感知 → 规划 → 控制 。(科学直通车)

VLA 的出现，并不意味着这些模块会被完全替代，而是带来一个新问题：

“VLA 究竟站在什么位置？怎样与已有模块协同，而不是互相掣肘？”

可以把系统想象成一个多层结构：

• 底层：控制（Control）——电机级控制、轨迹跟踪；
• 中层：运动规划（Motion Planning）——生成无碰撞轨迹；
• 上层：任务 / 策略（Task / Policy）——决定做什么、怎么做；
• 侧向：感知（Perception）——不断提供对环境的理解。

VLA 最自然的位置是**“上层任务 / 策略”的新实现方式**，但它可能渗透到中层与侧向模块。

10.1.4.1 感知模块

前面第 3 章已经详细介绍过视觉感知，这里从系统架构角度总结一下感知模块的角色：

• 构建环境的多层表示：
  • 几何层：地图、障碍物位置、物体 6D 位姿；
  • 语义层：物体类别、“可放置区域”、“可抓取区域”等语义信息；
• 提供统一的世界模型接口：
  • 规划器与 VLA 不直接操作原始图像，而是使用“物体列表 + 语义标签 + 几何信息”等结构化表示。

在与 VLA 的关系上，有三种典型模式：

1. VLA 直接读取原始感知（端到端）
   • 图像直接送入 VLA 的视觉 backbone；
   • 感知模块仅负责相机标定与基础预处理；
   • 优点：模型可以学到任务相关特征；缺点：可解释性差，难以复用传统感知成果。
2. VLA 读取感知模块的中间表示
   • 感知模块输出目标检测框、物体位姿等；
   • VLA 接收这些结构化信息，结合语言和历史，输出动作；
   • 这是经典模块化与 VLA 的折中：部分端到端，部分符号化 / 结构化。
3. VLA 指导感知模块
   • VLA 可以输出“关注区域”（attention ROI）、“要识别的物体类别”等，反过来驱动感知模块调整算法重点；
   • 特别是在计算资源有限时，VLA 可以作为“感知调度器”。

在系统实现中，感知模块与 VLA 之间同样通过明确的接口契约联系： 例如定义统一的场景图（scene graph）或物体列表结构，包含 ID、类别、位姿、尺寸等信息。

10.1.4.2 规划模块

规划模块是“把目标变成可执行路径”的那一层。 包括：

• 运动规划（如 RRT / PRM / TrajOpt / MPC）；(arXiv)
• 任务规划（如基于 PDDL 的符号规划，或基于图模型的多步任务分解）。

VLA 与规划模块的关系大致有三种：

1. VLA 取代任务规划，但保留运动规划
   • VLA 接受语言指令与场景信息，输出一系列子目标 / 子任务：
     • 例如：“先移开杯子，再擦桌子”；
   • 运动规划器负责把每个子任务转化为无碰撞轨迹；
   • 优点：兼顾 VLA 的通用性和传统规划的可靠性；
   • 缺点：需要为 VLA 设计清晰的“子任务接口”（类似 skill API）。
2. VLA 与规划器并联，互为备选
   • 对于简单场景，传统规划器可以独立完成任务；
   • 对于复杂、模糊目标（如“收拾桌面”）由 VLA 产生更鲁棒的动作序列；
   • 系统可以根据环境状态（拥挤、障碍复杂）、性能指标（时间 / 成功率）动态选择调用哪个规划来源。
3. VLA 内部隐式实现规划能力
   • 对某些简单任务，经过大量示教 + RL，VLA 可以近似实现一个端到端的“学习型规划器”；
   • 例如学会在各种桌面布局下抓取、排序物体，而无需显式调用 RRT；
   • 此时传统规划模块更多作为安全 fallback 或** 特殊场景的补充**。

无论采用哪种模式，工程上一个重要思想是：不要把传统规划直接废掉，而是让它在系统中保留“安全网”的角色——在 VLA 输出的动作可能导致碰撞时，规划器可以给出安全替代方案或拒绝执行。(科学直通车)

10.1.4.3 VLA 集成

综合前几小节，可以把 VLA 在整个模块化系统中的位置总结为三种典型集成模式（它们并不互斥，可以在同一系统中共存）：

模式 A：VLA 作为“高层策略模块”

• 输入：
  • 语言指令；
  • 感知模块输出的场景表示；
  • 机器人当前任务状态；
• 输出：
  • 子任务序列（调用现有 skill / motion primitive）；
  • 或短期子目标（某个物体的目标位姿）；
• 运动规划与低层控制保持原样，只是把原来手工编写的规则 / 状态机换成了 VLA 学到的策略。

这种模式对已有工业系统最友好：只替换最上层的大脑，不动底层“肌肉和脊髓”。

模式 B：VLA 作为“端到端控制策略”，传统模块做安全监护

• VLA 直接从图像和任务语言输出末端速度 / delta pose；
• 运动规划器主要做“离线验证”和“在线可行性检查”：
  • 异步预估 VLA 输出在多少步后是否可能碰撞；
  • 一旦检测到危险，修改或打断 VLA 的动作序列；
• 感知模块仍可以为 VLA 提供高级语义，例如标签、可抓取区域。

很多最近的具身智能系统在实验室阶段采用这种模式：主角是 VLA，但背后仍有一套“影子规划与监控系统”在兜底。(arXiv)

模式 C：VLA 与传统模块高度融合的“混合系统”

• 部分子任务完全由 VLA 决策（如整理桌面中的抓取顺序）；
• 部分子任务仍由传统模块负责（如全局导航、SLAM 建图）；
• VLA 与传统模块互相调用：
  • VLA 通过 API 请求“移动到某个导航目标”；
  • 规划模块通过 API 请求 VLA 生成“下一步操作建议”。

这种系统往往更复杂，但有更好的可扩展性： 新任务可以通过增加新的技能模块 + 训练 VLA 如何调用这些技能来实现，而不必完全重新训练一个端到端策略。

【图 10-6 占位： “模块化系统中 VLA 的三种集成模式”。 画出三个小图：

• 左图：VLA 在感知之上、规划之下；
• 中图：VLA 直接输出控制，规划器作为“安全监护”包裹在旁边；
• 右图：VLA、感知、规划之间有双向箭头，表示互相调用的混合系统。】

本节从接口、数据流、部署位置和模块化架构四个角度，讨论了 VLA 如何“落地”到真实机器人系统中。 与前面章节的区别在于：不再只关注模型本身，而是把它视为整个机器人软件栈中的一个**“高层智能组件”**，强调与感知、规划、控制以及边缘 / 云基础设施的协同关系。

理解这一层，对后续在第 10.2 节设计评测协议、在第 10.3 节系统性考虑安全与鲁棒性，都是必要的铺垫。