企业官网建设流程全解析

在 2025 年这个时间节点谈“具身智能”，你会发现一个非常明显的趋势：大模型不再只存在于云端聊天框里，而是开始往“胳膊”“轮子”“机械爪”上迁移。业界把这类尝试统称为 Vision-Language-Action Model，也就是视觉-语言-动作模型，简称 VLA。而 VLM（视觉语言模型）则是 VLA 的认知底座。

这篇文章会比较系统地讲清楚三条主线：VLM 和 VLA 到底有什么区别，OpenVLA、Octo、π₀ 这三套架构各自解决什么问题，以及如果你打算在自己的机器人项目里跑通一个 VLA 推理，应该从哪下手。文中会给出可参考的 Python 推理代码、C++ 桥接层示例，以及树莓派小车部署时的硬件选型建议，适合初学者建立框架认知，也适合刚转向具身智能开发的工程师快速做技术选型。

1. 具身智能与 VLM、VLA 的关系

1.1 什么是具身智能

“具身智能”可以拆成两个词来理解：具身、智能。

所谓“具身”，指的是智能体有一个物理载体，比如机械臂、四足机器人、人形机器人、履带小车。它不再像 ChatGPT 那样只能通过文字与你交互，而是能通过传感器感知真实物理世界，再通过电机、气缸、舵机等执行器改变世界状态。

所谓“智能”，在今天的语境下通常指大模型带来的理解、推理、规划能力。比如看到桌上一只红色杯子，模型能理解“把红色杯子放到托盘里”这句话的含义，并结合图像中的位置信息，规划出一条可行的轨迹。

所以，具身智能研究的核心问题可以概括为一句话：

如何让智能体借助大模型的感知与推理能力，在非结构化环境中完成物理操作任务。

这句话里的“非结构化环境”很重要。工业机械臂之所以不叫具身智能，是因为它在固定工位上重复执行固定轨迹，环境高度结构化。真正难的是：桌面乱糟糟、物体位置随机、光照变化、指令措辞不确定，机器人仍然能完成任务。

1.2 从 VLM 到 VLA：从“能看懂”到“能动手”

VLM 的全称是 Vision-Language Model，视觉语言模型。它接受图像和文本输入，输出文本。比如输入一张桌子照片和问题“桌上有几个苹果”，VLM 能回答“3 个”。

VLA 的全称是 Vision-Language-Action Model，视觉语言动作模型。它在 VLM 基础上多了一个动作输出，而且这个输出不再是文本，而是机器人可以执行的 action。action 可以是末端执行器的位姿增量，也可以是关节角度的增量，还可以是 6 自由度的速度指令。

两者的关系可以这样理解：

VLM 很多时候被用来做“感知和规划”，VLA 则负责把规划结果落到真正可执行的动作上。如果做一个 3 层架构来理解，就是：

1. 感知层：VLM / 视觉编码器，负责理解场景。
2. 规划层：大模型或专门的规划模块，负责拆解任务。
3. 控制层：VLA 或传统控制算法，负责输出低层动作。

1.3 两个典型误区先避开

误区一：VLA 只是“VLM 加了一个全连接层”。

这种说法过于简化。VLA 的关键难点在于动作的表示方式、动作与视觉特征的跨模态对齐、以及高频实时推理带来的工程挑战。它不是简单地在 VLM 后面接一个回归头。

误区二：有了 VLA，PID 控制、MPC、轨迹规划就完全不需要了。

VLA 目前主要输出的是高层动作意图或短时步的低层动作，实际部署时仍然需要底盘控制器、机械臂逆解、电机伺服环、安全限位等底层控制逻辑。VLA 更像是一套“决策大脑”，而不是末端电机的替代品。

2. VLM 入门：视觉语言模型的工作原理

2.1 VLM 的基本组成

几乎所有现代 VLM 都包含三个组件：视觉编码器、语言模型、模态对齐模块。

视觉编码器的作用是把图片切分成若干 patch，再转换成视觉 token。常见实现包括 CLIP 的 ViT、SigLIP、DINOv2 等。语言模型一般就是 Transformer decoder，负责理解文本指令并生成回答。模态对齐模块负责把视觉 token 映射到语言模型的语义空间。

