UBTECH Walker C1不是为工厂重复搬运物料而设计的工业机型，而是一款面向导览、购物协助、巡检和教育等人与机器人直接接触场景的全尺寸人形机器人。UBTECH强调其内置世界模型、动作库、全向感知、标准接口和SDK；同门Walker S2则把载荷、自主换电和产线连续运行摆在更靠前的位置，两者解决的并不是同一类问题。
Walker C1瞄准的是人与机器人当面交互的服务任务
UBTECH Walker C1官方产品页把应用归为四类：商业服务中的多语种接待、AI导览和购物协助；文娱场景中的活动及访客互动；城市安全中的巡检和交通协助；教育科研中的教学辅助与开发平台。这些空间的共同点，是人的问题、位置和行动会不断变化。
因此，评估C1不能只看它能举起多少kg。陌生人突然挡路时能否停车，多人同时说话时能否选定交互对象，嘈杂环境中能否听懂问题，以及无法处理时能否顺畅转交工作人员，都会直接决定服务质量。与工厂机器人相比，此类产品的交互失败会立刻反映在访客体验和现场安全上。
| 对比项目 | Walker C1 | Walker S2 |
|---|---|---|
| 官方定位 | 城市及商业服务人形机器人 | 工业人形机器人 |
| 典型任务 | 导览、购物协助、访客互动、巡检、教育 | 产线操作、物料处理、连续作业 |
| 公开强调的能力 | 世界模型、动作定制、全向感知、SDK | 标称15kg处理能力、自主换电、工业智能体 |
| 能源运行 | C1页面未详细披露轮班运行方式 | UBTECH称采用双电池，并可在3分钟内自主换电 |
| 部署KPI | 服务闭环率、安全停车、转人工率、访客等待时间 | 节拍、开机率、人工介入率、吞吐量 |
3m/s以上是动态能力上限，不是商场里的常态速度
官方产品规格图标注速度性能超过3m/s。这一数字体现的是动态能力上限，并不承诺机器人会在商场或展馆里始终以该速度穿行。真实服务速度会受到人流密度、地面摩擦力、制动距离、当地安全规定和运营方限速策略的共同约束，通常会低得多。
速度测试也不应只在空旷舞台上测最高值。应加入儿童突然跑入行进方向、婴儿车与行李遮挡视野，以及扶梯入口处人群停顿等场景。即使最高速度很高，若减速过晚或停车后机身大幅晃动，现场仍需缩小使用范围。“动作快”和“安全完成接待任务的吞吐量”是两个不同指标。
世界模型的价值，要到陌生标识、玻璃和临时隔断前验证
UBTECH称C1内置世界模型和高性能计算，但产品页没有披露具体模型名称、训练数据边界、失效率和更新策略。仅凭“世界模型”这一表述，不能推定机器人已经理解所有建筑布局和人类行为。首次出现的标识、临时隔断、反光玻璃和拥挤队列等分布外场景，才更能检验系统边界。
现场验收可以按“感知—判断—行动”拆分日志：机器人是否区分访客与障碍物，是否把请求映射到正确目的地，路径中断后能否继续导览，以及给出错误路线后能否自行纠正或转人工。若需要先理解具身智能（Physical AI）的基本结构，可从具身智能企业与技术生态梳理模型、传感器和机器人本体的关系。
动作库和SDK决定可改造性，却不等于业务系统已经接通
按照官方介绍，C1提供内置动作库，支持多种动作并允许定制，还提供标准接口和较完整的SDK。模块化、机型间兼容性以及单人即可部署的易用性，也是UBTECH公开强调的卖点。不过公开页面并未列出面向每类客户系统的API清单、版本兼容表、数据保存位置和故障恢复责任。
导览机器人要接入的往往不是一个动作，而是一串系统：楼宇地图、活动日程、门店库存、访客预约、多语种内容、员工呼叫和隐私同意流程。拥有SDK不代表这些连接会立即可用。签约前应索取沙箱环境、身份认证方式、调用限额、断网缓存范围以及升级后的回滚流程；仿真工具选择可继续参考机器人仿真器对比。
Walker S2优先解决产线连续运行，C1优先解决服务闭环
UBTECH Walker S2官方产品页把自主换电和24小时连续运行放在核心位置。UBTECH介绍了双电池架构、3分钟内自主换电、最高15kg处理能力，以及面向产线任务的Co-Agent。这与C1在大堂面向人群提供服务的产品叙事明显不同。
把C1理解成S2的低价版或简化版也不准确。C1扩展的是对话、文娱活动、巡检和教育等交互范围，S2面向的是工件、班次和产量边界更明确的工业现场。即便同属人形机器人，采购方要求的证据也应不同：C1要看访客任务闭环与安全转交，S2要看节拍和无人工介入的连续时长。
服务表现要按“访客的问题是否解决”来计分
机器人在展台上挥手并用多种语言问候，确实容易吸引注意，但真正的服务从下一步才开始。访客询问最近的洗手间，而目的地临时关闭、周围又十分嘈杂时，机器人仍应提供替代方案。若不知道答案或传感器受阻时不能自然转交工作人员，即使可以长时间对话，任务也没有完成。
| 测试场景 | 应测指标 | 容易漏掉的失败 |
|---|---|---|
| 多语种导览 | 不能只测问题理解率，还要测到达目的地和任务闭环率 | 回答流畅，却把访客带到错误地点 |
| 拥挤行走 | 与人最小距离、急停次数和绕行时间 | 为保证安全不断停下，访客反而越过机器人 |
| 巡检 | 发现异常到工作人员确认所用时间 | 报警很多，但误报过多导致告警被忽略 |
| 购物协助 | 库存及位置数据的新鲜度、转人工率 | 用过期信息延长顾客路线 |
| 故障状态 | 断网后的安全状态和恢复时间 | 屏幕仍亮，却不告知任务已经中断 |
试点日志还应记录工作人员为机器人清理前方的时间、远程操作员介入次数和访客放弃等待的节点。导览100次中回答了90次，不如其中多少次真正完成到达目的地或预约更能体现运营价值。如何划分本地处理和服务器上送的数据，可结合机器人边缘AI继续评估。
公开页面没有给出价格、交期和各国服务范围
产品页称模块化设计与量产能力有助于快速供货和部署，这是企业对供应能力的表述，并不等于页面已经公布统一售价、各国库存、实际交期、语言包范围和现场集成费用。“可快速使用”也不能自动解释为已经连接客户数据与楼宇系统。
更稳妥的做法，是通过UBTECH公司官方介绍和销售渠道，把机器人本体、充电设施、开发许可、内容制作、远程监控、现场培训、备件和质保响应时间分别报价。若用于导览、医疗或教育等涉及个人信息的环境，还要在合同中写明音视频保存位置、删除政策、管理员权限和安全更新期限。
C1更适合需要“在人群所在的城市空间中对话并移动”的团队；若目标是在产线上昼夜处理较重零部件，则应优先比较S2等工业机型。先定义任务何时算完成，再比较外形和演示效果，产品选择会更清晰。
知识更新和隐私边界，会直接缩小或扩大可用服务范围
城市服务机器人不是部署一次模型就能结束。门店位置、活动时间、出入限制、库存和交通信息一旦变化，回答知识也必须同步更新。自信地复述旧信息，往往比无法回答更容易误导访客。运营KPI应包含内容修改后的生效时间、来源过期时是否停止作答，以及发现错误导览后恢复上一版本所需的时间。
摄像头和麦克风带来的数据边界同样需要写清。用于避障的视频与用于访客分析的视频，保存目的并不相同。应确认是否保留人脸和原始语音，语音识别是否把数据发送到外部服务器，儿童与员工数据如何区分，以及管理员的检索、导出、删除权限和访问记录。机器人转交人工时，也要决定是传递完整对话，还是只传递必要请求。缺少这些运营设计，即使世界模型和动作库表现出色，实际服务范围仍会受限。
常见问题
Walker C1和Walker S2可以按同一套指标选型吗？
不建议。C1应重点核验接待任务闭环、安全停车和转人工，S2则更看重产线节拍、载荷、换电与连续运行。
采购Walker C1前，报价单至少要拆出哪些项目？
除本体外，还应分别确认充电设施、SDK或开发许可、系统集成、内容制作、远程监控、培训、备件、质保响应和目标国家支持范围。官方页面目前未给出统一公开售价及各国交期。
如何验证Walker C1的3m/s能力不会放大人群风险？
3m/s是能力上限。应在儿童突然穿行、行李遮挡、扶梯入口拥堵等场景中测减速、停车距离和机身稳定性，并由运营方设置更低的现场限速。
已核验的官方资料
最后核对：2026年8月23日