當 Agent 變成一種工作負載：從 Google AX 看 Agent 執行環境的設計

一個不太像微服務的新工作負載

想像你經營一間餐廳。外帶窗口（微服務）一單來一單走，桌子不會被占住；中央廚房（批次作業）排好時間表，時間到就整批開火。但 AI Agent 比較像是「坐下來慢慢點菜的客人」：先衝刺思考一分鐘、叫廚房備料、等上菜、再想下一道，中間大半時間只是坐著等。

這就是 Google 最近開源的 AX 想解決的問題。它在 Hacker News 拿到 146 分，官網把 agent 定位成「一種新的工作負載」：有狀態、爆發式、跑很久，算一分鐘之後就要等模型、等工具，或等人類核准。傳統 orchestrator 為無狀態服務或可預測的批次作業設計，讓閒置的 sandbox 一直開著很貴，又缺乏極快的暫停與恢復。

AX 的四個基本元件

AX 用 YAML 宣告任務，並歸納成四個 primitive：

• Task：隔離執行。在有 CPU、記憶體上限的 sandbox 裡跑不受信任的 agent 程式碼，建立、暫停、丟棄都很便宜。
• Workspace：工作環境。列出需要的 Git repo、MCP server、skills，甚至只寫一句目標，AX 會在任務開始前備好。
• Gateway：網路政策。只放行明確的主機與埠白名單，並可對出站請求注入憑證。
• Model：模型設定。模型、參數與金鑰集中在一處，換 key 或鎖定版本只要一次 apply。

用餐廳比喻來看：Task 是座位，Workspace 是桌上預先擺好的餐具，Gateway 是門口的保全，Model 則是菜單與帳單。

官網範例很直白：宣告一個指向 golang repo 的 Workspace，再宣告一個 Task，目標寫「確保 Go toolchain 由原始碼建置」。ax apply -f task.yaml 之後，可以用 ax ssh 進去看，也能 ax suspend 暫停再 ax resume 恢復，先前建立的檔案仍然在。

真正的重點：等待時不佔資源

我認為 AX 最值得學的不是 YAML，而是「等待時不佔資源」這個設計。官網說，閒置的 agent 會被 checkpoint、暫停，並在一秒內恢復；多個任務共用 worker，把等待時間變成備用算力。

這裡要誠實提醒：「每個 cluster 數十億任務」與「一秒內恢復」都是專案自己的宣稱，底層依賴另一個叫 Agent Substrate 的專案，實際數字要自己壓測才算數。

為什麼這件事重要？因為 agent 的成本結構跟一般 API 呼叫不同。一個跑 30 分鐘的 coding agent，真正吃 CPU 的時間可能只有幾分鐘，其餘都在等 LLM 回應。如果每個 agent 都占滿一台 VM，成本會被閒置時間吃掉。這和雲端從「一台伺服器一個服務」走向容器、再走向 serverless 的演化如出一轍：把資源綁定從「存活期間」改成「實際運算期間」。

安全也是一等公民

Agent 會執行模型產生的程式碼，也會連外呼叫工具，所以隔離與網路白名單不是加分項，而是必要條件。Gateway 的「注入憑證」設計尤其值得注意：agent 本身不需要看到金鑰，請求離開 sandbox 時才由閘道補上。就算 prompt injection 誘使 agent 想洩漏資訊，它手上能洩漏的東西也有限。這與最小權限原則一脈相承。

延伸思考

1. 如果 agent 可以便宜地暫停與恢復，人類核准（human-in-the-loop）就不再是拖慢系統的瓶頸，可以等一天而不多花錢。你的 agent 流程中，有哪些地方被迫「同步等待」？
2. 官網強調可大量產生可重現的 sandbox，用來收集 trajectory、跑強化學習與評測。當 agent 規模變大，Evaluation 的基礎設施會不會比模型本身更早成為瓶頸？
3. 宣告式 YAML 真的適合 agent 嗎？Kubernetes 的成功來自狀態可被明確描述，但 agent 的目標是自然語言、結果又不是決定性的，「期望狀態」該怎麼定義？
4. 目前 API 版本是 v1alpha1，介面必然還會變。與其現在就綁定，不如先理解它拆出的四個概念，套用到自己的 agent 系統裡：哪些是執行、哪些是環境、哪些是網路邊界、哪些是模型設定？