# 一个典型的 VLM 推理流程示意 from transformers import AutoModelForVision2Seq, AutoProcessor processor = AutoProcessor.from_pretrained("your_vlm_model_id") model = AutoModelForVision2Seq.from_pretrained("your_vlm_model_id") image = "desk.png" prompt = "请描述桌面上的物体位置。" inputs = processor( text=prompt, images=image, return_tensors="pt" ) output_ids = model.generate(**inputs, max_new_tokens=64) answer = processor.batch_decode(output_ids, skip_special_tokens=True) print(answer)

注意：不同 VLM 的加载方式差异很大，上面的代码只是通用概念示意，实际使用时要按你选择的模型仓库去调整 processor 和 model 的调用方式。

2.2 VLM 在机器人里的工作流

在机器人系统里，VLM 通常承担三个职责。

第一是场景理解。机器人需要知道面前有什么物体、物体在什么位置、它们的属性是什么。例如“托盘里是一个银色杯子还是蓝色螺丝刀”，这类任务直接用 VLM 就能完成。

第二是任务拆解。拿到一句高层指令“把桌面清理干净”，VLM 可以输出自然语言的子任务序列：先拿起杯子放到水槽，再把螺丝刀放回工具盒，最后把抹布叠好。这一步通常输出的是文本结构化结果，比如 JSON 数组。

第三是错误检测与状态判断。机器人执行完一个动作后，VLM 可以拍一张照片并判断“杯子是否已经放到托盘里”，用于闭环验证。

一个常见的工作流是：

用户指令 -> VLM 任务拆解 -> 子任务列表 -> 每个子任务调用 VLA 或控制策略 -> 执行后 VLM 验证结果 -> 进入下一个子任务

这个流程中，VLM 负责“认知”，VLA 或传统控制策略负责“动作”。

2.3 为什么 VLM 不能直接控制机械臂

原因是输出空间不匹配。

VLM 输出的是文本 token，而机械臂控制器需要的是数值向量，比如手爪开合状态、末端目标位姿、关节角度增量。如果要让 VLM 直接控制机械臂，就需要把数值动作序列转换成文本，这会造成严重的信息损失，也带来推理延迟问题。

再往深处说，VLM 的注意力机制是为“语言上下文相关性”设计的，它对连续轨迹、力学约束、执行器限制没有先验概念。它能告诉你“应该把杯子拿起来”，但它很难告诉你“在这一帧图像下，关节 3 需要转动 0.2 弧度”。

所以才会需要 VLA：让模型从机器人的实际轨迹数据中去学习如何把视觉特征、语言指令映射到动作向量。

3. VLA：把语言指令变成机器人动作

3.1 VLA 的架构思路

VLA 的基本架构通常可以分为两层：底座模型 + 动作头。

底座模型通常是预训练过的 VLM。优势很明显：模型已经具备视觉理解和语言推理能力，只需要再学一层“动作知识”。这样可以减少对机器人动作数据量的依赖。动作头则负责把模型最终输出的隐藏状态转换成动作向量。

在 OpenVLA 这类开源模型中，常见做法是让 VLM 输出离散的动作 token，再通过一个离散 token 到连续动作的映射器还原成机器人可以执行的动作。

在 π₀ 这类通用机器人大脑中，做法会更偏“直接回归”。模型预测连续动作 chunk，也就是未来若干步的动作序列一次性输出，减少高频推理带来的延迟问题。

3.2 动作空间的编码方式

机器人动作通常用三种方式表示。

第一种是关节空间表示。比如 6 自由度机械臂输出 6 个关节角的增量值。优点是控制精确，缺点是不同机器人结构不同，迁移难度大。

第二种是末端执行器空间表示。输出三维位置增量、三维姿态增量，以及手爪开合状态。优点是便于跨机械臂迁移，但需要下游机器人具备逆运动学能力。

第三种是离散化 token 表示。把连续的动作值离散成若干区间，再转成 token。比如 OpenVLA 就使用这种方案，模型最终输出的是离散动作 token 序列。

在实际部署中，动作空间选择决定了 VLA 模型的通用性和工程复杂度。如果你的目标是做单台六轴机械臂研究，首选末端执行器表示；如果你的目标是让同一套模型适配多种机器人，可能需要考虑关节空间与本体标定的配合。

