Reference · Company dossier
山景城的机器人编排（robot orchestration）软件公司，以 InOrbit Space Intelligence 把多品牌机器人、企业系统与空间数据统一调度，定位为"物理世界的操作系统"。[确认]
2017 年由 Florian Pestoni（CEO）、Julian Cerruti、Mario Munich 在加州山景城创立；Pestoni 长期推动 "RobOps"（机器人运维）品类，并参与创立 Robot Operations Group。[确认-第三方] Cerruti 为联合创始人、现董事，2024 年 1 月 Ramiro Diaz Trepat 以 AI 负责人身份加入，现任 CTO，主导 RobOps Copilot。[确认] 团队规模第三方口径为 11–50 人或 30–60 人，官方未披露。[确认-第三方] 总部位于山景城 Castro St。[确认]
2020 年 7 月种子轮 260 万美元，ANIMO Ventures 领投，Yamaha Motor Ventures、Kärcher New Venture、Motus Ventures、Berkeley Angel Network、Creative Destruction Lab 等参与。[确认] 2025 年 9 月 30 日 A 轮 1,000 万美元，L'ATTITUDE Ventures 与 Globant Ventures 共同领投，ANIMO、Kärcher、Yamaha 等老股东跟投；第三方统计累计约 1,260 万美元。[确认] 2024 年入选 Google for Startups Founders Fund（AI 方向），第三方记为 15 万美元资助。[确认/第三方] 估值未披露。[未获取]
旗舰产品 InOrbit Space Intelligence：跨品牌机器人、IoT 与设备的统一编排，含 Business Execution System（把 WMS/ERP/MES 订单翻译为机器人任务）、实时空间感知与交通管制、任务去冲突、远程干预与运营分析。[确认] RobOps Copilot 为自然语言与语音交互的 agentic AI 层，可查询机队状态并下发操作。[确认] 开发者侧为 Ground Control（机器人厂商的部署与机队管理平台）；2026 年 3 月产品线重组为 Space Intelligence、Ground Control、OpenRobOps 三层。[确认-第三方] OpenRobOps 以 Apache 2.0 开源，号称首个 ISO 21423 参考实现。[确认]
InOrbit 的平台是云端多租户 SaaS，边缘侧在机器人或现场网关运行连接器，云端负责接入、状态存储、任务编排与可视化[确认]。接入层支持 VDA-5050、Open-RMF 与 MassRobotics AMR Interop 三种互操作规范，也接受厂商私有协议[确认]。数据面提供 REST 与流式接口，业务面通过连接器对接 WMS、ERP、WES、MES 与 RTLS[确认]。2026 年 3 月的产品线重组把平台分为 Space Intelligence、Ground Control 与 OpenRobOps 三层，分别面向企业运营、机器人厂商与开源社区[确认]。
一条典型数据流是：WMS 下发订单，Business Execution System 把订单翻译成机器人任务，编排引擎按位置、电量、载具与优先级分配机器人，交通管制模块检查路径冲突并给出等待或改道指令，机器人执行后回传状态，运营看板与 Copilot 读取同一份状态[推测]。平台保留任务与事件的历史记录，提供告警、审计与回放，运营人员据此定位停机原因[确认]。控制回路的时延由网络与机器人接口决定，跨品牌车队里通常只能做到秒级，适用于仓储与产线，不适合高速运动控制[推测]。
平台自身不产传感器，感知能力来自接入的机器人：激光雷达、深度相机、二维码与 SLAM 位姿由本体提供，InOrbit 消费的是位姿、地图、电量、任务状态与事件流[确认]。空间理解的核心是把不同厂商的坐标系注册到同一张现场地图，再把机器人、门、电梯、充电桩与工位标在同一套坐标里[推测]。标定误差会让交通管制误判，地图更新依赖现场重新扫描，布局调整频繁的仓库需要定期维护[推测]。
失败模式包括位姿漂移、地图版本不一致、网络抖动与时钟不同步。位姿漂移让两台机器人在同一通道里互相看不见，地图版本不一致让禁行区失效，时钟偏差让事件顺序无法还原[推测]。平台的处理方式是设置安全距离、限制同区机器人数、保留人工接管[推测]。网络中断时连接器缓存本地状态，恢复后补传，缓存窗口有限，根因仍由本体厂商解决[推测]。替代方案是让每家厂商自建车队管理，代价是多套系统并存、跨品牌任务无法统一调度[推测]。
编排层的规划分任务级与路径级两段：任务级决定谁去做、什么时候做，路径级决定怎么走、在哪里让行[推测]。交通管制用预约表与区域锁，机器人进入路口前申请通行权，离开后释放，死锁靠超时回退与人工干预解除[推测]。充电调度把电量、任务间隙与峰值电价纳入排程，减少闲置与排队[推测]。
控制精度受限于本体接口。VDA-5050 一类标准定义了任务下发与状态回传的消息集，底层速度环仍由机器人控制器执行[确认]。跨品牌的动作语义差异需要适配层统一，例如到站判定条件、举升高度与对接精度[推测]。异构车队的任务语义由适配层翻译，新增车型需要重新验证举升、对接与避障行为，集成周期以周计[推测]。失败模式是优先级反转与低优先级任务饥饿：高优先级订单持续插入，清洗与补货任务长期得不到执行，平台用配额与老化机制缓解，效果依赖参数调校[推测]。
数据侧以机队遥测与运营事件为主：位置轨迹、任务时长、故障码、人工接管记录、充电与等待时间[确认]。这些数据用于异常检测、利用率分析与容量规划，也用于训练 RobOps Copilot 的自然语言查询与操作建议[确认]。平台不训练机器人本体策略，模型能力集中在运维问答、根因定位与任务优化[推测]。
跨客户的运营数据是潜在的差异化来源，前提是聚合与脱敏[推测]。客户对生产数据的授权范围有限，跨现场迁移学习存在合规与商业障碍[推测]。平台对不同客户的数据分域存储，跨客户的基准对比只使用匿名聚合值[推测]。告警规则仍以阈值与人工配置为主，误报率随设备数量上升[推测]。替代方案是客户自建 BI 与规则引擎，成本低、定制深，缺少跨品牌适配[推测]。验证边界在单站点内部的指标改善，跨站点、跨行业的泛化缺少公开评测[未获取]。
公司不生产硬件，成本结构以云基础设施、研发与交付人力为主[推测]。边缘连接器跑在客户的工控机或机器人控制器上，硬件成本由客户承担[推测]。部署需要现场勘测、地图标定、系统对接与培训，项目周期以周计，服务收入占比高[推测]。云侧依赖公有云的区域可用性，数据驻留要求会限制统一架构的复用[未获取]。
供应链风险转移到合作方：机器人厂商的接口变更、固件升级与停产会影响连接器的可用性，30 多个品牌的适配需要持续维护[推测]。公司规模第三方口径为 11 至 50 人，另有 30 至 60 人一说，A 轮 1,000 万美元，难以同时支撑多行业交付与产品研发[确认]。
接口与生态是这家公司的核心资产。开发者侧有 REST API、SDK 与 Webhook，机器人厂商通过 Ground Control 做部署与机队管理，企业侧通过 Space Intelligence 接入业务系统[确认]。OpenRobOps 以 Apache 2.0 开源，官方称是首个 ISO 21423 参考实现，A3 的互操作演示联合了 Ati、Kärcher、Neura、Omron、Peer、Quasi 与 Unitree 等厂商[确认]。
接入方式分三条路径。机器人厂商在连接器里实现状态上报与任务接收，消息体按 VDA-5050 或私有协议映射；企业侧通过 REST 与流式接口订阅任务与事件，Webhook 把告警推到工单系统；现场设备需要账号绑定与站点级权限，运营人员的操作权限按角色划分，下发任务的权限与查看权限分开配置[推测]。第三方要接入，需要按连接器规范实现协议适配，并通过平台的兼容性验证，验证清单未公开[未获取]。
标准话语权提高了采用意愿，锁定效应有限。开源实现降低了新厂商的接入成本，也降低了客户更换编排层的成本[推测]。生态的薄弱处在于开发者数量与第三方应用，平台没有形成应用商店式的分发渠道，集成工作仍由 InOrbit 或 Globant 交付[推测]。部署形态支持公有云与客户专有环境，专有部署的运维成本高于多租户版本[推测]。
网络效应成立，形态为间接网络效应。每增加一个机器人品牌，平台对多品牌车队的价值上升；每增加一个采用 OpenRobOps 的厂商，标准的分量上升[推测]。30 多个品牌的生态与数百万小时运营是现有证据，客户从单品牌扩到多品牌时，编排层的价值才显现[确认]。
转换成本成立。编排层接入 WMS、ERP 与现场地图，替换需要重新对接与重新标定，停线风险让客户倾向续约[推测]。
流程能力成立。现场勘测、地图标定、协议适配、系统联调与培训构成一套交付流程，30 多个品牌的适配经验记录在交付流程里[推测]。新增车型的集成周期以周计，流程效率是签单时的实际卖点[推测]。
反定位成立。本体厂商的车队管理系统只服务自家设备，云厂商的通用编排服务在 2024 年 3 月退出，AWS IoT RoboRunner 退役，中立层的位置现有厂商不愿意承担[确认]。
规模经济不成立。交付仍以项目制为主，人力投入随站点线性增长[推测]。
品牌证据不足。InOrbit 在机器人圈有认知，在企业 IT 采购里影响有限，品牌溢价无法从合同数据验证[推测]。
独占资源不成立。ISO 21423 参考实现是公开代码，可被复制，平台没有排他性权利[推测]。
成立的四项集中在中立接入与标准参与。强度中等，证据缺口在续费率与毛利率[未获取]。
本体厂商的反证。观察窗为 18 个月，指标为 OTTO、MiR、Geek+ 等厂商的 API 开放程度与客户的多品牌比例。若头部厂商开放车队接口并联合第三方做跨品牌调度，中立编排层的价值被压缩[推测]。
云厂商的反证。观察窗为 24 个月，指标为 AWS、Google 是否推出托管的多品牌编排服务。若云厂商把消息、地图与任务编排做成标准产品，InOrbit 的差异化只剩行业模板与交付[推测]。AWS IoT RoboRunner 在 2024 年 3 月退役，说明通用服务难做，云厂商重新进入的方式可能是收购[确认]。
开源的反证。观察窗为 12 个月，指标为 OpenRobOps 的部署量与付费转化率。若开源实现被广泛采用，客户可以自建或由系统集成商交付，付费版的溢价需要靠 Copilot 与运营分析维持[推测]。
规模的反证。观察窗为 12 个月，指标为 ARR、净收入留存率与单客户部署成本。若累计 1,260 万美元的融资无法支撑到订阅收入覆盖交付成本，公司会被迫收缩行业范围[推测]。
需要补齐的证据包括 ARR、净收入留存率、单客户部署成本、30 多个品牌里真正产生收入的比重[未获取]。
官方称机器人在四大洲运行、平台累计支撑数百万小时生产运营；企业客户包括 Colgate-Palmolive 与 Genentech（Roche 集团），早期客户有 Bossa Nova。[确认] 2026 年 6 月 Automate 展与 A3 合作，联合 Ati、Kärcher、Neura Robotics、Omron、Peer Robotics、Quasi Robotics、Unitree 等厂商做首次公开的联邦式多品牌编排演示（官方称 8 家企业参与，含 InOrbit 自身）。[确认] 渠道以机器人厂商 OEM 合作加企业直销为主，Globant 的战略投资带来企业集成与交付渠道。[推测]
直接对手是 Formant（数据与可观测更强）、Zebra 旗下的 Freedom Robotics（2023 年 8 月被收购，偏设备管理）；此外各本体厂商自带的 FMS（OTTO、MiR、Geek+）与 ROS 开源工具链也是替代方案。[确认/推测] 云侧 AWS IoT RoboRunner 已于 2024 年 3 月退役、AWS RoboMaker 收缩，反而留下第三方中立编排层的空位。[确认] 与 Formant 相比，InOrbit 更强调跨品牌任务编排与企业系统集成，Formant 更强调数据记录与遥操作。[推测]
风险：累计融资仅约 1,260 万美元，与企业级长销售周期、重交付的节奏不匹配；编排层价值依赖客户已部署多品牌机器人，单品牌大客户容易被厂商自建系统截流；OpenRobOps 开源可能稀释付费版；收入、续费与盈利均未披露。[推测] 结论："机器人界的 Kubernetes"叙事清晰，标准与生态动作领先于体量，但商业化仍处早期，需观察 A 轮后能否把 30 多个品牌的生态转成可复购的企业订阅收入。[推测]
Philosophy sword
融合主轴尚未定义。这里将放：一句话定性、三线状态、三项判定与反证条件。
预留位 · 不参与当前分析