Google AX（Agent Executor 编排运行时）
| 分类 | 🏗️ 架构范式 |
| 阅读时间 | ⏱️ 16 分钟 |
| 更新时间 | 📅 2026-10-12 |
| 条目编号 | ENC-ARCH-17-google-ax |
关键要点 ✦
- 2026 年 9 月 20 日以 Apache 2.0 许可在 GitHub 开源（仓库 google/ax，官网 agentexecutor.io），Go 语言编写；定位是智能体集群的控制平面——调度、挂起恢复、审计与出网管制都做进声明式原语，而不是等 agent 集群规模化之后再补
- 提供四个声明式原语：Task 在隔离沙箱中运行智能体代码并支持亚秒级挂起与恢复（空闲不计费）；Workspace 声明 Git 仓库、MCP 服务器与技能包等环境使任务热启动；Gateway 管控监听端口并把出站流量限制在显式主机白名单内；Model 集中管理模型供应商、生成参数与凭据
- v0.3.0 把项目重组为三组件控制面：ax-server 暴露 gRPC API 接收 Task 清单，ax-controller 作为水平扩展的 reconciler 从 Redis Streams 消费任务，ax-task-runner 在沙箱化 worker 中执行；任务状态从 Kubernetes 自定义资源迁至 Redis Streams，官方设计文档给出的理由是避免短生命周期海量任务拖垮 etcd
- 沙箱执行层基于独立的 Agent Substrate 运行时（substrate 仓库，v0.1.0 发布于 2026-09-10）；CLI 刻意对齐 kubectl 语义（ax apply、ax get、ax describe、ax delete），并提供 ax ssh 进入运行中任务、ax watch 流式查看状态、ax suspend 与 ax resume 做状态检查点
- 边界需如实标注：官方明确 v0.3.0 协议仍在剧烈变动；未公布性能数据与横向扩展实测规模，「单集群数十亿任务」目前是项目自述目标而非已验证结果；部署需要 Kubernetes 集群、ko 构建工具、容器镜像仓库与 Agent Substrate Control API 访问权限
- 与托管智能体运行时的差异在于部署形态：AX 面向自建 Kubernetes 集群的开源控制面，凭据放 Kubernetes Secret 支持一处轮换；托管运行时（如厂商 Agents API）则以托管服务形式提供类似能力
智能体为什么需要控制平面
2025 年以来 agent 框架大量涌现，多数回答的是「怎么拼出一个智能体」；但当企业真的把成百上千个智能体跑起来，另一层问题随之出现：任务状态存在哪、空闲怎么计费、出网怎么管制、坏了怎么审计。这些能力过去属于数据库与微服务的基础设施范畴，智能体此前并没有对等物。
据 InfoQ 2026 年 9 月 22 日报道与 google/ax 官方仓库 README，AX 给出的回答是把控制面当成一等公民：它将自主智能体界定为自己的工作负载类别——既非无状态服务，也非批处理作业——并为其配套隔离、状态管理、配额与成本控制。开发者用 YAML 清单描述一个智能体任务，AX 负责沙箱化、接通工作区、围栏网络并保持其运行。
这一思路与 Kubernetes 对容器化应用的意义类似：上层的框架可以随需求更替，而下层的调度、隔离与治理会随基础设施一起沉淀。这也解释了为什么媒体把 AX 视作 Google 在智能体基础设施层的卡位动作。
四个声明式原语：Task、Workspace、Gateway、Model
据 agentexecutor.io 官方文档的 Concepts 页，AX 的整个模型由四个声明式原语承载。Task 是核心执行单元：在隔离沙箱内运行不受信任的智能体代码，附带 CPU 与内存限制，可挂起并恢复以做状态检查点，亚秒级的挂起恢复意味着空闲期不计费。
Workspace 把环境声明一次而不是每个任务重建：Git 仓库、MCP 服务器与技能包都预先接线，任务因此可以热启动。Gateway 定义任务暴露哪些监听端口，并把出站流量限制在显式的主机与端口白名单内——这把「智能体只能访问哪些域名」从口头约定变成了配置项。
Model 是命名的 LLM 配置：供应商、模型标识、生成参数与凭据集中管理，凭据存放在 Kubernetes Secret 中，密钥轮换在一处完成而不必逐个智能体修改。四个原语共同把智能体运维中最容易失控的四个面——执行、环境、网络、凭据——收进声明式管理。
三组件控制面与状态存储迁移
v0.3.0（2026 年 9 月 20 日发布，上一版 v0.2.3 为 8 月 13 日）把项目重组为三个二进制：ax-server 暴露 gRPC API 接收 Task 清单；ax-controller 作为水平扩展的 reconciler 消费工作队列；ax-task-runner 在沙箱化 worker 中实际执行任务。
最值得注意的是状态存储的迁移：任务状态从 Kubernetes 自定义资源挪到了 Redis Streams。官方 DESIGN.md 解释了动机——海量短生命周期任务若写进 etcd，会触碰其容量与写入瓶颈；Redis Streams 作为工作队列与状态层，让系统按官方表述能够承载海量短任务而不拖垮底层存储。
日常操作界面对 Kubernetes 用户几乎零学习成本：ax apply、ax get、ax describe、ax delete 的行为与 kubectl 对应命令一致，ax watch 流式输出任务状态，ax ssh 可以直接进入运行中任务的沙箱执行命令。多集群切换则复用 kubectx。
沙箱、网络围栏与凭据治理
AX 的隔离执行层来自独立的 Agent Substrate 运行时（substrate 仓库，v0.1.0 发布于 2026 年 9 月 10 日）。据官方仓库与媒体报道，沙箱基于 gVisor 类的用户态内核隔离技术，任务代码在受限环境中运行，CPU 与内存配额在 Task 清单中显式声明。
网络维度由 Gateway 承担：出站流量只允许访问白名单内的主机与端口，这在企业场景里直接对应合规与数据外泄防护需求——智能体不再默认拥有整个网络的访问权。凭据维度由 Model 原语收口：所有模型调用的密钥集中在 Kubernetes Secret，一处轮换全局生效。
这三层叠加后，AX 实际上把本站安全风险条目中讨论的沙箱逃逸面收窄了不少：即便智能体代码被注入恶意指令，它能触达的文件系统、网络与凭据都被限制在清单声明范围内。当然，隔离强度取决于底层沙箱实现的真实安全性，部署方仍需自行跟踪相关 CVE 与配置基线。
边界、现状与适用判断
需要如实标注项目的现阶段边界。官方在 v0.3.0 中明确协议仍在剧烈变动，v0.3.0 也做了一次伤筋动骨的重构：移除了旧版 Python harness、ATE 客户端、SQL 事件日志与内置技能示例。这意味着现在基于 AX 二次开发需要承担接口变更风险。
性能方面，官方未公布基准数据，「单集群数十亿任务」是项目自述的容量目标而非第三方验证结果。部署门槛也不低：需要 Kubernetes 集群、ko 构建工具、容器镜像仓库以及 Agent Substrate Control API 的访问权限，CLI 本身倒是单个 go install 即可安装。
适用判断上，AX 适合需要自建智能体基础设施、对出网管制与凭据治理有硬性要求的团队；如果需求是快速获得托管能力而不想运维控制面，厂商托管运行时（参见本站托管智能体运行时词条）是更省力的路线。两条路线的长期竞争——智能体的稀缺资源究竟沉淀在模型侧还是运行时侧——值得持续观察。
🎯 应用场景
✅ 最佳实践
- 以 Task 清单显式声明 CPU、内存与出网白名单，不要依赖默认值；把 Gateway 白名单作为安全评审的一部分
- 模型凭据一律放 Model 原语与 Kubernetes Secret，禁止写入 Task 清单或镜像
- 利用 ax suspend 与 ax resume 做长任务的检查点，空闲期不计费可显著降低长时任务成本
- 跟踪 v0.3.0 之后的协议变更，二次开发尽量收窄对内部接口的依赖面
- 把「单集群数十亿任务」视作目标而非承诺，上线前用自己的真实负载做容量压测
🔮 未来展望
AX 代表了智能体基础设施从框架层下沉到运行时层的行业趋势：模型可以随时更换与路由，而任务状态、空闲计费与出网管制会跟着控制面沉淀。后续值得跟踪的节点包括：ax.io 风格 API 组是否会形成事实标准、Agent Substrate 沙箱层的独立演进、以及协议稳定后社区生态（技能包、清单模板）的生长速度。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。