HANDOFF 讓人形機器人更好控

HANDOFF 用更精簡的控制介面，把三種專家能力蒸餾進單一人形控制器，讓規劃器更容易下指令。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：摘要無公開 benchmark 數字
• 突破點：上下文門控蒸餾

這篇論文在解的問題很直接：人形機器人要做任務，規劃和控制之間常常講不同語言。規劃器想的是「去那裡、拿起來、站穩」，控制器卻常常要吃很密的運動參考。HANDOFF 想把這個中間層縮小，做成一個更適合規劃器使用的控制介面。

對開發者來說，這不是抽象的學術修辭，而是實作上的痛點。當控制介面太細，規劃器就得自己補出很多低階細節；當介面太粗，又會讓機器人缺乏表達能力。HANDOFF 的定位，就是在這兩者中間找一個比較好用的點。

它想解的，是規劃器和控制器之間的落差

摘要把瓶頸講得很清楚：既有的人形全身控制器，通常需要密集的運動學或空間參考。這類輸入對已經知道怎麼動的系統很友善，但對只知道任務語意的規劃器來說就很彆扭。

想像一下，規劃器知道的是高層意圖，例如移動、抓取、恢復平衡；但控制器要的卻可能是更細的姿態、軌跡或身體配置。中間這段翻譯工作如果做得不好，整個機器人系統就會卡住。HANDOFF 的核心，就是把這段翻譯變得更短、更穩定。

這也解釋了為什麼這篇論文會把「介面」放在第一位。它不是先追求一個更大、更複雜的 policy，而是先問：規劃器到底該怎麼跟人形機器人說話，才不會每次都要重寫一套低階控制細節？

HANDOFF 的方法，白話講是什麼

方法本身可以拆成兩個重點。第一，作者設計了一個更緊湊、明確的人形控制介面。第二，他們不是把這個控制器從零開始硬練出來，而是把多個專家能力蒸餾進同一個學生模型。

這些專家不是同一種人，而是各有分工：一個負責全身運動追蹤，資料還帶有安全過濾；一個負責行走；一個負責跌倒恢復。也就是說，作者不是假設一個單一模型可以自然學會所有能力，而是先把不同技能拆開，再想辦法整合。

整合的方式是 multi-teacher KL distillation，再加上 context-conditioned gating。前者是蒸餾方法，後者則像是動態分配權重的開關：系統會根據情境，決定哪些專家的影響力要大一點，哪些要小一點。這讓學生控制器不是死背技能，而是能依照情境切換側重。

從架構角度看，這是一種 mixture-of-experts 的思路，但重點不只是「多專家」，而是「有上下文的多專家」。如果沒有 gating，幾個專家的知識可能只是混在一起；有了 gating，系統才比較像是在不同情境下調用不同能力。

這個設計也很符合人形機器人的現實需求。走路、追蹤、站穩、跌倒恢復，本來就不是同一種控制問題。把它們硬塞進一個完全平坦的 policy，通常不會比拆開再整合更好。HANDOFF 的做法，是把複雜性留在訓練階段，讓執行階段更單純。

論文實際證明了什麼

摘要給出的結果，重點放在 Unitree G1 上。HANDOFF 被描述為能達到 state-of-the-art 的 velocity tracking，同時還擁有「最大的 robust manipulation workspace 之一」。這是原始資料裡唯一明確的性能結論，但摘要沒有公開完整 benchmark 數字，所以沒辦法從這裡直接比較差距有多大。

另一個值得注意的點，是它不只停留在模擬。摘要說作者在硬體上展示了多個由自然語言驅動的任務 roll-out，而且沒有使用 task-specific data，也沒有做 controller fine-tuning。這代表它想證明的不是單一技能分數，而是整個系統的可組合性。

這裡的訊號很重要。很多機器人方法在論文裡看起來很漂亮，但一上真機就要重新調參、重訓、換資料。HANDOFF 的摘要至少主張了一件事：它的介面和蒸餾後控制器，能讓 VLM 驅動的 agentic planner 直接下任務，而不需要針對每個任務再特調控制器。

