每日突破性工具推薦｜Google Agent Executor（AX）

Google Agent Executor（AX）

工具定位與適用情境

Google Agent Executor（AX）是一套開源、以 Go 實作的高吞吐量 Agent orchestration runtime。它不是用來定義 Agent 如何推理的框架，而是負責「Agent 要如何可靠地被執行」：隔離執行環境、工作區配置、模型設定、暫停與恢復、狀態觀察，以及大規模叢集排程。

AX 特別針對長時間、具狀態且大量等待外部輸入的 Agent workload。這類工作負載既不像無狀態 Web service，也不像跑完即結束的 batch job；Agent 可能執行數分鐘後等待模型、工具或人工核准數小時，再繼續原本工作。AX 的目標就是把這種生命週期變成平台層的一級抽象。

目前最適合的場景包括大型 Coding Agent 平台、多租戶 Agent SaaS、長時間 Research Agent、需要 Human-in-the-loop 的工作流，以及需要自行掌控 Kubernetes、模型與資料面的企業 Agent 平台。

為什麼今天推薦

AX 並非今天才首次發布；Google 已於 2026 年 5 月公開 preview。但近期專案快速成長且仍高度活躍，因此本次採用「近期快速成長且具代表性工具」fallback。

值得注意的不是另一套 Agent Framework，而是它代表 Agent 基礎設施開始出現與 Kubernetes 類似的分層：LangGraph、ADK 等框架處理 Agent 邏輯，AX 處理 Agent execution lifecycle，而 Agent Substrate 再處理更底層的 sandbox、snapshot 與高密度 compute multiplexing。

這種分工有機會把「如何可靠地跑數十萬甚至更多長時間 Agent」從各團隊自行拼裝的 infrastructure problem，逐步變成標準 runtime problem。

突破性重點

1. Agent 被視為新的 workload 類型

AX 的核心判斷是：Agent 不應直接套用傳統 microservice 或 batch job 的生命週期。

Agent 會累積 filesystem / memory state、執行不可信程式碼、頻繁呼叫模型與 MCP server，而且大量時間處於等待狀態。因此 AX 提供 Agent-specific 的 suspend、resume、workspace 與 sandbox primitives，而不是要求開發者自行用 Pod、Job、Queue 與資料庫拼出完整生命週期。

2. Declarative Agent Orchestration

AX 採取非常接近 Kubernetes 的宣告式操作方式。開發者以 ax.io/v1alpha1 manifest 描述 Task、Workspace 與 Model，再透過類似 kubectl 的 apply、get、describe、watch、delete 操作。

除此之外，它加入 Agent 特有的：

ax suspend
ax resume
ax ssh

這讓 Agent execution 從「啟動一支 Python 程式」提升成可以被平台持續管理的資源。

3. Suspend / Resume 不只是重新啟動 Process

AX 建立在 Agent Substrate 之上。Substrate 將 Agent-like workload 抽象為 actor，並把大量 actor multiplex 到較少的 ready worker 上。

當 Agent 閒置時，可以保存 memory 與 writable filesystem snapshot，釋放實際 compute；之後再把 actor 恢復到 worker 上繼續執行，而不是從 application checkpoint 自行重建狀態。

這特別適合 Agent，因為 Agent 經常等待 LLM、Tool、事件或人類輸入，傳統「一個 Agent 長期占一個 Pod」會浪費大量資源。

4. Execution Runtime 與 Agent Framework 解耦

AX 明確不是 Agent framework，也不要求使用特定模型。

Google 官方列出的方向包含自訂 Agent、ADK、LangChain / LangGraph、A2A Agent，以及不同 harness。換言之：

text

Agent Logic / Harness
        ↓
Agent Executor (AX)
        ↓
Agent Substrate
        ↓
Kubernetes / Compute

這個分層比把 orchestration、reasoning、sandbox、state persistence 全塞進同一套 Agent framework 更接近成熟基礎設施的設計。

核心架構與運作方式

開發者先建立 Workspace，描述 Agent 執行前需要的 Git repository、MCP server、skill package 等資源，再建立 Task 指定實際 Agent workload，Model 則負責平台需要使用的模型與 credential configuration。

AX control plane 接收宣告後，透過 Agent Substrate 建立 sandboxed actor。Task 執行期間可透過 ax watch 觀察狀態，也可以在 debug 模式下使用 ax ssh 直接進入 sandbox。

當 workload 進入長時間 idle，可以 suspend。Agent Substrate 將 actor 的記憶體與 working filesystem 保存為 snapshot，worker capacity 隨即可以重新分配給其他 actor；resume 時再恢復原有執行狀態。

