Google AX v0.3.0 深度解析：Agent 的 Kubernetes，還是太早的控制平面？（2026）

Google 名下的開源專案 Google AX v0.3.0，由 GitHub 帳號 rakyll（Jaana Dogan）於 2026 年 9 月 20 日發布。它不是另一套教 Agent 怎麼思考的框架，而是想補上更底層、也更難處理的一層：當數百、數千個 Agent 要長時間執行、保存工作區、限制網路、暫停再恢復時，誰來當它們的控制平面？這篇文章會先還原 v0.3.0 的真正改動，再核對官方架構與程式碼，最後判斷它現在是可用的基礎設施，還是一張很有方向感的藍圖。

v0.3.0 不是小改版，而是一次換骨

光看 release 頁，很容易低估這次更新：標籤所指的最後一個 commit 只寫著釘選 GitHub Actions 與補上 read permissions。真正改變 AX 身分的，是標籤前一個、在同一天完成的 架構重寫 commit。與 v0.2.3 相比，v0.3.0 的版本差異涵蓋約 150 個檔案、增加約 1.62 萬行並刪除約 1.95 萬行；其中包含生成程式碼，所以行數只能說明改動幅度，不能當作品質指標。

“AX is undergoing a significant redesign, moving away from a single CLI with an embedded Python harness toward a general-purpose orchestration layer for agentic tasks.”

中文：AX 正經歷一次重大重設，從內嵌 Python harness 的單一 CLI，轉向服務 Agent 任務的通用編排層。

Google AX v0.3.0 架構重寫 commit

這句話是理解 v0.3.0 的鑰匙。AX 在 2026 年 5 月公開亮相時，Google 稱它為分散式 Agent Runtime；到了這一版，重心已從「幫你跑某個 Agent」轉成「管理一群 Agent 工作負載」。內嵌 Python harness 與 SQL event log 在這次重寫中被移除，改由獨立 API server、controller、task runner、Redis 與 Agent Substrate 組成；舊 dashboard 則早在 7 月 22 日的 c0d8e5b commit 已移除。

AX 想解的問題：Agent 不是普通 batch job

傳統微服務通常常駐、可替換；batch job 通常跑完就結束。Agent 卻可能一邊修改程式碼、一邊累積檔案狀態，還會呼叫模型、MCP server 與外部工具。它既需要隔離，也需要持久化；既可能閒置數小時，也可能在錯誤迴圈裡持續燒錢。這正是 AX 官方網站把它描述成「新型工作負載」的原因。

這個缺口也解釋了社群反應：截至 2026 年 9 月 22 日 06:28（台北時間），Hacker News 討論串累積 626 points、288 則留言。這個熱度不是技術驗證，只能說明 Agent 基礎設施問題引發了大量討論。

Google AX v0.3.0 的四種資源，重新切分 Agent 執行環境

資源	它想管理什麼	v0.3.0 閱讀重點
Task	映像、命令、環境變數、工作區綁定與執行狀態	最接近可執行核心，最小單位是 task，不是整個 Agent 應用
Workspace	Git repo、技能、MCP 設定與可持久化檔案	讓新的 sandbox 能取得工作上下文
Gateway	入口與對外連線規則	API 方向合理，但目前網路政策的落地細節仍有關鍵缺口
Model	供應商、模型名稱、參數與 secret 參照	v0.3.0 的 TaskSpec 只參照 Workspace 與 Gateway；Model 目前是獨立設定資源

這種拆法的價值，是把「Agent 本身的推理」和「Agent 在哪裡、拿到什麼、能連去哪裡」分開。LangGraph、OpenAI Agents SDK 或你自己的迴圈，仍然可以決定 Agent 怎麼規劃；AX 想負責的是底下那層生命週期。它比較像 Agent workload 的 control plane，而不是 Agent framework。

像 Kubernetes 的操作語言，不是 Kubernetes 的擴充

Google AX v0.3.0 使用 ax.io/v1alpha1 YAML，CLI 也刻意做成 kubectl 熟悉的 apply、get、describe、watch、delete，再加上 suspend、resume 與 ssh。但把它直接稱為「Agent 版 Kubernetes」會漏掉最重要的差異：這些資源沒有進 Kubernetes API，也不是 CRD。

ax CLI → ax-server / gRPC → Redis Streams
      → ax-controller → Agent Substrate → sandbox

