Google Agent Compute Engine：AI 思考時暫停微型電腦，執行環境如何和模型分開？
Agent Compute Engine 把代理決策和工具執行分開，利用微型虛擬機、狀態快照與外部憑證管理支撐長時間工作。本文解釋待機時省下什麼、工作區如何保留，以及未來預覽服務和已開源 Agent Substrate 的差異。
Agent Compute Engine 關注的是代理的等待時間。AI 代理執行一段程式後，可能得等模型想下一步，也可能等使用者回覆。
它的工作還沒結束，電腦卻未必一直在忙。
如果每個等待中的代理都占著一台完整電腦，工作階段越多，閒置資源也會跟著增加。把環境刪掉重建，又可能丟掉剛才的工作。
Google 這項服務想同時保留狀態和回收閒置算力，為每個代理提供可暫停、恢復的隔離微型虛擬機。
這項服務已支撐 Google 內部代理，但客戶預覽還要等未來幾個月。公告裡另有開源 Agent Substrate，兩者的供應方式與數字不能混用。
我認為同時維持大量工作階段的平台團隊值得追蹤，先量自己的代理在算、在等、在存資料各花多少，才有依據評估新環境。
要看懂它如何減少等待成本，第一步是把決定下一步的模型，和實際跑工具的電腦分開。
Agent Compute Engine 跑的是模型，還是代理的電腦？
模型與代理框架決定下一步，微型虛擬機則提供執行程式、瀏覽器與檔案操作的環境。
Google 在發布公告裡，用大腦與雙手區分這兩層：模型負責推理，執行環境讓決定變成實際動作。這項新服務主要處理後者，不能把它理解成另一個聊天模型。
以程式代理為例，模型可能先要求讀取檔案，再要求修改函式，最後執行測試。讀檔、修改與跑測試，都需要實際的運算環境。
模型在思考下一步時，先前開出的終端機、安裝好的套件及工作檔案，卻可能仍留在那裡。所以長任務的難處，正是如何讓這個環境一直可用，又不持續占住完整資源。
微型虛擬機可以理解為替單一工作提供的一台小電腦。依官方設計，每個環境有自己的客體核心與管理權限，並以硬體虛擬化隔離。
這與單純在同一個作業系統裡切出不同工作目錄不同，也不等於所有容器在任何情境都不適合。但它是 Google 為這種代理工作選擇的隔離層。
執行環境能讓代理安裝工具、跑程式與使用瀏覽器，但不替代理決定應該做什麼。模型若誤解需求，仍可能在隔離空間裡完成錯誤修改。
程式若沒有通過應有測試，也不會因為放進微型虛擬機就自動正確。因此，環境能力與任務品質要分開衡量。
這種分工也有助於理解代管代理與執行基礎設施的差異。
本站先前的NVIDIA Open Agent Safety Platform 是什麼？OpenShell、Sentry 如何防止 AI Agent 越權討論了代理執行時的權限與隔離。
這次則把鏡頭拉到代理實際使用的電腦，觀察它何時需要運算、何時只需要保留狀態。
執行環境與模型分開後，系統才有機會暫停電腦，卻讓任務繼續存在。所以省下的不是模型思考本身，而是等待期間不必持續保留的活動資源。
工具跑完就暫停：快照與共享記憶體省下哪一段？
執行環境確認沒有工具或背景工作在跑後，可以保存狀態並交回主機資源。官方技術解析說明，系統會依執行狀態判斷何時閒置。不能因為前景指令結束，就假設所有背景程序也已完成。
因此，這個判斷影響暫停是否會打斷尚未完成的工作。
快照的概念，是把環境當下需要恢復的狀態保存起來，之後再從同一處繼續。相較於每次重新開機、安裝工具、讀回檔案，保留狀態可以減少重建步驟。
因此，模型在另一端繼續規畫時，這台工具電腦不必一直維持相同的活動配置。等到下一個工具呼叫出現，再恢復環境。
所以恢復與重新建立的差別，也影響使用者等待什麼。若每次模型提出下一個工具呼叫，都得先重新準備套件，等待時間就包含了反覆初始化。
若狀態能接續，工具可以從先前的工作位置繼續。但這仍需要執行框架正確傳遞工作階段，不能把任意一個新環境都當成原本的那台電腦。
另一個節省來源是共同的基礎映像。假設很多代理都需要相同的 Python 工具，若每個環境各自存一份完全相同的唯讀內容，就有重複負擔。
Google 描述以共享基礎內容搭配寫入時複製的方式處理：尚未修改的部分可以共用，環境要寫入時才產生自己的私有頁面。
這裡的「共用」不表示把不同使用者的工作檔案混在一起。共用的是適合重複使用的基礎內容。但個別環境的修改仍有自己的位置。
對開發者而言，重要的是哪些內容被當作基礎、哪些寫入會持續成長，而不是看到共享記憶體就推論所有代理都能讀到彼此的資料。
官方所稱閒置時沒有活動運算資源，也不能直接換算成帳單歸零。持久儲存、模型推理與其他服務可能有各自的成本。
截至查詢，客戶預覽尚未開放，也沒有足夠的公開費率可用來估算每個任務實際省下多少錢。
因此，較準確的說法是設計上回收等待期間的活動資源，而不是已證明所有代理成本降低某個固定比例。
保存狀態解決了資源問題，恢復後的代理仍要連到外部服務。這時身分如何交接，會決定敏感的長期憑證是否必須跟著每台小電腦一起保存。
憑證放在沙箱外：身分與網路請求怎麼接？
沙箱取得的是可驗證工作階段的短期身分，使用者的長期憑證則由外部閘道保管和換用。
依技術文件，客體環境不放入持久的使用者密碼、API（程式連接服務的介面）金鑰、OAuth 更新憑證或服務帳號金鑰。
這個設計希望減少執行任意程式的空間，直接持有後端機密的需要。
但「不放長期憑證」不等於環境裡完全沒有任何權杖。官方仍描述了短期身分權杖與憑證，用來證明請求屬於哪個環境及工作階段。
這些身分材料的用途，是向受控的外部路徑表明自己，而不是讓代理拿著使用者的長期金鑰，直接連到所有服務。
外部 Agent Gateway 會驗證委託關係、執行節點、工作階段與連線規則，再處理後端所需的憑證。
可以把它想成替工作環境代辦外部驗證的關卡：環境說明自己要去哪裡，閘道依規則決定是否放行，以及如何替請求附上需要的認證。
這種安排把兩種權限拆開。代理可以在自己的環境裡安裝工具或執行程式，不代表它就持有公司所有外部服務的登入資料。需要哪些外部連線，仍由另一層規則控制。
所以當工作階段很多時，能把請求追到特定身分，也有助於區分是哪一項任務在使用資源。
以上是 Google 公開的架構設計，並非對所有威脅都不可能發生的保證。
實際採用時，允許哪些外部目的地、委託範圍如何設定，以及後端服務本身給了哪些權限，仍會改變結果。
比較不同方案時，應看清楚憑證在哪一層保存，而不是只比較是否都使用「沙箱」這個名稱。
類似的問題也出現在其他開源代理環境，像Perplexity SPACE 開源：每個 AI 任務一台微型虛擬機，憑證與連線怎麼管？。
身分能追溯之後，跨天工作還需要另一種持續性：原來的檔案與工具狀態，應該保留到哪裡。
隔天接著工作：暫存、共用工具與持久工作區
代理需要保留的是自己的工作成果，而不是替每個工作階段重複保存整套相同工具。
官方技術說明區分了不同用途的儲存：有些內容只是暫時產生的資料，有些是共同的唯讀基礎，另一些則是需要持續保留的工作檔案。因此，不同資料適合不同生命週期。
例如，安裝好的共通執行工具可以成為基礎映像的一部分。下載後只在當次測試使用的中間檔案，未必需要長期保存。使用者正在修改的專案內容，則需要放在能跨工作階段留下的區域。
若把所有資料都混在一起，就很難同時兼顧快速恢復與清楚的保存責任。
文件提到以 Hyperdisk 支撐持久工作區。它處理的是檔案資料的持續保存，和記憶體快照保留執行狀態的用途不同。檔案還在，並不一定代表某個背景程序也仍在相同位置。
反過來，能恢復環境狀態，也不能省略對重要工作檔案保存方式的理解。
這對跨多次工具呼叫的任務很有幫助。代理可能先產生檔案，等待人類確認，再繼續跑測試。如果每次都從空白環境開始，就會重做安裝與準備。
所以保留適當狀態的價值，是讓下一步接得上前一步，並讓人有機會檢查中間成果。
不過，保存內容只是讓工作延續，不會替修改結果背書。專案仍可能有相依套件衝突、測試失敗或需求理解錯誤。
團隊要驗證的，是恢復後能否取得正確版本的檔案並繼續任務，而不是只確認環境顯示為啟動成功。這些能力描述的是新服務的設計，實際導入還得看可用階段。
Agent Compute Engine 和 Agent Substrate 有什麼不同？
ACE 是 Google 將開放預覽的代管服務，Agent Substrate 則提供 Kubernetes 上的開源執行路徑。
發布公告把兩者放在同一套代理基礎設施方向中介紹，但供應方式與管理責任不同，不能把開源專案可取得，寫成代管服務已全面開放。
新服務已用於內部代理工作。這是 Google 在台灣時間十月二十三日查詢時的公開說明，客戶預覽則預計在未來幾個月推出。
內部使用說明它已有實際服務對象，卻不代表外部團隊今天就能取得同樣的功能、地區與價格。因為費率未公開，也不適合自行補成成本比較表。
開源路徑讓已有 Kubernetes 的團隊，能研究如何在現有叢集管理代理環境。這條路提供更多自行部署的空間，也意味著團隊要理解底層資源、更新與維運責任。
公告中關於密度、啟動與暫停恢復的部分測量，屬於 Agent Substrate 的特定評估，不能借來當作代管服務的保證數字。
對已有叢集的團隊來說，開源版本可以先用來理解執行流程。對希望由雲端代管底層的平台，則更需要等待預覽公布實際介面與服務條件。
所以兩種選擇不是單純比較哪個名字更新，而是比較團隊願意承擔哪些管理責任，以及現有工具能否接上。
我會從一種需要安裝工具、寫檔並跨多次呼叫繼續的工作開始記錄：模型花多久決策、工具實際跑多久、其餘時間在等什麼。
若主要時間都在模型推理，改善工具電腦的閒置管理未必會讓整體速度明顯變快。若大量工作階段長時間等待，保存與恢復才可能是重要瓶頸。
記錄時還可以把人類等待另列一欄。程式測試可能只跑幾分鐘，使用者卻隔天才回覆是否接受修改。但這段時間與高負載運算的需求不同。
如果產品要支援這類跨天任務，保留什麼、保留多久，以及恢復後如何辨認原工作，就會比單次呼叫延遲更值得先問。
接著看恢復後是否少了重做。原先安裝的工具能否使用、修改過的檔案是否完整、等待中的任務是否能接續，都比單次建立環境的速度更接近長任務需求。
只有把等待、運算與保存分開，才有依據判斷新的代理電腦是否改善了自己的工作負擔。
若恢復後仍須重新安裝大量相依套件，或關鍵檔案沒有留在預期工作區，就代表保存方式尚未貼近任務需求。
相對地，若工具與檔案都在，瓶頸卻仍是模型等待時間，就應把優化焦點放回另一層。這種分開測量的方式，能避免把所有延遲都算在執行環境頭上。
對尚未開放的服務，先整理自己的負載與保存需求，也比預先估算一個沒有費率依據的省錢比例更實際。所以要等預覽條件公布後，團隊才能用相同任務做有意義的比較。
想繼續追蹤這類工具的正式推出條件與後續更新，可以免費訂閱 AI 郵報。
Agent Compute Engine 常見問題
今天就能使用 Agent Compute Engine 嗎？
Google 表示客戶預覽將在未來幾個月推出。已支撐內部工作，不代表外部服務已普遍開放。
暫停執行環境會停止模型思考嗎？
架構將模型決策與工具電腦分開。環境在符合閒置條件時保存狀態，模型可以在另一端繼續處理下一步。
零長期憑證是否代表完全沒有任何權杖？
不是。客體仍有短期身分權杖與憑證。設計重點是把使用者的長期後端憑證放在環境外，由閘道處理。
Agent Substrate 的測量能當作代管服務效能嗎？
不能。主體、部署條件與測量方式不同，應分開看，也不能直接用來估算尚未公布的服務費用。
