Gemini Robotics Cloud Preview 將 ER 2 帶進企業工作流程

Google 於 10 月 27 日推出 Gemini Robotics 雲端預覽版，讓企業客戶可公開預覽其 ER 2 機械人推理模型。這項公布透過 Google Cloud 擴大存取範圍，但客戶仍須自行將模型接駁至機器，並驗證其行為。

這項區分相當重要，因為 ER 2 已於 7 月推出。今次公布關乎企業存取與營運，而非一款新機械人智能模型首次面世。核心張力在於可適應的推理能力，與企業對實體設備可預測執行表現的需求之間。

Google 正與 NVIDIA 及 Physical Intelligence 在這個機遇上競爭，兩者均提供不同的機械人開發方法。對企業採購方而言，眼前的實際問題是：共享推理服務在哪些環節可減少工程工作，又在哪些環節責任仍須留在本地？

Gemini Robotics Cloud Preview 帶來甚麼改變

即時改變是企業可透過 Google Cloud，更廣泛地存取既有的推理模型。

Google 的機械人公開預覽公告，將 ER 2 納入其企業平台。公告亦提及客戶對檢查、訓練數據及實驗室自動化的興趣。這些例子展示了潛在應用，而非獨立驗證的部署表現證據。

這帶來一場與研究示範不同的採購討論。評估模型的機械人團隊，還必須考慮存取權限、營運責任歸屬、支援安排，以及變更如何傳達至已部署的設備。企業分發令這些問題更早進入初步評估階段。

公開預覽仍是一項重要限制條件。產品可用性讓客戶能依照適用條款研究產品，但並不代表特定安裝項目必然符合買方對正常運行時間、安全或支援的要求。

時序亦可避免對新聞作出誤導性解讀。Google 的 ER 2 介紹於 2026 年 7 月 30 日發布。當時透過 Gemini API 與 Google AI Studio 提供開發者存取，並透過其企業平台提供私有預覽存取。

ER 2 是一款具身推理模型，即能理解實體環境，並為機械人規劃行動。Google 將它描述為高層次大腦，把移動工作交由較低層系統處理。公司亦表示，它具備以影片追蹤進度及協調機械人的能力。

這些能力說明模型的預定定位，但不代表它是一套完整的機械人產品。買方仍需要合適硬件、可正常運作的控制系統，以及清晰界定的任務。推理服務必須配合既有營運系統。

對已在考慮採用機械人的企業而言，更廣泛的存取降低了評估門檻。團隊可以研究共用推理層是否適合納入其架構。這是具意義的商業一步，但不代表整個架構已經完整交付。

這項改變亦令規劃決定提前。買方必須識別哪些決策希望由模型作出，哪些則需要固定規則。若這條界線含糊不清，日後的效能聲稱將難以解讀。

狹義評估可以回答一個實用問題：與既有方法相比，加入 ER 2 是否能改善已界定的工作流程？廣泛示範則回答較難付諸行動的問題，只展示一種可能的互動，卻無法證明系統能否支援特定操作。

因此，Gemini Robotics 雲端預覽版值得作為企業分發事件而受關注。其重要性在於令評估更易進行，並把它連接到營運要求。實際部署成果將取決於客戶如何圍繞這項存取權建立系統。

企業存取把壓力轉移至機械人整合商

共享推理服務改變整合商需要證明的內容，同時提升其在模型周邊工作的關鍵性。

壓力最直接落在把機械人硬件連接至業務流程的團隊身上。若客戶能自行評估通用推理模型，度身訂造的推理軟件便需要更清晰的理據。然而，整合專業知識仍是讓最終系統發揮作用的核心。

以一項假設的檢查任務為例：設備分佈於整個設施之中。辨識物件只是任務的一部分，系統還要確認所檢查的是哪項資產、觀察是否足夠，以及例外情況應交由何處處理。

推理模型或可協助解讀陌生視角，或選擇後續觀察方式。整合商仍須將這些決策接駁至設施的設備紀錄與操作程序。客戶需要的是一套可問責的流程，而非一個孤立答案。

