小米正式开源自研具身基座模型 Xiaomi-Robotics-1，把一套经过大规模机器人数据训练的视觉、语言与动作模型推向开发者。来源摘要给出的规模包括 1000 个机器人训练场景、1700 种物体和 10 万小时数据；在 4 个主流机器人操作 benchmark 上，它超过了 Pi0、Gemma3 和 Qwen2.5-VL，其中 RoboDojo 指标高出 58.3%，VLABench 则领先第二名 11.1 个百分点。
这些数字值得关注，但对准备把模型接入真实机械臂的团队来说，更重要的问题是：模型能否读懂场景、生成可执行动作，并在面对遮挡、物体位姿变化和执行误差时稳定闭环。
具身基座模型解决的不是单轮识图
传统视觉语言模型可以回答“桌上有什么”，机器人却需要继续处理一串相互依赖的任务：识别目标、理解空间关系、选择抓取位置、规划动作、执行控制，再根据新的相机画面判断是否成功。
因此，具身模型的价值不能只用图像问答准确率衡量。一个完整的机器人操作回路通常包含以下信息：
- 观察：RGB、深度图、关节角、末端执行器状态和力传感器数据。
- 任务：例如“把红色杯子放进左侧托盘”，其中包含对象、方向和目标状态。
- 动作：末端位姿、关节增量、夹爪开合，或者由下游控制器消费的高层技能。
- 反馈：动作是否完成、目标是否移动、是否发生碰撞，以及是否需要重新规划。
Xiaomi-Robotics-1 的开源意义，在于开发者可以围绕模型权重、推理链路和数据格式开展适配，而不必把具身能力限制在封闭服务中。不过，来源摘要没有给出具体模型接口、许可证条款和硬件兼容列表，实际采用时仍应以仓库中的模型卡和许可证为准。
数据规模为何影响泛化能力
1000 个训练场景和 1700 种物体意味着模型有机会看到大量环境与对象组合。这里真正有价值的不是简单增加物体类别，而是覆盖同一任务中的变化：光照不同、背景不同、目标被遮挡、抓取角度变化，以及机械臂执行后产生的位置偏差。
10 万小时数据则可能扩大长尾动作和失败样本的覆盖范围。不过，仅凭数据时长无法判断训练质量。部署团队还需要确认几个问题：
- 数据来自真实机器人、仿真环境，还是二者混合？
- 10 万小时指原始采集时长、过滤后数据量，还是多视角数据的累计值？
- 训练硬件与目标机械臂之间是否存在相机、夹爪和自由度差异？
- benchmark 使用的是统一协议，还是针对不同模型做过额外适配？
RoboDojo 和 VLABench 的领先结果证明模型在标准测试中的竞争力，但 benchmark 不是生产环境。实验台上的积木抓取成功率，不能直接等价为家庭环境中的玻璃杯操作安全性。
可以这样实践：先建立受约束的推理适配层
下面是一个可直接运行、也便于改造的 Python 示例。它假设你已经把模型包装成一个 HTTP 推理服务，接口接收任务和机器人状态，并返回高层动作计划。请求路径和字段是集成示例，不代表 Xiaomi-Robotics-1 的官方 API；接入时需要按实际仓库提供的推理代码修改 MODEL_ENDPOINT 和请求体。
先安装依赖并设置服务地址：
python -m pip install requests
export MODEL_ENDPOINT=http://127.0.0.1:8000/v1/robot/plan
创建 robot_client.py：
import json
import os
from typing import Any
import requests
ENDPOINT = os.environ.get(
"MODEL_ENDPOINT",
"http://127.0.0.1:8000/v1/robot/plan",
)
ALLOWED_SKILLS = {"move_above", "grasp", "place", "open_gripper", "stop"}
def validate_plan(plan: list[dict[str, Any]]) -> None:
if not plan or len(plan) > 12:
raise ValueError("Plan must contain between 1 and 12 actions")
for index, action in enumerate(plan):
skill = action.get("skill")
if skill not in ALLOWED_SKILLS:
raise ValueError(f"Action {index} uses unsupported skill: {skill!r}")
confidence = float(action.get("confidence", 0.0))
if confidence < 0.75:
raise ValueError(
f"Action {index} confidence {confidence:.2f} is below threshold"
)
def request_plan() -> list[dict[str, Any]]:
payload = {
"instruction": "把红色杯子放入左侧托盘",
"observation": {
"rgb_image": "/data/latest/rgb.png",
"depth_image": "/data/latest/depth.png",
"joint_positions": [0.0, -0.42, 0.18, 1.21, 0.0, 0.63],
"gripper_open": True,
},
"constraints": {
"allowed_skills": sorted(ALLOWED_SKILLS),
"workspace_m": {
"x": [0.20, 0.75],
"y": [-0.45, 0.45],
"z": [0.02, 0.60],
},
},
}
response = requests.post(ENDPOINT, json=payload, timeout=30)
response.raise_for_status()
plan = response.json()["actions"]
validate_plan(plan)
return plan
if __name__ == "__main__":
try:
actions = request_plan()
print(json.dumps(actions, ensure_ascii=False, indent=2))
except (requests.RequestException, KeyError, TypeError, ValueError) as exc:
print(json.dumps({"safe_stop": True, "reason": str(exc)}, ensure_ascii=False))
raise SystemExit(1)
运行客户端：
python robot_client.py
这个适配层刻意不让模型直接输出电机电流或任意关节指令，而是把输出限制为 grasp、place 等经过验证的技能。低置信度、未知技能、超时和异常响应都会触发安全停止。实际系统还应增加工作空间检查、碰撞检测、速度限制和急停控制器，而且这些约束必须运行在独立于模型的控制层中。
benchmark 之外，还要测什么
内部评估应复现团队自己的任务分布。一个家庭机器人项目可以按物体、环境和干扰因素建立测试矩阵，并同时记录成功率与失败类型：
suite: kitchen-pick-and-place
trials_per_case: 50
scenes:
- daylight_clean_table
- low_light_cluttered_table
objects:
- ceramic_cup
- transparent_glass
- deformable_bag
perturbations:
- none
- partial_occlusion
- target_shift_after_planning
metrics:
- task_success_rate
- collision_rate
- replan_count
- p95_completion_time_ms
safety_limits:
max_tcp_speed_mps: 0.15
max_contact_force_n: 8.0
stop_on_unknown_action: true
不要只汇总平均成功率。透明物体、反光表面、柔性包装和拥挤桌面往往会暴露截然不同的问题。部署前还应保留失败视频、模型输入、动作计划和控制器反馈，确保每次异常都可以重放。
采用前的工程检查
Xiaomi-Robotics-1 展示了国产具身基座模型在公开 benchmark 上的竞争力，大规模场景与机器人数据也为跨任务泛化提供了基础。但开源权重只是起点，模型距离可靠产品之间仍隔着硬件标定、实时控制、安全约束和现场评估。
开始试验时，可以依次确认以下事项：
- 阅读许可证和模型卡，确认商业使用、再分发及数据合规要求。
- 核对显存、推理延迟、输入模态和支持的机器人本体。
- 先在仿真与隔离工作台运行，不直接接入高速机械臂。
- 使用受约束的技能接口，让确定性控制器掌握最终执行权。
- 用自有场景建立回归集，分别统计碰撞、误抓、掉落和超时。
- 对模型升级、量化和微调版本执行同一套安全回归测试。
对研发团队而言，最合理的切入点不是立刻追求通用家庭机器人，而是选定一个边界清晰、可重复测量的操作任务。只有当模型在真实任务矩阵中持续通过测试，公开 benchmark 的领先优势才真正转化为工程价值。