版本更新: Google 計劃於 2026 年 8 月 31 日停止提供舊版gemini-robotics-er-1.6-preview。其後續型號 Gemini Robotics ER 2 目前處於公開預覽階段。新的模型 ID、價格和遷移範圍請參閱ER 2 價格與 API 指南。停止日期以Gemini API 官方更新紀錄為準；下方原文將作為 ER 1.6 的歷史說明保留。
Gemini Robotics-ER 1.6 是一個具身推論模型，旨在將視覺和語言理解與對機器人有用的空間輸出連線起來。它可以推論物體、區域、軌跡和計劃，但不能替代校正感知、運動規劃、低階控制或安全系統。
工程問題是機率模型輸出如何跨越到確定性機器人棧。座標需要框架和比例，計劃需要可達性和碰撞檢查，動作需要極限、回饋和在場景或模型假設錯誤時的恢復。
本指南補充了 《物理 AI 控制迴圈》 和 GR00T 模型指南。產品存取、能力、限制和 API 行為可能會發生變化，請查閱目前的主要檔案。
ER 強調具身推論而非低層次的驅動
Google DeepMind 的 模型卡 將 Gemini Robotics-ER 1.6 描述為具備空間和具身推論能力的視覺語言模型。它能夠支援機器人應用中的感知和規劃問題。
其輸出仍然是提案或結構化資訊。機器人系統必須決定如何驗證、轉換和執行它們。不要用運動指令來描述一個點、一個方塊或軌跡。
輸入應揭示任務並協調假設
影像、影片影格、語言指令及相關上下文定義模型的檢視。相機內在因素、姿勢、裁剪、時間戳和場景變化會影響輸出與物理空間的對映。
記錄精確提示、型號辨識符號、 API 設定和輸入預處理。如果未提供機器人狀態或工具幾何形狀，模型不能被假定知道。對下游軟體消耗的每個模式納入版本管理。
定位點和盒子需要座標契約
模型可以辨識影像點、區域或物體位置。下游程式碼必須知道座標是畫素、正規化值、攝影機影格位置還是其他約定。影像大小調整和方向必須保持一致。
驗證座標與已知標記和物體的關係。拒絕越界、模糊或低信心分數輸出。視覺上合理的疊加仍可能在度量上錯誤，無法用於抓取。
| 輸出 | 有用的 | 必須轉換 | 關鍵檢查 |
|---|---|---|---|
| 指向或盒子 | 物體指代定位 | 影像座標對映 | 界限與同一性 |
| 深度或幾何形狀 | 空間關係 | 相機校正與比例 | 度量誤差 |
| 軌跡草圖 | 意圖或路徑提示 | 時間與機器人框架 | 碰撞與可達性 |
| 任務規劃 | 動作序列 | 技能與狀態對映 | 前提條件與恢復 |
空間推論必須與校正後的幾何結構進行調和
機器人規劃使用攝影機模型、變換、運動學和環境幾何。模型的語意理解可以選擇物件或關係，而校正感知則提供度量姿態和不確定性。
顯式融合源，而不是默默用模型估計替換幾何。每次變換和觀察都給時間戳。動態場景需要在執行前確認，因為推斷後人或物體可能會移動。
官方示例展示了介面邊界
官方機器人文件展示了模型輸出如何描述場景元素和軌跡。這些示例有助於定義可能的 API 互動，而非保證在任意機器人、攝影機和任務間的成功。
用置頂輸入復現示例，然後測試被保留的物體、光線、雜亂和視角。測量有效輸出以及棄權或失敗行為。展示應轉化為可重複的測試。
計劃應該對映到受限的技能庫
語言層面的計劃如“揀選”、“放置”或“開啟”應定義為具有明確參數、前提條件、限制和成功檢定的技能。自由文字不應直接傳遞給無限制機器人動作。
執行層可以請求澄清、重新觀察或在參數缺失時停止。技能應報告已驗證的結果和失效程式碼，以避免模型或規劃器假設已完成。
動作規劃和控制仍然是分開的安全邊界
地面目標進入反向運動學、碰撞檢查、軌跡生成和低空控制。關節限制、速度、力、工作區和保護區均獨立執行，不依賴模型建議。
透過感知和機器人回饋監控執行。僅在有限制規則內重新規劃；否則安全停止。安全級功能應排除在一般模型之外，除非在適當的架構中經過特別驗證。
| 失敗 | 檢測 | 立即反應 | 工程證據 |
|---|---|---|---|
| 錯誤的物體 | 身份驗證 | 不要執行 | 混淆矩陣與試驗 |
| 影格不匹配 | 幾何合理性檢查 | 拒絕輸出 | 校正測試 |
| 無法到達的目標 | 運動學檢查 | 請求替代方案 | 可達性覆蓋 |
| 碰撞路徑 | 規劃器檢查 | 阻止軌跡執行 | 場景套件 |
| 場景轉換 | 新鮮觀察 | 停止或重新規劃 | 延遲與動態測試 |
評估需求、任務分母和失敗分類法
統計有效的試驗數，而不僅僅是成功的例子。區分物件基礎、空間精度、計劃有效性、運動可行性、執行成功率和恢復。最終任務失敗可以從任何層開始。
使用保留的場景和帶有受控變異的重複試驗。報告介入、延遲、無效輸出和戒除率。與同一工作流程下更簡單的感知或指令碼基線進行比較。
延遲、成本和隱私都會影響部署
雲 API 呼叫引入了網路延遲、可用性和資料治理問題。本地預處理和快取可以提供幫助，但不應造成過時狀態。當服務不可用時，系統需要超時和明確的行為。
衡量端對端決策時間和任務價值，而非僅僅建模延遲。審查來自工作場所或人員影像的資料保留、存取控制及區域需求。部署前應查核目前服務條款。
漸進式整合路徑降低了硬體風險
先從錄製影像和離線評分開始，然後使用陰影模式、模擬和防護機器人設定。在擴充任務或速度前，要求在每個邊界進行確定性驗證。
維護提示、模式、校正、測試和紀錄作為版本管理工件。當模型在機器人保持有限制控制和安全恢復的同時，提升已驗證的任務結果時非常有用。
評估“Gemini Robotics-ER 1.6：空間推論、API 輸出與整合”時，還應儲存模型版本、機器人設定、校正檔案、測試日期和全部試驗記錄。
只有把這些持續投入與單位成功任務的價值比較，才能判斷方案是否適合擴大。
上線後仍要持續檢查分佈變化、感測器漂移、機械磨損和人工接管原因。
實際專案還應指定資料、模型、控制器和安全流程的負責人，並預先定義回復條件。責任邊界、審批記錄與變更紀錄越清楚，故障發生後越容易停止擴散、定位原因並安全恢復。
把任務拆成感知、決策、動作執行和結果確認，可以更準確地定位瓶頸。每一階段都應有獨立指標與失敗示例，避免用端對端成功率掩蓋偶發但嚴重的風險。
引用的產品規格、論文結果和監管要求需要記錄釋出日期與適用版本。資料更新後應重新核對關鍵結論；無法從一手來源確認的內容，應明確標註為待驗證資訊。
小規模試點的價值在於提前暴露介面、人員協作和異常處理問題。試點結束後應依據預設門檻決定擴大、修改或停止，而不是因為已經投入資源就預設繼續。
所有結論都應能夠追溯到原始記錄，並可複核。
介面定義變化時，舊資料和舊控制參數不能在未經驗證的情況下直接複用。
異常測試應覆蓋斷電、通訊丟失、感測器失真、物件滑移和人員進入工作區等情形。系統不僅要發現異常，還應以可預測的方式減速、停止或請求人工確認。
- 固定模型版本、提示詞和輸出模式。
- 定義座標、影格和比例。
- 驗證幾何形狀、可達性和碰撞。
- 只透過限制技能和控制來執行。
- 測量故障、延遲、介入和恢復情況。
常見問題
什麼是 Gemini Robotics-ER 1.6？
它是一種具身推論的視覺語言模型，旨在提供在機器人應用中有用的空間基礎理解。
Gemini Robotics-ER 能直接控制馬達嗎？
單獨不行。其輸出應透過幾何驗證、規劃、低層控制和獨立安全限制。
機器人模型能提供哪些定位輸出？
根據目前的 API 類型，示例可以包括點、區域、空間關係、軌跡或結構化任務規劃。
應如何評估 ER 輸出？
測量定位準確率、座標有效性、計劃可行性、任務成功率、延遲、介入措施及失敗恢復，均為多次進行的試驗。
它能取代機器人安全系統嗎？
不。安全功能需要基於危害的架構和經過驗證的保護機制，獨立於一般機率模型輸出。
型號與 API 版本說明
模型的可用性、存取、 API 模式和能力可能會發生變化。請確認目前的官方模型卡和檔案、引腳版本，並將幾何、控制和安全驗證排除在不可信的模型輸出之外。