全球人形机器人出货量统计口径不少但几乎所有第三方报告都指向同一个结论中国厂商拿下了非常高的比例按公开数据大约是 86%。这个数字不仅是新闻标题更是一个产业节点。它说明人形机器人已经从前几年的概念展示、实验室演示进入批量交付阶段。对做算法、做硬件的开发者来说真正的问题已经不是“人形机器人火不火”而是“我用什么环境开发、跑什么模型、买谁家的整机、怎么验证效果”。这篇文章会围绕“中国厂商占全球人形机器人出货量 86%”这个基本面展开先拆解人形机器人产业链和技术栈再说明主要国产厂商的产品路线然后给出一套从仿真到真机的开发验证路径包括仿真环境搭建、机器人描述模型、Python 控制接口、批量测试任务、接口访问和常见故障排查。文末会给出面向工程采购和研发选型的评估清单以及合规使用需要注意的边界。适合阅读本文的读者包括做具身智能算法和机器人应用的工程师准备采购国产人形机器人做技术验证的企业研发人员以及正在规划机器人课程和实验室方向的科研人员。看完你至少能回答三个问题国产人形机器人为什么出货量这么高如果要自己开发起步需要准备哪些东西拿到一台整机后怎么快速跑通一套功能验证流程。1. 核心数据速览从公开报道和市场研究机构的口径看当前全球人形机器人出货量中中国厂商占比约为 86%。这是一个出货量口径的份额不是高端技术能力的完整评价。它说明中国厂商在整机集成、量产制造、供应链组织和场景交付方面有明显优势。统计维度情况说明出货量份额中国厂商约占全球人形机器人出货量的 86%具体数字会随统计周期和口径变化统计含义主要指已交付给客户或进入真实场景试点的整机不是原型机代表厂商优必选、宇树、智元、傅利叶等国内整机厂商以及部分互联网和车企背景的机器人团队产品方向通用人形机器人、双足机器人、轮式人形机器人、工业场景人形机器人等典型场景工业制造、商业服务、教育科研、公共安全、导览讲解技术瓶颈高强度运控算法、长续航、高可靠性、复杂环境泛化能力、核心零部件国产化率开发者友好度不同厂商差异大部分厂商提供 SDK、仿真环境和二次开发接口需要逐一确认合规要求涉及人脸识别、语音交互、数据采集必须做隐私评估和授权管理这里要说清楚一个容易被混淆的点出货量领先不等于整条供应链全部国产化。很多高端芯片、精密减速器、高精度传感器仍然依赖进口。国产厂商强在整机整合和量产能力但核心零部件仍有卡点。对开发者来说这意味着两件事整机采购成本在下降开发门槛也在下降但涉及定制化高性能部件时交付周期仍然不可控。2. 人形机器人技术栈拆解人形机器人是一个典型的复杂系统不是单一模型或单一算法能搞定的。从底向上技术栈大致分为六个层次层级核心内容典型载体硬件层关节电机、减速器、结构件、电池、计算单元伺服电机、谐波减速器、行星滚柱丝杠传感器层视觉、力觉、触觉、惯性测量RGB 相机、深度相机、IMU、六维力传感器运动控制层双足步态、全身动力学、平衡控制MPC、WBC、ZMP 控制感知环境层目标检测、语义分割、SLAM、导航视觉导航、激光雷达定位行为决策层任务规划、动作生成、人类意图理解状态机、行为树、大模型任务规划具身智能层视觉语言动作模型、模仿学习、强化学习VLA 模型、Diffusion Policy软件环境上机器人描述文件是最先要接触的东西。URDFUnified Robot Description Format是最常用的机器人模型描述格式用来描述连杆、关节、质量、惯性、碰撞体等信息。下面是一段示意结构实际型号需要按真机参数替换。robot namehumanoid_example link namebase_link inertial mass value25.0/ origin xyz0 0 0.6/ /inertial visual geometry box size0.4 0.25 0.25/ /geometry /visual /link joint nameleft_hip_yaw typerevolute parent linkbase_link/ child linkleft_leg/ origin xyz0 0.1 0.85/ axis xyz0 0 1/ limit lower-1.57 upper1.57 effort300 velocity3.0/ /joint /robotURDF 本身不包含控制逻辑它只是模型描述。真正的运动控制要交给仿真环境、控制算法或厂商提供的 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(levellogging.INFO) robot HumanoidRobot(host127.0.0.1, port8000) 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, encodingutf-8) as f: json.dump([asdict(t) for t in batch], f, ensure_asciiFalse, indent2)批量任务的关键不是跑得快而是失败后可重试、可跳过、可定位。建议在任务队列中增加重试次数和超时时间字段避免某个动作卡死导致整个测试中断。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 个月可以重点关注几个方向具身智能大模型在整机上的部署效率真实场景数据飞轮的建设速度以及国产核心零部件的替代进度。对开发者来说最值得先做的事情是把手头已有的整机或仿真环境用起来跑通一套最小验证链路模型加载、单步控制、批量任务、日志记录。这个链路跑通后后续无论是切换模型、接入大模型还是增加场景都只是替换中间模块不用重来。最容易踩的坑则是跳过仿真直接上真机或者一上来就追求大模型部署把环境问题混淆为算法问题。建议从今天开始先下载一个仿真环境找一个人形机器人模型文件把它跑起来再说。