Google AX 把代理執行變成可恢復工作

Google AX 是一個可恢復、可稽核的分散式代理執行 runtime。

讀完這 5 項，你可以判斷 Google 的 AX 是不是適合拿來做長時間、可回復的 agent 工作，而不是只做一次性的模型呼叫。它目前仍在早期開發，但已經把「中斷後續跑、留下紀錄、分散部署」這三件事講得很清楚。

1. 可續跑的執行流程

AX 最核心的設計，是把 agent run 當成可以中斷、接續的工作。客戶端斷線、程序失敗，或工作做到一半需要改輸入時，runtime 不必整個重來，而是能從最後一個 sequence number 繼續。

這對長流程特別重要，例如多步推理、工具呼叫、外部系統等待回應。repo 裡的 CLI 也直接示範了 fresh run 與 resumed run 的差異。

• ax exec --conversation ... --resume
• ax exec --last-seq 12 --resume
• 可用 conversation ID 接回同一段工作

2. 事件日誌讓每一步都能追

AX 把執行狀態放進 event log，而且由單一 controller 負責寫入。這種單寫入架構的好處，是每次 agent、工具、技能的動作都有清楚順序，事後要重播或檢查也比較容易。

官方描述不只是把它當儲存方式，而是把它視為控制與稽核能力。對需要追責、除錯或觀察行為的團隊來說，這比單純保存對話內容更有價值。

• single-writer 架構
• durable event log
• controller 統一協調 user calls、agent calls 與 tools

3. 把 agent、工具、技能拆開跑

AX 把 agents、tools、skills 視為彼此隔離的 actors，彼此不必擠在同一個程序裡。架構圖顯示 controller 會把工作分派到遠端 agent、工具服務，還有內建 skills 的 environment。

這種拆法適合重視安全性、可靠性或水平擴充的系統。工具可以透過 RPC 或 MCP 服務暴露，讓整體架構更像分散式工作流，而不是單一巨型應用。

• remote agents 透過 gRPC
• tools 可接 MCP servers
• environment 與 skills 分離成獨立 actor

4. CLI 能直接接自訂代理

AX 不只是 runtime 規格，也提供實際可操作的命令列介面。你可以啟動遠端 agent server，把它註冊進 ax.yaml，再用 ax exec 叫它工作。

這讓開發者可以快速測試自己的 agent 行為，也能把自訂 agent ID、伺服器位址與恢復流程串在一起。對需要反覆調整 agent 的團隊來說，CLI 是很實用的入口。

• ax exec --server localhost:8494 --input "Hello agents!"
• ax exec --agent coding --input "Write a simple HTTP server in Python"
• ax serve --config my-config.yaml

5. 以 Kubernetes 當主要落地方式

專案明確寫出 AX 原生支援 Agent Substrate on Kubernetes，而且建議把它當作 production 的主要部署方式。同時它也被描述為 compute-agnostic，不綁死單一執行環境。

這代表 AX 更像是給要跑長時間 agent 工作的團隊，而不是只做 demo 的工具。如果你需要 controller、恢復機制與分散 actor，Kubernetes 會是最順的路。

• production 優先選 Kubernetes
• 可搭配 local 與 server mode
• 適合小型與大型部署

怎麼挑

如果你的 agent 系統需要中斷後續跑、保留完整紀錄，AX 很值得看。它比較適合長壽命任務、分散協調與可觀測性要求高的團隊。

如果你只想要一個簡單的本機模型包裝器，AX 目前可能偏重。但若你已經在規劃自訂代理、遠端工具與 Kubernetes 部署，它會是很明確的候選方案。