同樣的區分亦適用於假設的實驗室工作。解讀儀器顯示畫面的機械人，需要處理無法讀取數值的規則；當顯示結果與實驗預期狀態衝突時，亦需要一套已獲批准的應對方式。

這些例子說明主要商業問題。適應能力只有在企業能把它置於可接受的操作範圍內時才有價值。這個範圍包括哪些行動獲准進行、哪些證據可支持行動，以及何時必須由人員介入。

對整合商而言，這顯示重點轉移，而非單純面臨取代威脅。他們的價值可轉向可靠介面、例外處理及部署證據。客戶應詢問有多少工作可重用，又有多少仍須因應每項安裝而定。

這項區分亦影響採購。模型訂閱與可正常運作的機械人應用程式，代表不同承諾。當鏡頭更換、工作流程擴展，或上游模型出現不同表現時，買方需要明白誰擁有該應用程式。

企業平台可令組織內更易存取模型，卻不能自動解決這些責任歸屬問題。因此，成功的試點項目需要機械人團隊、營運人員、安全審核人員，以及維護設備的人員共同達成協議。

這亦是文件記錄成為部署一部分的地方。團隊需要一份共同紀錄，載列已核准行為、已知故障，以及每次評估的相關條件。否則，不同群組可能會從同一示範得出相互矛盾的結論。

就這類協調工作而言，可搜尋知識庫可協助工程師把技術文件連接至部署決策。它支援機械人周邊的人手審核流程，讓測試結果與操作假設能保持易於查閱。

因此，短期壓力相當明確：整合商必須展示如何把廣泛可用的推理模型轉化為可維護的應用程式。企業買方則必須清楚界定成功標準，從而區分模型能力與實際使用模型所需的工程工作。

可信的提案應說明意外結果出現後會如何處理，包括由誰調查、由誰授權作出變更。這個答案往往比示範中最流暢的部分，更能揭示部署準備程度。

推理層仍需要可靠的行動系統

這種架構透過把任務決策與移動分開來提供彈性，因此兩者之間的界線尤其重要。

視覺語言行動模型，即 VLA，會把視覺觀察與語言指令轉換為機械人行動。它與高層次推理模型扮演不同角色。在評估產品控制甚麼、以及它只是提出甚麼請求時，這項區分十分重要。

Google 的任務編排文件說明如何把推理功能連接至自訂機械人介面。API，即應用程式介面，讓另一系統能夠呼叫軟件功能。在這種安排下，可用功能界定了推理層可請求的行動。

這種分工創造了有用的工程機會。團隊或可調整任務規劃，而毋須重新設計每項移動技能；同時亦可在評估另一種從獲准行動中作出選擇的方法時，保留圍繞機器既有的控制措施。

這個機會取決於介面是否精確。「把樣本放入支架」這樣的指令，包含對身份、位置與完成狀態的假設。這些假設需要在推理系統與行動系統之間具有共同含義。

假設指令即使失敗，也未必會產生明顯錯誤。機械人可能完成移動，卻把物件放錯位置。下一個決策必須依據有關物件的證據，而非一項指令已完成執行這個事實。

這正是為何進度驗證與規劃同樣值得重視。有用的系統需要分辨預定行動與觀察到的結果。否則，早期錯誤可能變成獲接受的假設，並影響其後每項決策。

重複行動帶來另一項複雜性。再次請求影像或許無害，但重複分配物料或移動設備則可能產生後果。周邊軟件必須在接受重複請求前，確認先前行動是否已經發生。

這些屬於架構考量，並非指 ER 2 無法完成這些任務。它們說明企業評估必須檢視的內容。模型的推理質素與應用程式的營運正確性，回答的是相關但不同的問題。

當多台機器共用一個工作流程時，同樣的邏輯亦適用。計劃可以分配責任，但應用程式仍需要可靠紀錄實際發生的事情。實體交接需要就責任歸屬與狀態達成共識。

因此，有用的試點項目應測試各組件之間的邊界，包括不清晰觀察、不完整行動、延遲回應及環境變化。這些情況可揭示應用程式能否在不虛構一套方便敘事的情況下復原。