官方設計文件解釋，AX 把 Task 狀態放在 Redis，並以 Redis Streams 在 API server 與水平擴充的 controller 之間傳遞工作；真正的 sandbox 配置、actor 啟動、worker 指派與 egress enforcement 再交給 Agent Substrate。因此更精確的說法是：AX 借用 Kubernetes 的宣告式介面與 controller 心智模型，但另建了一套 gRPC＋Redis 控制平面，最後仍部署在 Kubernetes 之上。

這個選擇並非沒有理由。短命 Task 若全部塞成 Kubernetes CRD，etcd 的容量與寫入壓力會成為瓶頸；但把狀態移出 Kubernetes，也意味著 AX 必須自己補上驗證、授權、重試、收斂與觀測等能力。API 看起來像 Kubernetes，不代表 v0.3.0 已經繼承 Kubernetes 多年累積的運作保證。

Google AX v0.3.0 的 suspend／resume：保存工作區，不是程序記憶

AX 最吸引人的承諾之一，是讓閒置 Agent 暫停，需要時再喚醒。這確實對長時間任務很重要，但官方 runner contract 對語意寫得比首頁更精確：Agent Substrate 會 snapshot /workspace，resume 時把同一批檔案恢復到新的 container。

“the runner will see the same files but a new process tree.”

中文：runner 會看到相同的檔案，但程序樹是新的。

Google AX runner contract

所以這不是把 RAM、socket 或正在執行的指令凍結後原地解凍。Agent 若要可靠續跑，仍需把進度寫入 durable workspace，並能在新程序啟動後自行恢復。這比較接近「有持久磁碟的重新啟動」，而不是 Temporal 式事件歷史重播，也不是 VM 記憶體 checkpoint。

還要注意一個 v0.3.0 的實作風險：預設 runner 把初始化標記放在非持久化的 /ax，resume 後可能重新執行 workspace setup；而 Git setup 路徑使用 git checkout -f，可能覆寫已恢復但未提交的 tracked-file 變更。因此 /workspace 有 snapshot，不代表內容一定原封不動保留；pilot 必須把這種情境列入破壞式測試。

「數十億任務」是設計目標，不是公開成績

“AX is a high-throughput, declarative orchestrator to run billions of autonomous agent workloads in a cluster.”

中文意譯：AX 是高吞吐量、宣告式的編排器，目標是在單一叢集中執行數十億個自主 Agent 工作負載。

Google AX v0.3.0 README

這是整個專案最有傳播力、也最需要降溫的一句話。截至 2026 年 9 月 22 日，v0.3.0 的 README 與設計文件並未把「數十億」進一步拆成同時執行的 Agent、已登錄的 Task 或累積處理量，也未在該主張旁列出測試硬體、時間窗、延遲、吞吐量與失敗率。底層 Agent Substrate 公開的具體 demo，規模則是約 250 個 actor、8 個實體 pod 與約 30 倍 oversubscription。這能展示 multiplexing 概念，不能外推成 AX 已完成十億級驗證。

比較公平的讀法是：「數十億」描述架構想避開的上限，而不是一份可稽核的 benchmark 結果。若 AX 日後公開完整壓測方法、失敗恢復數據與多租戶隔離成本，再重新評價這個數字也不遲。

最值得注意的缺口：Gateway 還不是 fail-closed 邊界

官方把 Gateway 描述成 host＋port allowlist，這正好對應 coding agent 最需要的資料外洩防線；但 v0.3.0 的程式碼語意比網站文案寬鬆。

• API schema 的 HostRule 確實有 host 與 port。
• ApplyEgressPolicy 的 v0.3.0 實作只把 host 轉成 Substrate 規則，沒有把該欄位的 port 帶入；* 會轉成 All。
• controller 的預設路徑會建立 *:443，套用政策失敗時則記錄 warning 並繼續。
• 同一個 reconciler 最後以 actor 與 workspace readiness 判定整體 Ready，並不要求 GatewayReady=True。

這不代表 Agent Substrate 完全沒有網路隔離，也不等於每個部署都會外洩；它代表的是更窄、但更重要的結論：在 Google AX v0.3.0，不能只看 manifest 就假定 host＋port 政策已經 fail-closed 地生效。如果你要用它跑可接觸原始碼、token 或客戶資料的 Agent，必須自己做正向與反向連線測試，並把 policy apply failure 當成阻斷條件。

官方成熟度訊號，其實寫得很清楚

