AX 正式开源：面向 Agent 工作负载的新型编排器

Google 于 2026 年 3 月正式开源 AX（仓库地址：google/ax），这是一个专为自主 Agent 工作负载设计的高吞吐、声明式编排运行时。AX 目标是在单集群中调度十亿级 Agent 任务，其核心特性包括：

• Apache-2.0 开源协议，由 Google 主导开发
• 当前状态：Alpha 阶段，核心概念与协议仍在快速迭代
• GitHub 星标超 11,600+，Fork 超 560
• 操作兼容 Kubernetes 生态：ax apply、get、describe、watch、delete 一套命令风格
• 底层依赖 Agent Substrate：专注编排层，沙箱隔离交由子项目处理

为什么需要 AX？Agent 工作负载的独特挑战

传统调度系统（如 Kubernetes Pod 模型）假设工作负载是无状态服务或批处理任务，但 Agent 具备本质不同特征：

• 会积累状态，而非瞬时完成
• 需严格沙箱隔离防止越权行为
• 频繁调用模型 API 与工具服务器
• 可能因逻辑缺陷持续消耗 Token 预算
• 需支持「暂停后原地恢复」与「实时调试接入」

AX 团队在项目 README 中明确指出：Agent 是一种新的工作负载类型，既非微服务也非批处理任务。为此 AX 提出三个正交的声明式原语：

• Task：沙箱化执行单元，负责隔离、暂停、恢复
• Workspace：预热好的工作环境，支持 Git 克隆与_goal_驱动的环境搭建
• Model：集群级模型配置，实现密钥轮换与版本统一管理

一个意外的反差在于存储设计：AX 没有采用 Kubernetes 常用的 etcd 存储 Task 状态，而是使用 Redis + Streams。官方解释是，若将百万级短生命周期任务写入 etcd，将遭遇其「个位数 GB 存储上限」与写入瓶颈。这一选择表明 AX 团队从源头放弃了「一切皆 CRD」的 K8s 心智，仅保留用户可见的 kubectl 风格交互。

架构与核心特性解析

AX 采用清晰的分层架构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

用户输入 (ax apply)
     │
     ▼
ax-server (无状态 gRPC API)
     │
     ▼
Redis (Task Hash + Streams + PubSub)
     │
     ▼
ax-controller (水平扩展 Worker 池)
     │
     ▼
Agent Substrate (沙箱执行层)

关键特性包括：

• kubectl 风格 CLI：ax apply/get/describe/watch/delete + Agent 特有命令 ax ssh/suspend/resume
• Task 最小化设计：不建模 Agent 内部行为（计划/委派/重试），仅提供廉价可组合的执行单元
• Workspace 目标驱动引导：通过自然语言 goal 描述环境需求，由启动时的 Agent 自动完成依赖安装
• 沙箱常驻 Runner：ax-task-runner 作为 PID 1 守护进程，命令退出后仍维持 ax ssh 调试通道
• 集群级 Model 资源：统一管理模型密钥与生成参数，避免在各 Agent 环境变量中重复配置

谁适合 early adopter？

AX 目前处于 Alpha 阶段，官方明确提示「稳定版前可能存在重大 breaking change」。以下场景较为适配：

• 需大规模运行自主 Agent 的团队：如批量代码修复、多仓库运维 Agent，任务量已超出手动脚本管理能力
• 熟悉 Kubernetes 运维的团队：kubectl 用户可零成本迁移心智模型
• 需要暂停/恢复长任务的场景：通过 ax suspend/resume 实现资源节约与断点续跑
• 愿意承担 Alpha 风险的技术 contributor：可参与底层架构演进（如迁移到新 Actor API、空闲检测自动挂起等）

写在最后

AX 的价值不在于发明 Agent 该「如何思考」，而在于把「如何在集群中安全、大规模地运行会积累状态的新工作负载」这一基础设施问题解构为清晰的声明式原语与分层架构。当 Agent 从实验走向生产，底层编排的标准化将决定上层能力的上限。