← 返回首页
2026-04-16 · Robotics / Physical AI / Simulation Developer Tools
RealityForge
把机器人团队原本要去仓库、道路和封闭测试场里反复试错的那些周,压缩成一条可复现、可回放、可量化放行门槛的仿真发布工作台。
潜力评分 93/100
新闻来源
This simulation startup wants to be the Cursor for physical AI
Antioch 融资 850 万美元去做 physical AI 的高保真仿真平台,核心不是再卖一个『更像游戏引擎的 3D 工具』,而是试图把机器人公司最贵、最慢、最危险的那段工作流程——从现实环境采数、制造边界条件、验证传感器行为,到判断模型能不能真的上车/上路/上仓——重做成一条可迭代的工程操作面。真正值得下注的机会,不是做一个泛用 simulation editor,而是先做一层让感知、控制、安全与现场运营团队每天都能用的『sim-to-real 发布台』:把哪些场景还没覆盖、哪些传感器组合还不可信、哪一次模型更新会在哪类真实环境里翻车,说清楚。
查看原文 ↗
为什么值得做
这件事现在值得做,是因为 physical AI 正在遇到和软件工程前几年极其相似、但代价更高的瓶颈。第一,自动驾驶、仓储机器人、施工设备、农业机械和无人机都在加速上模型,但真实世界数据依然昂贵、稀缺且充满偶发边界条件;很多团队仍要靠临时搭建测试场、反复外场采集和少量高成本事故复盘来推进迭代。第二,新闻里明确点到 Waymo、DeepMind、Nvidia、World Labs 等生态信号,说明世界模型、传感器仿真和合成数据这几块底层能力开始成熟,已经足以让更多中小团队把仿真从研究附件变成日常工作流。第三,physical AI 的问题不是“模型会不会答题”,而是“它在雨天、反光、遮挡、设备老化、路线变化、载荷不同的时候会不会出事”;这类问题天然需要一条持续回归、能对照现实误差的仿真发布流水线。窗口期就在于:大量团队都知道应该更早做 simulation,但还没有一个轻量、工程导向、足够贴近日常迭代节奏的操作台。
RealityForge 不是从『做更炫的 3D 场景』切入,而是从『哪一个真实世界任务还不能放心放行』切入。它把仿真从一个专家工具变成跨团队共享的发布介面:感知工程师可以标记传感器盲点,安全负责人可以定义上线闸门,现场运营可以反馈真实失效条件,产品经理则能看到新客户场景还缺哪些验证证据。产品的中心不是“建模”本身,而是“把现实世界的失败模式组织成一个可被工程团队持续消费的资产库”。这样做的好处是,团队不必一开始就追求完美物理世界,而是先围绕最贵的几个场景——比如仓库拐角会车、夜间雨天反光、叉车穿行、临时障碍物——建立仿真覆盖、误差账本和放行标准。
Problem
要解决什么问题?
今天多数机器人和 physical AI 团队真正卡住的,不是没有模型,而是缺少一条稳定、低摩擦的方法,把『现实世界会出问题的地方』持续变成训练、测试和发布决策。新客户现场一变化,团队就要重新采数据;传感器一升级,旧的边界条件又得重跑;出了问题之后,复盘往往散落在 Slack、工单、视频片段和工程师个人记忆里。结果是:仿真和真实部署彼此脱节,训练和安全验证彼此脱节,产品团队也很难回答“我们到底还差什么证据才能上线下一站点”。这不是单纯缺一个仿真引擎,而是缺一个把场景、传感器、误差、任务风险和发布门槛串起来的工作系统。
目标用户
在做仓储机器人、自动驾驶、工业车辆、农业机械、无人机或园区巡检机器人的 early-stage / growth-stage physical AI 团队 负责感知、控制、安全验证与现场部署协同,但没有预算自建完整仿真基础设施的 robotics engineering leader 与 platform 团队 需要向客户、内部安全委员会或商业团队解释“为什么这一版可以上线、为什么下一版还不能放行”的机器人产品与运营负责人
Signals
来自新闻的关键信号
TechCrunch 报道 Antioch 获得 850 万美元种子轮,说明“sim-to-real gap”已经从研究议题变成值得独立融资的工程基础设施赛道。 报道明确指出大量机器人团队没有资本去自建测试场、跑海量里程或搭完整仿真栈,这意味着市场需要的是更轻、更工程导向的仿真操作层,而不是只服务巨头的重型平台。 Antioch 把自己类比为 physical AI 的 Cursor,释放了一个重要信号:下一代工具不会只帮团队“看结果”,而是要直接进入开发循环,成为日常迭代入口。 文章点到 Waymo、DeepMind、Nvidia、World Labs 等生态,说明底层世界模型与传感器仿真能力开始足够成熟,应用层可以更聚焦 workflow 而不是从零发明全部底座。 Antioch 让团队同时生成训练数据、测试 edge cases 和做强化学习实验,说明未来赢面不在单点合成数据,而在把训练、验证、回归测试和发布判断打通。 其早期客户既有 startup 也有大型跨国企业,说明这不是“只有科研团队才用”的 niche capability,而是会进入真实交付和安全责任链的产品。
如果一个轻量的 sim-to-real 发布台能让 physical AI 团队在不重建整个数字孪生体系的前提下,快速导入现场素材、生成高优先级边界条件、对照仿真和真实世界误差,并把这些结果直接挂到模型版本与上线决策上,那么自动驾驶、仓储机器人、工业与现场机器人公司会愿意先把它作为现有训练/测试流程前的一层操作面来试用,因为它替代的不是抽象的“AI 平台”,而是每周都在重复、且一次判断失误就可能造成停机、事故或客户流失的验证工作。
场景克隆台
把现场视频、传感器日志、地图片段、工位照片与文字备注快速整理成可复用场景包,先从最关键的作业区域和失败片段开始克隆,而不是要求团队一次性建完整数字世界。
传感器真值对账板
对比仿真输出与真实相机、激光雷达、深度传感器或 IMU 数据在关键任务中的偏差,按天气、光照、速度、遮挡、载荷与设备版本拆出误差账本,帮助团队知道“像不像”差在哪里。
边界条件工坊
围绕真实事故、near miss 和现场抱怨,一键生成高优先级 edge cases,例如反光地面、临时障碍、窄道会车、低电量、叉车横穿或传感器污损,并把这些条件挂到回归测试集合。
发布闸门时间轴
把每个模型版本在关键场景下的通过率、失败类型、人工豁免、客户现场备注与上线决定串成时间轴,让安全负责人和产品负责人都能看到“这次为什么能发、为什么不能发”。
Interactive demo
三种最先能打动市场的使用场景
点击不同场景,查看从体验入口到北极星指标的 MVP 路线。
仓储 AMR 团队为新客户站点做上线前验证 自动驾驶/园区车团队处理传感器升级后的回归风险 施工或工业机器人团队做事故复盘到发布标准沉淀
Use case
仓储 AMR 团队为新客户站点做上线前验证
最贵的不是仿真没做,而是车已经进仓之后才发现拐角反光、临时堆货和叉车混行让模型在最关键的 5% 场景里失真。
客户交付前,实施团队把仓库视频、平面图、货架尺寸和典型作业流导入 RealityForge,快速生成站点场景包 系统根据历史失败模式自动补出高优先级边界条件,如反光地坪、窄通道会车、叉车临时横穿与光照变化,并批量跑回归 感知负责人在发布闸门时间轴中查看新模型对关键任务的通过率与偏差,确认达到门槛后再批准站点上线
北极星指标:新站点上线前发现的高风险场景数 / 首月因感知问题导致的现场人工接管率
Use case
自动驾驶/园区车团队处理传感器升级后的回归风险
硬件一换,最怕不是模型完全失效,而是它只在夜间雨后、逆光弯道或低速近距离目标上悄悄变差。
团队导入新旧传感器配置和历史真实日志,RealityForge 自动建立可对照的仿真实验矩阵 传感器真值对账板按光照、天气、车速与目标类别对比误差,标记哪些场景需要补采真实数据、哪些场景可先靠仿真回归 安全负责人基于误差趋势和关键案例决定是否允许该硬件组合进入下一轮封闭道路测试
北极星指标:传感器升级后的关键场景误差收敛时间 / 进入真实道路测试前的问题发现率
Use case
施工或工业机器人团队做事故复盘到发布标准沉淀
真正有价值的不是做完一次事故复盘,而是让那次险情变成以后每个版本都必须通过的发布门槛。
现场团队把 near miss 视频、工单、操作者描述和环境照片上传为事件包 系统将事件拆成可仿真的关键变量,例如人员突然进入、地面坡度、粉尘遮挡、设备振动与载荷变化,并加入边界条件工坊 后续每次模型更新都会自动重跑该事件簇,只有在连续通过预设门槛后,版本才会从候选状态切换为可部署
北极星指标:重大 near miss 转化为长期回归用例的比例 / 同类问题重复发生率
Stack
当前技术栈
先用静态页面验证“sim-to-real 发布台”这个切口是否比传统数字孪生叙事更打动 robotics founder、perception lead 与 safety owner,再收集 demo 预约和场景上传意向。 前端优先做任务导向的 Web 控制台,而不是复杂 3D 编辑器首页;首页突出场景包、失败模式、传感器误差和发布闸门四个工作对象。 后端用 Postgres 或 Supabase 管理场景包、模型版本、传感器配置、事件簇、实验结果、人工豁免与审计日志。 仿真层优先集成现成引擎与世界模型底座,例如 Nvidia Omniverse、Isaac Sim、Habitat、AirSim 或自定义渲染服务,把产品重心放在 workflow orchestration。 数据层支持导入 ROS bag、视频片段、地图切片、工单文本与站点照片,并生成可追踪的数据 lineage,帮助团队知道每个场景来自哪里、服务于哪个放行决定。 AI 层重点做三件事:从真实事件自动抽取可仿真变量、为回归测试生成高价值 edge cases、把失败结果翻译成工程与运营都能理解的发布建议。
Risks
主要风险
如果仿真精度不够,团队会很快把产品视为“漂亮但不可信”的演示工具,因此必须先围绕少量高价值场景建立可信度。 不同机器人形态、传感器栈和任务环境差异极大,若产品一开始试图通吃所有 physical AI 场景,实施成本会失控。 工程团队已经在用各类仿真或数据工具,若无法顺滑接入现有日志、训练和测试流程,RealityForge 可能被视为额外负担。 安全与上线决策一旦被产品介入,就需要很强的审计性与责任边界设计;如果“建议”与“批准”界限不清,会造成组织阻力。 真实世界数据往往含客户现场、设备布局和人员信息,若权限、脱敏和共享边界设计不好,企业客户不会放心上传素材。
Next steps
如果继续迭代,接下来做什么
先聚焦一个最容易形成标准化失败模式库的垂直场景,例如仓储 AMR 或园区无人车,围绕 20-30 个高频高损失 edge cases 做深。 增加“真实事件到仿真用例”的自动转换能力,把 near miss、客服升级单与现场视频直接变成可回归测试的事件簇。 把发布闸门与 Git、ML 实验平台、ROS/仿真任务调度和工单系统连起来,让 RealityForge 真正进入工程团队的周迭代节奏。 进一步扩展到客户交付阶段的“站点上线 readiness report”,让销售、实施与客户成功团队也能消费同一套验证证据。