Google 开源 AX：为 AI Agent 打造的 Kubernetes

当 AI Agent 需要一个专属的 Kubernetes

Google 推出了一套面向 AI Agent 的运行时系统，名字叫 AX（Agent Executor）。它的定位一句话就能说清：如果 Kubernetes 是为 Web 服务而生，那么 AX 就是为 Agent 而生。

开发者用 YAML 声明一个 Agent 任务，一个为「十亿级并发会话」设计的运行时负责执行它——包括崩溃恢复在内。据 Prism Labs 频道的解读，AX 能在崩溃后从内核快照中恢复「死掉」的 Agent，耗时不到一秒。项目采用 Apache 2.0 协议开源，v0.3.0 版本已经发布。

这套系统的血统不简单。AX 源自 Google DeepMind 的研究，以及 Google 在行星级隔离与调度上的生产经验，由业界备受尊敬的基础设施工程师 Jana Dogan（Yana Dogan）发布，并配有官方的 Google Cloud 上线博文。仓库地址为 google/ax，纯 Go 编写，目前已有超过 3200 个 star，而 open issues 只有 7 个——这个数字说明它是一个小而专注、维护活跃的代码库，而不是堆砌功能的垃圾场。

四个声明式原语：熟悉 K8s 的人零门槛

整套系统可以归纳为四个声明式原语，如果你懂 Kubernetes，几乎能凭直觉理解它的运作方式。

• Task（任务）：执行单元，沙箱化的 Agent 代码，带有 CPU 与内存限制。
• Workspace（工作区）：预先接线好依赖项——Git 仓库、MCP 服务器、技能包，在 Agent 启动前就已「预热」。
• Gateway（网关）：控制网络，带有显式的出站白名单（egress allow list）和凭证注入。
• Model（模型）：集中管理 LLM 配置、参数和密钥，这样 50 个任务不必各自携带 50 份 API key。

用 YAML 声明这四者，apply 之后，运行时会让「现实」向「声明」对齐——正是这套心智模型让 Kubernetes 深入人心。

CLI 同样「说着一口流利的 kubectl」。ax apply 提交任务清单并启动，ax get tasks 列出运行中的一切，ax watch 实时流式追踪进度。最有意思的是 ax ssh：它能直接让你进入正在运行的沙箱做交互式调试。当一个 Agent 在第 400 步做了奇怪的事，你可以直接进去看。挂起（suspend）与恢复（resume）随时可用。对于已经生活在 kubectl 里的团队，学习曲线基本为零——一样的动词、一样的 YAML 反射，只是换了新名词。

真正撑起「一整套运行时」的能力

这些功能才是 AX 值得成为一个独立运行时的理由：

• 持久化执行：通过事件日志与快照实现。
• 亚秒级恢复：检查点 actor 无冷启动即可恢复。
• 连接恢复：中途掉线的客户端重连后，能从它看到的最后一个序列号开始，回补所有错过的响应。
• 轨迹分支（Trajectory Branching）：从内核快照 fork 出一个 Agent 去探索另一条路径，同时不丢失原始状态。
• 生成式配置：用自然语言描述工作区，AX 在首次启动时自动完成配置。

单独看，这些功能你都能自己「拼」出来。AX 的卖点在于——用一个运行时把它们全拿到手，而不是维护五套各自会在凌晨三点以不同方式崩溃的定制系统。

Jana Dogan 的发布定调是对这份野心最干净的总结：一个通用运行时，解决动态调度、恢复、自动修复、审计，以及从内核快照做轨迹分支。注意这个清单上的东西——都是那些无聊却残酷、真正在生产环境里杀死 Agent 产品的可靠性问题，而不是又一个 prompt 框架。这就是 Google 的赌注：别人在比拼 harness（编排壳层），Google 在竞争下面那一层。

**轨迹分支（Trajectory Branching）**值得单独解释一下。在强化学习和 Agent 研究中，「轨迹」指 Agent 从起点到终点所经历的完整状态-动作序列。传统调试方式下，如果你想测试「第 300 步换一个不同决策会发生什么」，只能从头重跑——代价极高。AX 的轨迹分支借鉴了操作系统中 fork() 的概念：在任意检查点对内核快照做写时复制（Copy-on-Write），派生出一个完全独立的 Agent 实例去探索另一条路径，原始实例继续运行，两者互不干扰。这个能力对 Agent 评估（evals）尤为关键——你可以在同一个「现场」同时对比多个策略的结果，而不必维护多套独立的重放基础设施。

Agent Substrate：那些「离谱」的数字

AX 之下是数字最夸张的部分——Agent Substrate，一个建立在 Kubernetes 之上的新抽象层。Google 宣称它面向「数亿注册 Agent、每秒数百万次亚秒级工具调用、每集群数十亿并发会话」而设计。

