AX 是一个开放、声明式的编排器，用于在集群中运行自主智能体工作负载。简单来说，它把智能体外部的infrastructure——隔离运行时、工具、网络访问和模型设置——转化为可复用的规格，并能像 Kubernetes 资源一样应用和管理。
文章将 AX 介绍为 Google 推出的开放项目，它把智能体基础设施封装为声明式集群资源。
该项目的网站和 `google/ax` 仓库介绍了四个核心对象。Task 在具备 CPU 和内存限制的沙箱中运行不受信任的智能体代码；Workspace 在执行前准备 Git 仓库、模型上下文协议（MCP）服务器和技能；Gateway 通过主机和端口允许列表控制出站流量；Model 则集中管理模型参数和密钥。因此，一份清单可以同时声明一个 Go 仓库，以及应在预配置环境中运行的任务目标。
这一工作流有意采用 Kubernetes 用户熟悉的模式：编写 YAML，运行 `ax apply`，通过 `ax watch` 观察状态，并使用 `ax ssh` 检查沙箱。当智能体等待模型、工具或人工回复时，AX 表示它能够对执行单元进行检查点保存并挂起，然后在不到一秒内将其恢复，且无需冷启动。其所述效率思路，是在任务空闲时共享工作节点资源，仅在智能体主动运行代码时消耗算力。
这一承诺伴随着大量前提条件。快速入门说明要求具备 Kubernetes 集群、`ko`、容器注册表，以及可访问的 Agent Substrate 控制 API；AX 依赖该底层平台执行沙箱化任务。仓库还警告称，其概念、协议和规范仍在完善中，在稳定版本发布前可能发生大幅变化。所谓“十亿级任务”是设计目标，而不是经过独立验证的基准测试，也不是现实世界容量已经得到证明的依据。
实际的问题在于，AX 的价值究竟来自沙箱本身，还是来自其外围控制平面。虚拟机能够提供隔离，但 AX 试图通过单一界面，让大量短生命周期或长期运行的智能体具备可观测性、网络限制、检查点能力和可复现配置。现有材料并未证明其生产成熟度或独立性能结果，也没有说明这种取舍与虚拟机快照相比如何，因此更稳妥的结论更为有限：对于已经准备好以集群规模运行智能体基础设施的团队，AX 提供了一套连贯的运行模型。