• AX README 明確警告核心概念、協定與規格仍在調整，stable 前很可能有重大破壞性變更。
• 所有 manifest 與 API 都還是 v1alpha1。
• 快速開始不只需要一個 binary，還要 Kubernetes、ko、可拉取映像的 registry、Redis，以及可連線的 Agent Substrate Control API。
• runner contract要求子命令結束後 runner 繼續存活，並註明 control plane 目前不會讀回該命令的 exit status。

“It is not ready for production use, and the APIs are almost guaranteed to change.”

中文：它還沒準備好投入 production，API 也幾乎確定會改變。

Agent Substrate 專案狀態

這些都不是小字警語，而是使用決策的核心。Google 名下、Apache 2.0、漂亮的 apply/watch/suspend 介面，會讓專案看起來比實際成熟；但 v0.3.0 更合理的定位仍是可以閱讀、試做與回饋的早期基礎設施。

AlphaLab 的判讀：方向對，可靠性證據還沒跟上

我同意的，是問題切得比多數 Agent 框架更深

Agent 一旦從一次性 demo 變成長時間服務，瓶頸很快就不再是 prompt，而是 sandbox、狀態、權限、成本、恢復與觀測。AX 把 Task、Workspace、Gateway、Model 分開，讓平台團隊能討論這些資源的生命週期，而不是把所有責任塞進一個 Python process。這個抽象方向值得注意。

我存疑的，是 API 名詞跑在實作保證前面

Gateway 聽起來像安全邊界，resume 聽起來像延續執行，declarative 聽起來像最終一定收斂；但逐一對照 v0.3.0 後，能確認的是 host 規則映射、durable workspace 與事件驅動 controller，而不是完整 port enforcement、程序記憶延續或 production-grade reconciliation。對早期專案來說，這些缺口不意外；真正的風險是使用者把熟悉的 Kubernetes 詞彙自動補成 AX 尚未提供的保證。

最大的機會，是成為 Agent 基礎設施的共同語言

如果未來不同 agent framework 都能把工作負載交給相同 control plane，平台團隊就能統一處理隔離、持久化、網路與容量，而應用團隊保留自己的推理迴圈。AX 最有價值的未來，不一定是「取代 Kubernetes」，而可能是成為 Kubernetes 與 Agent framework 之間那層目前缺少的協定。

誰適合現在試？誰應該先觀望？

適合現在試：已有 Kubernetes 與平台工程能力、正研究大批短命或間歇性 Agent、願意閱讀 Go 程式碼並自行補測試的團隊。最好的起點是沒有敏感資料、可隨時丟棄的內部 pilot。

應該先觀望：只想找可直接操作的 Agent 產品、需要明確 SLA／升級路徑，或準備立刻承載憑證、客戶資料與關鍵 production workflow 的團隊。你現在承擔的不只是新版本 bug，還包括 AX 與 Agent Substrate 兩層仍會變動的介面。

如果要做 pilot，先完成這 7 個驗收

1. 固定版本：釘住 v0.3.0 tag、映像 digest 與 Agent Substrate 版本，不要直接追 latest。
2. 從非敏感任務開始：先用公開 repo 與可撤銷的測試憑證。
3. 反向測 Gateway：除了確認允許的 host 能連線，也要確認未允許的 host、不同 port 與 policy 套用失敗時會被阻擋。
4. 另設完成判斷：在 AX control plane 能可靠接收子命令 exit status 前，用外部結果、artifact 或 callback 判斷工作成功與否。
5. 預設關閉 debug：debug: true 會開啟任意程序與檔案存取能力，只在受控環境短暫啟用。
6. 做破壞式 resume 測試：刻意保留未提交檔案、終止中的程序與部分完成狀態，確認你的 Agent 真的能從 /workspace 恢復。
7. 自己量容量：記錄符合你工作負載的併發、啟動延遲、Redis 用量、policy 錯誤與恢復時間，不沿用「數十億」作容量規劃。

結論：把 AX 當成方向指標，不要當成已完成的答案

Google AX v0.3.0 最重要的訊號，不是 Google 已經打造出能跑數十億 Agent 的 production 平台，而是大型 Agent 系統的競爭正從模型與 framework 往下移：誰能安全、便宜、可恢復地管理工作負載，將決定 Agent 能否真正大規模常駐。

AX 對問題的命名很有前瞻性，Task／Workspace／Gateway／Model 也提供了有用的討論邊界；但 v0.3.0 的程式碼、依賴與官方警告都指向同一個結論：它現在值得追蹤、值得用非敏感 pilot 驗證，卻還不值得取代你既有的 production control plane。