Google AX 怎麼用？開源 AI Agent 編排執行時安裝與開發教學

官方範例以 task.yaml 作為任務清單示例，並將 Task、Workspace 與 Runner 的角色分開說明。官方任務範例及概念文件指向同一個判斷：Google AX 安裝部署的重點，是組織分散式 Agent 任務與執行環境，不是替代模型或提供現成業務 Agent。先用官方 Quickstart 跑通單一任務，再逐項核對沙箱、網路與觀測邊界；本機範例能完成，不等於已達生產就緒。

適合你：以 Go 建構 Agent 任務執行器的工程師，可從任務與 runner 的官方介面開始理解接入方式。
也適合你：負責隔離執行環境的 SRE、平台工程師，以及評估本地或雲端開發環境的技術負責人。

最後更新於 2026 年 9 月 25 日；核對來源為 Google AX 官方倉庫、Quickstart及其 runner、清單、網路與沙箱文件。

先界定 Google AX Agent runtime 的工作範圍

把 Google AX 看成一個協調任務執行的執行時，比把它當成「會自己做所有事的 Agent」更準確。Agent 程式負責任務邏輯，底層模型負責模型推論；AX 則處理任務如何交給執行環境、工作區如何準備，以及 runner 如何啟動和回報執行狀態。官方runner 文件應作為理解這些邊界的起點。

這個區分會影響採購與架構決策：

• AX 不等於 Agent 程式：你仍要自行提供任務邏輯，並決定它如何呼叫模型、處理工具結果及回報錯誤。
• Workspace 不等於安全沙箱：工作區描述任務所使用的工作位置；檔案系統、程序與網路能否被限制，還要看 runner 與部署環境的實際設定。
• 任務能啟動，不代表運維條件齊備：若缺少失敗原因、工作區清理與網路連線的可見性，任務即使成功跑過一次，也不足以支撐平台試點。

使用場景：從單次程式碼任務到平台試點

假設你要讓 Agent 在指定工作區執行一段檢查程式。你需要分別決定任務描述如何傳入、Workspace 如何準備、由哪個 runner 啟動命令，以及在哪裡查看結果。若任務失敗，你還要能分辨是輸入或工作區準備有誤、執行命令失敗，還是環境政策阻擋了檔案或網路存取。AX 提供的是組織這段生命週期的執行架構；業務 Agent、權限政策與環境監控仍由你落實。

如何安裝並執行第一個 Agent 任務？

開始前，先依官方倉庫與 Quickstart核對目前的安裝方式、Go 工具鏈要求與執行依賴。不要照抄過期教學裡的 Go 版本或環境數字：先看倉庫中的 go.mod、README 與 Quickstart，並以當下文件列出的條件為準。若文件沒有列出某項資源要求，就不要自行把它寫成 AX 的硬性規格。

建議按以下流程安裝與執行：

• 從官方倉庫取得原始碼，切換至專案目錄，先讀 Quickstart 的先決條件。
• 檢查目前 Go 工具鏈是否符合倉庫明確要求，並依文件準備必要的執行依賴。
• 找到官方範例的任務清單，先確認它描述的輸入、工作區及執行內容；不要未讀欄位便替換成自己的任務。
• 依 Quickstart 提供的當前命令啟動範例，保留原始設定，避免同時改動任務、runner 和環境，否則問題難以定位。
• 觀察命令回報與 runner 提供的任務執行資訊，確認任務是否啟動、執行結果是否可取得，以及失敗時是否能辨識錯誤來源。

官方的 task.yaml 範例可用來理解任務清單的實際寫法；欄位意義則應對照官方 manifests 文件。照著目前 Quickstart 執行，才是可重現做法；這裡不臆造未能從文件核實的命令名稱、輸出字串或 API 簽章。

Google AX 如何準備任務工作區？

把工作區準備視為任務生命週期的一環，而不是啟動命令前的臨時目錄設定。先從官方清單欄位確認任務會取得哪些工作區資訊，再追查 runner 如何接收並使用這些資訊。對每個測試任務，至少確認工作目錄是否符合預期、任務是否只能接觸授權內容，以及任務結束後哪些檔案需要保留或清除。

提醒：工作目錄或 Workspace 的存在，本身不代表任務已被隔離。要把檔案存取限制當成安全能力之前，必須核對實際 runner 與執行環境的沙箱設定。

如何透過 runner 接入自訂 Agent？

