具身智能进入API时代：PI、Dream Labs、原力灵机相继开放模型服务

具身智能，也走到了 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 在设计能力时就把多本体适配、原生记忆，以及对光照、相机变化和外界干扰的鲁棒性算了进去。这些跟开放服务是一回事：外部用户的机器人、干活环境和流程都不一样，模型得能接住一定程度的变化，共享基础能力才谈得上实际用处。

原力灵机的看法也在这里。唐文斌之前说过，判断一个模型好不好用，要看它的泛化能力够不够强，还要看能不能靠后训练，省时省力地变成针对具体任务的专用模型。MaaS 把两条路摆在一起：开发者可以调通用模型，也可以接着训练自己任务要用的模型。

另一个推动力，来自模型计算需求与机器人身体之间的矛盾。

机器人调用云端模型，多数人先想到的是时延：图像传上去，模型算完再把动作发回来，反应窗口是不是已经过了？把推理放到端侧，看起来是条直路。

本地部署却不一定就是终点。GPT-6 Astra 这类探索已经显示，持续理解环境、记住交互过程、判断下一步该做什么，对模型的要求会越来越高。机器人若要具备这些本事，本体承担的计算量也会上去，功耗、散热、续航和成本又反过来卡住算力配置。

于是云端或者现场服务器有理由长期参与。远程推理能不能跑通，要看网络传输、模型计算和动作执行怎么排布。模型可以先输出一小段动作，机器人执行这段动作的同时，系统继续算后面的动作，再把两段接上。PI 公开的实时动作分块研究，做的就是让模型计算与动作执行重叠，把推理延迟对连续作业的影响压下来。

原力灵机 MaaS 把云端模型推理和本地动作执行串在一起：机器人上传相机图像和当前状态，模型预测后续动作，交给本地控制程序执行。配套的 DexOS Lite 提供推理循环、多步动作执行、请求重试等能力，开发者不必自己把这些环节接起来。模型能力对外开放，也得有这类工程配套，才落得到真实机器人上。

延迟仍然要处理。网络波动多大、任务要求多快反应、动作能不能平稳衔接，都会决定远程推理适用的范围。不过在一定的任务和系统条件下，工程方案已经能把这些因素装进去。

可复用的基础能力给了开发者调用模型的理由，推理与执行方式的改进让这种调用有机会进入真实作业，具身 API 由此开始具备实际应用的条件。模型接入客户的机器人之后能不能稳定完成任务，则是更深的下一道门槛。

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

最基础的变量是基础模型的跨本体能力。机械臂活动范围、夹爪结构、相机位置一变，模型原有的操作经验还能不能管用，决定了开发者是在已有能力上做适配，还是几乎要从头教一台机器人干活。

Dream Labs 把跨本体零样本能力当作 Dream-1 的重要卖点。眼下这类能力主要面向双臂平行夹爪机器人，效果还受本体运动学和控制系统影响。公司同时提供 FaaS 微调服务，给开发者的机器人定制模型。

它公开的跨本体仿真评估里，微调让多数受测机器人的语言指令跟随得分提高，但并非所有本体都有提升。对使用者来说，硬件进了支持列表，仍要验证模型在自己任务上的表现。

模型适应了新身体，还得继续适应现场。

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

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

PI 的 API 因此把数据上传、微调和托管推理连在一起。外部团队采集示范、训练模型、放到机器人上测试，再根据失败决定下一轮补什么数据。

原力灵机这次 MaaS 升级，也把重点压在接入之后的适配上。开发者可以上传任务示范来训练，也能针对真机运行中的偏差补充纠正数据，用失败记录继续优化策略。从学会基本流程到出错后能恢复，平台给不同阶段的问题留了对应的训练路径。

从 PI、Dream Labs 到原力灵机，几家都把后续适配算进了服务。即便强调零样本能力，也为效果不够好的情况备了继续训练的入口。这种安排透着务实：模型能承担多少、哪些得靠现场数据补，产品里要有明确的位置。

API 的质量，恰恰在这些后训练细节里拉开距离。

任务失败之后，「再采一些数据」算不上有效的建议。开发者要判断机器人到底卡在哪一环，该补什么样的示范，要不要从出错的状态开始演示恢复过程，下一轮测试又怎么确认问题改善了。采什么数据，本身就包含对任务和模型的理解。

