Google 开源 AX：Agent 工作负载的 Kubernetes 控制平面

Agent 工作负载的形状与微服务或批处理任务都不一样：短生命周期、突发、大量时间处于「等模型或等人」的空闲状态，而且经常要跑不被信任的代码。Kubernetes 原生的 Deployment / Job 抽象是为无状态服务或可预测批处理设计的，套用到 Agent 上会浪费大量资源在等待态。site:AIDEepT＋hink.cn

AX 的命名来自 Agent Executor，AX 并非传统的编排框架（如 LangGraph），也不是特定的模型控制器，而是一个专注于‌持久化执行（Durable Execution）‌和‌资源隔离‌的基础设施层，允许开发者在自有 Kubernetes 集群上以 YAML 配置的方式部署和管理亿级规模的 Agent 任务。Google Cloud 曾于 2026 年 5 月 20 日公布过相关的 Agent Executor 运行时。site:AIDEepT＋hink.cn

AX 把 Agent 的隔离、网络边界、凭据与生命周期从「每个团队各写一套」变成声明式的基础设施约束。尤其在跑不信任代码（模型生成的、或客户提交的）时，出向允许列表和沙箱是硬性需求。site:AIDEepT＋hink.cn

相比「VM + bash + 手写 iptables」，AX 把隔离、出向策略、凭据注入和挂起/恢复变成了一等公民。相比直接用 Kubernetes Job，它解决了等待态资源浪费与 etcd 压力问题。

一、关键参数

二、产品定位：填补“有状态 Agent”的基础设施空白

传统云原生架构（如 Kubernetes Jobs 或 Serverless Functions）专为无状态的请求-响应模式设计，而 AI Agent 具有截然不同的行为特征：

• 长生命周期与间歇性计算‌：Agent 可能在等待人类审批、外部 API 响应或模型推理时长时间空闲，但在执行工具调用时又需要突发高算力。
• 状态保持需求‌：Agent 需要维护对话历史、中间思考过程、文件上下文以及子任务状态。
• 脆弱性‌：在传统容器中，Pod 驱逐或节点故障会导致整个 Agent 会话丢失，无法从断点恢复。

AX 通过抽象出四个核心原语，将 Agent 转化为‌可挂起、可恢复的执行单元（Suspendable Actors）‌，而非易碎的 Python 进程：

• Task：隔离的沙箱执行单元，含镜像、命令、资源上限与 workspace 引用；可是一个完整任务，也可以是一棵子任务树中的节点。
• Workspace：预置 Git 仓库、MCP 服务器与技能包；支持「生成式 workspace」——用一句自然语言描述目标，让 Agent 首次启动时自行搭建环境（官方示例：Set up a Python 3 development environment）。
• Gateway：网络策略，显式定义出向 host/port 允许列表，并向请求注入凭据。
• Model：集中配置模型、参数与密钥，一次 apply 即可在整个集群生效。

三、技术特性

1. 持久化执行与状态恢复

AX 最核心的突破在于解决了“Pod 驱逐即丢失”的问题。当底层容器被驱逐或节点故障时，AX 会自动序列化 Agent 的内存状态、文件系统和执行指针。一旦资源重新可用，Agent 可从确切的断点恢复执行，无需重新开始。这对于耗时数小时甚至数天的复杂编码重构、多步科研推理任务至关重要。

2. 框架与模型无关性

AX 不绑定特定的 AI 框架或模型：

• 框架agnostic‌：它不是 LangGraph 的替代品，而是其底层运行环境。AX 可与 LangChain、Google ADK (Agent Development Kit) 或其他自定义框架集成。
• 模型agnostic‌：支持接入任何大语言模型（LLM），包括 Gemini、Claude、Llama 等，用户可自由切换或混合使用。
• Harness 抽象‌：AX 提供服务于 Agent “Harness”（具体实现逻辑，如编码 Agent Antigravity）的层。未来将支持 BYOH (Bring Your Own Harness)，允许用户插入自定义的 Agent 逻辑。

3. 声明式 Kubernetes 原生体验

