把 Gemini Robotics-ER 1.6 接上 MOTOMAN NEXT，最大的好處是讓高階推理不用重新發明工業機器人的動作控制；代價則是多了一條模型、任務、控制與安全之間的介面鏈。展示能復原掉落物，是有用證據，但還不是可採購方案。
Yaskawa 官方公告用一句話說明分工：Gemini 決定『要做什麼』，MOTOMAN NEXT 決定『如何移動』。這個邊界比『AI 直接控制每個關節』更接近公開架構，也更適合拿來分配驗證責任。
先確認誰正在做選擇
工廠若已有可靠的夾具、軌跡與 PLC 邏輯，需求可能只是增加物件理解與異常分類；若工作本身高度變動，才需要模型提出任務步驟。兩種場景不能用同一套成功率評估。前者關心介面穩定與停機，後者還要評估提示、場景理解與計畫錯誤。可先閱讀 Gemini Robotics-ER 1.6 專文確認模型能力，再回到本次 Yaskawa 整合的證據。
選擇前先把產品變動率、任務變動率與風險分級。零件每天換、擺放常變但接觸風險低的工作，可能適合讓模型規畫；焊接、重物或靠近人員的固定工序，即使語意理解很好，也應把動作限制在審核過的技能庫。這樣能避免把『可理解新指令』誤當『可自由產生任何動作』。
現場還要決定誰能下達自然語言任務。一般操作員、工程師與遠端維護人員的權限不同，提示也可能包含錯誤或互相衝突的目標。任務進入模型前應有身分、來源、時間與允許範圍；沒有授權的指令必須在到達控制層前被拒絕。
Gemini 適合處理語意與任務層
Google DeepMind 對 ER 1.6 的說明聚焦具身推理：理解環境、拆解目標、推演步驟並向機器人系統提供高階指令。它可以判斷物件掉落後是否需要重新抓取，卻不應在沒有機器人控制層約束的情況下直接送出每個馬達命令。
模型輸入若缺少視角、物件狀態或任務上下文，語意上合理的計畫仍可能在實體空間不可行。因此要保存模型版本、輸入影像、提示、輸出計畫、信心與拒絕理由。
Gemini 的輸出最好是具結構的任務、物件、限制和成功條件，而不是模糊文字。系統應檢查物件是否存在、目標是否可達、工具是否正確，再把每一步映射到已驗證技能。若模型無法確定，明確拒絕比產生貌似合理的下一步更有價值。
展示掉落物復原時，也要問它如何知道物件已掉落、何時停止原流程、是否重新辨識，以及失敗後會重試幾次。若這些判斷依賴固定攝影機和預設位置，就不能直接外推到移動相機、遮擋或多人工作區。
MOTOMAN NEXT 承擔可執行的身體層
Yaskawa 將機器視覺、路徑規畫與力感測列為 MOTOMAN NEXT 的身體能力。這一層要把高階目標轉成可達姿態、避碰路徑、接觸力與停止行為。夾具幾何、校正、工作區、速度與安全邏輯，不能因為上層模型更聰明就省略。
機器人 VLA 評估可用來區分語言指令理解、動作計畫與真實控制結果。若只報最終成功，不保留在哪一層失敗，就無法知道該換模型、改夾具還是修正路徑。
MOTOMAN 身體層也需要回報可用性，而不只是接受命令。可達空間、關節極限、夾具狀態、力感測品質和安全模式，應回傳給規畫層；否則模型可能反覆要求不可執行任務。控制層拒絕時，要給可分析的錯誤碼，而不是讓上層無限生成替代動作。
驗收可故意改變物件重量、摩擦、位置與遮擋，並在路徑中加入人員進入、夾具偏移和力感測異常。分開計數模型選錯工作、控制層無法規畫、夾取失敗與安全停止，才能把責任交給正確供應商。
同一展示，兩種採購情境的判斷不同
對少量多樣產線，具身推理可能減少每個新品的手寫流程；對節拍固定、法規嚴格的產線，額外模型層可能增加變更管理。選擇不在『AI 或傳統』，而是哪些變動值得交給模型，以及模型出錯時是否能退回固定流程。
比較矩陣還要加入網路與資料治理。若推理依賴雲端，延遲、斷線、資料出境與服務區域會影響產線；若在地執行，算力、模型更新與資安修補由誰負責。兩種方案都要在離線或降級時保留已知安全行為，並防止過期的高階計畫繼續執行。
投資評估不要只估新品換線省下幾小時，也要估每次模型更新的回歸測試、提示和技能維護、故障定位以及操作員訓練。若需要專家每天修正模型輸出，彈性可能只是把程式設計工作改成另一種人工。
| 情境 | 較適合的分工 | 主要代價 | 採購證據 |
|---|---|---|---|
| 固定節拍、高重複 | 固定流程為主，模型只做例外分類 | 介面與版本管理 | 長時間節拍、停機與回復 |
| 多品項、常換線 | 模型拆任務，機器人控制層約束執行 | 提示、資料與驗證成本 | 未見物件、換線時間與失敗分布 |
| 高接觸風險 | 模型提案，決定性安全層核准或拒絕 | 安全整合與審查 | 故障注入、停止與責任紀錄 |
用責任矩陣決定展示能否走向採購
商用系統要決定誰持有提示與模型版本、誰把任務翻成控制器可讀目標、延遲超標時怎麼處理，以及供應商更新後誰重跑驗收。模型服務費只是其中一部分；相機、運算、整合、資料標註、網路、回復舊版與現場支援都會進入總成本。
Yaskawa 公告的是整合開發與展示，尚未公布適用產業、一般供應時間、價格、支援地區或維護合約。掉落物復原只能證明指定情境可完成，不代表所有錯誤都能自動恢復。採購案應要求未剪輯測試、完整失敗分母與每次人工介入。
將場景感知、任務選擇、路徑、力控制、安全停止、日誌與人工接管逐項分配給 Gemini、Yaskawa 控制層、系統整合商與現場人員。只有在每一層都有可觀測輸出、失效條件與回復責任時，『大腦與身體』才從比喻變成可維護架構。
最終路由應設定三道門：公開資訊是否說明可供應版本；現場測試是否涵蓋失敗與人工介入；合約是否把模型、機器人和整合商責任綁定。任何一門未過，就把案子留在研究或試辦階段，不用因為展示流暢而跳到全線擴張。
後續最有價值的資料不是更多成功影片，而是指定軟體版本下的連續班次、未見物件集、完整錯誤分布和回復時間。若廠商願意公開模型服務停止時的退回行為、支援期限和版本相容矩陣，商用成熟度才有可驗證進展。
- 保存模型、提示、影像與任務輸出版本
- 分開計算語意錯誤、路徑失敗與接觸失敗
- 設定延遲、信心與安全規則的拒絕門檻
- 要求固定流程與人工接管的退回路徑
- 以完整連續班次而非單一復原展示驗收
讀者接著會問
價格較高是否一定換來較低總成本？
不一定。要把換線工程、資料與提示維護、模型服務、運算、停機、人工接管及版本回歸測試一起算入。若工作穩定且固定流程已可靠，多一層推理未必省錢。
兩家供應商支援範圍要怎麼拆？
合約應列出模型輸入輸出、任務介面、路徑與力控制、安全層、日誌、更新與回復舊版的責任。出現同一故障時，不能讓模型商、機器人商與整合商互相轉單。
資料最後查核：2026 年 8 月 25 日