全球人形机器人出货量统计口径不少，但几乎所有第三方报告都指向同一个结论：中国厂商拿下了非常高的比例，按公开数据大约是 86%。这个数字不仅是新闻标题，更是一个产业节点。它说明人形机器人已经从前几年的概念展示、实验室演示，进入批量交付阶段。对做算法、做硬件的开发者来说，真正的问题已经不是“人形机器人火不火”，而是“我用什么环境开发、跑什么模型、买谁家的整机、怎么验证效果”。
这篇文章会围绕“中国厂商占全球人形机器人出货量 86%”这个基本面展开，先拆解人形机器人产业链和技术栈，再说明主要国产厂商的产品路线，然后给出一套从仿真到真机的开发验证路径，包括仿真环境搭建、机器人描述模型、Python 控制接口、批量测试任务、接口访问和常见故障排查。文末会给出面向工程采购和研发选型的评估清单，以及合规使用需要注意的边界。
适合阅读本文的读者包括：做具身智能算法和机器人应用的工程师，准备采购国产人形机器人做技术验证的企业研发人员，以及正在规划机器人课程和实验室方向的科研人员。看完你至少能回答三个问题：国产人形机器人为什么出货量这么高；如果要自己开发，起步需要准备哪些东西；拿到一台整机后，怎么快速跑通一套功能验证流程。
1. 核心数据速览
从公开报道和市场研究机构的口径看，当前全球人形机器人出货量中，中国厂商占比约为 86%。这是一个出货量口径的份额，不是高端技术能力的完整评价。它说明中国厂商在整机集成、量产制造、供应链组织和场景交付方面有明显优势。
| 统计维度 | 情况说明 |
|---|---|
| 出货量份额 | 中国厂商约占全球人形机器人出货量的 86%，具体数字会随统计周期和口径变化 |
| 统计含义 | 主要指已交付给客户或进入真实场景试点的整机，不是原型机 |
| 代表厂商 | 优必选、宇树、智元、傅利叶等国内整机厂商，以及部分互联网和车企背景的机器人团队 |
| 产品方向 | 通用人形机器人、双足机器人、轮式人形机器人、工业场景人形机器人等 |
| 典型场景 | 工业制造、商业服务、教育科研、公共安全、导览讲解 |
| 技术瓶颈 | 高强度运控算法、长续航、高可靠性、复杂环境泛化能力、核心零部件国产化率 |
| 开发者友好度 | 不同厂商差异大，部分厂商提供 SDK、仿真环境和二次开发接口，需要逐一确认 |
| 合规要求 | 涉及人脸识别、语音交互、数据采集，必须做隐私评估和授权管理 |
这里要说清楚一个容易被混淆的点：出货量领先不等于整条供应链全部国产化。很多高端芯片、精密减速器、高精度传感器仍然依赖进口。国产厂商强在整机整合和量产能力，但核心零部件仍有卡点。对开发者来说，这意味着两件事：整机采购成本在下降，开发门槛也在下降；但涉及定制化高性能部件时，交付周期仍然不可控。
2. 人形机器人技术栈拆解
人形机器人是一个典型的复杂系统，不是单一模型或单一算法能搞定的。从底向上，技术栈大致分为六个层次：
| 层级 | 核心内容 | 典型载体 |
|---|---|---|
| 硬件层 | 关节电机、减速器、结构件、电池、计算单元 | 伺服电机、谐波减速器、行星滚柱丝杠 |
| 传感器层 | 视觉、力觉、触觉、惯性测量 | RGB 相机、深度相机、IMU、六维力传感器 |
| 运动控制层 | 双足步态、全身动力学、平衡控制 | MPC、WBC、ZMP 控制 |
| 感知环境层 | 目标检测、语义分割、SLAM、导航 | 视觉导航、激光雷达定位 |
| 行为决策层 | 任务规划、动作生成、人类意图理解 | 状态机、行为树、大模型任务规划 |
| 具身智能层 | 视觉语言动作模型、模仿学习、强化学习 | VLA 模型、Diffusion Policy |
软件环境上，机器人描述文件是最先要接触的东西。URDF（Unified Robot Description Format）是最常用的机器人模型描述格式，用来描述连杆、关节、质量、惯性、碰撞体等信息。下面是一段示意结构，实际型号需要按真机参数替换。
<robot name="humanoid_example"> <link name="base_link"> <inertial> <mass value="25.0"/> <origin xyz="0 0 0.6"/> </inertial> <visual> <geometry> <box size="0.4 0.25 0.25"/> </geometry> </visual> </link> <joint name="left_hip_yaw" type="revolute"> <parent link="base_link"/> <child link="left_leg"/> <origin xyz="0 0.1 0.85"/> <axis xyz="0 0 1"/> <limit lower="-1.57" upper="1.57" effort="300" velocity="3.0"/> </joint> </robot>URDF 本身不包含控制逻辑，它只是模型描述。真正的运动控制要交给仿真环境、控制算法或厂商提供的 SDK。建议开发者在选型时优先看一个指标：整机是否提供可导入仿真环境的 URDF 或 MJCF 模型文件，以及是否提供对应的 Python 接口。这个能力直接决定了二次开发的起点。
3. 主要厂商与产品路线
从公开产品线看，国产人形机器人厂商的技术路线可以归纳成几类。下面只做方向和特点说明，具体参数和报价需要以厂商官方文档为准。
优必选是早期进入人形机器人领域的厂商之一，产品线覆盖教育、商业服务、工业场景，起步时间早，交付案例相对多，在运动控制和整机可靠性积累比较久。宇树以四足机器人起家，后来切入人形机器人，产品定价策略比较激进，对开发者社区相对友好，很多高校和初创团队会选它作为研究平台。智元机器人主打具身智能方向，强调机器人与大模型结合，团队成员背景偏 AI 和自动驾驶，产品思路更偏向智能化应用层。傅利叶早期做康复机器人，后来进入通用人形机器人，在医疗和康复场景有交付基础，产品更强调力控和安全交互。此外，小鹏、小米等车企和消费电子背景团队也在布局人形机器人，他们的优势是供应链管理和消费级产品定义。
从“出货量 86%”这个结果往回看，国产厂商的共同优势是中国成熟的新能源汽车供应链。电机、电池、传感器、结构件都能在本地找到供应商，整机 BOM 成本显著低于海外同类产品。这是出货量能起来的关键原因。
对开发者来说，选型时的判断依据不应只看出货量，还要看一个更实际的问题：开放度。有的厂商提供成熟 SDK 和仿真环境，有的厂商只提供封闭的整机方案。建议把开放度放在和参数同等重要的位置。
4. 本地开发环境准备与前置条件
无论你拿到的是哪家整机，开发环境的准备思路是通用的。人形机器人开发通常会用到仿真环境、Python 运行时、机器人描述文件、控制接口和日志工具。下面的清单适合第一次搭建人形机器人开发环境的开发者参考。
4.1 硬件环境检查
- 操作系统：推荐 Ubuntu 20.04 或 22.04，部分厂商 SDK 对 Windows 支持有限。
- GPU：如果要做视觉语言动作模型或强化学习训练，需要 NVIDIA 显卡；仅跑仿真和控制，集成显卡也能跑起来，但速度会受影响。
- CUDA 和驱动：训练模型前先执行
nvidia-smi确认驱动版本和显存。 - 磁盘空间：仿真环境和模型文件占用较大，建议预留 50GB 以上。
- 内存：16GB 起步，训练场景建议 32GB 以上。
# 检查 GPU 驱动和显存 nvidia-smi显存占用没有统一标准。仿真环境占用显存不多，一般几 GB 内；但大模型推理和 RL 训练会明显吃显存。具体以实际模型和批次大小为准，不要轻信网上的固定数字，要自己测。
4.2 Python 环境和依赖
建议用虚拟环境隔离项目依赖，避免污染系统 Python。
# 创建虚拟环境（通用示例，具体包名以项目文档为准） python -m venv .venv source .venv/bin/activate pip install --upgrade pip # 常用仿真和控制依赖 pip install mujoco pip install numpy pip install rospkg如果使用 ROS 相关工具，还需要安装 ROS2 和对应依赖包。这里不指定版本，因为不同厂商 SDK 和仿真环境的依赖版本差异很大。
4.3 端口与服务准备
很多机器人系统运行时都会占用网络端口，比如仿真可视化界面、WebUI 调试面板、ROS2 通信端口。如果遇到端口冲突，排查顺序是：
# 查看端口占用情况 netstat -tulpn | grep <port> # 停掉冲突进程后重启服务，或者换一个端口启动比较稳妥的方式是统一规划端口段，例如仿真服务用 8000 段，调试接口用 9000 段，日志服务用 7000 段，避免相互干扰。
5. 从仿真到实机的功能验证流程
人形机器人的开发不能一上来就直接上真机。正确的顺序是：先建模型，再仿真，再小步迁移到真机，最后做小批量验收。下面是一套通用验证流程，适用于大多数情况。
5.1 仿真环境验证
第一步是让机器人模型在仿真环境里跑起来。以 MuJoCo 为例，先加载 URDF 或 MJCF 模型，然后做几步基础检查：模型是否能加载；关节数量是否正确；给定控制输入后，机器人是否按预期运动；是否会出现穿模或关节限位异常。
import mujoco # 这里以已知模型文件为例，实际路径需要替换为对应机器人的模型文件 model = mujoco.MjModel.from_xml_path("humanoid_example.xml") data = mujoco.MjData(model) for t in range(300): data.ctrl[:] = 0.0 mujoco.mj_step(model, data) if t % 50 == 0: print("time:", round(data.time, 3), "height:", round(data.qpos[2], 3))预期结果是机器人能在仿真环境中稳定站立或完成指定动作，不会出现位置异常发散。如果出现发散，优先检查模型参数是否与真机一致，包括关节限位、质量和质心位置。仿真通过后再进入实机验证。
5.2 真机小步迁移
真机测试要分成三个阶段做，不要一次性跑完整套动作：
- 单关节测试：逐个关节做小范围运动，确认电机使能、反馈、限位保护正常。
- 低复杂度动作测试：做蹲起、抬手、转身之类的动作，观察稳定性和震动。
- 任务链路测试：把感知、规划、控制串起来跑完整场景，确认端到端延迟和成功率。
每个阶段都要记录日志，包括电压、电流、关节温度、控制频率和上报延迟。这些数据在后续调优时非常关键。
5.3 批量测试任务设计
真实场景需要大量重复测试来评估稳定性，不能只跑一两次就下结论。建议用任务配置的方式管理批量测试。
{ "task_name": "industrial_inspection_demo", "scene": "warehouse_a", "episodes": 50, "max_steps_per_episode": 500, "action_mode": "joint_position", "log_output": "./logs/run_20250101", "stop_on_error": false }批量测试要记录两类指标：任务完成率和单步执行成功率。任务完成率反映整条链路的可用性，单步执行成功率反映具体环节的稳定性，比如“站立成功率”“抓取成功率”“导航到达成功率”。出现问题时要能定位到具体模块。
6. 接口调用与二次开发示例
人形机器人整机是否值得买，很大程度取决于 SDK 是否完善。不同厂商的接口差异很大，但通常都会提供 Python 或 C++ 接口，部分厂商会提供 ROS2 包。下面给出一个通用思路，具体接口路径和参数名需要以实际厂商文档为准。
6.1 Python 控制接口调用
一般流程是：连接机器人 -> 获取状态 -> 发送控制指令 -> 读取反馈。
import time import logging # 以下为通用示例，实际 SDK 名称和接口需以官方文档为准 from robot_sdk import HumanoidRobot logging.basicConfig(level=logging.INFO) robot = HumanoidRobot(host="127.0.0.1", port=8000) robot.connect() # 获取当前关节状态 state = robot.get_joint_state() print("joints:", state.joint_angles) # 发送运动指令 cmd = { "joints": { "left_hip_pitch": -0.3, "right_hip_pitch": -0.3, "left_knee_pitch": 0.6, "right_knee_pitch": 0.6 }, "duration": 2.0 } robot.move(cmd) time.sleep(3) # 验证机器人是否达到预期位置 feedback = robot.get_joint_state() print("feedback:", feedback.joint_angles) robot.disconnect()这段代码的意图是让机器人做一次浅蹲动作。正常的验证标准是：连接成功、发送指令无报错、关节反馈角度接近目标角度、机械结构无异常。
6.2 批量任务队列
如果有多个动作或场景需要连续测试，建议使用队列方式管理任务，逐条执行并记录结果，避免一个脚本里写一堆硬编码循环，后期难以定位问题。
from dataclasses import dataclass, asdict import json @dataclass class BatchTask: task_id: str action_name: str params: dict expected_result: str batch = [ BatchTask("001", "stand", {"duration": 5.0}, "stable_stand"), BatchTask("002", "walk", {"steps": 10, "direction": "forward"}, "reach_forward"), BatchTask("003", "grasp", {"height": 1.2}, "object_grasped") ] with open("batch_tasks.json", "w", encoding="utf-8") as f: json.dump([asdict(t) for t in batch], f, ensure_ascii=False, indent=2)批量任务的关键不是跑得快，而是失败后可重试、可跳过、可定位。建议在任务队列中增加重试次数和超时时间字段，避免某个动作卡死导致整个测试中断。
7. 数据、算力与合规边界
人形机器人在真实场景中会大量采集视觉、语音、动作和位置数据。这些数据一旦涉及人脸、声纹、特定场所的内部信息，就会触发隐私和合规要求。
7.1 数据采集和标注
训练具身智能模型需要大量轨迹数据，比如遥操作采集的人类动作数据、真实场景中的感知数据。采集这些数据要注意三点：
- 明确告知被采集对象，获得合法授权。
- 数据脱敏后再入库，尤其是人脸、车牌、地理位置信息。
- 标注数据要保留来源和版本记录，方便追踪。
7.2 算力策略
视觉语言动作模型训练通常需要较高算力，但实际研发并不一定一开始就用大集群。更实际的做法是先在仿真环境里用小模型验证链路，确认可行后再扩大数据量和模型规模。推理阶段可以先用本地 GPU 测试延迟，再决定是否需要部署到边缘设备。
7.3 安全与合规操作
人形机器人属于高能量运动设备，调试时必须在安全区域进行。这里要强调几个红线：不要在未授权场景采集陌生人数据；不要用机器人执行可能伤害人员的行为；不要在公共区域使用没有急停保护的整机；涉及人脸识别、语音交互、远程控制时必须做风险评估。对开发者来说，合规不是文档问题，是项目能不能落地的前置条件。
8. 常见问题与排查方法
人形机器人开发过程中，问题集中在模型加载、仿真发散、接口连接、批量测试中断几类。下面给出一个通用排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型加载失败 | URDF 文件路径错误或格式不兼容 | 查看仿真环境日志，确认模型文件路径 | 检查文件路径，使用官方模型文件 |
| 仿真中机器人倒地或发散 | 关节限位、质量、质心设置与真机不一致 | 逐个检查模型参数，对比真机 CAD 数据 | 修正模型参数，降低控制增益重新测试 |
| 真机启动后电机不动 | 电机未使能、急停按下、电压不足 | 检查是否下发使能指令，查看电压和急停状态 | 使能电机，恢复急停，确认供电稳定 |
| 真机执行动作时震动剧烈 | 控制频率过低或增益过高 | 查看控制日志，对比频率和增益设置 | 提高控制频率或降低增益 |
| SDK 连接失败 | 网络不通或端口错误 | ping目标主机，netstat查看端口 | 检查网络配置，修改端口或重启服务 |
| 批量测试中途卡住 | 单个任务超时未返回 | 查看任务日志，增加超时时间 | 在任务配置中增加超时和重试字段 |
| 模型推理延迟过高 | 图像分辨率过高或显存不足 | 观察推理耗时和显存占用 | 降低输入分辨率，减小模型输入尺寸或更换算力设备 |
| 数据采集涉及隐私风险 | 未做授权或脱敏 | 检查数据合规流程 | 停止采集，补充授权和脱敏方案 |
排查时要遵循先看日志、再查接口、后动硬件的顺序。很多人一上来就调参数，结果发现是网络故障。先确认服务正常，再动控制参数，能省掉大量时间。
9. 整机选型与采购评估清单
如果不只是做研究，而是准备采购国产人形机器人做项目交付，选型评估不能只看“参数好看”。建议按下面的维度做横向对比。
| 评估维度 | 需要确认的问题 |
|---|---|
| 整机规格 | 自由度数量、负载能力、续航、运动速度是否满足实际场景 |
| 开放程度 | 是否提供 SDK、API、ROS2 包、仿真模型 |
| 二次开发成本 | 文档是否完善，Python 示例是否可跑通 |
| 可靠性 | 平均无故障时间、散热表现、防护等级 |
| 交付能力 | 是否有批量交付案例，售后响应周期 |
| 采购成本 | 整机价格、配件价格、维护成本 |
| 数据安全 | 是否支持私有化部署，数据是否存储在本地 |
| 合规支持 | 是否提供产品认证材料和安全说明 |
另一个建议是先做 POC 再决定量产。POC 阶段优先验证四个检查项：仿真环境能否跑通；SDK 接口是否稳定；批量任务是否可重复；真机故障率是否在可接受范围。这四个检查项全部通过，再谈批量采购。
10. 趋势与下一步
人形机器人的竞争正在从“能不能走”转向“能不能干活”。中国厂商在出货量上的优势，意味着他们手里有更多真实场景数据和批量交付经验，这会进一步反哺模型训练和产品迭代。未来 12 到 24 个月可以重点关注几个方向：具身智能大模型在整机上的部署效率，真实场景数据飞轮的建设速度，以及国产核心零部件的替代进度。
对开发者来说，最值得先做的事情是把手头已有的整机或仿真环境用起来，跑通一套最小验证链路：模型加载、单步控制、批量任务、日志记录。这个链路跑通后，后续无论是切换模型、接入大模型还是增加场景，都只是替换中间模块，不用重来。最容易踩的坑则是跳过仿真直接上真机，或者一上来就追求大模型部署，把环境问题混淆为算法问题。建议从今天开始，先下载一个仿真环境，找一个人形机器人模型文件，把它跑起来再说。
