具身智能，也到了 API 时刻？

具身智能的 API 时刻意味着部分具身模型已经开始具备跨本体迁移、在一定范围内适应新任务的能力。作者｜Li Yuan编辑｜郑玄具身智能，也到了 API 时刻？过去，想知道一个具身模型有多强，往往要看它在发布视频里完成了什么任务。

不过，这条线正在松动。就在近期，一些公司开始把另一种检验方式交到开发者手里：接上你自己的机器人，试着把你的任务做出来。10 月，Physical Intelligence（PI）开放了模型 API 测试。

开发者可以上传自己的机器人数据，在平台上微调模型，再通过云端推理驱动机器人。PI 表示，一家公司，用这套服务迭代了四天，让双臂机器人开始为自身的零部件去毛刺。同月，Dream Labs 推出 Dream API，将机器人模型推理按作业时长计费，并提供面向开发者数据的模型微调服务。

让机器人调用云端模型，正在成为一种可以试用、适配和购买的服务。国内，11 月 3 日，原力灵机升级了 Dexmal MaaS，将重点放在模型进入具体场景所需的后训练上：开发者可以在同一平台完成数据上传、模型训练和部署，再根据真机执行中的失败继续改进。

这些动作让具身智能行业出现了一个值得关注的变化。过去，我们常常听到一些公司宣称自己在某个场景正在寻求落地突破。而现在，模型公司开始尝试把自己积累的能力，交给不同硬件、不同任务背后的开发者使用。

具身模型的竞争，也由此延伸到一个更实际的问题：别人能不能拿它做成应用？这一步比语言模型开放 API 要重得多。机器人需要适配自己的身体，理解现场的物体和流程，还要在执行出错时把任务接着做下去。

把模型交到外部开发者手里，就意味着让它走出熟悉的实验环境，接受不同本体和真实任务的检验。这需要模型能力作为底气，也需要公司有信心把尚未解决的问题暴露出来，在使用中继续改进。未来具身智能的形态，或许就会在这些尝试中逐渐清晰。

01为什么是现在？本体厂商提供身体、模型公司提供基础能力，开发者围绕场景构建应用，是行业早已讨论过的一种分工。不过在过往，借助通用模型构建具身应用，仍然往往是一个愿景。如今，几家公司相继开放 API，开始把这种设想变成开发者可以上手的服务。

为什么是现在？或许有几点原因。首先，一部分具身模型开始具备跨本体迁移、在一定范围内适应新任务的能力。过去，教机器人完成一个新任务，往往意味着围绕特定硬件开发算法、采集数据，再反复调试。

具身基础模型正在改变这个起点。模型从不同任务的训练中积累物理世界知识和操作经验，开发者便有机会借用这些能力，把新增投入集中在自己的机器人和任务上。一个基模能够支持的本体与场景越多，将它作为公共服务提供的价值就越大。

PI 展示的一个案例，甚至让机器人参与了自己的制造。开发双臂机器人 Axol 的公司 Almond，希望让它处理自身装配所需的零件。借助 Pi API，这个团队经过四天迭代，让机器人开始为装配用的垫块去毛刺。

原力灵机开放 MaaS，同样有一个能力上的前提：它的基模已经积累了一批能够交给外部开发者使用的操作经验。按照原力灵机展示的 DM0.5 的 Zero-shot 能力，模型目前已经可以完成抓取、推动、放置、叠放等操作，也能根据颜色、形状和大小区分物体，甚至能完成擦东西这样的更难的操作。

DM 0.5 还能执行序列指令，机器人需要理解多个操作之间的先后关系，完成前一步后，面对已经变化的现场继续执行下一步。DM0.5 对序列指令的支持，加上原生记忆能力，为任务从单个动作延伸到连续操作提供了基础。

这意味着，机器人开始能够把「看懂要求」与「做出动作」连起来：面对不同物体，判断指令指向哪一个，再按要求完成操作。开发者接入之后，已经有一组可以组合、验证的能力，而不必逐项从头训练。

这个起点还需要经得起本体和环境的变化。DM0.5 将多本体适配、原生记忆，以及对光照、相机变化和外界干扰的鲁棒性纳入能力设计。这些特性与开放服务直接相关：外部用户的机器人、工作环境和操作流程各不相同，模型只有能够承接一定程度的变化，共享基础能力才有实际意义。

原力灵机的判断也落在这里。唐文斌此前谈到，一个模型是否好用，要看它能否具备足够强的泛化能力，以及能否通过后训练，省时省力地变成面向具体任务的专用模型。MaaS 将这两种使用方式放在一起：开发者既可以调用通用模型，也可以继续训练适合自身任务的模型。

