AX：把 Kubernetes 的心智模型搬到 agent 上

yibie·约 4 分钟阅读

2026年9月21日9月21日

AX: Google 开源的 agent 编排器 —— 用 Kubernetes 那套心智模型管 agent

地址：https://github.com/google/ax （Apache-2.0，Go，2,343 星）

先说清楚它解决什么问题。Agent 不是微服务，也不是跑完就结束的批处理任务。它积累状态，需要严格隔离，要调外部模型 API 和工具服务，而且如果没人盯着，它能在循环里把钱烧掉。现有的编排器要么假设无状态（Kubernetes 那一套），要么假设可预测的批处理——保持空闲沙箱一直跑会贵得离谱，又没有原生的秒级挂起/恢复。

AX 的答案是四个声明式原语，全部是 ax.io/v1alpha1 的 YAML：

Task —— 最小隔离执行单元。声明容器镜像、命令、CPU/内存限额、环境变量，以及要挂载哪些 Workspace。一个 task 故意做得很小：agent 不是跑到底就完的单个进程，它会规划、委派、重试、把工作扇出去。AX 不去建模这个形状，只给你一个便宜、可隔离、可挂起、可丢弃的原语，让 agent 自己按需要组合出任意多个 task 的树。

Workspace —— 把「让 agent 能开始干活」这件事声明化。Git 仓库、MCP 服务器、技能包列一次，每个 sandbox 在命令启动前自动装配好。它还支持 goal：用大白话描述环境需要什么，首次启动时 runner 把这句话交给一个 agent 去装工具链、验依赖。

Gateway —— 网络边界。声明 task 暴露的监听端口，以及一个出口允许清单。把 agent 限制到「只能连你的 LLM 供应商和 Git 主机」。

Model —— 注意，它不是一个模型，而是一份命名配置：调哪个供应商、哪个模型 ID、什么参数、API key 存在哪个 Kubernetes secret 里。好处是换 key、钉版本、调参数都是一次 apply，而不是去每个 task 定义里翻。

一、和 Kubernetes 的关系

这一点官方说得很直白：「如果你用过 Kubernetes，ax 会让你觉得很像。」

命令行是刻意做成 kubectl 形状的：apply、get、describe、watch、delete，加几个 agent 专用的动词。它跟随你当前的 kubectl context，切换集群后 ax 会在后台自己解析并连上那个集群的控制面。

日常长这样：

ax apply -f task.yaml

ax get tasks

ax watch task task123

ax ssh task123 -- ls -la /workspace

ax suspend task task123

ax resume task task123

suspend / resume 是这里最值得注意的一对。挂起会检查点 actor 状态并暂停；恢复时接着来。官网的说法是「空闲 agent 等待模型响应、外部工具调用或人类回复时被检查点化、挂起，然后在一秒内恢复，零冷启动延迟」。

ax ssh 可以进到运行中的 sandbox 里看 agent 在干什么——需要 task 里开 spec.debug: true才行。

二、一个工程细节，比宣传语有信息量

他们的设计文档里有一段很少见的话：

「把几百万个短命 task 存成 Kubernetes CRD 会把 etcd 推到它不舒服的区域——存储上限个位数 GB、写入速率瓶颈、控制面劣化。」

所以 AX 的状态存在 Redis 里，用 Redis Streams 做 API server 和水平扩展的 controller 池之间的工作队列。控制面四个二进制：ax（CLI）、ax-server（无状态 gRPC API）、ax-controller（对账 worker，加副本就能扩）、ax-task-runner（每个 task 容器里的入口，负责装配 workspace、提供元数据、跑 agent 命令）。

这是全文我唯一愿意转述的架构判断：他们没有硬套 Kubernetes 的存储模型，而是在用它做调度外壳的同时，把状态放到了别处。同时保留 kubectl 的操作手感——两件事分开处理。

三、底层是另一个独立项目

AX 跑在 Agent Substrate 之上（github.com/agent-substrate/substrate，2,031 星，同样是 Apache-2.0、Go、今天还在提交）。它提供沙箱执行、actor 创建与激活、worker 分配、出口策略过滤。

官方把分工说得很清楚：AX 提供 agent 抽象和生成式运行时组件，Substrate 提供核心系统。两个仓库分开维护，这意味着 AX 是控制面，Substrate 是执行层，可以各自演进。

四、部署要求（这是门槛）

不是 pip install 就能跑的：

· 需要一个 Kubernetes 集群

· 需要 ko（brew install ko）和一个集群能拉取的镜像仓库

· 需要一个可达的 Agent Substrate 控制 API

然后 make deploy 会把 Redis 和控制面镜像部署到 ax-system 命名空间。

所以 AX 的定位不是「给你笔记本上跑个 agent」，是「给一个集群管一大群 agent」。这个区分很重要，别被「Open」这个词误导。

五、他们自己贴的警告