Google 在 2026 年 7 月 30 日把 Gemini Robotics ER 2 以 public preview 形式放進 Gemini API。ER 指的是 embodied reasoning：把文字、圖片、影片或音訊，轉成對實體世界可用的空間理解與任務規劃。

一般聊天模型主要回覆文字；ER 2 可以在畫面中指出物件，輸出點、軌跡或邊界框。這讓模型不只說「我看到一個方塊」，還能說方塊位於畫面的哪裡。

螢幕上的一個點，還不是機械手臂可以安全抵達的一個點。

模型回傳的 `[620, 340]` 不是馬達電壓、關節角度，也不是工廠現場的公釐座標。系統仍要完成相機校正、影像座標到機器人座標的轉換、深度估計、碰撞檢查與路徑規劃。任何一層對不上，模型找到的位置就不等於機械手臂能安全抵達的位置。

指令若是「把藍色積木放進橘色碗裡」，模型要先找出兩個物件，再安排靠近、下降、夾取、抬高、移動、放下與鬆開。

Google 的 task orchestration 文件用開發者自訂的 robot API 示範這條路徑。開發者先定義 move 與 setGripperState 等工具，模型依序提出函式呼叫，外部程式執行後再把結果傳回模型。

它像會看現場的調度員，不是直接把電流送進馬達的人。

官方範例使用 mock robot API，並設置 max_steps，避免代理迴圈沒有上限。這能證明工作流怎麼串起來，不能證明任何品牌、任何負載的機器人都已經可以直接量產部署。

Gemini Robotics ER 2 同時提供標準端點與串流端點。兩者不是「慢版」與「快版」這麼簡單，而是面對不同的輸入節奏。

如果任務可以停下來等一次判斷，先用標準端點；如果環境持續改變，才評估串流端點。串流不代表零延遲，也不代表每一幀都會得到完全一致的判斷。

兩種端點都要先寫好逾時、低信心、工具失敗與人工接管。

Google 在公開預覽限制中仍列出延遲、幻覺、提示品質與運算成本。端點選對，只是把資料送進模型的方式選對，並不會自動完成安全控制。

完整鏈條至少有四段：感知輸入、ER 2 的推理與規劃、開發者定義的 robot API 或 VLA、實際控制機械手臂的低階控制器。

模型可以提出「移到這裡」或「關閉夾爪」；外部系統必須先判斷這個要求是否在允許範圍，再把它轉成機器人能執行的軌跡與訊號。模型輸出若是錯的，外部控制層仍應有能力拒絕。

「支援 Gemini」不是控制與安全責任的完整答案。

台灣的機器人整合商、工廠資訊部門與採購者，還要問：支援哪一種機器人介面？座標怎麼校正？模型逾時時會停在哪裡？工具參數有沒有白名單？每一步是否留下紀錄？人進入工作區時，誰有權立即切斷動作？

Google DeepMind 把機器人安全描述成多層防護，包括語意、實體與操作層。官方同時表示，人員進入工作區時停止仍是研究方向，不是具安全等級保證的系統；模型也沒有在每一款機器人上完成測試。

模型只能提出動作；外部安全系統決定能不能動。

模型看見危險，可以多一道提醒；它不能取代最後一道保護。實際部署還需要安全 PLC、碰撞偵測、步數上限、人工核准與完整紀錄。

ER 2 是公開預覽版。官方文件列出的限制包括 API key 存取限制、延遲與效能取捨、幻覺、提示品質，以及運算成本。這些不是附註，而是決定它能不能接進現場的重要條件。

1. 幻覺：模型可能找錯物件、產生不合理座標，或提出錯誤工具呼叫。
2. 延遲：網路與推理等待會改變移動物體的真實位置。
3. 提示敏感：同一個模糊指令可能得到不同的步驟與參數。
4. 成本：持續串流影像與音訊會增加運算與連線負擔。

Google 也預告 Gemini Robotics ER 1.6 將於 2026 年 8 月 31 日停用。對開發團隊來說，模型版本更迭本身就是供應鏈風險：介面、提示、行為與測試基準都要留出升級空間。

Demo 成功證明「有可能」；安全上線還要證明「失敗時會怎樣」。

採購時不要只問「支不支援 Gemini」。要問清楚：整條控制鏈由誰負責？哪些元件有安全認證？模型逾時或回傳錯誤時，機器人會停在哪裡？每一次動作能不能追溯？

Gemini Robotics ER 2 能看、能想、能排步驟；要不要動，以及如何安全地動，仍是系統工程。