3.3 VLA 的训练流程简述

VLA 训练一般分两步。

第一步是加载预训练 VLM 权重，保持大部分参数冻结，只对部分层进行微调。第二步是在机器人轨迹数据上训练。轨迹数据由“图像序列 + 语言指令 + 动作序列”组成，也就是常说的一对一的训练样本。

训练时，通常把历史图像和动作也作为输入。为什么要历史信息？因为单帧图像无法判断物体运动方向，也无法处理机械臂手爪遮挡物体的常见情况。多帧输入可以给模型更好的时域感知。

下面是一个简化伪代码：

# 伪代码：VLA 训练数据构造 sample = { "prompt": "把红色杯子放到托盘中央", "images": [frame_1, frame_2, frame_3], # 历史多帧 "actions": [ {"dx": 0.01, "dy": 0.02, "dz": -0.03, "gripper": 1}, {"dx": 0.01, "dy": 0.02, "dz": -0.03, "gripper": 1} ] }

注意，动作序列需要做归一化，否则不同量纲的动作分量会让模型训练不稳定。常见做法是按各维度的标准差缩放到适合的数值范围，但具体实现要按模型仓库的说明为准。

4. 三大具身智能架构解析

4.1 OpenVLA：开源 VLA 的标杆实现

OpenVLA 是目前开源社区里非常有代表性的视觉语言动作模型。它基于一个 7B 参数的视觉语言模型底座，通过海量互联网图文数据预训练，再使用机器人示教数据微调，建立了视觉输入、语言指令与动作输出之间的映射能力。

OpenVLA 的一大特点是开放权重。无论你是研究机构还是个人开发者，都能拿它在自己的机械臂、仿真环境或小车上做二次训练，这大大降低了 VLA 的研究门槛。对于刚入门具身智能的同学，OpenVLA 是最容易“跑通一个完整 VLA 链路”的开源选择。

OpenVLA 的动作空间设计为离散 token。模型对一个动作向量的每一维都进行离散化，将一个连续向量转成一串离散 token。这种做法的好处是训练时和语言模型天然兼容，缺点是动作精度受离散化粒度限制，实际部署时通常要做后处理平滑。

使用 OpenVLA 时，要注意它的推理延迟通常较高。公式上，7B 模型在消费级显卡上做单帧推理，往往需要数秒钟。如果机器人任务要求高频控制，就需要在模型推理频率和执行频率之间做折中，通常会在上位机规划层面加缓冲。

4.2 Octo：跨具身预训练策略

Octo 是另一条技术路线的代表。它不强调“大规模语言推理”，而是专注于“跨具身、跨任务”的机器人预训练策略。

Octo 使用 Transformer 架构，处理多模态输入，包括视觉观测、任务描述、动作历史。它从多个真实机器人数据集和仿真数据集中学习通用的行为模式，目标是让新机器人、新任务能够快速适配，不需要从零开始训练。

Octo 早期版本采用的是一种基于扩散模型的策略输出方式，对整个动作序列进行去噪，而不是逐 token 回归。这种方式在动作连续性和多峰行为上表现更好。它适合做机械臂操作策略，但语言理解能力没有 VLM 底座那样强，更多时候配合外部语言模型使用。

4.3 π₀：通用机器人大脑

π₀（在不同资料中也会写作 pi-zero）是面向通用机器人大脑方向提出的架构，它把语言模型训练中的大规模预训练思路迁移到了机器人动作空间中。

π₀ 的核心理念是：先构建一个通用的“视觉-语言-动作”底座，用海量异构机器人数据做大规模预训练，再针对具体下游任务做轻量微调。相比早期 VLA，π₀ 更强调泛化性和实时性。

动作输出方面，π₀ 通常输出连续的 action chunk，也就是同时预测未来多步的动作，从而减少推理频率，提升控制稳定性。这一点在机器人实际控制中非常关键，因为单步预测很容易产生抖动，而多步预测可以让执行器轨迹更平滑。

需要说明的是，π₀ 相关的技术迭代较快，不同时间公布的细节可能存在差异。这篇文章只讨论通用架构思想，具体实现细节要以论文和开源仓库为准。

