具身智能这四个字在 2025 年的国内科技圈几乎是“焊死”在热搜上的。与此相伴的是各大云计算厂商接连发布的机器人模型、具身智能平台、机器人开发套件。光看发布会你会觉得机器人时代已经近在眼前但如果把这些方案真正拆开看会发现一个尴尬的事实绝大多数云厂商交出的答卷只走了半步。它们把 GPU、大模型 API、云端仿真环境做成了“具身智能云服务”却没有真正进入物理世界的数据闭环、机器人本体的实时控制以及软硬件协同的工程深水区。这半步有没有价值有它显著降低了开发者接触具身智能的门槛。但它离“具身智能”真正要解决的物理世界交互问题还隔着一整条河。这篇文章我想讨论三个问题被大家称为“四朵云”的头部云厂商这半步到底做了什么为什么说它们只是走了半步作为普通开发者与其等平台不如从哪些技术路径真正入场先给出我的判断如果“四朵云”继续维持今天的这种模式只做算力、模型和仿真平台的输出那么它们在具身智能的后程竞争中确实危险但如果能补上软硬一体、实时控制与场景数据闭环这几块短板局面仍有变数。这篇文章不打算做厂商点评而是想借这个切口把具身智能真正的门槛讲清楚同时给出一条可以照着走的技术路线。1. 具身智能为什么不是“云上 AI”的简单延伸1.1 什么是具身智能具身智能Embodied Intelligence并不是一个新词但在大模型爆发之后它被赋予了新的含义。通常的理解是智能体不仅要有“大脑”做推理和规划还要有“身体”去感知物理世界并在真实环境中执行动作、获取反馈、持续学习。一个典型的具身智能系统至少包含四层感知层摄像头、IMU、激光雷达、力矩传感器等负责采集物理世界的状态。决策层大模型、强化学习策略、运动规划算法等负责根据感知结果决定下一步动作。执行层电机、舵机、机械结构负责把决策转换为物理动作。数据层把感知-决策-执行的过程记录下来形成可供训练和迭代的数据集。注意最后一层。这是具身智能和传统云端 AI 最大的区别它天然需要物理世界的反馈数据而且这个数据是闭环的、连续的、多模态的。1.2 具身智能与传统云端 AI 的本质差异很多人以为具身智能就是把大模型接到机器人上这其实是一个很深的误解。传统云端 AI 解决的核心问题是“理解”和“生成”输入是文本、图片、语音输出是新的文本、图片、语音。整个链路发生在数字世界里延迟高一点、偶发失败用户还能接受。具身智能解决的核心问题是“物理交互”。机器人需要在毫秒级完成环境感知、决策、控制输出。如果决策层跑在云端一次往返延迟几百毫秒机器人可能已经撞上障碍物了。所以具身智能对实时性、可靠性、安全边界的要求和云端 AI 完全不在一个量级。用一句话概括云端 AI 像是给系统装了一个“大脑”而具身智能需要的是“小脑 脊髓 肌肉 神经反射弧”。只给机器人大脑不给它小脑和反射弧机器人是动不起来的。2. 走了半步的“四朵云”到底做了什么2.1 “四朵云”的具身智能布局通常包含哪些内容“四朵云”是业界对国内四家头部云计算厂商的通俗说法。这里不特指某一家而是讨论一种典型的布局模式。从公开发布的材料看云厂商的具身智能方案往往包含以下几类形态典型内容本质机器人基础模型发布多模态大模型声称能支持机器人的视觉理解和任务规划模型 API具身智能平台提供数据标注、模型训练、仿真测试的云上工具链PaaS 平台服务机器人开发套件提供软硬解耦的 SDK支持常见机器人硬件接入开发者工具仿真环境提供云端机器人仿真场景降低真机测试成本云渲染与算力资源这些布局单独看每一块都有道理。仿真环境确实能降低早期开发成本模型 API 也确实减少了模型训练的门槛平台工具链对数据管理也有帮助。所以我说“半步”不是贬义而是精准描述方向对了但深度不够。2.2 为什么这只能算“半步”如果仔细拆解会发现这些方案有几个共同特征。第一它们的产品重心仍然在“云资源”上。无论把机器人模型包装成什么样最终计费模式还是 GPU 算力、存储、API 调用次数。云厂商最擅长的生意没变变的是卖给谁、怎么包装。第二它们普遍绕开了机器人硬件。云厂商很少真正去设计和制造机器人本体。这可以理解硬件制造毛利低、供应链复杂不是云厂商的基因。但问题在于具身智能恰好是“硬件决定软件上限”的领域。没有本体数据、没有实时控制能力平台做得再漂亮也只是空中楼阁。第三它们没有真正打通“数据闭环”。具身智能的核心资产是机器人在物理世界中采集的数据。数据从哪里来谁来清洗谁来标注采集之后怎么回流到模型训练训练完怎么部署回机器人这是一个完整回路。目前的云平台多数只覆盖了其中“训练”和“仿真”两段最关键的真机数据采集环节仍然需要开发者自己解决。换句话说云厂商做的事情是给具身智能开发者提供了一个“远程武器库”但弹药怎么造、上了战场怎么打仍然没人帮你。2.3 后程真的无望吗单看现状“后程无望”这个判断确实有几分道理。原因是具身智能的竞争壁垒不在算力而在“物理世界的数据积累”和“软硬一体化的工程能力”。前者需要大量真机部署后者需要硬件、控制、操作系统、算法全栈协同。这两块都是云厂商目前的短板。但也不能把话说死。如果云厂商愿意放下“什么都在云端解决”的执念开始认真做端侧推理优化、机器人操作系统中间件、数据闭环工具链甚至以投资或合作方式深入本体制造它们仍然有机会。尤其是数据闭环工具链这是云厂商最有可能做出价值的环节因为数据处理、存储、标注、版本管理本来就是云厂商的强项。所以更准确的判断是走了半步不可怕可怕的是以为这半步就是终点。3. 具身智能真正的技术门槛数据、实时与闭环3.1 数据门槛物理世界的数据远比互联网文本难处理互联网文本数据是大模型时代的“石油”量大且容易获取。物理世界的数据则完全不同。机器人的传感器数据是多模态的图像、点云、力矩、关节角、IMU 时序数据每一种都有不同的采样频率和数据格式。这些数据在时间上必须严格对齐一旦时间戳错乱整个训练样本就是废的。更麻烦的是机器人数据的质量参差不齐。一次遥操作采集的任务可能包含大量机器人静止的无效帧、传感器瞬时故障产生的异常值、遮挡导致的脏图像。如果不做清洗直接拿去训练模型学到的就不是任务技能而是噪声模式。“具身智能数据清洗”成为热门搜索词恰恰说明这个环节已经成为大量开发者的共同痛点。3.2 实时性门槛端侧推理与控制延迟具身智能对时延的要求非常苛刻。以机械臂抓取为例从相机采集图像到输出关节力矩指令整个闭环通常需要做到几十毫秒以内。这个延迟预算要分配给感知、决策、规划、控制四个环节每个环节分到的可能只有几毫秒到十几毫秒。把模型部署在云端一个网络往返就可能超过这个预算。因此具身智能的推理最终必须走向端侧。这就是为什么边缘计算、端侧模型压缩、专用推理芯片在具身智能领域比在传统 AI 领域更加重要。云厂商如果只在云端做文章最多只能覆盖仿真、训练、评测这些离线的环节无法解决真机部署时的实时性难题。3.3 闭环门槛从仿真到真机不是一次发布很多团队在仿真环境里跑得很漂亮一上真机就翻车这被称为 sim-to-real gap。仿真环境再逼真也无法完全刻画物理世界的摩擦力、柔性形变、光照变化和传感器噪声。缩小这个差距需要不断用真机数据修正仿真模型再把修正后的策略放回真机验证形成持续迭代的闭环。这个闭环说起来简单做起来需要一套完整的基础设施数据同步、版本管理、自动评测、灰度部署、回滚机制。目前这些能力在云平台上非常零散更多依赖团队自己搭建。4. 开发者的具身智能入门路线前面说了这么多门槛并不是想劝退而是想告诉读者具身智能的学习路径和传统 AI 很不一样不能只盯着模型刷榜。从搜索热度看越来越多人开始关心“具身智能学习路线”这其实比关心某个具体模型更有价值。一个务实的入门路线我建议分五个阶段阶段学习内容关键产出阶段一Python/Linux/ROS 2 基础能写简单节点能看日志阶段二图像处理与深度学习感知能跑通目标检测、语义分割阶段三电机控制与运动学基础能控制一个电机/小车按指令运动阶段四端侧模型部署能在树莓派/Jetson 上跑轻量模型阶段五数据采集与闭环迭代能独立完成一次“采集-清洗-训练-部署”这个路线的特点是始终围绕“真实硬件”展开。哪怕开局只是一个廉价的树莓派小车也比纯写算法更有感知。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 ImagermacOS 示例 brew install --cask raspberry-pi-imager # 或直接在官网下载对应操作系统版本烧录完成后把 SD 卡插入树莓派开机后用 SSH 登录# 从开发机 SSH 连接树莓派IP 以实际分配为准 ssh ubuntu192.168.1.100 # 登录后更新系统 sudo apt update sudo apt upgrade -y5.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(parentsTrue, exist_okTrue) frames_dir episode_dir / frames meta_path episode_dir / metadata.json with open(meta_path, r, encodingutf-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 / fframe_{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:i4]) 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(), Boxdyn 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. 常见问题与排查方法在搭建具身智能小车和清洗数据的实践中有几个问题出现频率很高这里整理成一张排查表。问题现象可能原因排查方式解决方案树莓派 SSH 无法连接系统未开启 SSH或 IP 地址变化检查路由器后台确认设备 IP重新烧录系统并在烧录时配置 SSHROS 2 节点启动报错找不到包未 source 环境变量或包未安装运行ros2 pkg list查看包执行source /opt/ros/humble/setup.bash话题收发无输出节点命名空间不一致用ros2 topic list查看话题名确认发布和订阅使用相同话题名图像拉普拉斯方差全部偏低相机自动曝光异常或持续失焦查看原始图像是否存在大量虚影调整相机参数检查镜头焦距清洗后训练效果反而变差清洗阈值过于激进丢掉了关键帧检查保留帧数量是否过少调低模糊判定阈值增加人工复核小车电机抖动但不转PWM 频率设置不对检查占空比和频率是否匹配电机参数根据电机手册调整 PWM 频率这几个问题基本覆盖了从环境搭建到数据处理的常见踩坑点。遇到问题时先看日志再复现最小场景最后再动配置。这在机器人开发中是最有效的排错路径。9. 工程建议与最终判断9.1 给开发者的工程建议如果你真的想进入具身智能方向我的建议可以浓缩成四条第一尽早接触真实硬件。不用一上来就买昂贵的机械臂几百块钱的树莓派小车含金量远高于纯仿真项目。仿真解决的是算法验证问题但解决不了“传感器噪声、电机响应、电池电压下降”这些真实世界的问题。第二重视数据工程。如果你看过真实机器人训练项目就会发现数据采集、清洗、标注、版本管理消耗的时间远超模型训练。建议把数据质量检查脚本当成项目基础设施的一部分而不是临时脚本。第三不要迷信端到端大模型。端到端方案看起来很酷但在真实项目里模块化架构感知、规划、控制分离更容易定位问题和迭代。现阶段把大模型用在任务规划和语义理解层面性价比更高。第四跟踪 Rust、端侧推理、数据闭环工具链这些方向。这些不是热门概念但它们正在逐步成为具身智能的底层基础设施提前积累会有长期回报。9.2 回到标题四朵云的后程回到“四朵云”的话题。我的判断是如果云厂商继续只做远程算力、模型 API 和仿真平台不深入软硬一体和真机数据闭环那么它们在具身智能领域的后程确实不容乐观。这不是因为它们能力不够而是因为这条赛道的胜负手根本不在云端。但作为开发者我们反而因此获得了一个难得的时间窗口平台尚未垄断工具链仍在早期真机数据和工程能力远比“接入哪个云平台”更重要。与其等平台的完整方案落地不如先把手边的树莓派用起来跑通一次“采集-清洗-训练-部署”的最小闭环。等你积累了一个真实的物理世界数据集你自然知道哪些平台有用哪些平台只是包装。具身智能不是一个靠发布会就能堆出来的方向。它需要和物理世界硬碰硬这也正是它仍然值得投入的原因。