宇树科技发布的人形机器人通用智能模型 UnifoLM-OminiA-0.3，重点不只是让机器人识别画面或回答问题，而是把环境感知、任务理解、动作规划与自主执行串成完整闭环。公开演示中，搭载该模型的 G1 可以搬运地面抱枕、识别物品颜色和数量，并执行抓取等现实任务。这类能力意味着机器人系统正在从单项动作展示，转向由统一任务目标驱动的连续作业。
“全模态”真正难在把信息变成动作
家庭和康养环境并不像工厂产线那样固定。光照会变化，物品可能被遮挡，人的指令也往往不够精确。例如，“把地上的抱枕放回沙发”至少包含以下环节：
- 从视觉信息中找到地面、抱枕和沙发；
- 理解“地上的”是对目标物体的约束；
- 选择可接近、可抓取的位置；
- 规划走路、弯腰、抓取、搬运和放置动作；
- 在每一步后重新观察，判断任务是否成功。
因此，全模态交互理解不能停留在“图像加文本”的输入层。对于具身智能系统，更关键的问题是模型能否把语言、视觉、机器人状态和历史动作组织为一个持续更新的任务状态。
可以把这条链路抽象为：
用户指令 + 相机/传感器数据 + 机器人状态
↓
场景与意图理解
↓
可验证的结构化任务计划
↓
运动控制器与技能模块
↓
执行反馈、纠错与重规划
UnifoLM-OminiA-0.3 所展示的价值，正在于覆盖从理解到执行的完整流程，而不是只输出一个物体标签或动作名称。
从演示走向应用，要盯住三个接口
1. 感知结果必须带空间约束
机器人知道“这是一个抱枕”还不够。抓取需要目标的位置、姿态、尺寸、遮挡情况以及可接近区域。颜色和数量识别可以帮助机器人筛选目标，但最终仍要落到坐标系与动作空间中。
工程上应明确模型输出的是自然语言、二维框、三维位姿，还是已经参数化的技能调用。接口越模糊，越难测试，也越容易在控制层产生不可预测行为。
2. 高层模型不应直接绕过安全控制
通用模型适合决定“做什么”和“按什么顺序做”，但关节限位、碰撞检测、抓取力控制、急停和人员避障，应由确定性更强的控制模块负责。一个稳妥的分层方案是：
- 模型生成任务计划；
- 技能层校验参数和前置条件；
- 运动规划器生成轨迹；
- 安全控制器决定轨迹能否下发；
- 传感器反馈触发成功确认或重规划。
这种分层会牺牲一部分端到端的简洁性，却能换来审计、回放和故障隔离能力。在家居与康养场景中，这通常比追求动作速度更重要。
3. “做完了”必须能够被验证
搬起抱枕不等于完成任务。系统还要确认抱枕是否稳定落在沙发上、夹爪是否释放、机器人是否恢复安全姿态。实际部署时，应为每个技能定义明确的成功条件，例如：
- 目标物体进入指定区域；
- 末端执行器不再持有物体；
- 人员与机器人保持安全距离；
- 超时或连续失败时停止，而不是无限重试。
可以这样实践：先搭一个可审计的任务闭环
下面是一个可直接运行的 Python 示例，用来模拟“搬运红色抱枕”的计划、校验、执行和反馈过程。这不是 UnifoLM-OminiA-0.3 的官方 SDK 或接口，而是根据具身智能闭环构造的最小工程骨架。接入真实机器人时，可以把 observe、execute_skill 替换为模型服务和机器人控制中间件调用。
将代码保存为 robot_loop.py，然后运行 python robot_loop.py：
from dataclasses import dataclass
from typing import Any
@dataclass
class Step:
skill: str
args: dict[str, Any]
ALLOWED_SKILLS = {"navigate", "pick", "place", "verify"}
MAX_SPEED_MPS = 0.4
def observe() -> dict[str, Any]:
"""模拟视觉与机器人状态；实际项目中替换为传感器/模型输出。"""
return {
"objects": [
{"id": "pillow_1", "type": "pillow", "color": "red", "zone": "floor"},
{"id": "pillow_2", "type": "pillow", "color": "blue", "zone": "sofa"},
],
"robot": {"holding": None, "estop": False},
"human_distance_m": 2.3,
}
def make_plan(scene: dict[str, Any]) -> list[Step]:
target = next(
obj for obj in scene["objects"]
if obj["type"] == "pillow"
and obj["color"] == "red"
and obj["zone"] == "floor"
)
return [
Step("navigate", {"target": target["id"], "speed_mps": 0.25}),
Step("pick", {"object_id": target["id"], "max_force_n": 18}),
Step("navigate", {"target": "sofa", "speed_mps": 0.2}),
Step("place", {"object_id": target["id"], "zone": "sofa"}),
Step("verify", {"object_id": target["id"], "expected_zone": "sofa"}),
]
def safety_check(step: Step, scene: dict[str, Any]) -> None:
if step.skill not in ALLOWED_SKILLS:
raise ValueError(f"未授权技能: {step.skill}")
if scene["robot"]["estop"]:
raise RuntimeError("急停已触发，拒绝执行")
if scene["human_distance_m"] < 1.0:
raise RuntimeError("人员距离过近，等待安全区域清空")
if step.skill == "navigate" and step.args["speed_mps"] > MAX_SPEED_MPS:
raise ValueError("导航速度超过策略上限")
def execute_skill(step: Step) -> bool:
"""模拟技能执行；真实实现应调用运动规划器并读取执行反馈。"""
print(f"EXECUTE {step.skill}: {step.args}")
return True
def main() -> None:
scene = observe()
plan = make_plan(scene)
for index, step in enumerate(plan, start=1):
safety_check(step, scene)
if not execute_skill(step):
raise RuntimeError(f"第 {index} 步失败，停止后续动作")
print("任务闭环完成：计划中的动作均已执行并验证。")
if __name__ == "__main__":
main()
这个骨架刻意限制了模型的权限：模型只能从白名单中选择技能，速度和安全距离由独立策略检查。真实系统还应增加坐标合法性校验、动作超时、幂等控制、失败重试次数、视频回放与人工接管机制。
如果任务计划由大模型生成，还可以要求它输出严格 JSON，而不是直接产生自由文本或底层关节指令。例如：
{
"goal": "将地面的红色抱枕放到沙发上",
"steps": [
{"skill": "navigate", "target": "pillow_1"},
{"skill": "pick", "object_id": "pillow_1"},
{"skill": "navigate", "target": "sofa"},
{"skill": "place", "object_id": "pillow_1", "zone": "sofa"},
{"skill": "verify", "object_id": "pillow_1", "expected_zone": "sofa"}
]
}
控制服务收到计划后，应再次根据 JSON Schema、实时场景和安全策略进行校验，不能把模型输出直接当成可信控制命令。
评估时别只看一次成功的视频
从公开演示可以看到模型覆盖多种任务，但部署决策还需要更细的指标。建议至少建立以下测试集：
- 泛化能力：更换房间、光照、物体位置后是否仍能完成任务；
- 语言鲁棒性：面对省略、指代和口语表达时是否会选错目标；
- 操作成功率：抓取、搬运、放置各阶段分别统计，而不是只记录总成功率；
- 恢复能力：目标被移动、抓取滑落或路径受阻后能否安全重规划；
- 安全边界：人员突然靠近、传感器异常或网络中断时是否立即降级；
- 可观测性：是否能保存感知结果、计划版本、控制日志和失败原因。
UnifoLM-OminiA-0.3 释放出的明确信号是，人形机器人的竞争焦点正在从单个动作能力转向通用任务闭环。对准备采用这类模型的团队来说，最稳妥的路径不是一开始就开放全部自主权限，而是从低速、轻物体、限定区域和技能白名单入手。先让每一步可验证、可停止、可回放，再逐步扩大场景和任务范围。