具身智能落地：从四朵云的半步到树莓派小车实战

具身智能这四个字，在 2025 年的国内科技圈几乎是“焊死”在热搜上的。与此相伴的，是各大云计算厂商接连发布的机器人模型、具身智能平台、机器人开发套件。光看发布会，你会觉得机器人时代已经近在眼前；但如果把这些方案真正拆开看，会发现一个尴尬的事实：绝大多数云厂商交出的答卷，只走了半步。它们把 GPU、大模型 API、云端仿真环境做成了“具身智能云服务”，却没有真正进入物理世界的数据闭环、机器人本体的实时控制，以及软硬件协同的工程深水区。

这半步有没有价值？有，它显著降低了开发者接触具身智能的门槛。但它离“具身智能”真正要解决的物理世界交互问题，还隔着一整条河。这篇文章我想讨论三个问题：被大家称为“四朵云”的头部云厂商，这半步到底做了什么？为什么说它们只是走了半步？作为普通开发者，与其等平台，不如从哪些技术路径真正入场？

先给出我的判断：如果“四朵云”继续维持今天的这种模式，只做算力、模型和仿真平台的输出，那么它们在具身智能的后程竞争中确实危险；但如果能补上软硬一体、实时控制与场景数据闭环这几块短板，局面仍有变数。这篇文章不打算做厂商点评，而是想借这个切口，把具身智能真正的门槛讲清楚，同时给出一条可以照着走的技术路线。

1. 具身智能为什么不是“云上 AI”的简单延伸

1.1 什么是具身智能

具身智能（Embodied Intelligence）并不是一个新词，但在大模型爆发之后，它被赋予了新的含义。通常的理解是：智能体不仅要有“大脑”做推理和规划，还要有“身体”去感知物理世界，并在真实环境中执行动作、获取反馈、持续学习。

一个典型的具身智能系统至少包含四层：

• 感知层：摄像头、IMU、激光雷达、力矩传感器等，负责采集物理世界的状态。
• 决策层：大模型、强化学习策略、运动规划算法等，负责根据感知结果决定下一步动作。
• 执行层：电机、舵机、机械结构，负责把决策转换为物理动作。
• 数据层：把感知-决策-执行的过程记录下来，形成可供训练和迭代的数据集。

注意最后一层。这是具身智能和传统云端 AI 最大的区别：它天然需要物理世界的反馈数据，而且这个数据是闭环的、连续的、多模态的。

1.2 具身智能与传统云端 AI 的本质差异

很多人以为具身智能就是把大模型接到机器人上，这其实是一个很深的误解。传统云端 AI 解决的核心问题是“理解”和“生成”，输入是文本、图片、语音，输出是新的文本、图片、语音。整个链路发生在数字世界里，延迟高一点、偶发失败，用户还能接受。

具身智能解决的核心问题是“物理交互”。机器人需要在毫秒级完成环境感知、决策、控制输出。如果决策层跑在云端，一次往返延迟几百毫秒，机器人可能已经撞上障碍物了。所以具身智能对实时性、可靠性、安全边界的要求，和云端 AI 完全不在一个量级。

用一句话概括：云端 AI 像是给系统装了一个“大脑”，而具身智能需要的是“小脑 + 脊髓 + 肌肉 + 神经反射弧”。只给机器人大脑，不给它小脑和反射弧，机器人是动不起来的。

2. 走了半步的“四朵云”，到底做了什么

2.1 “四朵云”的具身智能布局通常包含哪些内容

“四朵云”是业界对国内四家头部云计算厂商的通俗说法。这里不特指某一家，而是讨论一种典型的布局模式。从公开发布的材料看，云厂商的具身智能方案往往包含以下几类：

这些布局单独看，每一块都有道理。仿真环境确实能降低早期开发成本，模型 API 也确实减少了模型训练的门槛，平台工具链对数据管理也有帮助。所以我说“半步”不是贬义，而是精准描述：方向对了，但深度不够。

2.2 为什么这只能算“半步”

如果仔细拆解，会发现这些方案有几个共同特征。

