AX 是一个开源的声明式控制平面，用来编排智能体执行，用户用 YAML 定义任务，平台负责沙箱、供给环境、网络围栏和跨集群伸缩，采用 Apache 2.0 许可。它出自谷歌，结合了 DeepMind 的智能体运行时研究和大规模隔离、恢复与调度经验，构建在 Agent Substrate 计算运行时之上。要规模化跑智能体的平台团队可以直接评估它，理由是智能体的运行特征和无状态微服务、批处理任务都不一样。
智能体为什么不能套用微服务的抽象
智能体会积累状态，需要严格隔离，要调用模型 API 和工具服务器，如果没有监视可以无限循环。无状态微服务的抽象假设请求之间没有状态，批处理任务的抽象假设任务跑完就结束，两者都不贴合。AX 的判断是智能体自成一类工作负载，需要专门的编排原语，这个判断决定了它的整个设计。
四个原语各自解决什么
接口版本是 ax.io/v1alpha1，声明式清单里定义四类资源。
- Task 提供带 CPU 和内存限制的隔离执行，创建、挂起和丢弃的代价都很低。
- Workspace 准备沙箱环境，可以拉取 Git 仓库、配置 MCP 服务器和技能，也可以只给一个自然语言目标，让智能体在任务开始前把环境搭好并验证。
- Gateway 管网络策略，包括主机和端口白名单，以及入站请求的凭据注入。
- Model 集中管理模型选择、参数和密钥，轮换密钥或锁定版本只需改一处声明。
清单里声明 Workspace 资源指定 Git 仓库和分支，再声明 Task 资源关联一个或多个 Workspace 并设置目标字符串，任务规格里有 debug 开关。命令行工具 ax 支持 apply、watch、get、ssh、suspend、resume、delete，任务生命周期有 Pending、Running 和终态。
检查点和恢复是怎么实现的
每个任务作为 Agent Substrate 上的轻量 actor 运行，官方称单集群可支撑数十亿并发智能体会话。智能体等待模型响应、外部工具调用或人工输入时会做检查点并挂起，恢复在一秒以内且没有冷启动。密集复用让几十个任务共享同一批 worker，把等待时间变成空闲算力。官方口径的并发与恢复指标缺少第三方复现，选型时要自行压测。
什么场景适合什么场景不适合
适用负载包括交互式编程智能体、长期运行的智能体服务器、Jupyter 笔记本、无头浏览器测试和自定义工具运行时。它不绑定特定智能体框架，是通用运行时。不适合的场景也很明确，一次性脚本和纯批处理用传统任务调度更省事，强实时低延迟的交互路径需要自己评估 actor 挂起和恢复引入的额外跳转，对现有 Kubernetes 生态有深度依赖的团队要考虑双控制面的运维成本。
引入前要验证哪些指标
- 检查点恢复时间在自己负载下的实测值，官方的一秒口径要用自己的任务验一遍。
- 密集复用下 worker 的 CPU 和内存水位，确认等待时间确实变成了可用算力。
- Gateway 白名单和凭据注入策略能否覆盖现有安全基线。
- Model 层的密钥轮换和版本锁定流程能否接进现有密钥管理。
- 声明式控制面那一处的权限和审计是否管严，集中配置的好处是单点修改，代价是这一处必须严管。
- 长任务的外部副作用不在检查点恢复范围内，状态可序列化是恢复的前提，涉及外部写入的任务要自己设计幂等。
常见问题
问，AX 和直接用容器跑智能体有什么区别。答，容器解决隔离，不解决状态挂起、恢复和密集复用，AX 把这三件事做成了控制面原语。
问，自然语言目标的工作空间可靠吗。答，生成式工作空间层会在任务开始前搭好环境并验证，简单环境够用，复杂环境建议显式声明工具和依赖。
问，现有调度系统要不要换掉。答，AX 是通用运行时，可以并行引入，先把一类智能体负载迁过去压测，再决定是否扩大范围。