很多人以为人形机器人“会规划”以后，剩下只是把动作做稳一点。真正上线后你会发现，系统最常翻车的地方不是不会分解任务，而是每一步都没有真正绑定到当前场景里的那个物体、那个位置、那个时刻。这篇文章要解决的就是这个问题：怎么把“知道要做什么”变成“在真实环境里做对地方、做对对象、做错还能退回来”。如果你正在搭一个能落地的抓取、整理、搬运或服务型 humanoid，这件事的工程优先级通常比继续堆更大的模型还高。
这篇适合谁
- 正在搭 humanoid 任务执行系统的人，尤其是已经有基础感知和基础动作能力，但一到真实场景就出错的团队。
- 要把自然语言任务、视觉感知、目标选择、运动执行串成闭环的工程师。
- 在做桌面操作、货架拣选、收纳整理、工位上料、门把手/抽屉/容器交互等中长流程任务的人。
先纠正几个很常见的误区
- 误区一，任务规划对了，执行自然就对。
错。规划输出通常只告诉你“去拿杯子”，但现场可能有三个相似杯子、两个遮挡、一个已经被人移动。没有目标绑定和执行前确认，规划正确也会抓错。 - 误区二，只要上更强的视觉大模型就能解决 grounding。
错。很多失败不是识别不出来，而是系统没有把“语言里的目标”“相机里的候选对象”“机器人当前可达区域”“动作前提条件”对齐成一个可验证的执行对象。 - 误区三，执行失败说明控制不够稳。
不一定。很多所谓控制失败，根源其实是上游把错误目标交给了控制层，或者场景状态在执行窗口内已经变化。 - 误区四，长流程主要靠更长上下文。
也不完全对。长流程更依赖阶段性重感知、状态更新、异常回退和中间结果确认，而不是把所有步骤一次性规划到底。
关键实现判断
如果你要把 humanoid 从 demo 做到可重复执行，建议尽早接受一个现实：执行系统的核心不是“计划”，而是“计划 + 场景绑定 + 执行前检查 + 步后确认 + 异常回退”这一整条闭环。
我更推荐把系统拆成下面五层，而不是把所有责任都塞给一个大模型：
- 任务层：把“整理桌面”“把零件放回周转箱”拆成有限个可执行技能。
- 目标绑定层：为每一步明确对象 ID、目标区域、约束条件、优先级和置信度。
- 执行前校验层：确认目标仍在、位姿可信、路径可达、抓取面可用、风险可接受。
- 技能执行层：抓取、放置、开关门、双手协同、基座移动、姿态调整。
- 回退与复核层：失败后重感知、换目标、换抓取策略、请求人工接管或降级完成。
工程上最关键的判断是：不要让 planner 直接输出一句模糊文本就驱动动作。 任何会触发真实接触的步骤，都应该先落到结构化执行卡片，例如：
- 目标对象：cup_03
- 目标来源：front_rgbd + shelf_cluster_b
- 预期位置：table_zone_left_rear
- 执行前提：目标可见、无遮挡、抓取间隙 > 2cm、腕部姿态可达
- 成功判据：对象离开原位置，末端载荷变化符合预期，放置后目标进入 tray_zone_1
- 失败回退：重新检测一次，若仍冲突则切换候选对象或请求人工确认
分步实践指南：把“计划”真正落到场景里
第 1 步，先把任务单位收窄到可验证技能
如果你的技能定义还是“整理桌面”“收拾工位”这种人类语言级别描述，后面几乎一定会漂。更稳的做法是把长任务拆成可验证技能单元，例如：
- 定位容器
- 识别并选择目标物
- 移动到预抓取位姿
- 执行抓取并确认抓取成功
- 移动到目标区域
- 执行放置并确认放置成功
每个技能都必须有输入、输出、前提条件、成功判据和失败码。没有失败码，你后面很难统计问题到底出在感知、规划、控制还是夹爪接触。
第 2 步，给对象建立“候选集”而不是单点答案
在真实场景里，系统很少第一次就能 100% 确认正确对象。与其强行输出唯一答案，不如维护一个候选集：
- 对象类别，例如 cup、box、tool
- 实例 ID 或临时跟踪 ID
- 空间位置与朝向
- 置信度
- 语义属性，例如“红色”“带把手”“位于托盘右侧”
- 执行可行性评分，例如是否可达、是否遮挡、是否稳定可抓
然后由目标绑定层做排序，而不是让上游一句话决定一切。这样你才能在第一候选失败时快速切到第二候选，不必整条任务重启。
第 3 步，把语言 grounding 转成结构化约束
“把左边那个杯子放到盘子里”这种指令，真正可执行的不是句子本身，而是句子解析后的约束集合：
- 对象类别：杯子
- 相对关系：位于多个杯子中的左侧
- 目标区域：盘子内侧可放置区域
- 动作约束：不能碰翻周边物体，放置姿态要稳定
如果不做这一层，你的系统会一直在“语言正确但动作错位”的状态里打转。最实用的方法不是追求一次推理得出完美答案，而是把解析结果喂给视觉和几何模块，再反过来验证有没有满足这些约束的候选对象。
第 4 步，执行前一定做四类检查
任何接触动作前，至少检查四件事：
- 目标还在不在：人、其他机器人、传送带都可能让目标在几秒内变化。
- 目标是不是同一个：跟踪 ID 漂移、遮挡恢复、视角切换都可能让实例关联出错。
- 当前还可不可达：基座位置、躯干姿态、手臂余量、碰撞体积都可能已经变化。
- 执行后果是否安全：抓了会不会带起相邻物体，推门时另一只手会不会进入危险区域。
很多团队只做“能不能识别到”，但真正让成功率提升明显的，通常是这些执行前校验。
第 5 步，把“执行后确认”当成技能的一部分
抓取动作结束不代表抓取成功，放置轨迹结束也不代表物体已经稳妥落位。每个技能完成后都要有确认：
- 视觉确认，目标是否离开原位、是否到达目标区域
- 力觉/电流确认，夹爪是否真的持有物体
- 状态确认，任务状态机是否进入正确下一阶段
- 环境确认，周边是否因为这一步变成新的障碍或风险
这一步很像工业自动化里的 interlock，只是在人形机器人里，确认信号更杂、环境更乱，所以更不能省。
第 6 步，把失败分桶，不要统一记成“任务失败”
如果日志里只有 success / fail，你几乎无法改系统。建议至少分成这些桶：
- 目标选择错误
- 目标跟踪丢失
- 位姿估计不稳
- 路径规划不可行
- 抓取接触失败
- 放置后滑落或姿态错误
- 场景变化导致前提失效
- 安全守护触发中断
一旦开始这样记，你会发现很多问题并不是“机器人不聪明”，而是某两层之间缺少接口约束或确认机制。
第 7 步，验证顺序要从静态桌面走到动态现场
不要一上来就测复杂自然语言长任务。更靠谱的验证顺序通常是：
- 单对象、无遮挡、固定光照
- 多相似对象，但位置分散
- 多相似对象，且带遮挡
- 执行中允许人工移动一个物体
- 执行中允许人类插手改变目标区域
- 加入时间约束、失败重试和人工接管流程
这个顺序的意义在于，你能知道系统究竟是死在语义歧义、视觉漂移、动作误差，还是场景变化响应太慢。
最容易翻车的地方
- 只看 top-1 识别结果：一旦 top-1 错了，整条链路跟着错。
- 目标检测和动作执行之间隔太久：检测时对，执行时环境已经变了。
- 规划层不知道控制层的真实能力边界：例如让手臂在肩部奇异位姿附近做高精度放置。
- 把“抓到东西”误判为“抓到对的东西”：这是现场最常见、也最容易被 demo 掩盖的问题。
- 没有人工接管入口：长流程系统如果没有明确 handover，现场只会越错越乱。
- 日志不够细：没有对象 ID、候选排序、执行前快照和失败码，后续几乎没法复盘。
一个实用的最小落地架构
如果你现在就想把系统做起来，而不是继续讲概念，我会建议从下面这个最小版本开始：
- 一个任务状态机或行为树，负责流程切换。
- 一个场景对象表，维护候选对象、位置、置信度和可执行性评分。
- 一个 grounding 模块，把语言或任务模板转成结构化约束。
- 一个技能调度器，只调用已经验证过的抓取/放置/开关门等原子技能。
- 一个执行前检查器，统一做可见性、可达性、碰撞和安全验证。
- 一个执行后确认器，统一处理成功判定和失败分桶。
- 一个人工接管接口，在冲突、低置信度或多次失败时及时让人接入。
这套架构不炫，但它比“单个大模型直接端到端驱动机器人”更容易调试，也更适合先做出稳定可复用的工程系统。
下一步怎么做
如果你已经有基础感知和操作能力，下一步最值得补的是三件事：
- 把每个技能的前提条件和成功判据写成机器可读规则。
- 给候选对象排序系统加入可达性和风险评分，而不只是视觉置信度。
- 开始积累失败回放数据，专门统计“选错对象”“识别对但抓错位置”“执行中场景变化”这三类问题。
一旦这三件事开始稳定，你的 humanoid 才会从“偶尔做成一个 demo”走向“在真实现场可重复地完成任务”。
延伸阅读方向 / Sources
- Spatially Grounded Long-Horizon Task Planning in the Wild（GroundedPlanBench）
- DROID 数据集相关操作场景与长时序执行研究
- 行为树、任务状态机、层级技能调度在机器人系统中的实现经验
- 面向 manipulation 的多模态感知、对象跟踪、抓取确认与失败恢复方法