另一个推动力，来自模型计算需求与机器人身体之间的矛盾。谈到机器人调用云端模型，人们最先担心的往往是延迟：画面传出去，等模型算完再把动作传回来，会不会已经错过了反应时机？把推理放在端侧，自然是一个直观选择。

但本地部署也未必是最终解法。像 GPT-6 Astra 这样的探索，已经让人看到：持续理解环境、记住交互过程、判断下一步做什么，会对模型提出越来越高的要求。如果机器人也要获得这些能力，本体需要承担的计算负担也会增加，而功耗、散热、续航和成本都会限制算力配置。

云端或现场服务器因此有理由长期参与其中。远程推理能否成立，关键在于如何安排网络传输、模型计算和动作执行。模型可以一次输出一小段动作，机器人执行当前动作时，系统继续计算后续动作，再将两段动作衔接起来。

PI 公布的实时动作分块研究，探索的就是如何让模型计算与动作执行重叠，降低推理延迟对连续作业的影响。原力灵机 MaaS 则将云端模型推理与本地动作执行连接起来：机器人上传相机图像和当前状态，模型预测后续动作，再交由本地控制程序执行。

配套的 DexOS Lite 提供推理循环、多步动作执行和请求重试等能力，减少开发者自行衔接这些环节的工作。模型能力向外开放，也需要这样的工程配套，才能落到真实机器人上。延迟仍然需要处理。

网络波动有多大、任务要求多快的反应、动作能否平稳衔接，都会影响远程推理的适用范围。但在一定任务和系统条件下，这些问题已经可以被工程方案容纳。可复用的基础能力，让开发者有了调用模型的理由；

推理与执行方式的改进，让这种调用有机会进入真实作业。具身 API 因而开始具备实际应用的条件。而模型接到客户的机器人之后，能否稳定完成客户的任务，则是下一道更深的门槛。02接上模型之后，工作才刚开始当模型能力和推理条件逐渐成熟，开发者开始有机会借用一个现成的「大脑」。

但不同具身 API 能帮用户走多远，差别可能很大。最基础的影响条件是基础模型的跨本体能力。机械臂的活动范围、夹爪的结构、相机的位置发生变化，模型已有的操作经验能否继续发挥作用，决定了开发者是在已有能力上做适配，还是接近重新教一台机器人干活。

Dream Labs 将跨本体零样本能力作为 Dream-1 的重要卖点。目前，这种能力主要面向双臂平行夹爪机器人，表现也受到本体运动学和控制系统的影响。公司同时提供 FaaS 微调服务，为开发者的机器人定制模型。

在其公布的跨本体仿真评估中，微调提升了多数受测机器人的语言指令跟随得分，但并非所有本体都获得提升。对使用者而言，硬件被列入支持范围之后，仍需要验证模型在自己任务上的效果。模型适应了新的身体，还要继续适应现场。

比如，把鸡蛋放进蛋托，模型可能已经具备抓取和放置的能力。但鸡蛋滑了一下、蛋托被碰偏，第一次抓取落空后，机器人还能不能调整动作，把任务接着做完？这些情况不一定出现在最初的示范中，却会在实际运行里反复发生。

现阶段，这些问题绕不开后训练。基模提供一个更好的起点，开发者仍然需要用自己的机器人和任务数据，让模型适应现场。如果一项服务只展示接入时的便利，却把此后的适配工作全部留给用户，那么它的 API 服务，并不够真诚。

PI 的 API 因此将数据上传、微调和托管推理连在一起。外部团队采集示范、训练模型、放到机器人上测试，再根据失败决定下一轮补充什么数据。原力灵机此次 MaaS 升级，也把重点放在了接入之后的适配上。

开发者可以上传任务示范进行训练，也可以根据真机运行中的偏差补充纠正数据，进一步利用失败记录优化策略。从学会基本流程，到出错后能够恢复，平台为不同阶段的问题提供了对应的训练路径。从 PI、Dream Labs 到原力灵机，值得关注的是，它们都把后续适配纳入了服务。

即使强调零样本能力，也为效果不够好的情况准备了继续训练的入口。这种安排体现了一种务实：模型能够承担多少，哪些还需要现场数据补足，需要在产品里有明确的位置。API 的质量，正是在这些后训练的细节里拉开距离。

任务失败之后，「再采一些数据」并不是一个足够有效的建议。开发者需要判断，机器人究竟卡在哪个环节，应该补充什么样的示范，是否需要从出错的状态开始演示恢复过程，以及下一轮测试如何确认问题得到改善。

采集什么数据，本身就包含了对任务和模型的理解。原力灵机就特别关注这一环节，将数据采集指南纳入后训练服务。它的价值在于把现场适配的经验交给开发者，让用户面对失败时，有依据判断下一轮该采什么、怎么采，减少盲目增加数据和反复重训的投入。