原力灵机对这一步格外上心，把数据采集指南放进了后训练服务。它的价值在于把现场适配的经验交给开发者，让用户面对失败时有依据判断下一轮采什么、怎么采，少走盲目加数据、反复重训的弯路。

数据后续怎么用，平台支持上传主流的 LeRobot v3 格式数据集，并通过可视化工作台管理数据和模型、发起定制训练、部署专属模型。从指导采集到训练部署，这些环节连起来，开发者现场攒下的经验才能持续变成机器人的能力。

放到这一轮具身 API 开放潮里看，原力灵机此次 MaaS 升级其实挺让人意外：既敢把模型交给外部任务检验，也愿意把开发者接入后最费力的适配工作，算进自己的产品责任。

今年 7 月 9 日的开发者大会上，原力灵机推出 MaaS 时，云端模型调用、在线后训练以及定制模型托管部署已经被纳入服务范围；在国内，它布局具身 MaaS 的时间算早的。

这次升级把这条路径拆得更细。数据怎么采、怎么上传管理，SFT 示范学习怎么做，运行中偏差如何靠 DAgger 纠偏，失败记录又怎样通过 RECAP 拿来优化策略——开发者在现场适配时碰到的问题，平台开始一件件具体处理。

业内的开源模型已经不少。可代码拿到手之后，数据怎么准备、训练怎么组织、效果怎么判断、失败之后如何继续迭代，每一关都要相当的模型经验。国内真能把这类后训练工具用起来的，或许只有千人的量级。

未来可能用上模型服务的团队，能力未必长在这里。本体厂商懂硬件，场景团队掌握业务流程，他们要把这些积累变成机器人能执行的任务。数据该怎么采，运行中的偏差怎么纠正，反复出现的失败又怎样用于下一轮训练，都得有具体方法可循。

把这些方法交到开发者手里，让应用团队不必先成为模型专家，也有办法把任务继续做下去——这才是让 MaaS 务实生长的关键。

举个例子。一支团队想让机器人在传送线侧完成供包，需要它把不同形态、不同摆放状态的包裹持续抓起来、放下去，还得达到现场要求的作业节拍。

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

第一版模型部署到机器人上之后，检验就可以开始了：哪些包裹能稳定处理，哪些状态容易抓偏，任务又会在哪一步中断。这些结果决定下一轮需要补什么数据。

机器人能走完基本流程、执行中却老是跑偏，怎么办？开发者可以在它出错的时候接手，把怎么纠正、怎么接着把任务做完记下来，再拿这些纠正数据去做 DAgger 训练。这样下一轮模型学的就是真实碰到的难点，不用光靠多堆顺利完成的示范去碰运气。

碰上反复出现的失败，还可以用 RECAP 接着优化。平台会针对任务训练价值模型，给执行记录逐帧打价值标签，再用这些评价去训练控制机器人动作的策略模型。成功的记录、纠正的记录、失败的记录，都可能成为改进表现的依据。

这几种方法，开发者可以按需要挑着用。每轮训练结束，把更新后的模型部署回机器人，看看成功率有没有上去、无效尝试有没有变少、人工接管是不是更少了，再定下一轮怎么做。模型服务与机器人之间的连接由 DexOS Lite 或 MaaS API 负责，整套迭代最终要落到真机上执行。

原力灵机方面介绍，针对具体本体和场景做过后训练之后，平台已在部分真实场景的原子任务测试中做到 100% 成功率。这个数字对应的是特定条件下的单项任务表现；换一个新的本体或场景，多半还得继续适配。

物流供包场景下，公司披露其 MaaS 机器人的综合作业节拍超过每小时 1200 件，整体成功率超过 99%。平台把训练与迭代能力进一步开放出来，是希望更多团队能围绕自己的任务把效果做上去，并用作业节拍、人工接管和运行成本来检验应用到底算不算得过账。

除物流供包外，原力灵机披露的应用还包括仓储拆零分拣、手机产线废料回收，手机打包、装配等环节也在持续测试与部署中。

眼下，具身应用的开发分工还没定型。能接模型的团队，不一定熟悉生产现场；懂场景需求的客户，也不一定具备模型训练能力。原力灵机的做法是两头走：一边靠自己的场景实践处理这些问题，一边把训练、部署和本体接入能力对外开放，试着把更多环节串起来。

具身智能进入 API 时刻，说到底要由开发者和原力灵机这类模型公司一起验证一件事：开发者能不能靠模型服务做出可用的应用，让机器人持续干活，并且把账算成立。