πR² 讓流式策略即時反應

做機器人控制的人很熟這個痛點：模型先吐出一整段動作，結果環境早就變了，手還在照舊往前走。

πR² 讓流式策略在執行中就能反應，靠快慢雙通道與單步延遲自適應去噪，把重規劃速度拉高。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：最高提升 30% 實機成功率
• 突破點：快慢輸入分流

這篇論文要解的，不是「模型會不會做」，而是「模型來不來得及做」。在機器手臂、抓取、操作這類任務裡，政策常常是一次產生一段 action chunk，再一路執行到結束。這種做法在靜態場景還行，但只要物體滑了一點、手臂姿態變了、或感測更新慢了，原本那段動作就可能變成過期指令。

作者的切入點很直接：不要放棄大型 pretrained backbone，也不要放棄多動作預測，但要讓策略能在閉迴路裡更快重規劃。換句話說，問題不是「策略夠不夠強」，而是「策略能不能跟得上真實世界的節奏」。

πR² 想改什麼

πR² 建在 diffusion forcing 的 per-position noise schedule 上，再往上加兩個設計。第一個是把 conditioning 拆成快、慢兩條路。proprioception 走快通道，每個 tick 都更新；vision-language 特徵走慢通道，可以非同步刷新。這樣一來，機器人的即時身體狀態可以先被看見，不必等較重的視覺語意特徵一起更新。

第二個是 latency-adaptive 的 flow schedule。它不再假設每次推理都要經過固定多步去噪才吐出一段動作，而是把執行中的動作當成 inpainting conditioning，讓每次呼叫只做一步去噪就能輸出動作。這個做法的重點很務實：把每個控制週期壓到夠便宜，模型才有機會在硬體延遲變動時仍然維持反應速度。

這也解釋了為什麼論文把 latency 當成一等公民。真實系統不會永遠跑在理想時序上。GPU 負載、感測器同步、模型大小，都會影響 policy 能多久重規劃一次。πR² 嘗試吸收這些波動，而不是要求整個系統硬體與排程都完美配合。

方法怎麼運作

可以把這個策略想成兩種輸入來源。第一種是機器人的即時身體狀態，例如關節位置、夾爪狀態、其他 proprioceptive 訊號。這些東西每個控制 tick 都在變。第二種是比較重的上下文，像視覺與語言特徵。這些資訊更新較慢，但對長一點的動作分塊仍然重要。

πR² 的重點是：這兩種資訊不該用同一種更新節奏處理。因為它們的「新鮮度」本來就不同。手現在在哪裡，應該立刻反映；相機 embedding 就算慢幾毫秒，對 chunked policy 來說未必致命。這不是理論上最華麗的改法，但很像真正會落地的工程取捨。

延遲自適應那一塊也很實際。作者不是假設永遠有固定算力預算，而是讓模型根據可用時間調整，並把 in-flight actions 當作 inpainting 的條件。結果就是，每次控制循環都能盡量維持便宜，讓同一個訓練好的模型在不同硬體延遲下都還能用。

對開發者來說，這裡不必先被 diffusion 名詞卡住。重點是：這個 policy 不是等整段推理做完才動，而是設計成能在執行途中持續修正，讓閉迴路控制更接近真實需求。

論文實際證明了什麼

摘要給了一個很具體的部署故事：作者把 πR² 從預訓練策略 GR00T-N1.7 微調而來，並在 xArm6+XHand 的實機平台上測試。根據摘要，這個方法讓 closed-loop replan 的速度比原始策略快約 4 倍，在 A5000 GPU 上可達約 25 Hz，並且能每 40 ms 接收一次新觀測。

這是摘要裡最有感的結果。它不是在說機器人突然變聰明很多，而是在說控制迴圈終於夠快，能跟上環境變化。對操作型任務來說，這種「來得及反應」本身就是性能的一大部分。

摘要也提到，πR² 在模擬與實機操作任務上都有成功率提升。數字上，模擬最高提升 23%，實機最高提升 30%，相對於最強 baseline。這些數字很值得注意，但摘要沒有公開完整 benchmark 細節，也沒有列出任務清單、逐項結果或 baseline 的完整身份，所以不能再往外延伸。

同樣重要的是，摘要沒有提供完整的 benchmark 表、信賴區間、ablation 數據或失敗案例統計。也沒有說快慢通道與 latency-adaptive schedule 各自貢獻多少。也就是說，從摘要能確定的是「整體方案有效」，但還不能精準拆解是哪一個設計帶來最大增益。

為什麼這對開發者有用

如果你在做機器人系統，這篇很像是把「模型能力」和「系統延遲」綁在一起看。很多 policy 工作默認模型可以先思考、再慢慢輸出動作。但真實機器人沒有這種奢侈。它需要的是能跟物理世界同步更新的策略。

πR² 的有趣之處在於，它沒有要求工程師放棄大型 pretrained backbone，也沒有放棄多動作預測。它做的是把這些東西變得更適合閉迴路控制，而且看起來不需要整個架構重寫。對部署端來說，這代表可以用 finetune 的方式延續既有策略，而不是從零重建一個控制器。

這也帶出一個更大的系統觀念：延遲不是事後補丁，而是設計條件。對 embodied AI 來說，紙面上最強的 policy，不一定是硬體上最有用的 policy。只要反應慢一步，就可能在實際操作裡失分。

還有哪些限制

即使有這些提升，摘要仍留下不少問題。它沒有說這個方法在不同機器人本體、不同感測配置、或不同算力預算下是否同樣穩定。也沒有說 one-step denoising 在需要更長期規劃、或更複雜多模態推理的任務裡，是否還能維持效果。

另一個未解點是 latency-adaptive schedule 的泛化範圍。摘要說同一個訓練好的模型可以適應不同硬體延遲，這很吸引人，但沒有交代測試過的延遲範圍，也沒有說當條件變差時，表現會怎麼退化。

所以這篇的結論應該講得保守一點：它證明了大型 flow policy 不必只能慢慢跑，也可以被改造成接近即時反應的閉迴路控制器。但摘要本身還不足以讓我們判斷，這套方法在更廣泛的硬體與任務條件下會不會同樣漂亮。

對實作的直接啟發

如果你要把這篇想成工程建議，最值得記住的是兩件事。第一，輸入的更新頻率可以分層，不必把所有感測都綁成同一個節拍。第二，推理流程可以依延遲調整，不一定要死守固定步數的去噪流程。

這兩點合在一起，才是 πR² 的核心價值。它不是單純把模型做小，而是把模型的反應節奏改得更像真實控制系統。對做 manipulation、抓取、或任何需要即時修正的任務來說，這種設計比單純再加大模型更接近可部署。

如果你的系統現在也卡在「模型會做，但來不及修正」，這篇提供的是一條很明確的路：保留大策略的表達能力，然後把 runtime 做成可反應、可重規劃、可適應延遲的形狀。這就是它真正的工程意義。

• 快慢雙通道把即時 proprioception 和較慢的 vision-language 特徵分開處理。
• 單步、延遲自適應去噪讓重規劃更接近即時控制。
• 摘要中的實驗結果顯示，實機成功率最高可提升 30%，且 closed-loop 重規劃約快 4 倍。

對做機器人策略的人來說，這篇的訊息很清楚：flow policy 不一定要犧牲反應速度，才能保留大模型的能力。