Google AX：大規模智能體的宣告式編排執行階段

随着大语言模型驱动的自主智能体（Agent）逐渐从实验走向生产，一种全新的工作负载形态正在涌现。与传统无状态微服务或一次性批处理任务不同，智能体在执行过程中会持续累积状态、调用外部模型 API 和工具服务器，并可能因循环决策而消耗大量成本。现有的容器编排平台（如 Kubernetes）虽然擅长管理微服务，却缺乏对智能体沙盒隔离、网络出口控制和状态持久化的原生支持。正是在这一背景下，Google 推出了 AX——一个专为智能体设计的声明式编排运行时。AX 定位为智能体工作负载的"Kubernetes"，它运行在 Agent Substrate 之上，提供高吞吐量的沙盒执行环境，目标是在单个集群中支撑数十亿级别的自主智能体任务。通过将智能体视为一等公民，AX 填补了从脚本化智能体到工程化智能体平台之间的关键空白。 AX 的核心设计围绕四个声明式原语展开：Task（任务）、Workspace（工作空间）、Gateway（网关）和 Model（模型）。Task 是最小执行单元，负责在隔离沙盒中运行不可信的智能体代码，并施加 CPU 和内存限制；Workspace 则预先挂载 Git 仓库、MCP 服务器和技能包，确保每个智能体启动时即处于"热"状态，避免重复初始化；Gateway 通过显式的主机白名单锁定出站流量，防止智能体访问未授权的外部服务，从而控制成本和安全风险；Model 用于配置平台自身使用的大语言模型，凭据从 Kubernetes Secret 注入，实现凭证与代码分离。所有原语均以 ax.io/v1alpha1 的 YAML 清单定义，通过一条 ax apply 命令即可部署。AX 还提供了类似容器的生命周期管理能力：ax watch 实时流式传输任务状态变更，ax ssh 允许开发者直接进入运行中的沙盒查看文件系统或进程，ax suspend 和 ax resume 则实现了智能体的检查点暂停与无缝恢复。这些能力使得智能体不再是一个黑盒，而是可观测、可干预、可复用的受控实体。与直接在 Kubernetes Pod 中运行智能体脚本相比，AX 的沙盒由 Agent Substrate 提供，具备更严格的隔离性和面向智能体的优化，例如对长时间运行任务的挂起和资源回收，以及网络围栏的精细控制。 上手 AX 需要准备 Go 环境、一个 Kubernetes 集群以及 ko 构建工具。通过 go install 命令安装 ax CLI 后，开发者可以使用 make deploy 将控制平面部署到集群的 ax-system 命名空间，该过程会自动部署 Redis 并构建控制平面镜像。随后，只需编写一个包含 Task、Workspace、Gateway 和 Model 定义的 YAML 文件，执行 ax apply -f 即可启动智能体任务。例如，示例中定义了一个名为 golang 的工作空间，从 GitHub 克隆 Go 源码仓库的指定分支，然后创建一个测试任务，目标是确保 Go 工具链可用并从源码构建。通过 ax watch 可以观察任务阶段变化，ax ssh 则能进入沙盒内部查看工作目录。项目还提供了 demo.sh 脚本，一键展示从应用到暂停、恢复的完整生命周期。目前，AX 仍处于早期开发阶段，官方明确警告核心概念和协议可能发生重大变更，不建议直接用于生产。文档以 README 和示例为主，社区规模尚小，但 GitHub 仓库已获得近万星标，反映出开发者对智能体编排基础设施的强烈兴趣。对于熟悉 Kubernetes 的团队，AX 的声明式体验会非常亲切，其命令行交互也刻意模仿了 kubectl 的风格。 AX 的出现标志着智能体工程化从 ad-hoc 脚本向平台化演进的重要一步。它为开发者社区提供了一套标准化的原语，使得智能体任务可以像容器一样被声明、部署、监控和回收，大大降低了大规模运行智能体的运维复杂度。对于企业工程团队而言，AX 有望成为构建可靠、可审计的智能体流水线的基石，尤其是在代码自动修复、持续集成、多步骤研究等需要成百上千个智能体并行工作的场景中。然而，风险同样存在：项目尚未稳定，API 可能频繁变动，且依赖 Agent Substrate 这一同样在演进中的底层，生态兼容性有待观察。此外，智能体编排的"最佳实践"仍在探索中，AX 的声明式模型是否能覆盖足够多样的智能体模式（如多智能体协作、人机协同）仍需验证。未来，随着 LLM 能力的提升和智能体应用的爆发，像 AX 这样原生支持智能体生命周期的运行时可能会成为云原生生态的新标配，值得持续关注。