Gemini Robotics 雲端預覽版令這類研究更易進行，但存取權本身並不會界定介面合約。客戶與整合商必須決定哪些資訊跨越每道界線，亦必須決定當觀察結果互相衝突時，哪個組件擁有決策權。

共享推理層最有力的架構論據是可重用性。當同一套規劃方法能跨不同安裝環境運作，而不隱藏一個不斷增加的例外集合時，這項論據才具可信性。評估應從一開始就讓這些例外情況顯現。

NVIDIA 與 Physical Intelligence 提供不同的參考點

各種機械人技術路線有助釐清 Google 所提供的內容，但不足以作出簡單的性能排名。

NVIDIA 將 Isaac GR00T 定位為涵蓋模型、開發工具、模擬及機載運算的開放平台。其 VLA 模型接收觀察結果、指令及機械人狀態，然後產生一連串動作。這使人們尤其關注學習所得的行為如何連接至實際執行。

Google 的企業推理服務處理的是系統中一個相關環節。評估兩種方案的買家，應檢視規劃在哪裏進行、動作從何而來，以及團隊可修改哪些元件。單憑產品名稱無法化解這些架構差異。

Physical Intelligence 透過其對開放世界泛化能力的研究，提供另一個參考點。泛化能力是指處理訓練期間未曾遇到的環境或物件。其 pi0.5 工作描述了在此前未見的住宅中完成家居任務，同時承認模型並非每次都能成功。

這項承認與企業評估有關。系統可以展現有用的適應能力，但仍可能需要限制、復原程序及人手協助。商業問題在於，這些要求如何影響某項特定工作，而不是原則上是否存在適應能力。

這些方案不應被視為單一基準測試中可互換的項目。它們著重不同元件，並在不同條件下發表證據。一個機構的任務示範，若沒有可比的評估，不能證明其優於另一機構的模型。

Google Cloud 的分發渠道也不代表每個競爭元件都必須消失。更廣泛的架構問題是，客戶會否受惠於將高層服務與另行選擇的動作及硬件系統結合。答案取決於整合質素及營運限制。

對部分買家而言，模型權重的控制權可能很重要，因為他們希望自行檢查、調整或託管模型。另一些買家則可能優先考慮託管存取及組織管理。這些偏好反映部署需要，而非開發模型之間存在一個普遍勝者。

因此，合適的比較應從客戶的工作負載開始。有甚麼觀察資料可用？哪些動作獲准執行？本地有多少運算資源？若遠端服務無法使用，會發生甚麼事？每個答案都會收窄值得評估的架構範圍。

同一工作負載亦應界定供應商需要提供的證據。對檢查工作有興趣的買家，需要相關的檢查結果。對操作任務有興趣的買家，需要有關處理任務的證據，包括困難個案及需要協助時的條件。

這讓競爭背景保持有用，而不會主導整個故事。Google 眼前的行動是擴大企業取得 ER 2 的途徑。NVIDIA 及 Physical Intelligence 說明了為何客戶應在更廣泛的機械人軟件架構選擇中評估這項行動。

Google 面臨的壓力，是證明其推理層在哪些地方能帶來可量度的價值。替代方案面臨的壓力，則是同樣具體地展示自身整合及營運優勢。可比較的客戶證據，會比互相競逐的通用機械人智能主張更具參考價值。

預覽條款及模型限制在實體工作中至關重要

企業存取提供評估途徑；它不會把機械人行為的責任轉移至平台。

Google 的機械人模型文件將 ER 2 列為預覽服務，支援可能有限。在適用條款規限下，它允許用於生產或商業用途。獲准將預覽版用於商業用途，仍有別於對特定應用的保證。

文件亦指出涉及錯誤輸出、提示品質、處理時間及運算要求的限制。文件明確將維持機械人周邊安全環境的責任交予客戶。這些條件應與能力主張一併納入部署討論。

實際含意很直接。企業需要決定，當系統沒有足夠證據採取行動時，應如何處理。可接受的回應可能包括再作一次觀察、受限制的復原程序，或升級交由操作員處理。

