具身智能成为大模型浪潮之后备受关注的 AI 方向，也在借鉴大模型产业走过的路。

大模型通过 API 开放底层能力，逐渐形成模型厂商提供基础模型、SaaS 厂商和开发者负责具体应用的分工。

开发者不必从零训练模型，就能基于已有能力开发产品；模型厂商也不必亲自完成所有行业应用。

类似的变化正在具身智能行业出现。

Physical Intelligence 于 10 月 13 日开放 Pi API Beta，支持开发者上传机器人数据、使用云端算力微调模型；Dream Labs 推出 Dream-1 公共 API，强调零样本泛化。

不同企业开始尝试把具身模型做成外部开发者可以使用的服务。

但具身智能能否复制大模型的 API 模式，行业仍有分歧。

一种观点认为，机器人本体的机械结构、传感器和控制方式差异巨大，跨本体适配需要大量工程投入，很难形成标准化服务。

另一种观点则认为，具身智能不能长期停留在逐个项目定制交付的阶段，模型厂商可以开放基础模型和后训练能力，让本体厂商、集成商和开发者负责具体应用。

争论背后还有一个更大的问题：具身智能的经济账，究竟应该怎么算？

有人主张看模型调用量，以消耗的算力与模型服务来计量；有人主张看有效智能工时，用活跃机器人数量与产出效能比衡量劳动

原力灵机则更直接地看机器人日活（DAR），关注有多少机器人真正进入场景、持续承担任务。

机器人要先在岗，才谈得上调用量和有效工时；模型要持续被调用，也必须有真实任务支撑。日活，是检验这件事有没有发生的第一个信号。

今年 7 月发布 Dexmal MaaS 的原力灵机，这次升级就是从后训练和真机验证入手，尝试让更多客户把模型用到自己的机器人上。

1、具身 MaaS 到底难在哪里？

大模型 API 能快速铺开，一个重要原因是文本、图像等数字信息有相对统一的表达方式和交互接口。模型接进来，接口对上了，开发者通常就可以开始构建应用。

具身模型面对的却是物理世界。不同机器人的构型、自由度、末端执行器、相机、传感器和控制接口各不相同。

模型即使学会了抓取、放置等通用操作，也未必能直接迁移到另一台机器人上。换一个本体，可能意味着新的坐标系、动作空间、控制参数和数据分布，模型需要经过训练和调试才能适应。

这也是具身 MaaS 遇到的第一道门槛。行业里对跨本体泛化的一个主要顾虑是，机器人本体种类太多，模型即使覆盖五六种机器人，背后也可能已经投入了大量适配工作。

如果每增加一个客户、一个机型，都要重新做数据采集、训练和工程调试，那么 MaaS 名义上是 API 服务，实际仍然是项目制交付，规模化优势很难体现。

不过，跨本体泛化难，并不意味着 MaaS 没有落脚点。真实业务并不总要求机器人在开放环境中完成长程复杂任务。

以物流供包为例，机器人面对的操作对象和流程相对明确：识别包裹、抓取、翻转，再送入后续分拣环节。这类原子任务目标清晰，可以先在特定本体和任务上训练、评估，再逐步拓展到更多设备。

MaaS 不必等到一个模型适配所有机器人、完成所有任务才有价值。先让客户用自己的数据，把模型调整到适合自己的本体和任务，同样是一条现实路径。

另一个问题在于交付方式。

物流仓储、生产制造和工业操作都已经出现具体需求，但不少项目仍然需要模型厂商深入现场，完成数据采集、场景适配、参数调整和上线验证。

这种方式适合早期验证，却很难长期复制。每增加一个项目，就要投入相应的人力和工程资源。

大模型产业提供了一个参照。基础模型厂商不必包办所有应用，SaaS 厂商和开发者更接近具体业务，可以基于模型开发产品。

具身智能要形成类似分工，模型厂商也需要开放基础模型、训练工具和部署能力，让更多本体厂商和集成商能够自己完成应用开发。

但 API 开放并不会自动解决适配问题。

客户拿到模型接口之后，还要准备机器人操作数据，处理视频和动作记录，完成数据标注，再选择后训练方法，最后通过真机评测判断模型有没有变好。