自訂 Agent 的接入重點，是依官方 runner 文件理解控制端與執行端的責任分界，再把現有 Agent 程式放進對應的啟動流程。先確認控制面如何傳遞 Task 與 Workspace，再確認 runner 如何啟動命令，以及如何提供執行狀態或結果資訊。不要只憑介面名稱推斷 AX 會替你管理模型金鑰、重試政策或業務狀態。

建議採取以下次序：

• 先依 runner 文件辨識任務輸入、工作區資訊與命令執行之間的關係。
• 從官方示例開始，僅替換 Agent 程式入口；暫時保留任務格式與工作區設定。
• 確認自訂程式能從預期位置讀取任務輸入，並將結果送回 runner 可觀測的通道。
• 分別測試成功與失敗路徑，確認錯誤不會被當成成功結果，也不會只留在無法存取的程序輸出中。
• 確認接口穩定後，再評估是否將 Agent 命令封裝成團隊共用的執行單元。

延伸程式入口時，以 runner 文件實際記載的介面與生命週期為準。文件未確認的類別名稱、函式簽章或生產部署拓撲，不要直接當成 AX 的正式承諾。這種做法比先搭出一套自行假設的控制面，再花時間回頭對齊官方介面，更容易定位接入問題。

部署前要檢查哪些沙箱與網路邊界？

官方有沙箱說明與網路設定文件，但文件描述的能力不等於你的部署已啟用相同限制。把官方內建能力、部署者自行設定，以及仍須在目標環境驗證的項目分開記錄。

• 檔案與程序：確認任務能讀寫的目錄範圍、是否可能接觸工作區以外的檔案，以及子程序是否受執行環境限制。
• 網路出口：逐項確認允許連線的目的地、DNS 與代理設定，以及是否存在未經預期的外連通道。網路規則應以實際部署政策為準，不能把「有網路設定文件」理解為預設已封鎖外連。
• SSH 與除錯入口：先確認目標環境是否明確啟用 SSH 或其他遠端除錯途徑，再核對憑證、可連線範圍及關閉方式；不要假定所有 runner 都有相同入口。
• 任務觀測：測試失敗時能否看到任務狀態、命令錯誤與必要日誌；並確認日誌不會意外包含憑證或敏感輸入。
• 清理與復原：確認任務結束後的工作區處理方式，並演練程序中斷、部分寫入與重跑時如何避免舊資料干擾。

Google AX 的價值，是提供任務與執行環境的組織方式；隔離是否有效，要由你在實際 runner、作業系統權限與網路政策中驗收。若你在比較遠端開發環境，可先閱讀本站的基礎設施說明，並將它作為檢視環境與連線條件的參考，而不是替代 AX 沙箱測試。

擴大部署前的驗收清單

先讓單一任務可重現，再從併發試點逐步放大；每次增加任務量或更改 runner 設定，都應重新檢視隔離與失敗觀測。以下清單可作為試點進入下一階段前的決策工具：

• [ ] 已依官方 Quickstart 跑通單一任務，並保留當時使用的任務清單與執行設定。
• [ ] 已確認 Task、Workspace 與 runner 的資料傳遞方式，並能解釋每一項設定由哪個元件負責。
• [ ] 已驗證檔案存取範圍與網路出口政策，不以預設值推定任務已隔離。
• [ ] 已測試成功、命令失敗與執行中斷情況，並能從觀測資訊判斷問題發生的位置。
• [ ] 已定義工作區清理、必要日誌保留及敏感資料處理方式。
• [ ] 已用受控的併發試點檢查排程、資源使用與失敗恢復；尚未取得實測前，不預先承諾吞吐量或可支援規模。

若清單中的隔離、網路或失敗可見性仍有未確認項目，先修正單機驗收，不要只因範例成功便直接擴大部署。本文不提供本站環境配置、地域節點或實測效能數據；這些項目必須以實際環境記錄為準。

對只需偶爾執行任務、手邊已有合適開發機的團隊，本地環境通常更直接；但硬體需自行維護、工作環境不一定持續可用，遠端協作也可能受本機網路與權限管理牽制。若你需要可遠端連線、適合持續驗證的 Mac 開發環境，可以比較Kvmjet 的服務資訊，再依 AX 的 runner、網路與沙箱需求安排小規模試點。需要實體介面、長期固定負載，或必須由團隊完全掌控底層環境時，則應先評估自購設備或自管環境，不必為了使用遠端環境而改變既有架構。