诀窍在于用轻量级 actor 取代重量级 pod。Agent 大多数时间在空闲等待模型或人类响应，因此密集多路复用能把海量会话打包进普通集群。控制平面本身运行在 Kubernetes 中，驱动 substrate 的控制 API。

这些数字是不是「营销级」的？坦白说，Google 之外还没有人验证过「数十亿」级别的任何指标，文档也公开承认这是实验性的。但架构论证是成立的，而且它出自一支先在内部生产规模上跑过这个问题的团队。

为什么不直接在裸 Kubernetes 上跑 Agent？因为 Agent 不是 Web 服务。Pod 假设的是长期存活、持续处理请求的进程；而 Agent 是突发性的、大多空闲、会在「思考到一半」时死掉。Kubernetes 重启很快，但重启出来的是一个冷 pod；AX 恢复的则是一个上下文完整的检查点 actor。K8s 的网络策略是通用的，AX 网关则「懂 Agent」——按任务注入凭证的出站白名单。当编排器的上限是每节点数千 pod 时，Substrate 靠密集多路复用宣称每集群可达数十亿会话。

Actor 模型是理解 Agent Substrate 密度优势的关键。与传统的线程或进程模型不同，Actor 模型将每个并发单元抽象为一个轻量的「行动者」：它有私有状态、通过消息传递与外界通信，空闲时不占用线程资源。Erlang/OTP 和 Akka 是该模型的经典实现，单节点可轻松维持数百万并发 Actor。AI Agent 的工作负载天然契合这一模型：绝大多数时间，Agent 在等待 LLM 推理返回或人类审批，真正占用 CPU 的时间极短。Kubernetes Pod 的调度粒度以「进程」为单位，空闲的 Pod 照样占用内存和 IP 地址；而基于 Actor 的 Substrate 可以将数十亿个「等待中」的会话压缩进少量实际运行的进程，这正是那个惊人数字背后的架构逻辑。

崩溃即恢复：这就是命名蝾螈的秘密

每个 Agent 开发者都熟知的失败故事是这样的：一个迁移 Agent 在运行数小时后挂掉。通常这意味着从零重启，一个下午白白蒸发。而有了检查点 actor，运行时从最后一个快照恢复，客户端像什么都没发生过一样重连。

Human-in-the-loop（人在回路）的暂停同理：Agent 挂起，等待审批——几分钟或一周都行，然后瞬间恢复，等待期间不占用任何算力。最后这点直接关系到账单：挂起的 Agent 零成本，这才让「隔夜审批队列」这类模式在经济上说得通。

这也解释了为什么整个项目以美西螈（axolotl，六角恐龙）命名。这种蝾螈能再生失去的肢体；一个从快照中「再生」而非死去的 Agent 运行，正是整个设计哲学披着吉祥物外衣的写照。

开放而非围墙：一步 go install 即可

从发布至今的数据显示这是一个「刻意稳健」的团队：仓库在 3 月底创建，5 月 20 日随 Google Cloud 公告发布 v0.1.0，7 月的 v0.2.0 带来工作区权限与会话 ID 保护，8 月是依赖修复，今日的 v0.3.0 则锁定了 workflow actions 权限——这类供应链加固并不炫酷，却正是你在期待企业上生产时该做的事：先锁好门，再请审计员进来。

四个月内 3000+ 开发者点星、123 天走完首次公开到 v0.3.0、期间六次发布、Fork 数 152——对一个 Google 自称仍在积极打磨的实验性预览而言，这是实打实的势头。

AX 也没做成围墙花园。它联邦化 Google 自己的技术栈（Antigravity、Deep Research、Gemini API 上的托管 Agent），同时兼容 LangChain、LangGraph、ADK 以及 A2A 协议。自带你的 harness，运行你的数据平面，无锁定。这份开放当然是战略性的——如果所有人 Agent 底层的 substrate 都是 Google 的，Google 就赢了。但战略性的慷慨仍然是慷慨，而 Apache 2.0 意味着无论如何它都属于你。

文中提到的 **A2A 协议（Agent-to-Agent Protocol）**是 Google 今年推出的一套开放标准，定义了不同 Agent 之间如何发现彼此、协商能力、委派子任务并返回结果——可以粗略理解为「Agent 世界的 HTTP」。**MCP（Model Context Protocol）**则是 Anthropic 主导的另一项标准，解决的是 Agent 与外部工具、数据源之间的接口问题——相当于「Agent 世界的 USB-C」。AX 同时兼容这两个协议，意味着它试图成为一个协议无关的执行层：无论上层 Agent 框架（LangChain、ADK 等）使用哪套通信标准，底层运行时都能承接。这种兼容策略是 Google「赢得 substrate 层」战略的具体体现。