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

具身智能的 API 时刻意味着部分具身模型已经开始具备跨本体迁移、在一定范围内适应新任务的能力。

过去，想知道一个具身模型有多强，往往要看它在发布视频里完成了什么任务。不过，这条线正在松动。

就在近期，一些公司开始把另一种检验方式交到开发者手里：接上你自己的机器人，试着把你的任务做出来。

10 月，Physical Intelligence（PI）开放了模型 API 测试。开发者可以上传自己的机器人数据，在平台上微调模型，再通过云端推理驱动机器人。PI 表示，一家公司，用这套服务迭代了四天，让双臂机器人开始为自身的零部件去毛刺。

同月，Dream Labs 推出 Dream API，将机器人模型推理按作业时长计费，并提供面向开发者数据的模型微调服务。让机器人调用云端模型，正在成为一种可以试用、适配和购买的服务。

国内，11 月 3 日，原力灵机升级了 Dexmal MaaS，将重点放在模型进入具体场景所需的后训练上：开发者可以在同一平台完成数据上传、模型训练和部署，再根据真机执行中的失败继续改进。

这些动作让具身智能行业出现了一个值得关注的变化。过去，我们常常听到一些公司宣称自己在某个场景正在寻求落地突破。而现在，模型公司开始尝试把自己积累的能力，交给不同硬件、不同任务背后的开发者使用。具身模型的竞争，也由此延伸到一个更实际的问题：别人能不能拿它做成应用？

这一步比语言模型开放 API 要重得多。机器人需要适配自己的身体，理解现场的物体和流程，还要在执行出错时把任务接着做下去。把模型交到外部开发者手里，就意味着让它走出熟悉的实验环境，接受不同本体和真实任务的检验。这需要模型能力作为底气，也需要公司有信心把尚未解决的问题暴露出来，在使用中继续改进。

本体厂商提供身体、模型公司提供基础能力，开发者围绕场景构建应用，是行业早已讨论过的一种分工。不过在过往，借助通用模型构建具身应用，仍然往往是一个愿景。

如今，几家公司相继开放 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 因而开始具备实际应用的条件。而模型接到客户的机器人之后，能否稳定完成客户的任务，则是下一道更深的门槛。

当模型能力和推理条件逐渐成熟，开发者开始有机会借用一个现成的「大脑」。但不同具身 API 能帮用户走多远，差别可能很大。

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

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

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

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