BATON 讓長程機器人更穩

BATON 怎麼讓長程機器人操作比較穩？

BATON 把長程機器人操作拆成子任務探索，並用轉移感知記憶處理步驟銜接，讓長序列任務更不容易在中途失手。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：RoboMemArena 任務成功率提升 11.6%
• 突破點：子任務探索＋轉移記憶

長程機器人操作最麻煩的地方，不是單一步驟做不做得到，而是很多步串起來之後，前一步留下的狀態會不會害到下一步。這篇論文的重點，就是把這個「串接失敗」當成核心問題來處理，而不是只盯著單點技能表現。

作者的判斷很直接：現在很多 vision-language-action 模型，單看某個技能已經不差，但一旦任務拉長，錯誤就會在步驟之間累積。也就是說，模型可能會抓得起、放得下、會移動，但一旦要把這些能力接成一條完整流程，系統就開始不穩。

這篇論文要解的痛點

論文先點出一個現實：長程機器人操作不是一串獨立動作，而是會互相影響的接觸型技能鏈。抓取、放置、重新調整手腕位置，這些動作看起來都只是局部成功，但它們會改變環境狀態，進而影響下一個子任務能不能接得上。

摘要也提到，目前常見做法是把 VLA 模型凍結，交給 LLM agent 做語言規劃，再用解析式原語處理自由空間移動，接觸段落才呼叫 VLA，最後把適應資訊寫進語言記憶。這種分工聽起來很模組化，但作者認為它在長任務上會卡住，原因有兩個。

• 整個任務一起探索，成本會隨階段數放大。
• 系統缺少「轉移」的表示，導致前一子任務的輸出不一定能直接餵給下一子任務。

這也是 BATON 想處理的核心：不是只讓單步更聰明，而是讓步驟之間的銜接更可控。對機器人來說，真正難的常常不是「這一步會不會做」，而是「這一步做完之後，下一步還能不能做」。

BATON 的做法到底是什麼

BATON 的第一個改動，是把探索單位從整個長任務改成子任務。不是反覆嘗試完整流程，而是先在較短的範圍內把每個子任務探索出來，再把這些結果存進記憶，之後組合成更長的軌跡。

這種設計的意義很實際。論文把成本描述成從乘法型轉成加法型：如果每一階段都要付出探索代價，整個 K 階段任務就不該像 T^K 那樣爆炸，而是盡量接近 T*K。這不是在說長任務變簡單，而是在說探索不必每次都從頭賭整條路。

第二個重點是 transition-aware memory，也就是「知道怎麼轉移」的記憶。論文裡，子任務內有一個 verifier agent，負責控制什麼時候該叫 VLA 出來做事。只有在 wrist view 確認場景已經準備好之後，才會呼叫 VLA。這等於先做前置檢查，再讓昂貴的接觸型策略上場。

跨子任務時，BATON 進一步用了兩種轉移機制。第一個是 handoff transition，作用是把入口狀態恢復到下一步能用的樣子，避免前一個子任務留下殘留干擾。第二個是 lookahead transition，會挑出那種「後續子任務也接得住」的策略。換句話說，它存的不是單純的成功解，而是能被下一步繼承的成功解。

這裡還有一個對工程師很重要的細節：論文把 BATON 描述成 test-time 的 agentic orchestration 和 memory 方法，不更新參數。也就是說，它比較像是在既有 VLA 堆疊外面加一層控制與記憶，不是重訓一個新底模。

論文實際證明了什麼

摘要有給出一個具體 benchmark：RoboMemArena。作者在這個長程 benchmark 上，報告 BATON 的 task success 提升 11.6%，cumulative success 提升 14.9%，相較於 state of the art 有進步。

這兩個數字很重要，因為它們剛好對應論文的診斷。如果問題真的是多階段串接時的失誤累積，那麼能改善子任務重用與轉移處理的方法，理論上就應該在長序列完成率上看到效果。從摘要的結果來看，BATON 至少在作者選定的 benchmark 上，確實把這件事做出來了。

不過，摘要沒有公開完整 benchmark 細節。它沒有列出任務總數、具體 robot setup、baseline 名稱，也沒有拆出每個技能的表現。所以目前能確定的，是 BATON 在端到端長程完成度上有幫助；但還不能從摘要直接推到它在所有操作場景都同樣有效。

這裡也有一些仍待回答的問題。verifier 在視角不清楚時會不會誤判？提升到底主要來自子任務切分，還是轉移記憶本身？如果換成不同機械臂、不同感測器，這套方法還能不能保持穩定？摘要都沒有交代。

對開發者有什麼實際意義

如果你在做機器人系統，BATON 最值得注意的地方，是它把長程失敗視為系統整合問題，而不只是模型能力不足。這個角度很重要，因為很多團隊其實已經有不錯的單步策略，真正難的是怎麼把它們接成能長時間工作的流程。

子任務先探索、再組合的思路，也很符合實作現場的成本考量。短程探索通常比整條任務一起試便宜，失敗也比較容易定位。你可以知道是哪一段出問題，而不是只看到最後整個任務掛掉，卻不知道是抓取、轉移，還是放置前的狀態就已經歪掉。

更實用的是 transition-aware 這件事。真實操作裡，「成功」不等於「下一步可用」。物體姿態、手腕角度、空間餘裕、殘留接觸，這些都會影響後續步驟。BATON 的 handoff 和 lookahead 概念，提醒開發者在設計 agent 流程時，步驟之間的介面要跟技能本身一樣被重視。

但它也不是在宣稱長程機器人問題已經解掉。摘要很明白，這是一個不更新參數的 test-time 方法，而且只提供一個 benchmark 的結果。它證明的是：在既有 VLA 架構上，透過子任務探索和轉移記憶，可以讓多步操作更不脆弱；不是說所有長程 manipulation 從此都變簡單。

所以如果從工程角度看，BATON 比較像一個可借鏡的設計模式：把探索切細、把轉移顯式化、把記憶寫成能被下一步使用的形式。這種思路不一定只適用於機器手臂，也適用於任何需要多步驟接續的 agent 系統。

總結

BATON 證明了一件事：長程機器人操作的關鍵，不只是單步技能夠不夠強，而是子任務之間能不能正確銜接。

這篇摘要公開的結果是，BATON 在 RoboMemArena 上把 task success 提升 11.6%，cumulative success 提升 14.9%。細節 benchmark 沒有完全展開，但方向很清楚：把探索拆開、把轉移做實，確實能讓長序列任務比較穩。

對台灣的開發者來說，這篇比較像一個系統設計提醒。當任務長到一定程度，問題往往不在單一模型，而在模型、記憶、驗證和轉移之間怎麼接。