具身智能后训练横跨数据工程、模型算法和机器人控制，能独立完成这些工作的往往是技术储备较强的客户。对更多硬件厂商和系统集成商来说，这仍然是一道门槛。

目前，几家公司的模型服务也呈现出不同的侧重点。

Physical Intelligence 的 Pi API Beta 提供数据上传、云端微调和托管推理；Dream Labs 的 Dream-1 强调零样本泛化，并提供面向特定机器人的微调服务。

原力灵机 Dexmal MaaS 将多种后训练 Pipeline、数据处理和机器人接入放在同一套服务体系中，重点降低客户自行完成场景训练的门槛。

具身 MaaS 真正要解决的，不只是提供一个模型接口，而是让客户不必从头搭建算法团队，也能完成数据准备、模型训练、机器人接入和效果验证。

2、Dexmal MaaS：打造行业最强普惠后训练，盘活真机日活

今年 7 月发布 Dexmal MaaS 时，原力灵机已经开放基础模型调用和云端推理。一些技术实力较强的客户能够调用模型，并利用自身能力完成后训练。

但对大多数本体厂商和集成商来说，数据采集、标注和训练策略仍然需要专业团队。API 能把模型交到客户手里，却不能保证客户知道怎么把它调到自己的机器人上。

这次升级的重点，就是进一步降低这道门槛：将 SFT、DAgger、RECAP 三种常用后训练 Pipeline 整合进 MaaS 服务，让客户能够直接基于原力灵机的基础模型开展场景定制。

后训练不再只是少数算法团队掌握的专业能力，而是逐渐成为普通工程人员也能使用的产品服务。三种训练方法，分别对应模型在不同阶段遇到的问题：

• SFT 通过标准示范数据帮助模型建立或提升基础能力，适合任务冷启动
• DAgger 利用机器人实际运行数据纠正动作偏差，让模型适应真实环境，解决实验室里会、到了现场就偏的问题
• RECAP 则围绕失败案例开展针对性优化，处理复杂任务中的长尾问题，把反复失败的场景变成下一轮训练的输入

三种方法对应模型在不同阶段遇到的问题：刚开始需要建立任务能力，进入真实环境后需要纠正执行偏差，遇到反复失败的情况则需要针对性突破。

三条路线组合起来，覆盖了模型从建立基础能力到持续优化的完整周期。

对使用者来说，重要的不是先掌握这些方法的算法原理，而是能判断模型卡在哪里，再选择对应的训练路径。把后训练从专家活变成按阶段可选的标准化操作，也是这次升级最想做到的事。

一次完整的后训练，从数据开始。原始数据可能是第一视角视频、机器人位姿、手部动作或执行过程记录，但这些还不能直接等同于训练样本。

Dexmal MaaS 提供 Ego 数据服务、HandPose API 和任务语义标注 API：Ego 用于处理第一视角操作数据，HandPose API 提取手部关键点和三维动作信息，任务语义标注 API 则把场景、任务、原子动作、物体属性和状态变化转化为结构化信息。

数据处理完成后，客户再根据具体任务的问题选择训练路线，形成适配自身场景的模型。

训练完成，模型还要进入机器人本体。

Dexmal MaaS 依托 DexOS 提供标准化的本体接入能力，首批已适配原力灵机 Mirror 移动式训推一体机器人和松灵 Cobot Magic，其他符合标准接口的机器人也可以接入；模型推理可借助云端算力，实时伺服与动作执行仍在本体侧完成。

接入层要做的，是把不同机器人的硬件差异封装起来，减少客户重新连接模型和控制系统的工作量。

模型能否真正解决问题，还得看机器人进入场景之后的表现。

在物流仓储领域，接入 MaaS 模型服务的桌面机器人已经部署在传送线侧承担供包任务，综合作业节拍超过每小时 1200 件，整体成功率超过 99%。

在仓储拆零分拣场景中，机器人已经能够稳定抓取数千个 SKU，并与搬运机器人协同完成分拣。

生产制造场景对机器人的要求又有所不同。接入 MaaS 模型服务的移动机器人已经应用于手机生产线，配合产线完成废料回收，手机打包、装配等环节的应用也在持续测试和部署。

工业作业中，针对接口插拔等精密操作场景，接入 MaaS 的桌面机器人正在部署，面向亚毫米级精度要求的质检任务开展应用。

