人形机器人这个词过去几年基本等于“概念视频”。要么是实验室里走两步就倒的样机要么是发布会上闪亮登场、随后再无下文的原型。但进入 2024 年之后情况发生了一个容易被忽略的变化行业开始用“出货量”这个制造术语来形容人形机器人而且市场统计口径给出了一组让全球都侧目的数据——中国厂商占据了全球人形机器人出货量的大约 86%。这个数字的含金量不在于“我们卖出去了多少台”而在于它背后藏着一整条被验证过的供应链、一套快速迭代的硬件工程能力以及一批愿意把机器人放到真实场景里去试错的客户。它标志着人形机器人的竞争已经从实验室原型阶段进入到了量产爬坡和场景落地的阶段。但这里也要冷静。出货量领先不等于技术全面领先更不等于整个产业的利润和话语权都握在国内厂商手里。人形机器人是一个典型的“硬件软件数据”三位一体赛道上半场比的是谁能把机器人造出来、造得便宜、造得稳定下半场比的是谁能让机器人在真实环境里干活、持续学习、形成数据回收和复用。如果只看 86% 而忽视后面这两个战场很容易高估现状也很容易在职业或技术选型上做出误判。这篇文章会从产业和技术两个角度来拆解这件事。我会先讲清楚 86% 这个数字在产业链上的真实含义然后把人形机器人从执行器到感知决策的技术栈完整过一遍再解释中国厂商为什么能在这个阶段领先以及开发者生态、具身智能、仿真环境这些“下半场”的关键变量。最后我会给出一条技术开发者能直接上手的最小入局路径包括 ROS 2、MuJoCo 仿真和运动控制示例。看完之后你不仅知道“为什么中国厂商出货量高”还能知道“这个赛道下一个机会点在哪里我该从哪入手”。1. 86% 出货量的产业分量量产能力才是关键信号先说清楚“出货量 86%”意味着什么。很多人看到这个数字第一反应是“中国机器人已经全球第一了”。这个判断不够准确。更准确的表述是在能够被统计到的人形机器人整机出货口径里中国厂商的数量占绝对多数这说明中国厂商已经跨过了“做出样机”的门槛开始进入“稳定交付”的阶段。这件事在产业链上是有分量的。人形机器人不是手机它一台就要协调几十个关节电机、十余种传感器、一套实时控制系统再加上外壳结构、散热、线束任何一个环节不成熟产能都上不来。过去几年很多海外公司的问题不是设计不出机器人而是造不出足够多的机器人。硬件设计可以靠天才团队但量产必须靠供应链。“能出货”三个字背后是整个制造链条经受住了良率、成本、交付周期的三重考验。从公开信息看国内有多个厂商已经在工业巡检、商用服务、科研教育等场景批量部署人形机器人。比如优必选、宇树、智元、傅利叶等一批公司已经不再停留在展示原型机而是把机器人交付给客户并收取服务费用。尽管具体的季度出货量数据仍在变化但从产业链上下游反馈和公开报道的装机量来看国内厂商在整机交付数量上确实领先。有一个细节值得注意这种领先和消费电子、智能汽车过去十年的积累高度相关。人形机器人需要的无框力矩电机、行星滚柱丝杠、谐波减速器、编码器、IMU、摄像头模组这些零部件在国内几乎都能找到供应商。零部件的本地化带来两个结果一是采购成本快速下降二是改版速度大幅提升。海外同行可能三个月才能等来一批新电机国内厂商两周就可以拿到定制样品重新装配测试。这种速度差放在出货量上就是一年半年后被拉开的身位。不过也要泼一盆冷水量产领先和核心零部件自主是两回事。虽然整机装配在国内但部分高端减速器、高精度力矩传感器、车规级芯片仍然依赖外部供应。也就是说目前的 86% 更多体现在“系统集成和整机制造”维度而不是“全部核心器件自研”的维度。对于技术从业者来说这个判断很重要如果你正在做职业规划硬件方向的机会仍然在核心零部件国产化这条线上而不是简单再去做一个“总装厂”。2. 人形机器人技术栈拆解从关节电机到大模型要理解“下半场”的竞争先得理解人形机器人到底由哪些技术组成。很多文章喜欢用“大脑小脑身体”这种通俗类比这个类比是准确的但不够细。从工程开发的角度看我更倾向于把人形机器人的技术栈分成五层。2.1 执行层关节、电机与机械结构执行层是机器人运动的基础也是决定成本和可靠性的关键。人形机器人全身通常有 20 到 40 个自由度每个自由度都需要一个执行器。目前主流方案是旋转关节和线性关节的混用旋转关节用于髋、肩这类需要大角度转动的部位线性关节用于膝、肘这类需要高推力输出的部位。核心部件包括无框力矩电机、谐波减速器、行星滚柱丝杠、编码器和力矩传感器。这层技术的特点是“每一克重量都有成本”。关节越轻、输出扭矩越大机器人的动态性能就越好但材料和加工难度也越高。国内厂商能做出高性价比整机很大程度正是因为电机、减速器和丝杠的供应链足够成熟。2.2 控制层运动规划与动态控制控制层解决的是“怎么让机器人稳定地走、跑、站”的问题。人形机器人本质是欠驱动系统脚底和地面接触点远比身体重心少稍微失去平衡就会摔倒。传统双足步态控制依赖动力学模型常见方法有零力矩点ZMP、模型预测控制MPC、全身动力学控制WBC。近两年强化学习RL被越来越广泛地引入步态控制。通过仿真环境让机器人模型自己试错学习出鲁棒性很强的站立和行走策略。相比传统模型方法RL 策略对地形变化和外部扰动更不敏感。这就是为什么我们在视频里看到机器人在草地、沙地、斜坡上都能行走而不仅仅是光滑的地板。2.3 感知层环境理解与状态估计感知层给机器人提供眼和耳。主要传感器包括双目相机、深度相机、激光雷达、IMU、关节编码器和六维力传感器。视觉信息用于目标检测和导航IMU 和编码器用于状态估计力传感器用于感知接触力。这个层次的难点不是传感器本身而是多传感器的标定和时序同步。机器人行走时摄像头震动、IMU 漂移、关节编码器延迟任何一个环节没对齐都会导致控制指令出错。这也是很多团队在仿真里跑得很好、一到真机就崩的原因之一。2.4 决策层任务规划与大模型推理决策层是“大脑”。传统机器人依赖手写状态机把任务拆成“走过去—识别—抓取—放置”这样固定步骤。但人形机器人的目标是执行复杂任务比如“把桌上红色杯子拿到厨房水槽”这就需要理解自然语言、结合视觉信息做推理并拆解成可执行动作序列。大模型LLM和视觉语言动作模型VLA承担了这层工作。VLA 把图片、文本指令和机器人动作映射到同一个空间让机器人根据语义直接输出动作。相比传统方法大模型让用户可以用自然语言控制机器人而不需要程序员预先写死每一条命令。2.5 平台层操作系统、仿真与数据平台层是最容易忽略、却决定生态的一层。ROS/ROS 2 是机器人领域的通用操作系统框架提供通信机制、驱动接口和工具链。仿真平台包括 MuJoCo、Isaac Sim、Gazebo 等用于在虚拟环境中训练和验证算法。这层决定了开发者的上手成本也决定了不同厂商之间能否互通。层次核心内容代表技术国内厂商现状执行层关节、电机、减速器、传感器无框电机、谐波减速器供应链优势明显控制层步态、平衡、运动规划MPC、WBC、强化学习算法人才密集开源作品较多感知层视觉、力觉、状态估计深度相机、多传感器融合与全球水平基本同步决策层任务理解、动作生成LLM、VLA开源模型丰富数据获取是瓶颈平台层操作系统、仿真、数据回流ROS 2、MuJoCo、Isaac Sim仍以 ROS 2 为事实标准自研工具链在演化中3. 中国厂商领先的关键供应链、场景验证与成本迭代如果说技术栈是“骨架”那产业链和商业模式就是“血液”。中国厂商能在出货量上拿到 86% 的优势核心原因有三点。首先是供应链的复用和完整度。人形机器人需要的很多零部件比如电机、减速器、视觉模组、电源管理芯片在消费电子和新能源汽车产业链里已经大规模量产过。这意味着国内厂商不用从零建设生产线可以直接复用成熟产能。这里的经验积累非常值钱——客户要求机器人夹爪能够精准抓取 500 克以内的物品这条需求翻译到供应链可能就要求一款微型力矩传感器在保证精度的同时成本控制在几十元以内而这种“把需求翻译成可量产零部件选型”的能力正是国内硬件团队的强项。其次是场景验证的密度。人形机器人不能只在实验室里“活着”它需要在工厂车间、仓库、商场、园区里连续运行。国内厂商有一个独特优势落地场景多。工厂巡检、电力能源设施巡视、零售导览、物流搬运都有愿意尝鲜的客户。这些场景虽然初期规模不一定大但给厂商提供了宝贵的真机运行数据。一个机器人只有真正在工厂里每天运行 8 小时才会暴露出线束磨损、关节过热、视觉在逆光下识别失败这些只存在于实战的问题。第三是成本迭代速度。造出第一台机器人需要顶尖工程师但造出第一百台需要的是供应链管理。国内团队习惯小步快跑先交付、再收集反馈、快速修改设计、马上出下一版。这种迭代节奏配合国内供应链的响应速度让整机成本得以快速下降。成本下降又会带来新的客户形成正循环。但这并不等于高枕无忧。目前行业里一个比较普遍的现象是硬件功能同质化严重大家都在展示“能走、能跑、能抓取”真正拉开差距的是在多长时间内不掉链子。机器人要在真实场景中稳定运行上千小时对可靠性、散热、线束寿命、算法鲁棒性的考验是全方位的这些都不是靠堆配置能解决的。从性能参数表很难看出这些差异只有经历过长时间运行的团队才清楚成本和故障率之间的平衡点在哪。4. 出货量之外的关键战场操作系统与开发者生态硬件只是第一步真正的平台型机会在软件生态。过去二十年科技行业的规律是谁掌握了开发者生态谁就掌握了行业标准。智能手机的 iOS 和 AndroidPC 的 Windows都是如此。机器人领域大概率也会走同样的路径。当前机器人领域的“操作系统”事实上就是 ROS / ROS 2。ROS 2 并不是一个完整的操作系统而是一套运行在 Linux 之上的中间件框架提供进程通信、硬件驱动、行为树、参数服务、TF 坐标变换等基础能力。它的问题在于功能强大但工程化不足调试和部署对开发者并不友好。因此真正成熟的厂商会在 ROS 2 之上做一层自研的上层封装把通信中间件、算法模块、云端管理、数据回流串起来。国内厂商在这个方向上正在分化。一些公司选择拥抱 ROS 2在上面做优化保持开源生态的兼容性另一些公司则试图建立自研框架把机器人开发变成一套相对封闭的云平台服务。这两种路线目前在行业内都没有形成绝对优势。对开发者来说这意味着同时掌握 ROS 2 和至少一种厂商 SDK 是基本功而具备跨生态迁移能力的人会很吃香。从个人开发者角度我更推荐先扎实掌握 ROS 2再去看厂商的 SDK。原因很简单ROS 2 是行业共同语言招聘市场上几乎所有机器人相关岗位都要求 ROS 2 经验。而厂商 SDK 会随版本变化今天学的东西不一定明天还用得上但 ROS 2 的消息通信、节点生命周期、参数服务器这些概念是通用的理解之后换到任何平台都能快速迁移。5. 具身智能人形机器人真正的增长引擎和人机交互拐点如果说供应链和整机制造是中国厂商目前领先的领域那么具身智能就是下一轮竞争的核心变量。所谓具身智能是让 AI 不只是“思考”还能通过物理身体去感知和改变环境。简单来说大语言模型学会了“说话”具身智能则让它学会“做事”。这里最关键的技术趋势是视觉语言动作模型VLA。传统机器人流程是“理解任务—规划路径—执行动作”每一步分开处理容易累积误差。VLA 试图把这三个步骤合并成一个模型输入图像和文本指令直接输出动作。它不再需要人工定义每一个中间状态而是让模型自己从数据里学习“看到什么、该动哪只手”。这个方向带来的问题也非常明显数据从哪里来大语言模型可以依靠互联网文本数据但机器人训练需要动作数据这类数据必须从真实物理世界采集成本高、速度慢。当前行业主要有三条解决路径第一条路径遥操作采集。人通过动作捕捉设备控制机器人执行任务同时记录关节角度、力矩、视觉画面形成数据集。优点是真实、质量高缺点是人工成本太高很难规模化。第二条路径仿真合成数据。在 MuJoCo、Isaac Sim 等仿真环境里生成大量数据和动作轨迹配合域随机化让模型在虚拟环境里学习控制策略。优点是成本低、效率高缺点是仿真和真实世界之间的差异Sim2Real Gap容易导致策略“只在仿真里有效”。第三条路径借助大模型的通用知识。利用基础模型对世界常识的理解来降低动作学习难度。比如模型已经知道“手要先伸到杯子上方再握住”不需要从零学习。这条路径目前最被看好但也最考验团队的模型工程能力。对产品经理和开发者来说这里的启示是人形机器人现在还远没有到“性能决定性胜利”的阶段用户体验的决定性因素更多在于“机器人能不能稳定可靠地完成一件小事”。如果一个机器人可以在 5 分钟里完成“倒水并送到人手上”这个操作那它已经比 90% 的演示视频更有商业价值。所以不要被华丽的 demo 迷惑要关注它在真实场景里把一件事重复做一万次的成功率。同时要注意具身智能的发展还伴随着一条容易被忽略的脉络机器人不再只是一个“执行设备”而正在成为“数据采集终端”。每一次真实场景里的运行都会把触觉、视觉、力矩、音频数据回传给厂商用于训练下一代模型。这意味着出货量领先的厂商在数据资产上会形成巨大的先发优势。这也是我在第一部分说“出货量是重要信号”的原因它的意义不止于卖硬件更在于数据积累。6. 开发者如何入局最小可用的机器人开发环境讲了这么多产业判断下面进入实操环节。作为开发者不管你现在做后端、算法还是嵌入式想切入人形机器人领域最不推荐的方式是“一上来就买一台真机”。真机价格高、操作风险大、调试周期长而且大多数人是没有机会直接接触到量产人形机器人的。更合理的路径是在自己的电脑上搭一个仿真环境把 ROS 2 的核心通信跑通再用 MuJoCo 之类的物理引擎加载一个人形机器人模型观察关节运动和控制指令的关系。这条路径成本为零效果却很明显。6.1 环境准备这里以 Ubuntu 22.04 作为示例系统ROS 2 的版本使用 HumbleHumble 是适配 Ubuntu 22.04 的长期支持版本。实际上不同发行版对应的 ROS 2 版本会有差异如果你用的是其他系统请以 ROS 官方文档的版本对应关系为准。# 1. 安装 ROS 2 Humble以 Ubuntu 22.04 为例 sudo apt update sudo apt install -y ros-humble-desktop # 2. 配置环境变量 echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc # 3. 安装 Python 依赖 sudo apt install -y python3-colcon-common-extensions pip3 install mujoco安装完成后建议先验证 ROS 2 是否可用。打开两个终端第一个执行ros2 run demo_nodes_cpp talker第二个执行ros2 run demo_nodes_py listener如果能互相打印输出说明通信框架已经正常。6.2 示例一用 MuJoCo 加载人形机器人并运行仿真MuJoCo 是一个高效的物理仿真引擎目前已经开源安装非常简单。下面这个示例会加载一个自带的人形机器人模型然后执行 1000 步仿真并打印机器人质心高度。# 文件路径sim_humanoid.py import mujoco import time # 使用 MuJoCo 自带的 humanoid 模型 model_path mujoco.utils.get_assets_path() /humanoid/humanoid.xml model mujoco.MjModel.from_xml_path(model_path) data mujoco.MjData(model) for step in range(1000): mujoco.mj_step(model, data) # 每 100 步打印一次机器人躯干高度 if step % 100 0: # 简单模拟qpos[0:3] 代表根节点位置z 方向即高度 height data.qpos[2] print(fstep{step}, height{height:.4f}) time.sleep(0.01)运行方式python3 sim_humanoid.py这段代码的关键点是理解data.qpos的含义。在 MuJoCo 中qpos保存了机器人的所有关节状态前 3 个值通常是根节点的空间位置。如果你的模型初始化时设定站在地面上那么height应该在一个稳定值附近波动。如果数值持续下降说明机器人在仿真中摔倒了你可以通过调整初始姿态或者给模型施加一步控制力矩来缓解。6.3 示例二ROS 2 订阅机器人关节状态真实机器人开发中你通常不会直接读取底层关节数据而是通过 ROS 2 话题来订阅。下面这个节点监听/joint_states话题这个话题上每一条消息都带有所有关节的角度。# 文件路径joint_state_listener.py import rclpy from rclpy.node import Node from sensor_msgs.msg import JointState class JointStateListener(Node): def __init__(self): super().__init__(joint_state_listener) # 订阅 /joint_states 话题消息类型为 JointState self.subscription self.create_subscription( JointState, /joint_states, self.listener_callback, 10 ) def listener_callback(self, msg): # msg.name: 关节名列表msg.position: 关节角度列表 if len(msg.name) 0: joint_text , .join(f{n}: {p:.3f} for n, p in zip(msg.name[:6], msg.position[:6])) self.get_logger().info(fjoints - {joint_text}) def main(): rclpy.init() node JointStateListener() rclpy.spin(node) node.destroy_node() rclpy.shutdown() if __name__ __main__: main()运行前先在另一个终端发布测试消息ros2 topic pub /joint_states sensor_msgs/msg/JointState \ {name: [joint1, joint2], position: [0.1, -0.2], velocity: [0, 0], effort: [0, 0]} \ --rate 1再启动监听节点python3 joint_state_listener.py如果看到终端打印出joints - joint1: 0.100, joint2: -0.200说明整个链路已经通了。这个流程与真机调试完全一致只是把硬件话题替换成了仿真或测试数据理解它之后切换到真机上只是换一个驱动层而已。6.4 示例三一个极简的关节位置控制脚本人形机器人控制中最基础的闭环是位置控制。下面用一个简单的 PD 控制器来演示给定目标关节角度计算误差和误差变化率输出控制力矩。这是你在真实机器人和仿真环境中都会用到的基础算法。# 文件路径simple_pd_controller.py class PDController: def __init__(self, kp50.0, kd2.0): self.kp kp # 比例系数 self.kd kd # 微分系数 def compute(self, target_pos, current_pos, current_vel, dt): # 位置误差 error target_pos - current_pos # 误差变化率简化处理直接使用当前速度的反方向 error_vel -current_vel # PD 控制律P 作用于位置误差D 作用于速度误差 torque self.kp * error self.kd * error_vel return torque if __name__ __main__: controller PDController(kp50.0, kd2.0) # 模拟一次控制循环目标位置 1.0 rad当前位置 0.5 rad当前速度 0.1 rad/s torque controller.compute( target_pos1.0, current_pos0.5, current_vel0.1, dt0.001 ) print(fcontrol torque {torque:.3f} Nm)这段代码展示的是控制层的核心逻辑。实际工程中你还需要把计算出的力矩指令下发到关节执行器并实时读取传感器的反馈数据。很多机器人初学者看到复杂的机器人“走起来”很惊叹其实底层就是无数个这样的 PD 控制在各关节上协调工作。6.5 如何验证学习效果按照上面三个示例一步一步跑通你的收获应该有三个层次第一理解 ROS 2 的发布订阅机制。你能看懂一个真实机器人项目的通信结构知道“关节状态从哪里来控制指令到哪里去”。第二理解物理仿真的运行逻辑。你能在 MuJoCo 中加载模型、运行仿真、观察状态量变化这比看任何原理文章都有用。第三理解控制回路的本质。你能写一个最基础的控制器并且知道在仿真里调试一个机器人让它站住的难度有多高——这会让后续接触真机时更从容也会让你对厂商宣传的“稳定行走”有更准确的判断。7. 入局过程中的常见问题与排查方法很多刚开始接触机器人开发的工程师会遇到一些常见的坑。我整理了一个排查表覆盖从环境到仿真的高频问题。问题现象可能原因排查方式解决方案ROS 2 命令找不到未 source 环境变量检查source /opt/ros/humble/setup.bash是否执行将 source 写入~/.bashrc仿真中机器人一直摔倒初始化姿态不稳查看data.qpos初始值确认脚底与地面接触调整初始姿态增大 PD 增益话题订阅不到数据发布者与订阅者不在同一网络/域ros2 topic list查看话题是否生成ros2 topic echo验证消息流检查ROS_DOMAIN_ID是否一致机器人运行一段时间后发热关节负载过高散热不足查看日志中力矩和温度读数的关系降低运动频率优化控制策略仿真与真机行为差异大仿真参数与真实物理参数不一致对比相同输入下关节角度响应曲线引入域随机化改用真实模型参数大模型推理延迟过高模型过大算力不足检查单次推理耗时考虑模型量化使用轻量级模型或边缘计算设备视觉识别在强光下失效相机动态范围不足检查 ROI 区域曝光统计调整曝光参数加偏光镜排错的核心原则是“逐层隔离”。先确认底层通信是否正常再确认物理仿真是否稳定最后才去调上层算法。如果直接跳到算法栈里调参往往事倍功半。8. 工程建议与理性判断现在是进入人形机器人领域的好时机吗从开发者的角度人形机器人领域现在处在“供应链成熟、软件生态未定、场景需求爆发”的窗口期。这个阶段的特点是机会多但泡沫也不少。我的建议是用半年到一年时间建立“仿真控制感知”的最小技能闭环再用一个真实场景去验证而不是急着买设备、追热点。在工程实践上有几点建议值得记住。第一别被参数表迷惑关注故障率和连续运行时长。厂商宣传里“峰值扭矩”“自由度数量”“最大行走速度”这些参数很好看真正决定产品价值的是在连续搬运、巡检、服务场景里能稳定工作多少小时。采购或选型时优先看客户案例和平均故障间隔时间MTBF而不是峰值参数。实际上真正决定用户“留存”的往往是第一周的故障率和三个月的稳定性而不是峰值性能测试那一分钟的表现。第二先把仿真练熟再碰真机。仿真环境MuJoCo、Isaac Sim完全可以在个人电脑上运行用来学习控制算法、验证感知流程、做强化学习训练。真机调试的成本远高于仿真动辄数万甚至数十万的设备损坏风险不是个人开发者能够随意承担的。从仿真切入成本低、风险小而且学到的基础概念完全可迁移。第三重视数据回收和利用。如果你在真实场景里运行机器人一定要设计好数据记录链路。关节角度、力矩、视觉图像、任务完成情况这些数据是训练后续模型的重要资产。很多团队一开始不重视数据等到需要训练 VLA 模型时才后悔数据采集已经中断了真实场景已经复现不出来了。第四保持对 ROS 2 和行业标准工具的敏感度。虽然国内厂商都在做自研工具链但 ROS 2 生态依然是人形机器人领域的通用语言。不管未来平台怎么变掌握 ROS 2 都能让你快速适应新的工具链。还有一点宏观判断人形机器人产业链的下一轮洗牌不会发生在“谁能做出更多机器人”上而会发生在“谁的机器人能在真实场景里持续产生价值”上。前两年拼的是硬件和演示未来拼的是交付能力、数据积累和成本控制。对国内厂商来说86% 的出货量是一个很好的起点但要做到“出货量领先且利润领先、生态领先”还要在核心零部件、系统软件、数据闭环三个方向持续补齐。9. 结语回到标题那组数据中国厂商占全球人形机器人出货量 86%。这个数字意味着中国已经建立了人形机器人整机制造的规模优势也意味着这个行业正式从“概念到量产”迈出了关键一步。但更值得关注的不是 86% 本身而是它背后那条正在并行的竞争逻辑硬件供应链决定你能交付多少台软件生态决定你能留下多少开发者数据资产决定你能把算法迭代到什么高度。对开发者而言这是一个值得投入的窗口期。不用等遥远的技术成熟今天就可以在你的电脑上安装 MuJoCo跑一个人形机器人模型写一个 ROS 2 节点调一个 PD 控制器。这些看似基础的步骤恰恰是进入这个千亿级赛道最短的路径。未来的机器人红利大概率属于那些现在就把“仿真—控制—感知—数据”完整链路跑通的人。 中国厂商占全球人形机器人出货量86%：产业格局与技术拆解
人形机器人这个词过去几年基本等于“概念视频”。要么是实验室里走两步就倒的样机要么是发布会上闪亮登场、随后再无下文的原型。但进入 2024 年之后情况发生了一个容易被忽略的变化行业开始用“出货量”这个制造术语来形容人形机器人而且市场统计口径给出了一组让全球都侧目的数据——中国厂商占据了全球人形机器人出货量的大约 86%。这个数字的含金量不在于“我们卖出去了多少台”而在于它背后藏着一整条被验证过的供应链、一套快速迭代的硬件工程能力以及一批愿意把机器人放到真实场景里去试错的客户。它标志着人形机器人的竞争已经从实验室原型阶段进入到了量产爬坡和场景落地的阶段。但这里也要冷静。出货量领先不等于技术全面领先更不等于整个产业的利润和话语权都握在国内厂商手里。人形机器人是一个典型的“硬件软件数据”三位一体赛道上半场比的是谁能把机器人造出来、造得便宜、造得稳定下半场比的是谁能让机器人在真实环境里干活、持续学习、形成数据回收和复用。如果只看 86% 而忽视后面这两个战场很容易高估现状也很容易在职业或技术选型上做出误判。这篇文章会从产业和技术两个角度来拆解这件事。我会先讲清楚 86% 这个数字在产业链上的真实含义然后把人形机器人从执行器到感知决策的技术栈完整过一遍再解释中国厂商为什么能在这个阶段领先以及开发者生态、具身智能、仿真环境这些“下半场”的关键变量。最后我会给出一条技术开发者能直接上手的最小入局路径包括 ROS 2、MuJoCo 仿真和运动控制示例。看完之后你不仅知道“为什么中国厂商出货量高”还能知道“这个赛道下一个机会点在哪里我该从哪入手”。1. 86% 出货量的产业分量量产能力才是关键信号先说清楚“出货量 86%”意味着什么。很多人看到这个数字第一反应是“中国机器人已经全球第一了”。这个判断不够准确。更准确的表述是在能够被统计到的人形机器人整机出货口径里中国厂商的数量占绝对多数这说明中国厂商已经跨过了“做出样机”的门槛开始进入“稳定交付”的阶段。这件事在产业链上是有分量的。人形机器人不是手机它一台就要协调几十个关节电机、十余种传感器、一套实时控制系统再加上外壳结构、散热、线束任何一个环节不成熟产能都上不来。过去几年很多海外公司的问题不是设计不出机器人而是造不出足够多的机器人。硬件设计可以靠天才团队但量产必须靠供应链。“能出货”三个字背后是整个制造链条经受住了良率、成本、交付周期的三重考验。从公开信息看国内有多个厂商已经在工业巡检、商用服务、科研教育等场景批量部署人形机器人。比如优必选、宇树、智元、傅利叶等一批公司已经不再停留在展示原型机而是把机器人交付给客户并收取服务费用。尽管具体的季度出货量数据仍在变化但从产业链上下游反馈和公开报道的装机量来看国内厂商在整机交付数量上确实领先。有一个细节值得注意这种领先和消费电子、智能汽车过去十年的积累高度相关。人形机器人需要的无框力矩电机、行星滚柱丝杠、谐波减速器、编码器、IMU、摄像头模组这些零部件在国内几乎都能找到供应商。零部件的本地化带来两个结果一是采购成本快速下降二是改版速度大幅提升。海外同行可能三个月才能等来一批新电机国内厂商两周就可以拿到定制样品重新装配测试。这种速度差放在出货量上就是一年半年后被拉开的身位。不过也要泼一盆冷水量产领先和核心零部件自主是两回事。虽然整机装配在国内但部分高端减速器、高精度力矩传感器、车规级芯片仍然依赖外部供应。也就是说目前的 86% 更多体现在“系统集成和整机制造”维度而不是“全部核心器件自研”的维度。对于技术从业者来说这个判断很重要如果你正在做职业规划硬件方向的机会仍然在核心零部件国产化这条线上而不是简单再去做一个“总装厂”。2. 人形机器人技术栈拆解从关节电机到大模型要理解“下半场”的竞争先得理解人形机器人到底由哪些技术组成。很多文章喜欢用“大脑小脑身体”这种通俗类比这个类比是准确的但不够细。从工程开发的角度看我更倾向于把人形机器人的技术栈分成五层。2.1 执行层关节、电机与机械结构执行层是机器人运动的基础也是决定成本和可靠性的关键。人形机器人全身通常有 20 到 40 个自由度每个自由度都需要一个执行器。目前主流方案是旋转关节和线性关节的混用旋转关节用于髋、肩这类需要大角度转动的部位线性关节用于膝、肘这类需要高推力输出的部位。核心部件包括无框力矩电机、谐波减速器、行星滚柱丝杠、编码器和力矩传感器。这层技术的特点是“每一克重量都有成本”。关节越轻、输出扭矩越大机器人的动态性能就越好但材料和加工难度也越高。国内厂商能做出高性价比整机很大程度正是因为电机、减速器和丝杠的供应链足够成熟。2.2 控制层运动规划与动态控制控制层解决的是“怎么让机器人稳定地走、跑、站”的问题。人形机器人本质是欠驱动系统脚底和地面接触点远比身体重心少稍微失去平衡就会摔倒。传统双足步态控制依赖动力学模型常见方法有零力矩点ZMP、模型预测控制MPC、全身动力学控制WBC。近两年强化学习RL被越来越广泛地引入步态控制。通过仿真环境让机器人模型自己试错学习出鲁棒性很强的站立和行走策略。相比传统模型方法RL 策略对地形变化和外部扰动更不敏感。这就是为什么我们在视频里看到机器人在草地、沙地、斜坡上都能行走而不仅仅是光滑的地板。2.3 感知层环境理解与状态估计感知层给机器人提供眼和耳。主要传感器包括双目相机、深度相机、激光雷达、IMU、关节编码器和六维力传感器。视觉信息用于目标检测和导航IMU 和编码器用于状态估计力传感器用于感知接触力。这个层次的难点不是传感器本身而是多传感器的标定和时序同步。机器人行走时摄像头震动、IMU 漂移、关节编码器延迟任何一个环节没对齐都会导致控制指令出错。这也是很多团队在仿真里跑得很好、一到真机就崩的原因之一。2.4 决策层任务规划与大模型推理决策层是“大脑”。传统机器人依赖手写状态机把任务拆成“走过去—识别—抓取—放置”这样固定步骤。但人形机器人的目标是执行复杂任务比如“把桌上红色杯子拿到厨房水槽”这就需要理解自然语言、结合视觉信息做推理并拆解成可执行动作序列。大模型LLM和视觉语言动作模型VLA承担了这层工作。VLA 把图片、文本指令和机器人动作映射到同一个空间让机器人根据语义直接输出动作。相比传统方法大模型让用户可以用自然语言控制机器人而不需要程序员预先写死每一条命令。2.5 平台层操作系统、仿真与数据平台层是最容易忽略、却决定生态的一层。ROS/ROS 2 是机器人领域的通用操作系统框架提供通信机制、驱动接口和工具链。仿真平台包括 MuJoCo、Isaac Sim、Gazebo 等用于在虚拟环境中训练和验证算法。这层决定了开发者的上手成本也决定了不同厂商之间能否互通。层次核心内容代表技术国内厂商现状执行层关节、电机、减速器、传感器无框电机、谐波减速器供应链优势明显控制层步态、平衡、运动规划MPC、WBC、强化学习算法人才密集开源作品较多感知层视觉、力觉、状态估计深度相机、多传感器融合与全球水平基本同步决策层任务理解、动作生成LLM、VLA开源模型丰富数据获取是瓶颈平台层操作系统、仿真、数据回流ROS 2、MuJoCo、Isaac Sim仍以 ROS 2 为事实标准自研工具链在演化中3. 中国厂商领先的关键供应链、场景验证与成本迭代如果说技术栈是“骨架”那产业链和商业模式就是“血液”。中国厂商能在出货量上拿到 86% 的优势核心原因有三点。首先是供应链的复用和完整度。人形机器人需要的很多零部件比如电机、减速器、视觉模组、电源管理芯片在消费电子和新能源汽车产业链里已经大规模量产过。这意味着国内厂商不用从零建设生产线可以直接复用成熟产能。这里的经验积累非常值钱——客户要求机器人夹爪能够精准抓取 500 克以内的物品这条需求翻译到供应链可能就要求一款微型力矩传感器在保证精度的同时成本控制在几十元以内而这种“把需求翻译成可量产零部件选型”的能力正是国内硬件团队的强项。其次是场景验证的密度。人形机器人不能只在实验室里“活着”它需要在工厂车间、仓库、商场、园区里连续运行。国内厂商有一个独特优势落地场景多。工厂巡检、电力能源设施巡视、零售导览、物流搬运都有愿意尝鲜的客户。这些场景虽然初期规模不一定大但给厂商提供了宝贵的真机运行数据。一个机器人只有真正在工厂里每天运行 8 小时才会暴露出线束磨损、关节过热、视觉在逆光下识别失败这些只存在于实战的问题。第三是成本迭代速度。造出第一台机器人需要顶尖工程师但造出第一百台需要的是供应链管理。国内团队习惯小步快跑先交付、再收集反馈、快速修改设计、马上出下一版。这种迭代节奏配合国内供应链的响应速度让整机成本得以快速下降。成本下降又会带来新的客户形成正循环。但这并不等于高枕无忧。目前行业里一个比较普遍的现象是硬件功能同质化严重大家都在展示“能走、能跑、能抓取”真正拉开差距的是在多长时间内不掉链子。机器人要在真实场景中稳定运行上千小时对可靠性、散热、线束寿命、算法鲁棒性的考验是全方位的这些都不是靠堆配置能解决的。从性能参数表很难看出这些差异只有经历过长时间运行的团队才清楚成本和故障率之间的平衡点在哪。4. 出货量之外的关键战场操作系统与开发者生态硬件只是第一步真正的平台型机会在软件生态。过去二十年科技行业的规律是谁掌握了开发者生态谁就掌握了行业标准。智能手机的 iOS 和 AndroidPC 的 Windows都是如此。机器人领域大概率也会走同样的路径。当前机器人领域的“操作系统”事实上就是 ROS / ROS 2。ROS 2 并不是一个完整的操作系统而是一套运行在 Linux 之上的中间件框架提供进程通信、硬件驱动、行为树、参数服务、TF 坐标变换等基础能力。它的问题在于功能强大但工程化不足调试和部署对开发者并不友好。因此真正成熟的厂商会在 ROS 2 之上做一层自研的上层封装把通信中间件、算法模块、云端管理、数据回流串起来。国内厂商在这个方向上正在分化。一些公司选择拥抱 ROS 2在上面做优化保持开源生态的兼容性另一些公司则试图建立自研框架把机器人开发变成一套相对封闭的云平台服务。这两种路线目前在行业内都没有形成绝对优势。对开发者来说这意味着同时掌握 ROS 2 和至少一种厂商 SDK 是基本功而具备跨生态迁移能力的人会很吃香。从个人开发者角度我更推荐先扎实掌握 ROS 2再去看厂商的 SDK。原因很简单ROS 2 是行业共同语言招聘市场上几乎所有机器人相关岗位都要求 ROS 2 经验。而厂商 SDK 会随版本变化今天学的东西不一定明天还用得上但 ROS 2 的消息通信、节点生命周期、参数服务器这些概念是通用的理解之后换到任何平台都能快速迁移。5. 具身智能人形机器人真正的增长引擎和人机交互拐点如果说供应链和整机制造是中国厂商目前领先的领域那么具身智能就是下一轮竞争的核心变量。所谓具身智能是让 AI 不只是“思考”还能通过物理身体去感知和改变环境。简单来说大语言模型学会了“说话”具身智能则让它学会“做事”。这里最关键的技术趋势是视觉语言动作模型VLA。传统机器人流程是“理解任务—规划路径—执行动作”每一步分开处理容易累积误差。VLA 试图把这三个步骤合并成一个模型输入图像和文本指令直接输出动作。它不再需要人工定义每一个中间状态而是让模型自己从数据里学习“看到什么、该动哪只手”。这个方向带来的问题也非常明显数据从哪里来大语言模型可以依靠互联网文本数据但机器人训练需要动作数据这类数据必须从真实物理世界采集成本高、速度慢。当前行业主要有三条解决路径第一条路径遥操作采集。人通过动作捕捉设备控制机器人执行任务同时记录关节角度、力矩、视觉画面形成数据集。优点是真实、质量高缺点是人工成本太高很难规模化。第二条路径仿真合成数据。在 MuJoCo、Isaac Sim 等仿真环境里生成大量数据和动作轨迹配合域随机化让模型在虚拟环境里学习控制策略。优点是成本低、效率高缺点是仿真和真实世界之间的差异Sim2Real Gap容易导致策略“只在仿真里有效”。第三条路径借助大模型的通用知识。利用基础模型对世界常识的理解来降低动作学习难度。比如模型已经知道“手要先伸到杯子上方再握住”不需要从零学习。这条路径目前最被看好但也最考验团队的模型工程能力。对产品经理和开发者来说这里的启示是人形机器人现在还远没有到“性能决定性胜利”的阶段用户体验的决定性因素更多在于“机器人能不能稳定可靠地完成一件小事”。如果一个机器人可以在 5 分钟里完成“倒水并送到人手上”这个操作那它已经比 90% 的演示视频更有商业价值。所以不要被华丽的 demo 迷惑要关注它在真实场景里把一件事重复做一万次的成功率。同时要注意具身智能的发展还伴随着一条容易被忽略的脉络机器人不再只是一个“执行设备”而正在成为“数据采集终端”。每一次真实场景里的运行都会把触觉、视觉、力矩、音频数据回传给厂商用于训练下一代模型。这意味着出货量领先的厂商在数据资产上会形成巨大的先发优势。这也是我在第一部分说“出货量是重要信号”的原因它的意义不止于卖硬件更在于数据积累。6. 开发者如何入局最小可用的机器人开发环境讲了这么多产业判断下面进入实操环节。作为开发者不管你现在做后端、算法还是嵌入式想切入人形机器人领域最不推荐的方式是“一上来就买一台真机”。真机价格高、操作风险大、调试周期长而且大多数人是没有机会直接接触到量产人形机器人的。更合理的路径是在自己的电脑上搭一个仿真环境把 ROS 2 的核心通信跑通再用 MuJoCo 之类的物理引擎加载一个人形机器人模型观察关节运动和控制指令的关系。这条路径成本为零效果却很明显。6.1 环境准备这里以 Ubuntu 22.04 作为示例系统ROS 2 的版本使用 HumbleHumble 是适配 Ubuntu 22.04 的长期支持版本。实际上不同发行版对应的 ROS 2 版本会有差异如果你用的是其他系统请以 ROS 官方文档的版本对应关系为准。# 1. 安装 ROS 2 Humble以 Ubuntu 22.04 为例 sudo apt update sudo apt install -y ros-humble-desktop # 2. 配置环境变量 echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc # 3. 安装 Python 依赖 sudo apt install -y python3-colcon-common-extensions pip3 install mujoco安装完成后建议先验证 ROS 2 是否可用。打开两个终端第一个执行ros2 run demo_nodes_cpp talker第二个执行ros2 run demo_nodes_py listener如果能互相打印输出说明通信框架已经正常。6.2 示例一用 MuJoCo 加载人形机器人并运行仿真MuJoCo 是一个高效的物理仿真引擎目前已经开源安装非常简单。下面这个示例会加载一个自带的人形机器人模型然后执行 1000 步仿真并打印机器人质心高度。# 文件路径sim_humanoid.py import mujoco import time # 使用 MuJoCo 自带的 humanoid 模型 model_path mujoco.utils.get_assets_path() /humanoid/humanoid.xml model mujoco.MjModel.from_xml_path(model_path) data mujoco.MjData(model) for step in range(1000): mujoco.mj_step(model, data) # 每 100 步打印一次机器人躯干高度 if step % 100 0: # 简单模拟qpos[0:3] 代表根节点位置z 方向即高度 height data.qpos[2] print(fstep{step}, height{height:.4f}) time.sleep(0.01)运行方式python3 sim_humanoid.py这段代码的关键点是理解data.qpos的含义。在 MuJoCo 中qpos保存了机器人的所有关节状态前 3 个值通常是根节点的空间位置。如果你的模型初始化时设定站在地面上那么height应该在一个稳定值附近波动。如果数值持续下降说明机器人在仿真中摔倒了你可以通过调整初始姿态或者给模型施加一步控制力矩来缓解。6.3 示例二ROS 2 订阅机器人关节状态真实机器人开发中你通常不会直接读取底层关节数据而是通过 ROS 2 话题来订阅。下面这个节点监听/joint_states话题这个话题上每一条消息都带有所有关节的角度。# 文件路径joint_state_listener.py import rclpy from rclpy.node import Node from sensor_msgs.msg import JointState class JointStateListener(Node): def __init__(self): super().__init__(joint_state_listener) # 订阅 /joint_states 话题消息类型为 JointState self.subscription self.create_subscription( JointState, /joint_states, self.listener_callback, 10 ) def listener_callback(self, msg): # msg.name: 关节名列表msg.position: 关节角度列表 if len(msg.name) 0: joint_text , .join(f{n}: {p:.3f} for n, p in zip(msg.name[:6], msg.position[:6])) self.get_logger().info(fjoints - {joint_text}) def main(): rclpy.init() node JointStateListener() rclpy.spin(node) node.destroy_node() rclpy.shutdown() if __name__ __main__: main()运行前先在另一个终端发布测试消息ros2 topic pub /joint_states sensor_msgs/msg/JointState \ {name: [joint1, joint2], position: [0.1, -0.2], velocity: [0, 0], effort: [0, 0]} \ --rate 1再启动监听节点python3 joint_state_listener.py如果看到终端打印出joints - joint1: 0.100, joint2: -0.200说明整个链路已经通了。这个流程与真机调试完全一致只是把硬件话题替换成了仿真或测试数据理解它之后切换到真机上只是换一个驱动层而已。6.4 示例三一个极简的关节位置控制脚本人形机器人控制中最基础的闭环是位置控制。下面用一个简单的 PD 控制器来演示给定目标关节角度计算误差和误差变化率输出控制力矩。这是你在真实机器人和仿真环境中都会用到的基础算法。# 文件路径simple_pd_controller.py class PDController: def __init__(self, kp50.0, kd2.0): self.kp kp # 比例系数 self.kd kd # 微分系数 def compute(self, target_pos, current_pos, current_vel, dt): # 位置误差 error target_pos - current_pos # 误差变化率简化处理直接使用当前速度的反方向 error_vel -current_vel # PD 控制律P 作用于位置误差D 作用于速度误差 torque self.kp * error self.kd * error_vel return torque if __name__ __main__: controller PDController(kp50.0, kd2.0) # 模拟一次控制循环目标位置 1.0 rad当前位置 0.5 rad当前速度 0.1 rad/s torque controller.compute( target_pos1.0, current_pos0.5, current_vel0.1, dt0.001 ) print(fcontrol torque {torque:.3f} Nm)这段代码展示的是控制层的核心逻辑。实际工程中你还需要把计算出的力矩指令下发到关节执行器并实时读取传感器的反馈数据。很多机器人初学者看到复杂的机器人“走起来”很惊叹其实底层就是无数个这样的 PD 控制在各关节上协调工作。6.5 如何验证学习效果按照上面三个示例一步一步跑通你的收获应该有三个层次第一理解 ROS 2 的发布订阅机制。你能看懂一个真实机器人项目的通信结构知道“关节状态从哪里来控制指令到哪里去”。第二理解物理仿真的运行逻辑。你能在 MuJoCo 中加载模型、运行仿真、观察状态量变化这比看任何原理文章都有用。第三理解控制回路的本质。你能写一个最基础的控制器并且知道在仿真里调试一个机器人让它站住的难度有多高——这会让后续接触真机时更从容也会让你对厂商宣传的“稳定行走”有更准确的判断。7. 入局过程中的常见问题与排查方法很多刚开始接触机器人开发的工程师会遇到一些常见的坑。我整理了一个排查表覆盖从环境到仿真的高频问题。问题现象可能原因排查方式解决方案ROS 2 命令找不到未 source 环境变量检查source /opt/ros/humble/setup.bash是否执行将 source 写入~/.bashrc仿真中机器人一直摔倒初始化姿态不稳查看data.qpos初始值确认脚底与地面接触调整初始姿态增大 PD 增益话题订阅不到数据发布者与订阅者不在同一网络/域ros2 topic list查看话题是否生成ros2 topic echo验证消息流检查ROS_DOMAIN_ID是否一致机器人运行一段时间后发热关节负载过高散热不足查看日志中力矩和温度读数的关系降低运动频率优化控制策略仿真与真机行为差异大仿真参数与真实物理参数不一致对比相同输入下关节角度响应曲线引入域随机化改用真实模型参数大模型推理延迟过高模型过大算力不足检查单次推理耗时考虑模型量化使用轻量级模型或边缘计算设备视觉识别在强光下失效相机动态范围不足检查 ROI 区域曝光统计调整曝光参数加偏光镜排错的核心原则是“逐层隔离”。先确认底层通信是否正常再确认物理仿真是否稳定最后才去调上层算法。如果直接跳到算法栈里调参往往事倍功半。8. 工程建议与理性判断现在是进入人形机器人领域的好时机吗从开发者的角度人形机器人领域现在处在“供应链成熟、软件生态未定、场景需求爆发”的窗口期。这个阶段的特点是机会多但泡沫也不少。我的建议是用半年到一年时间建立“仿真控制感知”的最小技能闭环再用一个真实场景去验证而不是急着买设备、追热点。在工程实践上有几点建议值得记住。第一别被参数表迷惑关注故障率和连续运行时长。厂商宣传里“峰值扭矩”“自由度数量”“最大行走速度”这些参数很好看真正决定产品价值的是在连续搬运、巡检、服务场景里能稳定工作多少小时。采购或选型时优先看客户案例和平均故障间隔时间MTBF而不是峰值参数。实际上真正决定用户“留存”的往往是第一周的故障率和三个月的稳定性而不是峰值性能测试那一分钟的表现。第二先把仿真练熟再碰真机。仿真环境MuJoCo、Isaac Sim完全可以在个人电脑上运行用来学习控制算法、验证感知流程、做强化学习训练。真机调试的成本远高于仿真动辄数万甚至数十万的设备损坏风险不是个人开发者能够随意承担的。从仿真切入成本低、风险小而且学到的基础概念完全可迁移。第三重视数据回收和利用。如果你在真实场景里运行机器人一定要设计好数据记录链路。关节角度、力矩、视觉图像、任务完成情况这些数据是训练后续模型的重要资产。很多团队一开始不重视数据等到需要训练 VLA 模型时才后悔数据采集已经中断了真实场景已经复现不出来了。第四保持对 ROS 2 和行业标准工具的敏感度。虽然国内厂商都在做自研工具链但 ROS 2 生态依然是人形机器人领域的通用语言。不管未来平台怎么变掌握 ROS 2 都能让你快速适应新的工具链。还有一点宏观判断人形机器人产业链的下一轮洗牌不会发生在“谁能做出更多机器人”上而会发生在“谁的机器人能在真实场景里持续产生价值”上。前两年拼的是硬件和演示未来拼的是交付能力、数据积累和成本控制。对国内厂商来说86% 的出货量是一个很好的起点但要做到“出货量领先且利润领先、生态领先”还要在核心零部件、系统软件、数据闭环三个方向持续补齐。9. 结语回到标题那组数据中国厂商占全球人形机器人出货量 86%。这个数字意味着中国已经建立了人形机器人整机制造的规模优势也意味着这个行业正式从“概念到量产”迈出了关键一步。但更值得关注的不是 86% 本身而是它背后那条正在并行的竞争逻辑硬件供应链决定你能交付多少台软件生态决定你能留下多少开发者数据资产决定你能把算法迭代到什么高度。对开发者而言这是一个值得投入的窗口期。不用等遥远的技术成熟今天就可以在你的电脑上安装 MuJoCo跑一个人形机器人模型写一个 ROS 2 节点调一个 PD 控制器。这些看似基础的步骤恰恰是进入这个千亿级赛道最短的路径。未来的机器人红利大概率属于那些现在就把“仿真—控制—感知—数据”完整链路跑通的人。