第一，它们的产品重心仍然在“云资源”上。无论把机器人模型包装成什么样，最终计费模式还是 GPU 算力、存储、API 调用次数。云厂商最擅长的生意没变，变的是卖给谁、怎么包装。

第二，它们普遍绕开了机器人硬件。云厂商很少真正去设计和制造机器人本体。这可以理解，硬件制造毛利低、供应链复杂，不是云厂商的基因。但问题在于，具身智能恰好是“硬件决定软件上限”的领域。没有本体数据、没有实时控制能力，平台做得再漂亮，也只是空中楼阁。

第三，它们没有真正打通“数据闭环”。具身智能的核心资产是机器人在物理世界中采集的数据。数据从哪里来？谁来清洗？谁来标注？采集之后怎么回流到模型训练？训练完怎么部署回机器人？这是一个完整回路。目前的云平台多数只覆盖了其中“训练”和“仿真”两段，最关键的真机数据采集环节仍然需要开发者自己解决。

换句话说，云厂商做的事情，是给具身智能开发者提供了一个“远程武器库”，但弹药怎么造、上了战场怎么打，仍然没人帮你。

2.3 后程真的无望吗

单看现状，“后程无望”这个判断确实有几分道理。原因是：具身智能的竞争壁垒不在算力，而在“物理世界的数据积累”和“软硬一体化的工程能力”。前者需要大量真机部署，后者需要硬件、控制、操作系统、算法全栈协同。这两块都是云厂商目前的短板。

但也不能把话说死。如果云厂商愿意放下“什么都在云端解决”的执念，开始认真做端侧推理优化、机器人操作系统中间件、数据闭环工具链，甚至以投资或合作方式深入本体制造，它们仍然有机会。尤其是数据闭环工具链，这是云厂商最有可能做出价值的环节，因为数据处理、存储、标注、版本管理本来就是云厂商的强项。

所以更准确的判断是：走了半步不可怕，可怕的是以为这半步就是终点。

3. 具身智能真正的技术门槛：数据、实时与闭环

3.1 数据门槛：物理世界的数据远比互联网文本难处理

互联网文本数据是大模型时代的“石油”，量大且容易获取。物理世界的数据则完全不同。机器人的传感器数据是多模态的：图像、点云、力矩、关节角、IMU 时序数据，每一种都有不同的采样频率和数据格式。这些数据在时间上必须严格对齐，一旦时间戳错乱，整个训练样本就是废的。

更麻烦的是，机器人数据的质量参差不齐。一次遥操作采集的任务，可能包含大量机器人静止的无效帧、传感器瞬时故障产生的异常值、遮挡导致的脏图像。如果不做清洗直接拿去训练，模型学到的就不是任务技能，而是噪声模式。“具身智能数据清洗”成为热门搜索词，恰恰说明这个环节已经成为大量开发者的共同痛点。

3.2 实时性门槛：端侧推理与控制延迟

具身智能对时延的要求非常苛刻。以机械臂抓取为例，从相机采集图像到输出关节力矩指令，整个闭环通常需要做到几十毫秒以内。这个延迟预算要分配给感知、决策、规划、控制四个环节，每个环节分到的可能只有几毫秒到十几毫秒。

把模型部署在云端，一个网络往返就可能超过这个预算。因此，具身智能的推理最终必须走向端侧。这就是为什么边缘计算、端侧模型压缩、专用推理芯片在具身智能领域比在传统 AI 领域更加重要。云厂商如果只在云端做文章，最多只能覆盖仿真、训练、评测这些离线的环节，无法解决真机部署时的实时性难题。

3.3 闭环门槛：从仿真到真机不是一次发布

很多团队在仿真环境里跑得很漂亮，一上真机就翻车，这被称为 sim-to-real gap。仿真环境再逼真，也无法完全刻画物理世界的摩擦力、柔性形变、光照变化和传感器噪声。缩小这个差距，需要不断用真机数据修正仿真模型，再把修正后的策略放回真机验证，形成持续迭代的闭环。