Agent Substrate 本身仍利用 Kubernetes 管理 worker infrastructure，但將高頻 actor lifecycle 從 Kubernetes API critical path 移開，避免大量短週期 Agent 操作直接壓向 Kubernetes control plane。

主要優勢

Agent-native lifecycle。 Suspend、resume、workspace、sandbox 與 execution observation 都是平台原生概念，不必由每個 Agent application 重做。

高密度資源利用。 Agent 大量 idle 的特性可以被轉化為 compute multiplexing，而不是讓閒置 Pod 長期占用 CPU、RAM 與節點容量。

Framework / Model agnostic。 Agent reasoning framework 與 execution infrastructure 分離，降低平台被單一 Agent SDK 或模型供應商綁死的風險。

隔離能力。 Agent 產生並執行程式碼時，sandbox 是重要的安全邊界；底層 Agent Substrate 支援 gVisor 與 microVM 類型的隔離方向。

Kubernetes-friendly mental model。 對已熟悉 Kubernetes 的 Platform Engineering 團隊而言，declarative manifest 與 apply/get/watch 類型的操作模型相對自然。

狀態恢復能力。 Agent 可以跨斷線、等待與暫停持續工作，比單純重新啟動 container 更符合長時間 autonomous workload。

相較同類型工具的優點

對 LangGraph / CrewAI / ADK

這些工具主要解決 Agent graph、reasoning loop、tool calling 與 application logic；AX 則解決 execution lifecycle、isolation、resumption 與 cluster orchestration。

因此 AX 更像是它們下面的一層，而不是直接競爭者。大型系統甚至可能同時使用 ADK / LangGraph + AX。

對 Kubernetes Job / Pod

Kubernetes 可以執行 Agent，但其核心 abstraction 並沒有針對數量龐大、長時間 idle、需要保存 RAM / filesystem state 且頻繁 suspend / resume 的 actor workload 設計。

Agent Substrate 讓 Kubernetes 繼續管理 infrastructure capacity，同時把高頻 Agent lifecycle 移到專門 control plane，這是 AX 架構最重要的差異之一。

對自行建立 Queue + Worker 系統

傳統 Queue Worker 很適合無狀態 task，但長時間 Agent 通常還需要 session state、sandbox、workspace、network policy、resume、debugging 與 model/tool integration。AX 試圖把這些能力收斂成共同 runtime contract。

缺點與限制

AX 目前仍處於 heavy development，官方明確警告 stable release 前可能發生重大 breaking changes，因此目前不適合把 API stability 視為既定條件。

其基礎設施成本也不低。要發揮完整能力，需要 Kubernetes 與 Agent Substrate，團隊必須具備 Platform Engineering、cluster operation、container security 與 observability 能力。

Agent Substrate 同樣仍屬 preview。官方安全文件明確指出目前沒有 stable release，security fixes 主要落在 main，尚未具備正式 release branch、backport 與完整 security SLO。

此外，若專案只有少量 Agent、工作時間短、沒有 sandbox 或 suspend/resume 需求，直接使用現有 Agent SDK + container/serverless 通常更簡單。

適合的使用者與專案

適合：

建立大量 Coding Agent / Research Agent 的平台團隊
需要 Agent 長時間執行與斷點恢復的系統
Multi-tenant Agent SaaS
需要執行 Agent-generated code 的服務
已有 Kubernetes / Platform Engineering 能力的企業
希望 Agent framework、模型與 infrastructure 解耦的架構
需要自行掌控資料面、sandbox 與 compute 的環境

不適合：

單一聊天機器人
短生命週期 function calling
每次請求都可完全無狀態重建的 Agent
沒有 Kubernetes 維運能力的小型團隊
目前要求非常穩定 API / 長期相容性的 Production 核心系統
不需要 sandbox、snapshot 或大規模 Agent orchestration 的應用

簡短結論

AX 最值得關注的不是它又提供了多少 Agent API，而是它提出了一個更底層的問題：如果 Agent 真正成為新的計算 workload，是否也需要自己的 execution control plane？

Google 的答案是把 Agent logic、execution runtime 與 compute substrate 拆成不同層級。AX 負責宣告與管理 Agent workload，Agent Substrate 負責高密度、可暫停的 actor execution，Kubernetes 則繼續管理底層 infrastructure。

這條路線若成熟，未來 Agent 平台可能不再是「在 Kubernetes 上跑很多 Python Agent container」，而會更接近一套專門為 autonomous、stateful、bursty workload 設計的作業層。

目前 AX 還太早期，不建議直接視為成熟 Production 標準；但從架構創新與生態潛力來看，它是近期非常值得 Platform / AI Infrastructure 開發者追蹤的一套工具。