機器人恢復作業之前，誰來驗收交接後的現場

Google Cloud 在 2026 年 10 月 30 日的機器人生態文章中描述了雲端規劃與裝置端控制的分工。相關 ER2 公共預覽公告發布於 10 月 27 日。兩個日期應當分開，生態介紹也不能代替生產現場的驗收結果。

這種分工提出一個值得採購方提前處理的問題：一次任務被打斷之後，誰有責任證明現場已經適合繼續？以下是 Open Market Notes 對交付與驗收的分析框架，並非對上述產品事故、缺陷或客戶表現的報導。

交付邊界應延伸到恢復作業

採購討論容易圍繞正常運行展開：模型能否理解任務，機械臂能否完成動作，業務系統能否接收完成紀錄。三個部分分別合格，仍然可能留下一個沒有被任何單項驗收涵蓋的環節。有人介入、工件移動或任務取消以後，原來的計畫依據是否還成立？

這裡需要約定的不是籠統的「系統恢復正常」，而是恢復所需的具體現場條件。工件在哪裡，夾具處於什麼狀態，原任務哪些步驟已經完成，後續步驟以什麼觀察為依據。軟體服務重新可用，只能回答其中一部分問題。

以一個假設的包裝工作站為例。機械臂放下零件後，工作人員為了排查問題把零件挪到另一隻托盤。模型供應商可以確認服務正常，設備供應商可以確認運動控制正常，整合商也可能確認任務佇列仍然存在。但這些確認尚未說明哪隻托盤應接收下一步操作。若恢復流程只是重複舊指令，技術部件的健康狀態就會被誤當作整個任務的連續性。

這個例子不說明任何具體產品會犯這樣的錯誤。它說明採購驗收最好包含一次真實可觀察的交接：誰更新任務狀態，誰核對現場變化，誰在什麼條件下批准繼續。最終執行動作的系統應當知道自己接收的是新的確認，還是中斷前留下的判斷。

將故障歸因與復工授權分開

根因調查可能需要多個供應商共同參與。模型輸出、感測器觀察、控制器回饋和業務紀錄之間的差異，也可能一時無法解釋。如果必須先判清責任才能決定下一步，現場就只能等待合約爭議結束。

更實用的安排是分別約定兩條路徑。調查路徑保留相關版本、時間和證據，供後續確認原因。復工路徑則由事先指定的負責人依據現場驗收條件作出決定。這是治理建議，不是法律責任的判斷，也不意味著降低設備安全要求。

負責人不應只作為聯絡人列在文件裡。其權限、所需輸入、可接受的證據以及無法判斷時的升級管道，都應屬於交付範圍。若某個條件沒有人能夠核驗，正確的驗收結論應允許任務繼續停留在未恢復狀態，而不是把缺失資訊自動理解為通過。

測試完整的交接，而不只測試部件

採購方可以要求供應商共同設計受控的中斷演練。關鍵不在於製造危險，而在於使用經現場專業人員批准的測試方式，驗證資訊和決定如何流轉。例如，在模擬環境或適當隔離的測試條件下改變工件位置，觀察舊任務狀態是否被識別為過期，以及現場確認是否真正進入新的執行依據。

紀錄應涵蓋從發現狀態不一致，到指定負責人接手，再到滿足恢復條件的整個過程。單個元件的回應速度不能代表這段時間。若需要人工參與，人工投入及等待也應進入交付評估，否則自動化收益會把重要的配套工作排除在外。

不同業務的合理條件不會相同。實驗室樣品、零售貨架和工廠零件的處理約束各有差異。供應商可以提供通用能力，採購方仍需要說明自身允許怎樣的中斷、返工和人工接管。把這些限制寫清楚，也有助於避免日後將業務規則誤歸為模型缺陷。

升級時保留共同驗收的版本組合

如果模型、控制軟體或任務系統由不同團隊更新，原來通過的交接流程可能不再對應當前組合。建議保留一次聯合驗收所涵蓋的版本、介面含義和現場假設；變更時根據影響重新驗證相關交接，而不是僅憑每個供應商自己的測試報告判斷整體仍然有效。

這會增加協調成本。對於固定、簡單的工作站，過於複雜的聯合流程可能不划算，因此應按任務後果和現場變化程度確定深度。採購比較也應把恢復能力的證據、責任範圍與價格一起考慮，而不是要求所有場景採用同一套繁重制度。

Google 的兩篇文章為討論提供了技術背景，沒有證明哪一種責任安排在所有場景中最好。真正值得在合約和試運行階段回答的，是營運方能否觀察到一次交接已經完成，以及交接未完成時是否有人擁有明確的處置責任。這樣的答案，往往比再增加一項正常運行示範更能幫助判斷系統是否適合交付。