Fujitsu、FANUC、Yaskawa、Kawasaki和NVIDIA并没有宣布一款完成的共同机器人或合资公司。2026年7月启动的合作仍处于研究阶段，目标是用主权、开放的控制底座连接不同企业的机器人和设备，并评估制造、物流和医疗场景中的商业机会。产品名、价格和上市日期均未确定，真正价值要等多厂商现场验证和标准文件出现后再判断。
五家公司目前达成的是共同探索与底座开发方向
Fujitsu 2026年7月16日官方发布称，已与FANUC、Yaskawa Electric和Kawasaki Heavy Industries开始探索具身智能（Physical AI）商业机会。Fujitsu牵头讨论，计划整合NVIDIA开放式Physical AI技术，开发连接数字世界和物理世界的协同控制平台。
发布中的关键词是“explore”，即研究和探索。确认共同开发方向，不代表共同人形机器人已经量产、付费客户合同已经签署或方案已成为国际标准。各公司的合同条款、知识产权、具体产品和支持日程仍需后续文件。
| 参与方 | 官方发布显示的资产 | 仍缺少的证据 |
|---|---|---|
| Fujitsu | AI、计算、数据、安全，并牵头协同控制平台讨论 | Physical OS的提供范围与版本 |
| FANUC | 工业机器人、AI功能、支持ROS 2与Python的开放平台 | 接入共同平台后的客户现场验证 |
| Yaskawa | MOTOMAN NEXT、i3-Mechatronics和ROS 2支持 | 机器人、伺服与上层AI的责任边界 |
| Kawasaki | 工业机器人、运营数据和医疗集成经验 | 医院业务中的安全与隐私验证 |
| NVIDIA | Cosmos、Omniverse、Isaac和Newton | 工具使用之外的重复性能与成本 |
Fujitsu想建立的是业务系统与机器人控制之间的共同层
工厂里，生产计划、安全PLC、机械臂、AMR和检测设备往往各自独立；医院里，处方、样本、挂号系统和搬运机器人也分开。Fujitsu所说的协同控制底座，可以理解为把业务应用的目标拆成多台机器人和设备可执行的任务，再把结果返回上层系统。
Fujitsu其他技术战略材料中所称的Physical OS也位于这一层。它需要连接表达人员、物体和设备状态的世界模型、任务规划器、各厂商控制接口以及数据和安全政策。但当前官方发布描述的是研发方向，并未确定公开API、支持设备清单、时延保证或价格。
即使有共同层，也不应取代设备内部全部实时控制。上层AI可以下达“把零件送到下一工序”，但关节扭矩、急停和安全区仍应由各厂商经过认证的控制层优先处理。若没有文档规定命令冲突时谁有否决权，开放集成反而可能成为新的单点故障。
FANUC、Yaskawa和Kawasaki解决的并不是同一种机器人问题
FANUC强调制造现场的工业机器人和开放平台连接。官方高管发言提出支持ROS 2和Python，并与Fujitsu自主AI平台结合。关键是能否在保持既有生产单元稳定性的同时，灵活接受上层规划。
Yaskawa把2017年提出的i3-Mechatronics和数据自动化经验、标配NVIDIA GPU的MOTOMAN NEXT以及ROS 2支持连接起来。它不仅有机械臂，还掌握运动与伺服层数据，现场要验证上层模型的慢推理与毫秒级控制在哪里分界。
Kawasaki强调多种工业机器人、现场运营数据和医疗应用，并提到把住院、诊疗、手术和康复连接起来的医院集成设想。但患者、样本和药品同时存在的环境，在安全、责任和隐私上比普通物流严格，医院演示不能等同于医疗机构长期运营。
NVIDIA技术栈辅助训练、仿真和开发，不直接证明现场结果
官方合作文件列出NVIDIA Cosmos基础模型、Omniverse库、Isaac开放平台和Newton物理引擎。Cosmos面向真实环境理解与社会、物理仿真；Omniverse和Newton用于物理虚拟环境与验证；Isaac则连接机器人训练、开发和部署。
NVIDIA官方机器人平台把训练、仿真和推理拆成不同计算层。这些工具可能缩短开发时间，却不能证明某台FANUC、Yaskawa或Kawasaki机器人已经通过客户任务。必须附上模型与库版本、仿真条件、实体重复次数和人工介入。
Fujitsu Physical AI Technology Strategy把空间世界模型和多机器人协作放入长期技术路线。战略文件说明“准备做什么”，不能当作当前可交付功能表。
制造、物流和医疗会用不同失败条件考验共同平台
Fujitsu列出的初期场景包括制造、零售物流和医疗。工厂侧希望根据生产变化和现场状态优化计划；物流侧连接销售、库存与物料搬运；医院侧则考虑药品、样本运输和接待引导。
场景一变，失败含义也会改变：工厂停机会造成产量损失，物流故障带来订单延误与集群拥堵，医院送错药品或样本则涉及安全与责任。通过共同API并不等于已经满足三个行业的全部运营要求。
| 应用场景 | 需要连接的系统 | 必须测试的失败条件 |
|---|---|---|
| 制造 | 生产计划、机械臂、检测和安全PLC | 紧急计划变更与安全控制冲突 |
| 物流 | 销售库存、AMR、门和电梯 | 一个集群故障阻塞其他厂商机器人 |
| 医疗 | 医院运营、药品样本运输和引导 | 患者识别错误、敏感数据泄露、阻塞急救通道 |
| 共同层 | 模型、接口、日志和升级 | 签名错误、断网和部署错误版本 |
“开放”和“主权”并不矛盾
开放平台的目标，是让参与企业和研究机构使用共同接口并扩展能力，不是允许任何人无限制地控制机器人。必须有调用方认证、角色权限、签名软件、安全门控和审计日志。
主权控制也不只是把数据存放在日本境内。它还包括谁能查看生产或患者数据、能否用于训练、谁批准或拒绝模型升级、事故日志由谁保存和删除。服务器位置满足要求，但运营权限完全交给外部，也不能算完整的数据主权。
发布还指出，机器人应用扩大后，网络攻击、系统中断、误动作和机密泄露风险会上升。多厂商平台方便连接，也可能让一个账户或升级问题扩散到多台设备，因此要设计设备群隔离、回滚和离线安全运行。
标准化最终要靠多厂商适配性测试，而不是一份接口文档
Fujitsu表示将同时推动协同控制底座的标准化和开放。即使标准草案公开，若不同厂商机器人仍无法在真实现场完成同一任务，互操作性也没有得到验证。
好的试点会把FANUC机械臂、Yaskawa设备、Kawasaki系统和其他公司的AMR放在同一现场，共享任务预约、地图、安全状态和故障恢复；再故意升级或停掉一台，观察其余设备是否安全绕行。还应注入时延、拒绝命令、版本不一致和日志缺失。
现场连接可参考Open-RMF多机器人协同，集群命令规范见VDA 5050 3.0标准解读，定位见VIO与SLAM对比。这项合作与现有标准是竞争还是互补，也要等详细规格公开后再判断。
合作能否成功，要看共同客户现场是否出现可重复结果
下一次更新最值得看的是两家以上厂商的机器人在同一客户现场反复执行任务。除任务成功率，还应公开介入率、集群拥堵时间、故障隔离、旧版本恢复和数据访问记录。
其次是商业证据：付费试点、客户、上市日程和支持组织出现后，才能说合作从探索进入产品阶段。第三是标准产物：接口、安全、数据主权规范和适配性测试流程，必须详细到外部参与者可复现。
五家知名企业聚在一起只是起点。长期价值在于证明：不同代际和不同厂商的机器人能够安全互联，同时客户仍保有数据与运营控制权。
常见问题
五家公司已经决定联合推出人形机器人了吗？
没有。官方发布确认的是探索Physical AI商业机会和开发协同控制底座，联合产品的型号、价格和上市日期尚未确定。
开放接口意味着外部人员都能控制机器人吗？
不是。共同接口仍需要身份认证、角色权限、安全门控、软件签名和审计日志；开放与无限制控制是两回事。
主权数据只要求服务器放在日本吗？
不止。还包括数据访问、训练复用、升级审批以及日志保存、删除和审计权限由谁控制。
已核验的官方资料
最后核对：2026年8月23日