这个闭环说起来简单，做起来需要一套完整的基础设施：数据同步、版本管理、自动评测、灰度部署、回滚机制。目前这些能力在云平台上非常零散，更多依赖团队自己搭建。

4. 开发者的具身智能入门路线

前面说了这么多门槛，并不是想劝退，而是想告诉读者：具身智能的学习路径和传统 AI 很不一样，不能只盯着模型刷榜。从搜索热度看，越来越多人开始关心“具身智能学习路线”，这其实比关心某个具体模型更有价值。

一个务实的入门路线，我建议分五个阶段：

这个路线的特点是：始终围绕“真实硬件”展开。哪怕开局只是一个廉价的树莓派小车，也比纯写算法更有感知。

5. 从零搭建：树莓派具身智能小车

5.1 选型：树莓派 4GB 还是 8GB

“具身智能小车树莓派需要 4g 还是 8g”是一个出现频率很高的搜索词。我的建议非常直接：条件允许直接上 8GB 版本。

原因很简单。一个具身智能小车通常要同时跑好几样东西：ROS 2 主节点、相机驱动的图像采集节点、目标检测模型推理、电机控制节点、远程调试服务。其中视觉模型推理是内存大户，4GB 很容易吃紧。一旦系统开始使用 swap 交换分区，实时性就会明显恶化，小车的控制响应会变得“肉”。

当然，如果只是学习 ROS 2 通信机制、跑跑小车的底盘控制，4GB 也够用。但从“少折腾”的角度出发，多花一点预算选 8GB，可以避免后期升级的痛苦。

5.2 环境准备与系统烧录

这里以一个常见的方案为例：树莓派 5 + Ubuntu Server 22.04 + ROS 2 Humble。版本请以实际安装时官方提供的最新稳定版为准，重点是跑通流程。

先在 PC 上下载树莓派系统镜像，然后用 Raspberry Pi Imager 写入 SD 卡。写卡时建议提前配置好 SSH 和 Wi-Fi，这样开发机无需外接屏幕。

# 在 PC 上安装 Raspberry Pi Imager（macOS 示例） brew install --cask raspberry-pi-imager # 或直接在官网下载对应操作系统版本

烧录完成后，把 SD 卡插入树莓派，开机后用 SSH 登录：

# 从开发机 SSH 连接树莓派（IP 以实际分配为准） ssh ubuntu@192.168.1.100 # 登录后更新系统 sudo apt update && sudo apt upgrade -y

5.3 安装 ROS 2 并验证通信

ROS 2 是机器人开发最常用的中间件。以 Ubuntu 22.04 安装 ROS 2 Humble 为例，主要步骤如下：

# 1. 添加 ROS 2 软件源 sudo apt install software-properties-common curl -y sudo add-apt-repository universe sudo apt update sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \ -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null # 2. 安装基础版 ROS 2 sudo apt update sudo apt install ros-humble-ros-base -y # 3. 配置环境变量 echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc source ~/.bashrc # 4. 验证安装 ros2 --help

安装完成后，可以用一个小实验验证 ROS 2 通信是否正常。终端 A 启动一个话题发布节点，终端 B 订阅并打印消息：

# 终端 A：发布一个整数话题 ros2 run demo_nodes_cpp talker # 终端 B：订阅这个话题 ros2 run demo_nodes_py listener

如果能看到持续输出的 Hello World 计数，说明 ROS 2 环境已经可用。这一步是整个小车项目的基础。

6. 具身智能数据清洗：最容易被忽略的工程环节

6.1 具身智能数据为什么特别脏

很多初学者一开始不理解数据清洗为什么要单独拿出来说。他们以为机器人数据就是从传感器里读出来的数值，直接存下来就行。实际采集过真机数据的人都知道，原始数据远没有这么理想。

常见问题包括：

• 视觉帧模糊：机器人运动过程中，相机快门速度跟不上，产生大量模糊帧。
• 重复帧：机器人静止时，传感器持续输出几乎相同的图像，造成数据冗余。
• 时间戳错乱：多个传感器时钟未同步，导致同一时刻的图像和关节状态对不上。
• 异常值：传感器瞬时抖动、遮挡、通信丢包，产生明显偏离正常范围的数据。
• 任务无效帧：采集人员操作失误，导致某段数据根本没有执行有效任务。