4.4 三者对比

选择哪套架构，关键看你的实际场景。如果想兼顾语言理解和操作，先看 OpenVLA；如果有多台不同构型机器人，希望复用行为策略，建议研究 Octo；如果想追踪前沿机器人大脑方向，π₀ 的思路必须了解。

5. 本地运行 VLA 的完整示例

5.1 环境准备

在开始跑 VLA 之前，先确认你的环境。

操作系统方面，推荐 Ubuntu 20.04 或 22.04。Python 版本建议 3.10 以上。PyTorch 版本建议使用 CUDA 12.x 对应的稳定版本。模型推理建议至少准备一块 16GB 显存以上的 GPU。如果你只有 CPU，7B 模型虽然也能启动，但推理速度会非常慢，不推荐用于实时控制验证。

如果是树莓派小车这类边缘设备，情况要单独讨论。树莓派 4GB 版本适合跑基础控制、图像采集和轻量视觉模型；如果希望在边缘端跑更接近 VLA 的轻量化模型，建议直接上 8GB 版本，并且优先考虑挂载 NPU 或 GPU 加速卡。即便如此，7B 级别的 VLA 也很难在树莓派上实时运行，通常的做法是：树莓派负责传感器采集和电机控制，大模型推理放在远端服务器。

5.2 Python 端：调用 OpenVLA 做推理

下面给出一段基于 Hugging Facetransformers风格接口的 OpenVLA 推理示例。请重点理解流程，而不是照抄每一行代码，因为具体 API 会随版本变化。

# 文件路径：examples/vla_inference.py import torch from PIL import Image from transformers import AutoModelForVision2Seq, AutoProcessor from transformers.image_utils import load_image model_id = "openvla/openvla-7b" processor = AutoProcessor.from_pretrained(model_id) model = AutoModelForVision2Seq.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto" ) image = load_image("example_table.jpg") prompt = "把红色杯子推到黑色托盘里。" inputs = processor( text=prompt, images=image, return_tensors="pt", padding=True, truncation=True ).to(model.device, dtype=torch.bfloat16) with torch.inference_mode(): output_ids = model.generate(**inputs, max_new_tokens=128) norm_actions = processor.batch_decode(output_ids, skip_special_tokens=True) print("归一化动作输出：", norm_actions)

这条代码要说明的核心点在：模型输出的是归一化后的动作 token，你需要根据你的机器人运动学范围做反归一化，才能得到真实物理单位下的动作向量。这一步不同机器人差异很大，是工程落地时最常踩坑的地方。

实际部署中，更推荐的模式是把它封装成一个动作服务：

# 文件路径：examples/action_server.py class VLAActionService: def __init__(self, model_id: str = "openvla/openvla-7b"): self.processor = AutoProcessor.from_pretrained(model_id) self.model = AutoModelForVision2Seq.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto" ) self.model.eval() def predict(self, prompt: str, image_path: str): image = load_image(image_path) inputs = self.processor( text=prompt, images=image, return_tensors="pt", padding=True, truncation=True ).to(self.model.device, dtype=torch.bfloat16) with torch.inference_mode(): output_ids = self.model.generate(**inputs, max_new_tokens=128) return self.processor.batch_decode(output_ids, skip_special_tokens=True)

这样，C++ 控制端可以通过 HTTP、ZMQ 或 ROS 服务来请求这个类，拿到动作结果。

5.3 C++ 端：桥接层与 Linux 实时调度

具身智能系统通常采用“大脑 + 小脑”架构。大脑负责 VLA 推理，小脑负责实时电机控制。连接二者的桥接层要解决的最核心问题，是“从模型推理结果到电机指令”的低延迟转发。

下面给出一段 Linux 实时调度优先级的设置代码，目的是让桥接线程获得较高的调度优先级，减少控制指令传输抖动。

