如果你想让人形机器人真正进入机场、医院、展馆、商场或园区这类半开放公共空间，最先要解决的通常不是“它会不会说话”，而是它在高噪声、多人流、频繁打断、路线变化和人工介入下还能不能稳定工作。本文想解决的，就是怎么把一个看起来能动的 humanoid，做成一个可部署、可验证、可收敛的问题闭环。它适合正在做公共场景导览、巡检、迎宾、问询分流或轻操作原型的团队。最关键的工程判断是：公共空间项目的核心不是单点能力，而是“导航、交互、安全、接管、运维”五件事能不能同时闭环。
这篇适合谁
- 正在做机场、医院、展馆、商场、校园、园区等公共场景 humanoid 原型的团队
- 已经有底盘、双臂或人形本体，但落地时总在真实场景里翻车的工程师
- 要定义验收标准、测试流程、人工接管策略和多角色协同边界的项目负责人
- 想判断“这个场景现在到底适不适合上 humanoid” 的产品或系统集成人员
先纠正几个很常见的误区
- 误区 1：公共场景主要考验对话能力。
真正先把项目拖垮的，通常是定位漂移、路径被挡、行人避让、任务中断恢复、权限边界不清，而不是大模型回复不够漂亮。 - 误区 2：只要实验室里能跑通，现场再调一调就能上线。
公共空间最大的问题是变量太多，灯光、反光地面、儿童干扰、轮椅、行李车、突发封路、保洁作业都会让实验室里“差不多能跑”的系统瞬间失效。 - 误区 3：机器人足够聪明，就能少做规则和人工介入。
恰恰相反，场景越开放，越需要明确的升级路径、接管权限、禁行区、保守策略和日志回放机制。 - 误区 4：公共部署首先追求通用性。
早期项目应该优先把任务范围收窄，例如导览、带路、问询分流、固定点巡检，而不是一开始就追求“一个机器人包打天下”。
关键实现判断：先做“半开放任务闭环”，不要先做“通用公共机器人”
公共空间不是完全开放，也不是工厂那种强结构化环境。真正可落地的切入点，通常是人流复杂，但任务边界清晰的子问题。比如：
- 从服务台带人到固定区域
- 在限定楼层做问询分流与路线引导
- 在夜间或低峰时段做巡检与异常上报
- 在展区、医院门诊或园区大厅做固定脚本的接待与转交
如果你的项目定义还是“在公共空间里自主完成各种服务任务”，那大概率还没有到可实施阶段。更可执行的做法是把系统拆成 5 个层：
- 场景层：地图、禁行区、等待区、服务点、人工接管点
- 任务层：带路、问询分流、巡检、转交、播报
- 行为层：移动、停靠、转身、等待、确认、呼叫人工
- 安全层：避障、减速、急停、区域限速、权限切换
- 运维层：任务下发、远程看护、日志回放、失败分桶、版本回滚
这 5 层同时存在，项目才有希望从 demo 变成部署。
分步实践指南
第 1 步，先选对任务，而不是先选最炫的机器人动作
公共场景项目最应该先做的是任务筛选。一个任务适不适合 humanoid，上来先问 5 个问题：
- 是否有明确起点、终点和触发条件？
- 失败后能否低成本交给人工接手？
- 环境变化是否可以通过地图更新或区域规则吸收？
- 是否需要“像人”这一形态带来的身高、交互视角或多模态表现？
- 是否能定义清楚成功率、平均时长、阻塞率和升级率？
如果这 5 个问题里有 3 个答不上来，不要急着进现场。先回去收窄任务。
第 2 步，把场景地图从“导航地图”升级成“运营地图”
很多团队只做 SLAM 地图，但公共空间更需要“运营语义”。也就是地图里不只要有可走区域，还要有：
- 高峰拥堵区：高峰时段自动降级或绕行
- 弱感知区：玻璃、镜面、强逆光、反光地面
- 交互停靠点：适合停下说话，不挡人流
- 人工接管点：远程无法恢复时，方便现场人员接手
- 安全边界：儿童密集区、设备作业区、自动门、扶梯、电梯口
你要维护的不是一张几何地图，而是一张和运营策略绑定的场景模型。
第 3 步，把导航设计成“可解释的保守系统”
公共空间里的导航不要过度追求激进穿行。更稳的设计是：
- 默认保守限速，不靠“最后一刻急刹”换通行效率
- 接近人群时提前减速，给周围人留出可预测反应时间
- 路线规划优先选宽通道、低干扰区，而不是最短路径
- 在人流过密时允许进入等待态，而不是强行挤过去
- 连续受阻超过阈值时，自动请求重规划或人工协助
这里最重要的不是能不能绕开障碍，而是旁人能不能看懂它下一步准备怎么走。
第 4 步，交互系统要围绕“澄清”和“降级”设计
在公共空间里，真正高频的交互不是复杂问答，而是以下几类：
- 确认对方是不是在和机器人说话
- 判断对方想问路线、找人、找窗口，还是只是路过
- 当语音听不清或多语言混杂时，快速切到按钮、屏幕或固定选项
- 在自己不确定时，把问题转给人工或引导到服务台
因此交互状态机至少要有：待命、唤起、澄清、执行、失败、升级、结束 7 个状态。不要把所有能力都塞进一个自由对话入口，否则线上问题会很难控。
第 5 步，提前定义人工接管链路
公共部署项目如果没有接管链路，基本等于没有上线资格。最少要定义：
- 谁能接管：远程坐席、现场安保、前台、运维人员分别拥有什么权限
- 什么时候接管：定位异常、连续受阻、用户投诉、硬件告警、语音失配、危险区域误入
- 接管后怎么恢复：继续任务、终止任务、人工领走、原地等待、回充或回基站
- 日志怎么留：接管前 30 秒、接管中操作、恢复后结果都要可追溯
很多项目失败，不是因为机器人做不到，而是因为机器人做不到时，没人知道下一步谁负责。
第 6 步，把验证流程拆成“离线、封场、低峰、真实高峰”四个阶段
公共空间项目不能直接拿营业时段当测试场。更合理的验证顺序是：
- 离线回放：用历史日志重放定位、避障、交互和调度决策
- 封场测试：验证路线、停靠、播报、急停、远程接管链路
- 低峰试运行：观察少量路人交互、临时障碍和噪声干扰
- 真实高峰验证：只在前 3 步指标过线后再上，并且限定区域、限定任务
每个阶段都要有停线条件，例如定位丢失率、连续阻塞率、人工升级率、误导用户次数、风险事件数。不要只看“有没有跑完”。
第 7 步，运维侧一定要做失败分桶
公共场景最忌讳把所有失败都归成“现场太复杂”。至少要分成这几桶：
- 地图与定位问题
- 局部避障与路径规划问题
- 语音/多模态理解问题
- 交互状态机设计问题
- 调度与权限切换问题
- 硬件、电量、网络或传感器健康问题
只有分桶后，团队才能判断下一轮该改地图、改策略、改传感器，还是干脆缩任务边界。
最容易翻车的地方
- 把“人多”当成唯一难点。 其实临时围挡、保洁车、玻璃反射、自动门、轮椅和儿童更容易造成极端情况。
- 交互和导航各自能跑，但组合后不稳定。 机器人一边说话一边移动时，定位、避障、收音和用户理解都可能同步变差。
- 没有明确停靠策略。 机器人停下来问询时如果正好挡在主通道，体验会迅速恶化。
- 没有现场责任人。 真出问题时，如果安保、前台、运维都以为不是自己负责，项目会被一次事故直接打回去。
- 缺少灰度上线机制。 一上来全楼层、全天候运行，通常不是勇敢，而是没有工程纪律。
一个更稳的最小可行部署方案
如果你现在就要落地一个公共场景 humanoid，我更建议从下面这个 MVP 开始：
- 只做 1 到 2 类任务，例如固定路线带路 + 固定问询分流
- 只覆盖一个楼层或一个大厅，不要一开始全场景铺开
- 只在低峰和中峰时段运行，先避开最高密度人流
- 远程看护默认在线，人工升级链路先跑顺
- 每周固定做日志回放和失败复盘，按分桶逐类收敛
这类方案不够炫，但更有机会活到第二阶段。
下一步怎么做
如果你准备把 humanoid 带入公共空间，下一步不要先去扩功能，而是按顺序补下面几件事：
- 写出明确任务清单和禁做清单
- 把场景语义地图和运营规则补齐
- 定义人工接管条件、角色和恢复策略
- 建立离线回放与失败分桶机制
- 先从一个区域、一个时段、一个任务闭环跑通
只有这些基础设施在，公共场景里的“智能”才不会变成昂贵而脆弱的表演。
延伸阅读方向
- 多传感器导航与动态障碍避让在共享空间中的验证方法
- 远程接管、现场接管与权限切换的人机协作流程设计
- 公共空间里的人形机器人安全证据、事件分级与审计日志
- 导览、问询、巡检三类任务在半开放环境中的 KPI 设计