这些问题如果不处理，训练出来的策略轻则表现不稳定，重则在真机上做出危险动作。所以数据清洗在具身智能项目里，不是脏活累活，而是决定模型上限的关键环节。

6.2 Python 数据清洗示例

一个最小可用的清洗流程通常包括：读取数据、筛选有效帧、检查关节角范围、剔除模糊帧、输出干净数据集。

# 文件路径：scripts/clean_robot_data.py import json from pathlib import Path import cv2 import numpy as np def is_blurry(image: np.ndarray, threshold: float = 100.0) -> bool: """使用拉普拉斯算子方差判断图像是否模糊。""" gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) var = cv2.Laplacian(gray, cv2.CV_64F).var() return var < threshold def clean_episode(episode_dir: Path, output_dir: Path) -> None: output_dir.mkdir(parents=True, exist_ok=True) frames_dir = episode_dir / "frames" meta_path = episode_dir / "metadata.json" with open(meta_path, "r", encoding="utf-8") as f: metadata = json.load(f) frame_paths = sorted(frames_dir.glob("*.jpg")) valid_count = 0 for idx, frame_path in enumerate(frame_paths): image = cv2.imread(str(frame_path)) if image is None: continue if is_blurry(image): print(f"剔除模糊帧: {frame_path.name}") continue joints = metadata["joints"][idx] if not all(-3.14 <= j <= 3.14 for j in joints): print(f"剔除异常关节角帧: {frame_path.name}") continue output_path = output_dir / f"frame_{valid_count:06d}.jpg" cv2.imwrite(str(output_path), image) valid_count += 1 print(f"原始帧数: {len(frame_paths)}, 清洗后保留: {valid_count}") if __name__ == "__main__": clean_episode(Path("data/raw/episode_001"), Path("data/clean/episode_001"))

这段代码主要完成三件事：用拉普拉斯方差过滤模糊帧、按物理范围过滤异常关节角、将有效帧重新按序号输出。它不复杂，但在很多真实项目里，这个环节会直接影响最终训练效果。

6.3 清洗后的数据质量验证

清洗完成后不要直接拿去训练，至少做一次简单的数据质量检查：

# 统计数据集目录下的帧数量 find data/clean -name "*.jpg" | wc -l # 随机抽取若干帧生成一张拼接预览图 python -c " from pathlib import Path import cv2, numpy as np files = sorted(Path('data/clean/episode_001').glob('*.jpg'))[:16] images = [cv2.imread(str(f)) for f in files] grid = np.vstack([np.hstack(images[i:i+4]) for i in range(0, 16, 4)]) cv2.imwrite('preview.jpg', grid) print('preview saved') "

判断标准很简单：预览图里的每一帧都清晰、内容相关、无明显残缺，且时间顺序连续。如果这一关没过，先不要急着调模型，回头检查采集环节的问题。

7. Rust 与具身智能：为什么这个热词值得关注

7.1 Rust 在机器人领域的位置

“rust 具身智能”成为热搜词，多少有点意外，但仔细想想并不奇怪。机器人系统的底层是嵌入式设备和实时控制，这两块恰好是 Rust 的优势领域。

Rust 在具身智能中的价值可以概括为三点：

• 内存安全：机器人控制程序长期运行，内存泄漏或悬垂指针可能导致严重后果，Rust 在编译期就排除了大量这类问题。
• 实时性能：Rust 没有 GC（垃圾回收），运行时开销可控，适合延迟敏感的控制回路。
• 嵌入式生态：Rust 支持多种 MCU 和交叉编译，可以直接编写固件级代码。

对于刚入门的开发者，我不建议一上来就用 Rust 写全套机器人系统，但深入学习阶段，把 Rust 引入底层控制、外围传感器驱动是非常值得的方向。

7.2 一个简单的 Rust 控制示例

