10,459 颗星、v0.3.0 刚发：Google AX 把”在 Kubernetes 上跑 Agent”做成了标准化基础设施

智源·AI 开源观察 技术创作者 2026-09-25 71 阅读

Google 刚刚把它的 Agent 运行时从”内部实验”变成了开源项目：AX v0.3.0 上周发布，10,459 颗星，Apache 2.0 开源，直接把”在 Kubernetes 上跑 AI Agent”这件事做成了标准化的基础设施层。

这不只是一个技术发布。它是 Google 第一次把自己的 Agent 编排思路完整开源，而且没有藏在某个 Google Cloud 服务后面——你可以在任何 Kubernetes 集群上跑它。

AX 是什么：Agent Substrate 之上的控制平面

简单说，AX 是一个声明式的 Agent 编排运行时，运行在 Agent Substrate（也是 Google 开源）之上。它解决的核心问题是：AI Agent 既不是微服务，也不是批处理任务，它们是 Stateful、时断时续、长时间运行的 Actor。

Kubernetes 设计出来是跑无状态服务的。Agent 完全不符合这个模型——它们会积累状态（文件修改、对话历史、浏览器 session），会在等待模型 API 响应时长时间空闲，还会在循环里烧掉大量金钱。传统方案下你只能选择让容器一直空跑（浪费算力）或者每次从冷启动（增加延迟）。

AX 的答案是：checkpoint + suspend + resume。idle 的 Agent 被挂起，不占用计算资源；需要恢复时，在亚秒级内从快照恢复，多个任务复用同一个 Worker 节点。Google 声称这个架构可以支持”数十亿任务每集群”，当然这个数字目前没有第三方独立 Benchmark 验证。

四个声明式原语：Task / Workspace / Gateway / Model

AX 暴露四个 ax.io/v1alpha1 资源，用 YAML 描述，用 ax apply -f 部署：

Task：隔离执行沙箱，定义 CPU/内存限制、引用的 Workspace 和 Gateway、执行命令。轻量级，可以快速创建和销毁。

Workspace：预装环境。可以声明 Git 仓库、MCP 服务器、Skill 包；也可以直接写一句自然语言目标（”set up a Python 3 development environment”），AX 会在首次启动时自动用生成式 Agent 配置好工具链和依赖。

Gateway：出站网络安全策略。白名单允许的 hostname 和端口，注入凭证到出站请求。防止跑进来的 Agent 乱打电话，是生产级部署的必备边界。

Model：统一管理 LLM 提供商配置、模型参数、Kubernetes Secret 里的 API Key。一处配置，全局生效，换 Key 或切模型只需要一次 ax apply。

实际使用起来大约是这样：

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
    - repo: https://github.com/golang/go.git
      branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspaces:
    - name: golang
      goal: "Ensure that Go tool chain is available and is built from source"
  debug: true   # 开启后可以用 ax ssh 进沙箱调试

然后：

ax apply -f task.yaml
ax watch task test
ax ssh test -- ls -al /workspace

v0.3.0 的关键变化：状态从 etcd 迁出到 Redis Streams

AX v0.3.0（2026-09-20）是一次架构重构。团队把任务状态从 Kubernetes CRD（存储在 etcd）迁移到了 Redis Streams。理由是：如果在 etcd 里创建数百万个短生命周期 Task CRD，会把 etcd 撑爆。Redis Streams 更适合这种高频写入、顺序消费的场景。

这个版本还引入了 Gateway 资源（v0.2.x 没有网络隔离能力），并正式把”生成式 Workspace”作为一等公民——你可以用自然语言描述环境，AX 内部跑一个初始化 Agent 来完成配置。

真实的使用门槛：不适合谁

说清楚它的边界很重要。

不适合你如果：

  • 只有几个 Agent 在跑，Kubernetes 集群也没有——AX 需要一个完整的 K8s 集群、Redis、Agent Substrate，没有单机路径
  • 你是个人开发者或小团队——运维成本很高，API 是 v1alpha1，随时可能有 breaking change，维护成本超过收益
  • 需要开箱即用的框架而不是基础设施——AX 不提供 Agent 逻辑框架（Agent 写什么、怎么推理），它只负责”在哪里跑、怎么隔离、怎么 suspend/resume”
  • 需要对每个 Agent 有完整的身份和审计——多路复用模式下 pod 身份不再是单一 Agent 的边界，OIDC/SPIFFE 身份注入还在开发中，没有正式发布

适合你如果：

  • 你在跑大规模 Agent 评估、强化学习训练数据收集、批量工具调用等”突发密集型”场景
  • 你有专职平台工程师，有能力维护一套 Kubernetes + Redis + Agent Substrate 的控制平面
  • 你在评估” Agent 基础设施层应该选什么”，想看看 Google 自己的答案

社区反应：有人兴奋，有人怀疑

AX 上周登顶 Hacker News，获得 500+ 分，但评论区讨论比点赞更有价值。

基础设施工程师普遍认可它解决的是真实问题——idle Agent 的算力浪费是所有跑 Agent 的人都会遇到的账单噩梦。

怀疑的声音集中在两点：“十亿任务”的数字没有第三方 Benchmark，Google 自己的 Demo 数据不等于可验证的生产数字；以及多路复用模式下的安全边界——当多个 Agent 共享一个 Worker Pod，Pod 身份不再是可信边界，而替代方案（OIDC/SPIFFE 身份注入）目前还在开发中。

还有一点值得注意：Google 内部同时还有另一个项目 Scion 在做 Agent 编排——只是 Scion 选择在现有 harness 之上做 Kubernetes 包装层，而不是 AX 这种从底层重新设计的路线。两个项目并存说明 Google 内部对”正确答案”还没有收敛。

可执行的下一步

  1. 如果你在评估 Agent 编排基础设施：在本地 Kind 或 Minikube 集群里跑一遍 AX Quick Start（go install github.com/google/ax/cmd/ax@latest 然后 ax apply -f examples/task.yaml），感受它的 YAML 原语和 CLI 是什么手感
  2. 如果你在跑 Agent 评估或 RL 训练：这是 AX 真正设计的场景，值得认真评估它的 suspend/resume 机制能否降低你的 GPU/算力账单
  3. 持续关注：v1alpha1 意味着还在快速迭代，不要在生产环境锁死它，等 Google 内部产品线（Antigravity、Managed Agents API）是否最终路由到 AX 再做长期押注

相关链接：

评论区

0 条评论

登录后可评论。

智源·AI 开源观察 71 阅读