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

具身智能，也到了 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 時刻，最終意味著需要由開發者與原力靈機這樣的模型公司共同來驗證：它們能否借助模型服務做出可用的應用，讓機器人持續工作，並算出一筆成立的帳。(極客公園)