下面是一个在树莓派上用 Rust 控制电机 PWM 输出的最小示例。这里使用rppalcrate 操作树莓派 GPIO，具体 API 请以你项目实际引入的版本为准。

// 文件路径：src/main.rs use std::{thread, time::Duration}; use rppal::gpio::Gpio; const PWM_PIN: u8 = 18; const DIR_PIN: u8 = 23; fn main() -> Result<(), Box<dyn std::error::Error>> { let gpio = Gpio::new()?; // 方向引脚，控制正转 let mut dir = gpio.get(DIR_PIN)?.into_output(); dir.set_high(); // PWM 引脚，先设置 50Hz，初始占空比 0 let mut pwm = gpio.get(PWM_PIN)?.into_pwm(50.0, 0.0); pwm.enable(); // 以 15% 占空比运行 2 秒 pwm.set_duty_cycle(0.15); thread::sleep(Duration::from_millis(2000)); // 停止 pwm.set_duty_cycle(0.0); pwm.disable(); println!("电机控制完成"); Ok(()) }

这段代码的价值不在于复杂，而在于展示了 Rust 在底层控制中的编程范式：引脚操作、PWM 配置、延迟控制，全程没有运行时环境，代码编译后直接运行在设备上。可以把它理解成“更安全的 C 语言”在机器人控制场景的一次应用。

7.3 Rust 适合用在具身智能的哪些位置

• 底层驱动与嵌入式控制：适合。
• ROS 2 节点中的高性能感知处理：适合。
• 快速原型验证和算法探索：不太适合，开发速度不如 Python。
• 全栈机器人应用：现阶段不建议，生态还不够成熟。

一句话总结：Rust 在具身智能的角色是“加固底层”，而不是替代 Python 做算法层。学习它可以，但不要本末倒置。

8. 常见问题与排查方法

在搭建具身智能小车和清洗数据的实践中，有几个问题出现频率很高，这里整理成一张排查表。

这几个问题基本覆盖了从环境搭建到数据处理的常见踩坑点。遇到问题时，先看日志，再复现最小场景，最后再动配置。这在机器人开发中是最有效的排错路径。

9. 工程建议与最终判断

9.1 给开发者的工程建议

如果你真的想进入具身智能方向，我的建议可以浓缩成四条：

第一，尽早接触真实硬件。不用一上来就买昂贵的机械臂，几百块钱的树莓派小车含金量远高于纯仿真项目。仿真解决的是算法验证问题，但解决不了“传感器噪声、电机响应、电池电压下降”这些真实世界的问题。

第二，重视数据工程。如果你看过真实机器人训练项目，就会发现数据采集、清洗、标注、版本管理消耗的时间远超模型训练。建议把数据质量检查脚本当成项目基础设施的一部分，而不是临时脚本。

第三，不要迷信端到端大模型。端到端方案看起来很酷，但在真实项目里，模块化架构（感知、规划、控制分离）更容易定位问题和迭代。现阶段把大模型用在任务规划和语义理解层面，性价比更高。

第四，跟踪 Rust、端侧推理、数据闭环工具链这些方向。这些不是热门概念，但它们正在逐步成为具身智能的底层基础设施，提前积累会有长期回报。

9.2 回到标题：四朵云的后程

回到“四朵云”的话题。我的判断是：如果云厂商继续只做远程算力、模型 API 和仿真平台，不深入软硬一体和真机数据闭环，那么它们在具身智能领域的后程确实不容乐观。这不是因为它们能力不够，而是因为这条赛道的胜负手根本不在云端。

但作为开发者，我们反而因此获得了一个难得的时间窗口：平台尚未垄断，工具链仍在早期，真机数据和工程能力远比“接入哪个云平台”更重要。与其等平台的完整方案落地，不如先把手边的树莓派用起来，跑通一次“采集-清洗-训练-部署”的最小闭环。等你积累了一个真实的物理世界数据集，你自然知道哪些平台有用，哪些平台只是包装。

具身智能不是一个靠发布会就能堆出来的方向。它需要和物理世界硬碰硬，这也正是它仍然值得投入的原因。