NAVER 1784 如何运营约100台机器人

NAVER 表示，1784 大楼内每天约有100台 Rookie 服务机器人穿梭于不同楼层，配送咖啡、包裹、午餐等物品。要达到这一规模，机器人、ARC、Roboport、订单系统和楼宇基础设施必须共享任务与状态。

官方披露的6万次以上配送来自对1,000天运营的回顾，是长期运行证据，但不是独立审计的成功率。东京 Midtown Yaesu 已部署 ARC，而2026年底前扩展至所有楼层仍属于计划，两种状态不能合并描述。

约100台机器人背后有五个不同角色

NAVER 的机器人技术官方页面称，1784 内约100台机器人通过云端控制提供多种服务。Rookie 负责搬运；ARC brain 处理移动、定位和任务规划；ARC eye 利用数字孪生与定位 AI 估计位置；ARC mind 提供基于 Web 的机器人服务操作层。

单机避障只是其中一环。车队还要根据距离、拥堵、电量与优先级分配订单，多机器人任务分配指南解释了这一层决策。1784 还要把电梯、服务点与收件通知纳入同一个流程，所以最短路线不一定是全局最优任务。

1784 官方服务页分别介绍 Rookie、Roboport、ARC System 与办公助手。订单先变成包含物品和目的地的任务，ARC 选择机器人和路线，Roboport 支持跨层移动，通知系统再引导用户取件。电梯与门禁因此也是配送系统的一部分。

AMR 与 AGV 选择指南能解释自由导航和固定引导路线的差别，但能自主移动不等于能稳定运营百台车队。订单取消、电梯排队、通信中断、无人取件和恢复责任都要被记录。

NAVER 的1784 运营1,000天记录称，约100台机器人每天在楼内运行，已完成6万次以上配送，覆盖便利店商品、咖啡、包裹、午餐盒和个人物品交换。相比展会短片，这更能说明多种服务被长期重复使用。

页面没有同时披露总订单数、失败次数、配送时长中位数、恢复时间或人工介入比例。因此不能把6万直接换算成可靠性。采购方应要求统一失败定义、繁忙时段、服务窗口和异常分类，并明确这是 NAVER 自报的累计数据。

ARC eye 使用数字孪生数据辅助定位。日本项目的官方说明也提到，团队先创建建筑数字孪生，定义路线与服务点，再由 ARC 连接服务系统、楼宇设施和运营控制。它提供了机器人与建筑共同使用的空间参照。

建立数字孪生不等于完成控制测试。虚拟调试与数字孪生的区别提示我们，还要测试电梯冲突、封闭通道、定位陈旧、无线断连和交付延迟等异常场景。

NAVER 于2026年7月23日发布的ARC 日本部署文章确认，ARC 已进入东京 Midtown Yaesu。团队针对既有商业建筑调整了电梯、路线、下单和通知方式，这说明方案已走出 NAVER 自有大楼。

同一文章把所有楼层的机器人配送写成2026年底前的扩展计划。截至2026年8月7日，不能据此称全楼层已经完成。当前部署、现有覆盖范围和未来扩展应分开记录，机器人数量与最终楼层覆盖需要后续官方信息。

实施团队应先梳理电梯 API、门禁、无线盲区、充电位、消防疏散路线、订单接口与故障责任，再决定机器人数量。若混用不同厂商设备，还要定义任务、状态、地图和通行优先级的共同接口。

验收不能只跑正常配送，还应加入电梯停运、目的地变化、无人取件、走廊封闭、网络中断和低电量。1784 证明 ARC、Rookie、Roboport 与楼宇服务可以形成长期运营体系，但并不保证另一栋楼无需重新集成就能达到同样吞吐量。

官方资料称每天约100台机器人在楼内运行，但未披露同一时刻在线数量或分时利用率，需用额外运营数据确认。

不是。ARC 是连接机器人、空间、服务和运营的多机器人平台；Roboport 是支持机器人跨楼层移动的专用电梯。

2026年7月官方文章确认 ARC 已部署，但把全楼层配送描述为年底前的扩展计划，完成状态仍需后续确认。

2026-08-07