// 文件路径：bridge/scheduler_utils.cpp #include <sched.h> #include <sys/mman.h> #include <unistd.h> #include <cstdio> #include <cerrno> #include <cstring> bool setupRealtimeThread(int priority) { #ifdef _POSIX_PRIORITY_SCHEDULING // 锁定内存，避免控制过程发生页缺失导致延迟 if (mlockall(MCL_CURRENT | MCL_FUTURE) != 0) { perror("mlockall failed"); // 非致命错误，继续执行 } sched_param param; param.sched_priority = priority; int ret = sched_setscheduler(0, SCHED_FIFO, &param); if (ret != 0) { fprintf(stderr, "sched_setscheduler failed: %s\n", strerror(errno)); return false; } printf("thread set to SCHED_FIFO, priority=%d\n", priority); return true; #else printf("real-time scheduling not supported on this platform\n"); return false; #endif }

使用实时调度前需要注意：SCHED_FIFO 是实时调度策略，如果优先级设置过高，会抢占系统的关键任务，可能导致系统响应问题。建议先在测试环境验证，并仅在真正需要低延迟控制的桥接线程中使用，而不是把所有线程都设置为实时调度。

桥接层完整的逻辑可以这样设计：

// 文件路径：bridge/bridge_main.cpp // 流程概念示意，非完整可编译工程 #include <atomic> #include <thread> #include "scheduler_utils.cpp" std::atomic<bool> running{true}; void frameCollector() { // 采集相机帧，通过共享内存传给 Python 侧 } void actionReceiver() { // 接收 VLA 服务返回的动作向量 } void motorController() { // 将动作向量拆解为底盘速度 + 机械臂关节指令 } int main() { setupRealtimeThread(40); std::thread t1(frameCollector); std::thread t2(actionReceiver); std::thread t3(motorController); t1.join(); t2.join(); t3.join(); return 0; }

注意：scheduler_utils.cpp和bridge_main.cpp在真实工程中建议拆成头文件和源文件，这里为了展示方便放在了一起。

5.4 树莓派小车部署建议（4GB 还是 8GB）

如果你有一台树莓派小车，目标是把 VLA 落地到车上，那么选型建议如下。

如果只是一辆基础巡线车，用树莓派 4GB 就够，因为只需要跑 GPIO、电机驱动、图像采集和简单颜色识别。这类任务用不上 VLA，传统视觉方案都能完成。

如果你想在车端部署轻量 VLM，用于物体识别、指令理解、简单路径规划，那么建议选择树莓派 8GB 版本。部分蒸馏过的 VLM 可以勉强跑起来，但也要经过量化、剪枝等优化。

如果你计划让小车与 OpenVLA 或 π₀ 这类 VLA 模型配合，最合理的架构是车端只做采集和控制，模型推理放到 PC 服务器或者带有独立 GPU 的开发板。树莓派本身只承担“肢体”，不承担“大脑”。

总之：在预算允许的情况下，具身智能小车优先选择 8GB 版本。4GB 适合做纯运动控制和小尺寸模型实验，8GB 能给你保留更多模型选择和扩展空间。

6. 高频问题与排查清单

6.1 常见问题表

6.2 选型建议：业务什么时候选 VLM，什么时候选 VLA

如果你的任务只需要“看”，比如物体计数、缺陷检测、场景描述，直接用 VLM。

如果你的任务需要“看懂并说出下一步做什么”，比如“先拿 A，再放 B”，那么用 VLM 做任务拆解，配合传统运动规划器即可。

如果你的任务是从语言指令直接生成可执行动作，并且希望机器人具备较强的泛化能力，比如在未知物体和随机桌面上完成抓取放置，那么需要引入 VLA。

如果你的生产环境对实时性要求极高，比如毫秒级响应，那么现阶段 VLA 并不适合直接承担全部控制链路，建议把 VLA 放在上层决策，底层仍然保留实时控制算法。

7. 工程实践与最佳实践建议

7.1 数据清洗是高质量策略的前提

具身智能大模型的训练效果，很大程度上取决于演示数据的质量。很多初学者容易忽略数据清洗这一步，直接收集一批遥操作数据就丢给训练脚本，最后发现模型学到的是一些奇怪的行为。

从具身智能数据清洗角度，有几点需要优先关注。

第一，去除动作抖动严重的数据段。遥操作过程中操作者手抖、数据采集频率不稳定，都会导致动作序列出现不连续的跳变，这类数据会干扰模型学习平滑策略。