AX 采用 YAML 配置方式，完美融入现有的 K8s 运维体系。开发者无需编写复杂的 Orchestrator 代码，只需定义 Task 规格、资源限制和恢复策略，AX 控制平面即可自动处理调度、扩缩容和故障转移。这使得具备 K8s 经验的团队能够快速上手，利用现有基础设施监控和日志工具管理 Agent 集群。

4. 安全隔离与审批流

针对 Agent 可能产生的高风险操作（如删除文件、调用生产 API），AX 内置了 Gateway 机制：

• 工具调用审批‌：支持在子 Agent 执行敏感操作前暂停，等待人类或策略引擎批准。site:AIDEepT＋hink.cn
• 网络隔离‌：限制 Agent 仅能访问白名单内的外部服务，防止数据泄露或恶意调用。

架构要点：设计文档明确说明，AX 避免把大量短生命周期任务放进 Kubernetes CRD（会压垮 etcd），改用 Redis 做状态、Redis Streams 做通信；控制器通过 Agent Substrate 供给执行空间与 actor；task runner 负责具化 workspace 并启动命令。状态保存在单写者事件日志中，崩溃不丢运行。

四、与传统方案的对比

五、产品横向对比

六、定价与使用

开源自托管，无授权费用。但部署成本不低：需要 Kubernetes 集群、ko、集群可拉取的容器镜像仓库、可达的 Substrate 控制 API。已读的部署 manifest 使用 gcr.io 镜像、gcloud 凭据与 Vertex AI IAM 角色，文档化路径是 Google Cloud 形状的——「可以在任何地方运行」与「在任何地方都有文档」是两个不同的声明。site:AIDEepT＋hink.cn

七、落地场景与路线图

1. 典型应用场景

• 大规模代码重构‌：Agent 持续数小时分析多个仓库，期间可能因资源紧张被驱逐，AX 确保其恢复后继续未完成的重构步骤。site:AIDEepT＋hink.cn
• 自主科研助手‌：执行长达数天的实验循环（提出假设->编写代码->运行实验->分析结果），中间需等待人类确认关键决策。
• 企业级客服代理‌：处理复杂多轮对话，需在等待用户回复时释放算力，并在用户回应后快速恢复上下文。

2. 后续发展路线

根据 GitHub 官方 roadmap，AX 即将推出以下功能：

• Antigravity 集成‌：将 Google 内部的编码 Agent Antigravity 作为内置 Harness 提供。
• 子 Agent 挂起/恢复‌：支持层级化 Agent 结构中子任务的独立状态管理。
• 细粒度审批协议‌：增强工具调用的安全审批流程，支持更复杂的策略引擎集成。
• BYOH 支持‌：允许社区贡献和接入更多第三方 Agent 实现。

• 风险提示：v1alpha1 + 依赖一个「非官方支持」的底层项目，意味着 API 可能变、Substrate 可能断更。评估它应当像评估基础设施，而不是因为「数十亿任务」这个未被独立测量的口号而采用。

八、总结

Google AX 的开源标志着 AI Agent 基础设施从“应用层编排”向“系统级持久化执行”的演进。它并不取代 LangGraph 等开发框架，而是为其提供坚实、可扩展且容错的运行底座。对于希望在生产环境中部署大规模、长周期、高可靠 AI Agent 的企业而言，AX 提供了目前最成熟的 Kubernetes 原生解决方案，有效解决了状态丢失、资源浪费和运维复杂三大难题。 site:AIDEepT＋hink.cn

附录：配置脚本

配置形态就是 Kubernetes manifest：site:AIDEepT＋hink.cn

apiVersion: ax.google.com/v1
kind: Workspace
metadata:
  name: go-toolchain-workspace
spec:
  repos:
    - url: https://github.com/golang/go
  goal: >
    Ensure that Go tool chain is available and is built from source.
---
apiVersion: ax.google.com/v1
kind: Task
metadata:
  name: go-toolchain-task
spec:
  workspaceRef: go-toolchain-workspace
  resources:
    cpu: "2"
    memory: "4Gi"