NVIDIA 已發布一份教學，說明如何在不同硬體平台之間訓練機器人導航策略，並利用 AI 代理自動化大部分工程工作流程，同時保留人工核准關卡。參考實作將 NVIDIA 預先訓練的 X-Mobility 策略，調整到 Boston Dynamics Spot 四足機器人，以及不同的模擬或重建環境中。

這項工作之所以重要，是因為導航不只是讓機器人移動而已。導航系統必須結合感知、定位、路徑選擇、避障與運動控制，並且對不斷變化的周遭環境做出反應。若要把這種能力移植到新的機器人或場景，往往需要為每一種組合建立新的介面、模擬資產、訓練執行、除錯與評估。

NVIDIA 的文章將 COMPASS，也就是 Cross-Embodiment Mobility Policy via Residual RL and Skill Synthesis，作為降低這類重複工作的方式。該公司將此工作流程定位為開發者參考實作，而非報告新的商業部署或獨立效能結果。

COMPASS 如何將導航適配到新機器人

COMPASS 從預先訓練好的 NVIDIA X-Mobility 策略開始；根據 NVIDIA 的說法，該策略提供的是從單一 embodiment 的專家示範中學得的通用導航行為。COMPASS 並非為每個目標平台重新訓練完整導航策略，而是透過強化學習訓練一個殘差專家。

這個專家會為選定的機器人與環境學習修正動作。實務上，基礎策略提供起始行為，而殘差策略則調整輸出，以因應目標機器人的本體、感測器、動力學或場景。NVIDIA 表示，針對多種 embodiment 訓練出的專家，最終可蒸餾成一個共通的跨身體策略，不過教學證據並未提供該後續蒸餾步驟的結果。

參考工作流程使用 Boston Dynamics Spot，並沿著三條場景路徑進行。第一條是內建倉庫，旨在提供最可重現的設定。第二條使用由 SAGE-10K 生成的室內環境。第三條則使用透過 NVIDIA Omniverse NuRec 重建的擷取環境，為開發者提供在真實地點表徵上測試的可選路徑。

在執行時，匯出的策略會讀取 RGB 相機資料、里程計與目標點，然後透過 /cmd_vel 發佈速度命令。當機器人無法提供相容的狀態估計與轉換時，NVIDIA cuVSLAM 可提供部署用里程計。

AI 代理組織訓練管線

這份教學的獨特之處不在於 AI 代理在執行時控制機器人。NVIDIA 明確區分了開發自動化與執行：程式撰寫代理負責準備與訓練，而訓練完成的策略與機器人控制器則在部署後執行導航。

開發者先指定機器人、場景來源與導航目標。接著，代理會利用儲存庫技能檢查相依性、準備場景資產、執行 smoke test、啟動殘差強化學習、診斷失敗、比較 checkpoints，並將結果打包供執行時使用。NVIDIA 表示，教學在開發期間使用 Codex，而同樣的工作流程也可透過儲存庫中的 COMPASS 技能在 Claude Code 中呼叫。

人工介入仍是設計的一部分。核准關卡涵蓋場景接受、單一環境 smoke test，以及 checkpoint 的晉升。這對機器人團隊很重要，因為自動化訓練迴圈否則可能在沒有人察覺前，就把大量算力耗費在無效場景、損壞的介面或不安全策略上。

此工作流程也保留中間證據。訓練會定期儲存 checkpoints、追蹤獎勵組成與安全指標，並支援在相同條件下比較基礎 X-Mobility 策略與殘差候選項。目標是讓失敗與改進更容易檢視，而不是把最終 checkpoint 當作充分證明。

NVIDIA 的證據說明了什麼、沒說明什麼

來源材料是 NVIDIA Developer Blog 的教學與參考實作。它確認了工作流程設計、支援元件、軟體堆疊、輸入與輸出，以及評估程序。它沒有提供系統的獨立評估、客戶部署，或 COMPASS 持續優於其他導航方法的量化主張。

NVIDIA 將目標達成率、跌倒率與行進時間列為 COMPASS 的標準評估指標。比較設計上要讓基礎策略與殘差候選使用相同的 seed、目標與 rollout 條件。這種相同條件設計有助於分離適應效果，但提供的材料並未包含最終分數或任何改善幅度。