从传送线供包到仓储拆零分拣，再到手机生产线和精密工业操作，这些任务的对象、节拍和精度要求各不相同，也说明模型进入真实场景，需要数据、后训练、本体接入和真机验证共同完成。

这些场景也让原子任务成功率有了更具体的落点。原子任务是一步即可完成、边界相对清楚的动作，并不等于机器人已经能以同样成功率完成复杂长程任务。

在特定真实场景的原子任务测试中，原力灵机通过三种后训练方法已经实现接近 100% 的成功率；供包场景超过 99% 的综合成功率，则体现了模型在连续作业流程中的表现。

这组数字，也是这次升级敢于以后训练为核心的底气。

先在供包、抓取、翻转这些高频任务里把稳定性做起来，再逐步扩展到更长流程，更符合产业落地的节奏。

MaaS 好不好用，最终要看客户能不能以较低门槛完成模型调用、后训练和真机验证，更要看训练出来的模型能不能在自己的场景里稳定运行。

Dexmal MaaS 升级，想做的就是把原本依赖专业团队的模型适配流程，变成更多工程人员能够使用的产品服务。

3、具身 MaaS 能否成立，最终要看有多少机器人真正开始工作

模型能力开放之后，产业分工也可能随之变化。

模型厂商提供基础模型、后训练工具和部署能力，本体厂商、系统集成商及开发者结合自己的硬件和行业经验，完成场景应用与最终交付。

交付给客户的仍然是软硬件协同的系统，变化在于模型厂商不必亲自包揽每一个项目，模型能力也可以成为更多企业共同使用的基础服务。

这也让机器人日活有了更实际的意义。相比模型被调用了多少次、机器人卖出了多少台，日活关注的是有多少设备真正进入生产线、仓库或其他作业现场，并持续承担任务。

一台机器人交付出去，不代表它已经创造了生产力；能够在真实场景中正常运行、稳定完成任务，才意味着它开始产生实际价值。

当然，日活本身也不能代表全部生产力。一台机器人每天在线，却频繁停机、需要人工接管，与一台能够长时间自主完成任务的机器人，创造的价值并不相同。

日活还需要结合自主工作时长、任务完成量、成功率和人工介入程度来判断。

因此，机器人日活更适合作为观察具身智能应用规模的基础指标，它至少能够帮助行业回答一个先决问题：有多少机器人已经从测试和演示状态，进入了真实工作状态？

这也是 MaaS 对产业分工的意义：开放模型服务，让更多本体厂商和集成商获得模型能力；后训练和接入工具降低使用门槛，让他们能够结合自身场景完成部署。

当然，原力灵机也并不是只做模型服务。其同时布局了 Apex 等机器人硬件产品，并通过 DexOS 连接不同本体；机器人多智能体混合作业系统则面向仓储场景，将自动化设备和具身机器人组织起来，处理不同复杂度的作业。

MaaS 与硬件、场景解决方案并不割裂：自有设备和项目可以检验模型在真实环境中的表现，开放服务则让模型能力有机会进入更多外部机器人。

更多客户接入后，不同本体和任务会带来新的运行数据、失败案例和使用需求。

这些反馈帮助模型发现能力边界，成为下一轮后训练的输入；模型优化后，又有机会支持更多机器人和场景。

更多接入带来更多任务，更多任务积累更多数据，数据再推动模型优化，这才是 MaaS 有机会形成的长期循环。

眼下，物流供包、仓储拆零分拣、手机产线废料回收和工业接口插拔，已经呈现出具身 MaaS 在不同场景中的使用方式。

接下来不仅要看模型又开放了多少接口，也要看这些项目能否持续运行，机器人日活能否增长，单台机器人能否完成更多任务，并逐步减少人工干预。

大模型的发展证明，开放基础能力可以带来更广泛的应用生态。

但具身智能有自己的产业复杂性：本体差异、数据准备、后训练和真实作业可靠性，都需要在实际部署中逐步解决。

原力灵机 Dexmal MaaS 的升级，就是希望降低模型适配和部署门槛，让更多客户能够把模型用到自己的机器人上。

毕竟，具身智能的商业化，不会只由模型能力或硬件出货量决定。

最终要看的是有多少机器人每天都在工作，又有多少任务能够稳定地交给它们完成。