AX 是 Google 开源的声明式智能体编排运行时，基于 Agent Substrate 实现沙箱执行，用 Task、Workspace、Gateway、Model 四类原语管理集群中大规模自主智能体任务的隔离、网络与生命周期。
项目做什么
AX 旨在为自主智能体这一新型工作负载提供声明式编排能力。它通过 Kubernetes 风格的 YAML 清单（ax.io/v1alpha1）让用户声明任务、工作区、网关和模型，并由控制平面完成沙箱化、工作区预接线、网络出站限制以及批量运行。其定位介于无状态微服务与一次性批处理之间，针对智能体需要积累状态、严格隔离、调用模型 API 和工具服务器、且可能陷入烧钱循环等特征，提供可声明、可观测、可暂停恢复的统一管理方式。
与同类方案相比
从 README 可见的优势包括：以四个小型原语覆盖智能体运行的主要需求，全部通过单条 ax apply 命令应用；CLI 刻意模仿 kubectl，提供 apply、get、describe、watch、delete 等命令，并支持 ax ssh 进入运行中的沙箱、ax suspend/ax resume 对空闲智能体做检查点与恢复；可跟随当前 kubectx 上下文并在后台自动解析和建立隧道，也支持通过 –context 定向其他集群；工作区可预先配置 Git 仓库、MCP 服务器和技能包，使智能体启动即处于就绪状态。README 未与其他编排系统做具体性能对比，因此相对竞品的量化优势尚无法验证。
设计与创新
AX 的创新点在于将智能体视为一类独立工作负载，并为其设计了 Task、Workspace、Gateway、Model 四类声明式原语，分别对应沙箱执行与资源限制、工作区预接线、出站主机白名单和平台所用 LLM 及凭据配置。它建立在 Agent Substrate 之上做沙箱化执行，提供 ax suspend/resume 对智能体状态做检查点式暂停与恢复，以及 ax ssh 直接观察运行中沙箱内部情况。README 提到其设计目标是每集群运行数十亿任务，但未给出实测数据，因此该吞吐能力与具体实现机制尚无法独立验证。
适用场景
适用场景包括：在集群中批量运行不受信任的智能体代码，并为其设置 CPU、内存限制和沙箱隔离；为每个智能体预先准备好 Git 仓库、MCP 服务器与技能包，避免每次冷启动重新拉取和配置；通过 Gateway 将出站流量限制到显式主机白名单，以约束智能体对外部模型的访问面；配置平台自身的 LLM 及其从 Kubernetes Secret 读取的凭据；对空闲智能体暂停以节省资源，之后从原状态恢复；在调试时用 ax ssh 进入沙箱查看工作区与执行一次性命令。演示脚本 demo.sh 展示了从应用工作区、等待就绪、执行命令到暂停任务的完整生命周期。
谁会受益
对于已经使用 Kubernetes 的团队，AX 的 kubectl 风格 CLI、命名空间与上下文处理方式降低了学习成本，声明式清单便于版本化和复用。它把智能体运行中常见的隔离、网络管控、模型配置和状态恢复收拢为统一抽象，使运维者无需为每个任务手工搭建沙箱与依赖环境，也便于通过 ax watch 和 ax describe 观察任务阶段与条件变化。README 明确说明核心概念、协议与规范仍在积极完善中，稳定版发布前预计会有重大破坏性变更，因此当前更适合评估、实验和内部原型，而非直接承载对稳定性要求极高的生产负载。
使用前需要注意
README 以 WARNING 明确指出核心概念、协议和规范仍在完善，稳定版发布前很可能引入重大破坏性变更，说明当前版本尚不适合依赖长期稳定 API 的生产环境。部署需要 Kubernetes 集群、ko、可被集群拉取的镜像仓库以及可达的 Agent Substrate 控制 API，存在一定前置依赖与运维成本。ax ssh 要求任务在清单中开启 spec.debug，意味着调试能力并非默认开放。README 未披露实际的吞吐测量、资源开销、多租户安全边界细节或与同类系统的对比数据，因此其每集群数十亿任务的目标、隔离强度与性能表现均尚无法验证。
本文基于抓取时的项目 README 和仓库简介整理；功能、限制与文档可能随项目更新而变化。