围绕数据的后续使用，平台支持上传主流的 LeRobot v3 格式数据集，并通过可视化工作台管理数据和模型、发起定制训练、部署专属模型。从指导采集到训练部署，这些环节连在一起，才能让开发者在现场积累的经验，持续转化为机器人的能力。

03把后训练交到开发者手里放在这一轮具身 API 开放潮中看，原力灵机此次 MaaS 升级其实很令人惊喜：既敢于把模型交给外部任务检验，也愿意把开发者接入之后最费力的适配工作，纳入自己的产品责任。

原力灵机是国内较早布局具身 MaaS 的公司。今年 7 月 9 日，它在开发者大会上发布 MaaS 时，就已将云端模型调用、在线后训练和定制模型托管部署纳入服务。此次升级，则把这条路径进一步细化：从数据采集指南、上传管理，到 SFT 示范学习、DAgger 运行纠偏，再到通过 RECAP 利用失败记录优化策略，平台开始更具体地处理开发者在现场适配中遇到的问题。

业内已经有不少开源模型，但拿到代码之后，怎样准备数据、组织训练、判断效果，再根据失败继续迭代，仍然需要相当的模型经验。国内能把这些后训练工具真正用起来的人，或许只有千人的量级。而未来可能用上模型服务的团队，能力未必长在这里。

本体厂商熟悉硬件，场景团队掌握业务流程，它们需要把这些积累转化为机器人可以执行的任务。数据该怎么采，运行中的偏差怎么纠正，反复出现的失败怎样用于下一轮训练，都需要有具体的方法可以遵循。

把这些方法交到开发者手里，让应用团队不必先成为模型专家，也有办法把任务继续做下去，才是让 MaaS 务实生长的关键。比如，一支团队想让机器人在传送线侧完成供包。它需要的，是把不同形态、不同摆放状态的包裹持续抓取、放置，并达到现场要求的作业节拍。

通过 MaaS，开发者可以从 DM0.5 已有的操作能力出发，先按照采集指南，用自己的机器人录制任务示范，上传到平台进行 SFT 训练。模型由此学习现场的物体、动作和流程，开发者也不必为这一步自行搭建整套训练系统。

第一版模型部署到机器人上之后，就可以开始检验：哪些包裹能稳定处理，哪些状态容易抓偏，任务又会在哪一步中断。这些结果决定下一轮需要补什么数据。如果机器人已经能完成基本流程，却经常在执行中发生偏差，开发者可以在它出错时介入，记录如何调整、怎样继续完成任务，再将纠正数据用于 DAgger 训练。

下一轮，模型学习的就是这些实际遇到的困难，而不必只靠增加顺利完成的示范碰运气。对于反复出现的失败，还可以使用 RECAP 继续优化。平台针对任务训练价值模型，为执行记录逐帧生成价值标签，再利用这些评价训练控制机器人动作的策略模型。

成功、纠正和失败的记录，都有机会成为改善表现的依据。这几种方法可以按需选择。每完成一轮训练，开发者就将更新后的模型部署回机器人，检查成功率是否提高、无效尝试是否减少、人工接管是否更少，再决定下一轮的工作。

DexOS Lite 或 MaaS API 则负责连接模型服务与机器人，让这套迭代能够落实到真机执行上。据原力灵机介绍，经过针对具体本体和场景的后训练，平台已在部分真实场景的原子任务测试中实现 100% 成功率。

这对应的是特定条件下的单项任务表现，换到新的本体或场景，仍可能需要继续适配。在物流供包场景，公司披露，使用其 MaaS 的机器人综合作业节拍超过每小时 1200 件，整体成功率超过 99%。

平台进一步开放训练与迭代能力，是希望让更多团队也能围绕自己的任务改善效果，并通过作业节拍、人工接管和运行成本，检验应用是否真正算得过账。除物流供包外，原力灵机披露的应用还包括仓储拆零分拣、手机产线废料回收，手机打包、装配等环节也在持续测试与部署中。

现阶段，具身应用的开发分工仍在形成。能够接入模型的团队，未必同时熟悉生产现场；掌握场景需求的客户，也未必具备模型训练能力。原力灵机一方面通过自身的场景实践处理这些问题，另一方面将训练、部署和本体接入能力向外开放，尝试把更多环节连接起来。

具身智能进入 API 时刻，最终意味着需要由开发者与原力灵机这样的模型公司共同来验证：它们能否借助模型服务做出可用的应用，让机器人持续工作，并算出一笔成立的账。*头图来源：原力灵机本文为极客公园原创文章，转载请联系极客君微信 geekparkGO极客一问具身 API 的核心是泛化能力，还是现场迭代能力？