這項由北京航空航天大學CoLab實驗室完成的研究，於2026年7月發表，論文編號為arXiv:2607.02646。有興趣深入了解的讀者可以通過該編號在arXiv平台查閱完整論文。
**訓練出來了，然後呢？**
機器人領域有一個鮮為人知的窘境。科研人員花費大量時間訓練出一個智能機器人策略——也就是讓機器人"知道該怎麼做"的那個大腦——但當他們興沖沖地想把這個大腦裝進真實機器人身上時，卻發現這才是真正麻煩的開始。
打個比方，你煞費苦心地學會了一道複雜菜餚的配方，可到了真正的廚房裡，卻發現爐灶的旋鈕位置不一樣、鍋的尺寸跟書上寫的對不上、計時器還得手動操作……光是把配方轉化成實際操作，就已經讓人頭大了，更別說還要在客人面前優雅地端上桌。機器人部署的處境與此如出一轍。
EVA-Client就是為解決這個"從配方到上桌"的鴻溝而生的。它是一套開源框架，專門負責把訓練好的機器人策略順利搬到真實機器人上，並且把整個過程變得可檢查、可重複、可比較。
**一、機器人界的"最後一公里"難題**
近年來，機器人操控領域發展迅猛。各類視覺-語言-動作模型（VLA）、影片-動作模型（VAM）和世界-動作模型（WAM）相繼湧現，簡單理解就是讓機器人能"看圖說話再動手"的各種AI大腦。與此同時，openpi、LeRobot、StarVLA等訓練框架也日趨成熟，大大降低了訓練一個機器人策略的門檻。
然而，訓練好策略之後該怎麼辦，整個行業卻像是集體忽視了這個問題。把一個訓練好的"大腦"實際接入真實機器人，需要解決一連串的技術難題：機器人硬體的接入與適配、實時動作的調度與執行、延遲補償、動作平滑處理、執行過程的記錄與回放……這些工作通常被每個團隊各自實現為臨時湊合的腳本，既難以復用，又難以比較。
這個局面造成了三個具體痛點。第一個痛點是"機器人不通用"——不同機器人有各自不同的攝影機、關節狀態反饋方式和通信協議，為一台機器人寫的部署代碼幾乎不可能直接用到另一台上。第二個痛點是"執行細節影響結果卻難以追蹤"——機器人策略執行時，如何把每次預測出的一小段動作序列（專業術語叫"動作塊"）拼接成連貫的運動，直接影響任務成敗，但這些執行細節往往埋藏在各自的實現里，根本無從比較。第三個痛點是"評估不留證據"——團隊通常只是跑幾次機器人，憑感覺判斷效果好不好，既沒有系統記錄，也不能事後重現，更談不上把實際運行數據反哺回去繼續訓練。
EVA-Client正面回應了這三個痛點，提出了一套統一的解決方案。
**二、EVA-Client是什麼，它做了什麼**
從架構上看，EVA-Client扮演的是"翻譯官加調度員"的角色，坐落在兩側之間：左邊是各種策略來源——包括openpi、StarVLA、GR00T、Dream-Zero等AI策略伺服器，以及人工遙控操作——右邊是真實機器人硬體。EVA-Client從左邊接收動作指令，經過一系列處理後，向右邊的機器人發出控制命令，同時把機器人反饋回來的觀測數據整理好再送回給策略伺服器，形成一個完整的閉環。
更重要的是，EVA-Client把整個部署過程包含的三大工作流——調試（Debug）、數據採集（Collect）和評估（Evaluation）——全部整合進同一套框架，讓"訓練一測試一再訓練"的循環不再需要換工具。
整個框架在內部分為五個層次，彼此之間通過簡潔的接口通信。傳輸層負責搬運觀測數據和控制命令，機器人描述層聲明具體機器人的特徵，策略客戶端層負責跟AI策略伺服器打交道，推理策略層決定如何把一段段預測出的動作平滑地變成連續運動，最上面的界面層提供可交互的網頁控制台。因為各層之間只通過小數據結構交換資訊，任何一層都可以獨立替換，不影響其他層。
**三、各種機器人都能用：硬體適配的奧秘**
機器人界有個老大難問題：每家機器人的"通信方言"都不一樣。EVA-Client的解決思路是"聲明式"配置，而非為每台機器人單獨編寫專屬代碼。只需要為一台新機器人寫一個"機器人描述類"，說明它有哪些關節組（手臂、夾爪、底盤等）、攝影機在哪、用什麼話題名稱傳數據、是否需要運動學計算——框架里的其他所有部分就能自動跟這台機器人協作。
目前框架已經支持的機器人包括Franka機械臂、UR5e、Galaxea R1-lite、AgileX Piper、AgiBot G2和ARX R5，並且仍在持續擴展。這些機器人全都通過同一套通用後端接入，區別僅在於各自的描述類不同。
數據傳輸方面，框架支持ROS1、ROS2和ZMQ三種傳輸後端。其中ROS1和ROS2是機器人領域最主流的通信中間件，框架對它們的時間同步做了特別處理：不是簡單設定一個容許誤差窗口，而是為每個數據流維護一個緩衝隊列，每次取數據時精確對齊各流中時間戳最接近的那一幀，如果各流之間找不到共同的時間戳，就等待它們重新同步，而不是將就著用一幀不匹配的數據。這種精確的時間對齊，避免了機器人"看到的"和"當時實際在做的"對不上號的尷尬。ZMQ後端則允許開發者完全不接機器人，只通過一個模擬節點產生假觀測數據，就能調試整個推理流程。
另一個關鍵能力是動作空間的轉換。策略模型輸出的動作可能是"手末端應該到哪個位置"，而機器人實際接受的命令是"每個關節應該轉多少角度"——這兩者之間需要"逆運動學"（IK）計算來橋接。框架內置了基於PyRoki的IK求解器，採用Levenberg-Marquardt非線性最小二乘法，在保證手末端軌跡連續的同時，還加了防止關節突變的懲罰項，以及偏向"安全姿態"的正則化約束。每幀動作的IK求解都從上一幀的解出發做熱啟動，保證整條軌跡的關節角連續變化，避免執行時機器人突然抖動。
**四、從謹慎調試到全速運行：五種執行模式**
EVA-Client把部署過程當作調試活動來設計，提供了一個從最安全到最激進、可以逐步升級的執行模式譜系。
最安全的是"開環仿真"模式：策略產生的動作不會發送給真實機器人，只在網頁界面的3D可視化場景里播放出來。這個模式讓研究人員可以先確認策略的動作"看起來合理"，完全沒有硬體風險。
往前走一步是"真實單塊步進"模式：機器人確實會動，但每次只執行一個動作塊（可以理解為"邁一步"），執行完就停下來等待人工確認再繼續。這樣，如果某個動作出了問題，可以精確定位是哪一步預測出了偏差，而不是在連續運動結束後只剩下"不知道哪裡出了問題"的迷惑。
更謹慎的是"仿真轉真實步進"模式：每個動作塊先在3D仿真里預演，人工看完覺得可以才放行到真實機器人執行。這在測試新策略或者在脆弱物品周圍操作時尤為有用。
最後是"連續執行"模式，也就是全速實時部署：控制循環以配置的頻率持續發出命令，推理策略在後台自動處理動作塊的調度和平滑，機器人不間斷運動，這是正式任務執行時所用的模式。
整套操作界面通過一個網頁控制台呈現，包含五個標籤頁：調試、採集、評估，以及回放和結果查看。每個標籤頁共享同一套布局——左側控制面板、中間Viser渲染的3D場景（實時顯示關節狀態和執行軌跡）、右側時間同步的攝影機畫面（含俯視和兩個腕部視角）。
**五、讓機器人動得更順暢：五種推理策略**
機器人策略的一個特點是每次推理會預測未來一段時間的動作序列，而不是只預測"下一個動作"。可以把這理解為：策略每次給出的不是"接下來動一下"的指令，而是"接下來這一小段時間該怎麼動"的腳本。問題在於，推理本身需要時間，當新的動作腳本算出來時，機器人早已執行了若干步，導致新腳本的開頭已經過時，結尾也未必能和當前狀態自然銜接。
EVA-Client統一實現了五種處理這個問題的策略，並把它們放在同一個配置界面下，方便切換和比較。
最簡單的是"同步執行"：算完一段動作腳本就執行完，再算下一段，期間機器人等著，會產生明顯的"停頓-運動-停頓"節奏。這種模式調試方便，但對於需要連續流暢動作的任務來說是個硬傷。
為了解決停頓問題，"異步預取加線性重疊混合"策略讓推理在後台線程里持續運行，同時主控制循環以機器人控制頻率持續發出命令。當新的動作腳本到來時，框架先丟棄開頭那些對應於已執行時間步的過時動作，然後在新舊腳本的重疊時間窗口內做線性混合——越靠近重疊區開頭，越信任舊腳本；越靠近重疊區結尾，越信任新腳本。這樣，動作軌跡在腳本交接處不會出現跳變。
"ACT風格時序集成"策略來自一篇有影響力的機器人學習工作（ACT），其思路是不丟棄任何已有的預測，而是讓所有覆蓋當前時間步的歷史預測都參與投票，用指數加權平均來決定最終執行的動作。越老的預測權重越大——這個設定承襲自ACT的原始設計，出發點是認為更早、更穩定的預測通常更可靠。
"樸素異步替換"策略作為對照基線：新來的動作腳本直接替換整個緩衝區，不做任何混合，但通過時間戳偏移來補償延遲。它的存在是為了讓研究人員在對比實驗中剝離"混合平滑"這個變量的貢獻。
第五種是"實時分塊（RTC）"策略：這種方法在客戶端把已提交執行的動作腳本打包發回給策略伺服器，伺服器在生成新預測時會以此為約束條件，保證新預測與機器人當前正在執行的內容天然銜接，而不是事後縫合。客戶端收到伺服器的新預測後，還會再做一次線性混合作為最後的平滑保險。
這五種策略的選擇對任務成敗有實質影響。論文展示了兩個對比鮮明的真實案例：在桌球接球這種高動態任務里，同步執行導致機器人因為每次推理時的停頓而根本來不及追球，換成異步策略後球就能打起來了；在疊衣服這種需要長時間連貫操作的任務里，異步策略的重疊混合則保持了整條動作軌跡的平滑穩定。
**六、數據採集：遙控操作直接變訓練素材**
EVA-Client不只是"用策略驅動機器人"，它同樣支持反過來"用人驅動機器人來採集數據"。採集模式（Collect）利用完全相同的控制台、機器人描述和傳輸後端，只是數據來源從AI策略變成了人工遙控。
操作方式是人手持一個"領導臂"，機器人上的"跟隨臂"實時鏡像模仿，同時框架逐幀記錄機器人的實測狀態和所接收的命令動作，兩者都同時以關節角度和末端位姿的形式保存。錄製開始前有明確的激活步驟，不會意外開始錄製。
採集到的數據直接以LeRobot格式輸出，這是一種業界通用的機器人學習數據格式：每步的觀測和動作存成列式表格，攝影機畫面存成H.264影片，附帶數據集元數據。為了滿足這種格式要求固定幀率的規定，框架在儲存時把時間戳規整為精確等間隔，同時另存一列保留原始採集時刻，兩者都不丟。
採集完成後，框架會對每一段錄製進行質量檢查，包括時間戳是否單調遞增、攝影機幀是否完整、向量維度是否正確、數值是否有限、影片和數據表長度是否一致。有問題的片段不會被靜默刪除，而是把有問題的欄位補零後保留，並標註問題原因，讓研究人員有機會審查處理。操作員隨後可以在控制台里以開環回放的方式逐幀檢查整段錄製，打上通過或不通過的標記，也可以附上文字備註，整個過程不會改動原始軌跡數據。
**七、讓評估留下證據：可追溯的評估系統**
如果說數據採集是"生產素材"，評估就是"檢驗成果"——而EVA-Client把評估過程變成了有據可查的系統流程，而不是靠印象評分。
評估在"場景"層面組織。每個場景對應一種物體擺放方式加一條任務指令，並列出若干"里程碑"——也就是任務執行過程中的關鍵節點，例如"成功抓取物體"、"成功放置到目標位置"等。每次運行後，操作員對照里程碑列表逐項評分，而不是籠統地打一個通過/不通過。這樣得到的是一個有層次的"過程分"，而不是單一的二元結果，可以更細緻地分析策略在哪個步驟出了問題。
每次試驗的結果都被持久化儲存：按（場景、位置、試驗次序）三元組索引，記錄里程碑結果、得分、持續時長、文字備註，並通過一個影片片段標識符與對應的錄像綁定，即使重啟會話也不會錯位。從這些結構化記錄出發，系統可以自動計算每個場景的成功率和每個檢查點版本的匯總統計，不需要人工再整理。
多個不同版本的模型可以在同一個會話內依次評估。切換"當前模型"時，框架透明地重新連接到新模型端點，在完全相同的場景設置下重新運行，確保不同模型的評估在同等條件下進行，結果可以直接對比。
日誌記錄方面，EVA-Client對每次運行記錄三條平行的動作時間序列：策略原始輸出的逐塊預測、經過推理策略處理後的平滑動作，以及最終實際發給機器人的執行動作。每個時間步都標註了來自哪個動作塊。有了這三條記錄，如果機器人動作出現問題，研究人員可以精確定位是策略預測本身有誤、還是平滑處理引入了偏差、還是執行層做了什麼改變。
評估結果通過一個只讀網頁查看器展示，無需連接機器人或策略伺服器即可訪問。它提供每個檢查點的統計數據、每個場景的細分結果，以及跨檢查點的並排對比視圖，每條評分記錄都鏈接到對應的影片片段和里程碑詳情。
**八、現有局限與未來規劃**
誠實地說，EVA-Client目前也有幾處尚待完善的地方。首先，它是部署基礎設施，不是策略本身，也不是基準測試集，論文中展示的任務表現是真實部署觀察，而非嚴格控制變量的對照實驗。其次，攝影機支持目前主要面向基於ROS的機器人，非ROS機器人的圖像採集還依賴各自的中間件。逆運動學求解器針對串聯機械臂設計，其他形態（如人形機器人、移動底盤）需要額外的描述類和運動學模型。
在後續規劃中，團隊提出了四個方向。一是強化學習數據閉環：把評估運行產生的軌跡和結果標籤直接用作強化學習或在線微調的素材，而不只是被動記錄。操作員在運行中途接管並糾正機器人動作的"人在環中"採集模式也屬於這一方向。二是層級策略支持：讓EVA-Client能夠託管高層規劃器和底層控制器組成的層級策略，規劃器通過掛鉤接口下發子目標，執行狀態可以上報。三是精細數據標註：在採集模式里增加對長時程任務的分段標註功能，把一段完整錄製切分為帶標籤的子任務單元，讓同一批數據在更細粒度上被復用。四是擴展機器人形態：把支持的機器人擴展到人形機器人和移動底盤，通過同一套描述類註冊機制接入。
歸根結底，EVA-Client想解決的問題說起來很簡單：機器人AI的訓練工具已經很成熟了，但把訓練好的AI真正跑在實體機器人上的那套工具，長期處於"各做各的臨時方案"的狀態。這套框架試圖填上這個空白，讓部署、調試、採集、評估這幾件事能在同一個地方、以可重複的方式完成，讓不同團隊對不同機器人跑不同策略的實驗結果有了可比性的基礎。
一個有意思的引申問題是：當部署標準化之後，機器人研究的"可重複性危機"會不會有所緩解？畢竟，如果兩個團隊報告同一個策略在同一類任務上的成功率截然不同，現在終於有了一個工具可以幫助追溯差異是來自策略本身、還是部署方式的不同。對這個問題感興趣的讀者，可以通過arXiv上的編號2607.02646找到完整論文，裡面有更詳細的技術細節和系統設計說明。
Q&A
Q1：EVA-Client支持哪些機器人型號？
A：EVA-Client目前支持Franka、UR5e、Galaxea R1-lite、AgileX Piper、AgiBot G2和ARX R5這六款機械臂。添加新機器人只需編寫一個"機器人描述類"，說明關節組、攝影機位置和通信話題即可，不需要修改框架其他部分，後續還計劃擴展到人形機器人和移動底盤。
Q2：EVA-Client的五種推理策略有什麼區別，應該怎麼選？
A：五種策略的核心區別在於推理和執行是否並行，以及如何處理前後兩段動作預測的銜接。同步執行最簡單但會產生停頓；異步預取用線性混合消除接縫；ACT風格時序集成對所有歷史預測加權平均；樸素異步替換是只補償延遲不混合的基線；實時分塊從源頭讓伺服器保證前後銜接。高動態任務通常需要異步策略，調試階段適合同步執行。
Q3：EVA-Client採集的數據是什麼格式，能直接用於訓練嗎？
A：EVA-Client採集的數據以LeRobot格式輸出，這是機器人學習領域的通用格式，包含列式儲存的觀測與動作數據表、H.264攝影機影片和元數據文件。openpi、StarVLA、GR00T等主流訓練框架都能直接讀取這種格式，採集完成後不需要額外轉換就可以送入訓練。