不過，這篇摘要也很克制。它沒有提供成功率、延遲、workspace 的實際數值，也沒有列出完整對照組。換句話說，摘要層級只能知道它「做得到」，還不能完整判斷它「贏多少」或「在哪些條件下會失效」。

為什麼這對開發者有意義

如果你在做機器人軟體，這篇最值得看的不是某個單點技巧，而是系統切法。HANDOFF 把 planner 和 controller 之間的邊界，當成一個需要被設計的產品介面，而不是理所當然的實作細節。這種思路很像做 API：介面好不好用，常常比底層實作更決定整體體驗。

對 agentic robotics 來說，這尤其重要。當語言、視覺、規劃和控制都要串在一起時，最容易爆掉的地方往往不是單一模組，而是模組之間的接縫。如果控制介面太硬，規劃器就會很痛苦；如果介面太鬆，控制器就會失去約束。HANDOFF 想做的，就是把這個接縫收斂成一個比較穩定的中介層。

它的多教師蒸餾也提供了一個實用模式。真實的人形行為本來就不是一種技能，而是一包技能的組合，而且這些技能常常來自不同資料、不同安全條件、不同訓練目標。把它們蒸餾到同一個 context-gated student，等於是在維持多樣性的同時，降低部署時的複雜度。

對工程團隊來說，這種做法的吸引力很明顯：你不一定要為追蹤、行走、恢復各自維護一套完全獨立的控制堆疊。若介面設計得夠好，理論上可以讓上層規劃更容易接上去，底層執行也更一致。這對要做長鏈任務的人形系統，會比單純追求單一 benchmark 更有實際價值。

它的限制，也很明確

首先，摘要沒有公開完整 benchmark 細節。這表示我們目前只能知道它在 Unitree G1 上有幾個正向結論，卻無法從摘要判斷提升幅度、穩定性邊界，或是跟其他方法相比的具體優勢。

其次，摘要沒有說這套方法能不能順利跨到不同機型。它展示的是 Unitree G1，但沒有交代是否能轉移到別的人形平台、不同感測器配置，或不同任務族群。對想把方法拿去落地的人來說，這是很關鍵的空白。

第三個問題是 gating 在新情境下會怎麼表現。mixture-of-experts 很強，但前提是 gate 要判斷得對。當機器人遇到訓練分佈外的狀況時，該偏向哪個專家、要不要切換，這些都會影響結果。摘要沒有回答這點，所以仍需要看全文。

也因為這些限制，HANDOFF 比較像是一個架構方向的證明，而不是一份完整的性能報告。它證明的是：把控制介面做小、把多種專家能力整合到一個 context-aware 的學生模型裡，確實可以支撐真機上的自然語言任務執行。

這篇論文真正傳達的訊號

HANDOFF 最重要的訊號，不是它又做出了一個更大的模型，而是它把「人形機器人怎麼接任務」這件事，提升成第一級設計問題。這很像把資料庫 schema 或 API contract 放到產品核心位置：你不先處理好接法，後面再強的能力都很難順利組合。

從研究角度看，它把三種互補能力——全身追蹤、行走、跌倒恢復——收斂成一個可被規劃器使用的控制器。從系統角度看，它試圖讓 VLM 驅動的 agent 不必碰太多低階控制細節。從部署角度看，它至少在摘要裡聲稱自己能在真機上跑自然語言任務，而且不靠 task-specific data 和額外 fine-tuning。

所以，如果你關心的是人形機器人怎麼從「能動」走向「好接任務」，這篇的價值就在這裡。它不是單純把控制做得更強，而是把控制變得更好用。對開發者來說，這種改變往往比多幾個百分點的分數更接近真正能落地的系統。

總結一句，HANDOFF 證明了人形控制可以被整理成更適合規劃器使用的介面，並透過上下文門控的多教師蒸餾，把多種專家能力整合進單一控制器。摘要沒有給完整數字，但它已經清楚指出：在人形機器人裡，介面本身就是性能的一部分。

• 它把人形控制的關鍵，放在規劃器與控制器之間的介面設計。
• 它用上下文門控蒸餾，把追蹤、行走、恢復整合成單一控制器。
• 它在 Unitree G1 上展示真機任務 roll-out，但摘要未公開完整數字。