這項決定應視乎後果而定。在審閱畫面中錯認物件，與將設備移向錯誤物件，會產生不同的營運風險。共同模型可參與這兩種工作流程，但周邊控制措施應反映當中的差異。

處理時間同樣需要按工作負載作出解讀。延遲回覆對審閱已完成的檢查錄影或許可以接受；相同的延遲，對影響持續動作的決定則可能並不適合。評估應釐清哪些決定可以等待，哪些需要由本地處理。

同樣地，正確答案不會自動構成安全授權。模型或可正確理解場景，卻未必知道維修限制，或鏡頭視野外有人。應用程式需要視覺理解以外的存取規則及營運限制。

當攝影機及咪高峰進入工作場所，私隱亦值得同樣關注。相關問題包括收集甚麼資料、誰可存取，以及資料會保留多久。這些決定應伴隨試點設計，而非在部署後才處理。

這一切並不表示 ER 2 不適合企業機械人應用；它表示企業機械人需要應用層面的證據。預覽公告讓客戶有機會在自身營運條件下收集這些證據。

有用的評估會連同成功個案記錄失敗情況，並保留每項結果的背景。它應區分自主完成的工作與需要人手修正的工作。這項區分可避免有前景的示範被誇大為營運主張。

商業案例亦應包括機械人周邊所需的工作。設定、監督、復原及維護都會影響實用性。即使應用程式能完成一項任務，若支援負擔超過它所減少的工作，仍可能令人失望。

因此，審慎的立場並不是否定這項技術。Google 已擴大一個具備相關已報告能力模型的存取途徑。客戶仍需證明完整應用程式的行為可接受，包括模型不確定或出錯時的情況。

留意客戶證據、服務承諾及重用能力

下一批有用訊號，關乎營運成果、服務的商業成熟度，以及整合是否更容易重複採用。

第一個訊號是來自明確工作負載的客戶證據。未來數月的報告應說明所執行的任務、所處條件，以及人員介入的頻率。清楚描述失敗及復原情況，會令這些報告更具價值。

若客戶展示超越預設示範的穩定效益，這些證據將強化企業應用的論點。若公開案例略去營運條件，或未有解釋周邊人手工作，則會削弱這項論點。一個知名客戶名稱不能取代這些細節。

第二個訊號是服務承諾或可用性的改變。買家應留意發布狀態、支援及文件化部署條件的更新。即使服務底層推理能力不變，這些更新仍可釐清機構如何圍繞服務進行規劃。

更廣泛的商業承諾會支持較大規模的部署規劃。持續處於預覽狀態仍可進行評估，但買家需要將適用限制納入考慮。兩種結果都不應被誤作實體任務表現的證據。

第三個訊號是不同客戶整合之間的重用能力。若團隊能將推理層套用至另一部機器或另一個工作流程，而毋須重建周邊應用程式，架構承諾便會更具說服力。重用應包括復原行為及營運記錄，而不只是一次成功的模型呼叫。

反覆整合的證據將支持 Google 作為共用企業推理層的定位。若證據顯示每次部署都需要大量特殊處理，這個定位便會收窄。模型仍可能有價值，但其價值會顯得更具應用特定性。

綜合而言，這些訊號可讓焦點維持在 Google 實際宣布的改變上。公司已透過其企業雲端服務，令 ER 2 更易存取。尚未解答的問題是，這種存取如何轉化為可靠的應用程式及可管理的營運責任。

對開發人員而言，機會是針對既有基準評估推理元件。對企業買家而言，優先事項是將該評估連繫至清晰的營運要求。兩個群體都可受惠於把已報告的模型能力與已驗證的應用結果分開看待。

Gemini Robotics 雲端預覽值得進行聚焦評估，並應連繫至你的機構已經理解的工作。選擇一項範圍明確的任務，記錄其目前表現，並界定模型可作出的決定。評估中應包括不清晰的觀察、不完整的動作及交接予操作員的情況。保留足夠背景，讓另一位審閱者理解每項結果為何被視為成功或失敗。然後將完整工作流程，包括監督及復原，與現有方案作比較。在擴大試點前，先問一個具體問題：甚麼結果足以證明這個系統應對下一項任務承擔責任？