第二，统一图像分辨率和相机位姿。不同数据采集环境中，图像分辨率、视角、曝光差异过大会导致模型学到错误的视觉先验。建议所有数据统一为同一分辨率，并记录相机外参。

第三，维护语言指令的一致性。同一个任务，指令不要来回换说法，比如“拿起红色杯子”和“把红色杯子拿起来”可能属于同一意图，但如果训练数据里两者对应完全不同的动作分布，模型会困惑。

第四，对齐时间戳。图像帧、机械臂状态、动作指令之间必须严格对齐。一个常见坑是：图像已经变化了，但动作序列还停留在上一毫秒，这会让模型学到滞后策略。

7.2 大小脑桥接与实时性设计

在具身智能的实际部署中，我比较推荐把系统划分为大脑、小脑两个层面，中间通过桥接层通信。

大脑负责 VLA 推理，输出低频动作目标，频率通常在 1 到 10 Hz。小脑负责电机控制、逆解、避障、限位保护，频率通常在 100 Hz 以上。桥接层则负责两者之间的协议转换。

你在做桥接层时需要注意三点：通信协议尽量轻量化，例如使用 flatbuffers 而不是重复解析 JSON；消息必须带时间戳，方便两端对齐；小脑侧必须做动作目标插值，让电机运行轨迹平滑。

在 Linux 实时环境里，控制线程的调度策略和优先级设置非常关键。上面给出的sched_setscheduler示例只是基础，实际工程还要关注 CPU 亲和性、中断绑核、内核PREEMPT_RT补丁等因素。但建议从简单开始，先确保控制线程稳定运行，再逐步优化实时性。

7.3 安全与可回退机制

任何涉及真实电机的具身智能项目，都要设计安全边界。

VLA 模型并不具备安全常识，它可能因为视觉遮挡、异常光照或语言歧义而输出不安全动作。因此，机械臂执行前必须增加位置限位、速度限位和力矩保护。如果模型输出的目标位置接近机械臂极限，小脑应当拒绝执行而不是盲目跟随。

同时，系统要支持一键急停和策略回退。急停功能必须在最底层电机驱动实现，不依赖大脑或小脑的决策线程。策略回退则是一旦 VLA 推理结果连续多帧异常，系统自动切换到预设的安全姿态或人工接管模式。

在真实生产环境里，还要考虑模型服务的故障恢复。VLA 推理服务崩溃后，机器人应该保持当前状态，等待重启，而不是直接失控。

8. 学习路线与下一步

如果你是从零开始学具身智能，可以按下面这条路线逐步推进。

第一步，先把 VLM 跑通。选择一个轻量视觉语言模型，在本地环境做一次图像问答，理解多模态模型的输入输出结构。关键要理解视觉 token、语言 token 是怎么对齐的。

第二步，学习机器人数据格式。用真实机械臂或仿真环境采集一段遥操作数据，理解图像、指令、动作三个模态的对应关系。这个阶段可以借助 URDF、ROS、gym 等工具。

第三步，选择一个开源 VLA 跑通推理。建议先下载 OpenVLA 的预训练权重，用自己的图片和语言指令做一次动作推理，对比不同输入下输出动作是否合理。

第四步，把 VLA 接入仿真环境。在 Isaac Sim 或 MuJoCo 里验证模型输出的动作是否能完成抓取，发现端到端的链路问题。

第五步，在真实小车或机械臂上部署。先不做复杂模型，而是用桥接层把图像采集、模型推理、电机控制串起来，跑通一个简单的“走到红球前并停止”任务。

第六步，再思考如何提升泛化能力。包括采集更多多样化数据、做领域随机化、使用 action chunk 预测、引入跨本体预训练、尝试多模型融合等方向。

随后可以去关注具身智能领域的数据引擎、仿真到真机的迁移、VLA 的轻量化部署、以及小脑层专用模型等细分方向。具身智能是一个系统工程，早一天把第一套 demo 跑通，就能更早理解真正的问题所在。

如果这篇文章对你有帮助，建议先收藏，然后挑一个开源模型跑一次推理。动手实践比看十篇文章都有效。遇到具体报错时，把你用的模型版本、显卡型号、显存大小和完整报错贴出来，基本都能在开源社区找到答案。