硬體與軟體需求也顯示，這是一套相當完整的開發環境。NVIDIA 列出 Ubuntu 22.04 或 24.04、至少 32 GB RAM、至少 16 GB VRAM 的 RTX 相容 GPU、Docker Engine 24 或更新版本，以及 NVIDIA Container Toolkit。測試堆疊包含 NVIDIA Isaac Lab 3.0 與 NVIDIA Isaac Sim 6.0，並將 GeForce RTX 4080 列為 Isaac Sim 6.0 的最低參考 GPU。

這套流程並非完全無門檻。開發者需要 Hugging Face 帳號與讀取權杖，才能存取包含 COMPASS 與 X-Mobility 資產的受限 NVIDIA 儲存庫。NVIDIA 也建議安裝前先執行 Isaac Sim Compatibility Checker。這些細節讓具備相容基礎設施的團隊更容易重現教學，但也限制了較小型機器人團隊驗證此方法的速度。

為什麼這個工作流程對機器人團隊很重要

對機器人製造商與自主系統開發者而言，最主要的潛在好處是降低適配成本。若一個策略能保留通用導航行為，同時學會殘差修正，就可能不必為每一種新底盤、感測器配置或環境重建整個堆疊。這對於同時混用不同機器人形態，或在倉庫、辦公室與客戶現場運作的車隊尤其有用。

代理驅動流程在另一個層面也可能有價值。以模擬為基礎的機器人工作，常常會卡在資產準備、middleware 設定、環境有效性、訓練腳本與評估之間的交界。一個把這些程序編碼進去的儲存庫技能，讓 AI 代理擁有可重複執行的操作契約。接著，核准關卡就在自動檢查與高成本或具重大影響的下一步之間，插入人類決策。

這並不代表不需要工程審查。殘差強化學習仍可能在不完整的模擬上最佳化，而相符條件下的模擬指標也未必能預測實體硬體上的行為。團隊仍需在教學參考路徑之外，驗證感測器時序、里程計品質、碰撞行為、恢復動作與安全限制。使用 Spot 也只是個有用的示範目標，並不能證明每一種機器人都能以相同努力完成適配。

因此，對企業買家來說，眼前的訊號是工作流程成熟度，而不是一款已證實可直接上手的產品。其價值取決於儲存庫技能能否可靠地延伸到公司的機器人介面、模擬資產、部署控制與驗證標準。

接下來要觀察什麼

下一個具體訊號是 NVIDIA 或外部開發者是否會針對內建倉庫、SAGE-10K 場景與 NuRec 環境發布結果，包括與基準的比較以及實體機器人驗證。若能公布跌倒率、行進時間與目標達成率，將更容易超越實作細節來評估這個框架。

開發者也應關注是否支援更多機器人 embodiment、更廣泛的感測器配置，以及多個殘差專家能否蒸餾成單一共享策略的證據。Codex 與 Claude Code 中儲存庫技能的成熟度也很重要：有用的進展包括更清楚的失敗復原、可重現的日誌，以及能對應真實部署審查的核准控制。

最後，市場上的關鍵問題是：這種方法是否能縮短模擬到真實的適配時間，而不會把過多複雜性轉移到環境重建、里程計設定與安全測試上。NVIDIA Omniverse NuRec 與 NVIDIA cuVSLAM 或許能擴充可用工作流程，但它們的實際價值取決於目標環境中的結果，而不是它們是否出現在參考堆疊中。

Creati.ai 觀點

NVIDIA 的公告最好被理解為一個工程工作流程的發布，而不是證明 AI 代理已解決跨身體機器人問題的證據。其最強的貢獻，是殘差策略適配、儲存庫層級自動化、checkpoint 證據與明確人工關卡的結合。

這種組合正面對機器人團隊的一個真實瓶頸：把策略構想變成可測試成果所需的碎片化工作。若獨立使用者能重現這條管線、在實體機器人上量化收益，並證明代理自動化能提升可靠性而不削弱安全審查，這種方法的重要性就會更高。