这篇文章要解决的不是“机器人会不会说话更自然”，而是更实际的问题：当 humanoid 进入有人类同事、操作员或旁观者的空间时，系统怎样做到任务边界清楚、动作可预测、异常能被及时发现、人工接管不慌乱、恢复上线有依据。
如果你在做共享工位、半自动操作、遥操作辅助、人工复核或现场部署，这类交互层不是 UI 点缀，而是决定项目能不能稳定跑起来的基础设施。最关键的工程判断是：先把模式机、反馈链和接管链搭扎实，再去追求更“自然”的语音、表情或拟人体验。
这篇适合谁
- 正在做人形机器人现场试点，希望机器人与操作员共享空间、共享任务的人。
- 已经有基本感知、规划、控制能力，但一到异常、停机、误动作就不知道该怎么让人接手的人。
- 准备把遥操作、人工确认、任务编排、恢复流程接进真实项目，而不是只做实验室 demo 的团队。
先纠正几个很常见的误区
误区 1：人机交互主要是语音、对话和“更像人”
对真实工程来说，HRI 首先是监督接口，不是表演接口。操作员最需要知道的是：机器人当前在哪个模式、下一步会做什么、什么情况下会停、什么时候必须人工确认。
误区 2：有急停按钮，就算有接管机制
急停只是最后一道硬刹车。真正可用的接管链至少要有三层：减速或暂停、人工接管、硬停。如果所有异常最后都只能急停，现场节拍会很快崩掉，团队也会开始绕开系统使用。
误区 3：动作规划做得足够聪明，交互层可以后补
恰恰相反。没有清楚的模式边界和反馈面板，再好的规划器也会在现场被误解。很多“机器人不可靠”的抱怨，根本原因不是算法太差，而是人不知道它现在有没有看清、有没有抓稳、到底会不会继续执行。
关键实现判断：把交互系统当成“可监督的状态机”，不要当成一层前端皮肤
共享空间里的 humanoid，最好把整套协作过程拆成有限、明确、可见的状态，而不是让“自动执行中”包办一切。这里很值得参考 ROS 2 的 managed lifecycle 思路，至少把系统区分成类似 未配置、已就绪但未激活、执行中、故障/终止 这样的稳定状态。这样做的好处不是形式好看，而是你终于能明确回答几个关键问题：
- 什么时候允许机器人开始动？
- 什么时候只能接受人工确认，不允许自动推进？
- 出错后是回到待命、局部重试，还是必须人工复位？
- 哪些模块可以在线替换或重启，哪些必须整机停机？
如果这些边界说不清，人和机器人之间的协作关系一定会越来越脆弱。
分步实践指南
第 1 步，先把任务切成“人能理解、系统能验证”的阶段
不要一开始就定义一个笼统的“完成整理台面”或“协助装配”任务。更实用的拆法是把流程分成几个可以观察和中断的阶段，例如：
- 等待任务输入
- 感知确认与目标锁定
- 动作预演或路径检查
- 执行接近
- 接触/抓取/放置
- 结果确认
- 异常处理或人工复核
这一步可以借鉴 MoveIt Task Constructor 的思路。它把复杂任务拆成多个有输入输出关系的 stage，而不是把抓取或放置塞进一个黑盒动作里。你在 humanoid 项目里也该这么做，因为只有阶段化之后，人才知道应该在哪一层确认、暂停、回退或改目标。
第 2 步，给每个阶段定义“人能看到的反馈”
一个最小可用的人机协作界面，不一定复杂，但至少要持续暴露下面几类信息：
- 模式：自动、待确认、人工接管、暂停、故障恢复中。
- 目标：当前要操作哪个物体、去哪个位置、执行哪一类动作。
- 置信度或风险提示：比如目标丢失、接触不确定、路径可行性下降、手爪闭合异常。
- 下一步动作预告：如“向前接近 12 cm”“抬臂到安全过渡位”“等待人工确认后放手”。
- 可用操作：确认、暂停、减速、接管、放弃本次任务。
注意，这里最重要的不是做一块炫酷大屏，而是让现场任何一个责任人都能在两三秒内看懂系统打算做什么。
第 3 步，把“动作可预测”设计成默认行为，而不是事后补丁
真正让人不安的，不是机器人慢一点，而是机器人突然做出没有预告的动作。一个可预测的 humanoid 协作层，通常要遵守三条规则：
- 执行前给出短暂、明确的动作预告。
- 位姿大幅变化前先经过安全过渡姿态，避免突然甩臂、转身或抬手。
- 进入接触、高力矩、近身协作时自动降速，并把节奏控制权更多交给监督层。
这方面可以参考 BehaviorTree.CPP 与 Nav2 的做法。它们把导航、重规划、恢复动作放进显式的树结构里，而不是让系统“悄悄在后台试一试”。对 humanoid 也一样，重试、回退、重新感知、请求确认，都应该是可见节点，而不是藏在控制器内部。
第 4 步，把人工接管设计成一条短链路，不要让人临场找菜单
人工接管常见的失败，不是没有接管能力，而是接管路径太长。现场真正有用的顺序通常是：
- 软暂停：当前动作平滑停住，保持姿态与抓持安全。
- 低速人工接管：操作员直接接管末端、手臂或基座，优先把系统带回安全位。
- 任务放弃与状态保留：记录这次失败在哪一步、感知看到什么、为什么需要人工接手。
- 必要时硬停：只在风险已经越过软暂停和人工接管能力时使用。
如果你已经在做示教或远程辅助，很适合参考 Open-TeleVision 这类项目。它强调沉浸式主动视觉反馈与直观的手臂、手部映射，本质上就是在减少“人看不懂机器人当前处境”这件事带来的接管延迟。即使你不做 XR，也该吸收其中一个判断：接管质量很大程度取决于操作员是否获得了足够接近机器人体感的反馈，而不是只看一块普通监控画面。
第 5 步，恢复流程必须和日志、证据链绑在一起
很多团队把恢复理解成“重新启动一下试试”。这会导致两个问题：第一，问题不断复发；第二，现场越来越不信任机器人。更靠谱的做法是给每类异常都配一个最小恢复模板：
- 异常属于感知丢失、规划失败、抓取失败、外界干扰，还是执行器/通信异常？
- 允许自动重试几次，重试前要不要重新感知或换抓取策略？
- 超过阈值后是否必须人工确认？
- 恢复完成后要回到哪一个稳定状态，而不是直接续跑？
如果没有这套模板，你的“恢复”很容易退化成随机试错。共享空间项目里，随机试错就是风险源。
第 6 步，把共享空间协作的边界条件写死，不要依赖现场人员“自己懂”
人机协作最怕默认假设。你要明确规定：
- 人进入哪个区域后，机器人必须降速或暂停。
- 哪些动作必须先等待确认，比如递交刀具、放置重物、靠近人体关键部位。
- 哪些任务允许单人监督，哪些任务必须双人确认。
- 哪些传感器异常下仍可低风险运行，哪些一旦丢失就必须退出自动模式。
这一层和“安全”当然相关，但它不只是安全规则，更是工作流设计。边界写不清，操作员就会不断猜系统意图，最终不是过度保守，就是过度冒险。
最容易翻车的地方
- 只显示“运行中”，却不告诉人机器人当前卡在哪一步。
- 异常提示过晚，等到已经接触失败或路径冲突才让人知道。
- 接管入口太深，需要切多个菜单才能接管。
- 自动恢复过度积极，系统在没告诉人的情况下连续重试，越试越危险。
- 日志不够，人工接管后没有回放证据，团队只能靠记忆争论问题根因。
- 把所有协作问题都推给语音或大模型，却没有先把模式和责任边界理顺。
怎么验证你真的搭对了
不要只看“用户觉得还行”。至少做下面 5 组验证：
- 模式识别测试：随机抽一个现场同事，看他能不能在 3 秒内说出系统当前模式与下一步动作。
- 异常感知测试：人为制造目标丢失、抓取滑脱、路径受阻，检查界面是不是能先于危险动作发出提醒。
- 接管时延测试：从发现异常到软暂停，再到人工接管成功，把时间打点记录下来，别只凭感觉。
- 恢复正确性测试：同一类失败连续触发 10 次，确认系统回到的是预设稳定状态，而不是偶然跑通。
- 责任边界测试：让不同班次、不同经验的人上手，看看他们会不会在同一位置误解系统。只要解释口径不一致，边界设计就还不够清楚。
如果你愿意更进一步，可以把每次人工接管都当成高价值数据：接管前状态、接管动作、恢复结果、是否需要修改树节点或状态机，都该进入下一轮迭代。
下一步怎么做
如果你现在的系统还比较早期，我建议按这个顺序推进：
- 先补齐模式机和基本反馈面板。
- 再把任务拆成可以确认、暂停、回退的阶段。
- 然后做最短人工接管链，并实测接管时延。
- 最后再考虑语音、多模态提示、自然语言任务输入等“体验增强层”。
对 humanoid 来说，真正让人放心的，不是它看起来多聪明，而是它在共享空间里出问题时，人有没有办法稳稳接住。
延伸阅读与参考来源
- ROS 2 Managed Lifecycle Design: https://design.ros2.org/articles/node_lifecycle.html
- BehaviorTree.CPP ROS 2 Integration: https://www.behaviortree.dev/docs/ros2_integration/
- Nav2 Detailed Behavior Tree Walkthrough: https://docs.nav2.org/behavior_trees/overview/detailed_behavior_tree_walkthrough.html
- MoveIt Task Constructor: https://moveit.picknik.ai/main/doc/concepts/moveit_task_constructor/moveit_task_constructor.html
- Open-TeleVision: https://robot-tv.github.io/