Google AX Agent Executor：预算、沙箱与自托管

沙箱可以限制智能体，却不一定能限制账单。 这是采用 Google AX，也就是 Agent Executor 之前，最值得厘清的区别。给智能体准备工作区、限制网络访问很有价值；证明它不会超支、重复执行危险操作，或把状态留在无法迁移的环境里，则是另一项工程任务。

AX 是 Google GitHub 组织下采用 Apache 2.0 许可证的开源编排项目。当前接口包含四种资源：Task、Workspace、Gateway 和 Model。仓库明确提醒，在稳定版本发布前，核心概念、协议和规范可能发生重大不兼容变更。查看 AX 仓库及开发状态说明。

本文于 2026 年 9 月 20 日核查资料，AX 基线为提交 d8ed0fe38bce。这是一份源码与架构评审，不是部署测试，也不是吞吐量基准。我们聚焦的问题是：要让 AX 智能体真正处于自己的运维控制之下，究竟需要验证什么？

AX 的四种声明式资源究竟控制什么？

AX 将执行环境与智能体的推理逻辑分开。一个 Task 可以运行完整智能体、委派出去的子任务，或其他可执行程序。Workspace 描述起始环境，Gateway 声明网络访问，Model 资源集中管理模型提供方的配置。

以上职责来自 AX 核心概念文档。尤其要注意，Model 是一份有名称的配置，不是新发布的大语言模型。AX 自身的组件可以读取它，但 Task 中运行的任意程序仍需要兼容的集成方式。

AX 是智能体框架、沙箱，还是 Kubernetes 的替代品？

AX 是 Agent Substrate 上方的编排层，不会取代智能体的决策循环。 API 和控制器管理资源，Agent Substrate 提供底层执行生命周期。Kubernetes 仍然是基础设施的一部分。

类似 Kubernetes 的 YAML 容易造成误解：AX 的架构把资源状态存入 Redis，通过 Redis Streams 分发协调任务，而不是把每个短生命周期任务都存为 Kubernetes 自定义资源。控制器可通过增加副本进行横向扩展。查看控制平面架构。

这是面向大量任务的一种架构设计，不等于证明你的集群能够同时运行数十亿个智能体。容量仍受任务类型、Worker 资源、存储、模型延迟和运维限制影响。在代表性负载下测出自己的边界之前，应把项目的规模描述视为设计目标，而非已验证的部署承诺。

我们的 Agent Harness 工程指南讨论模型周围的决策循环、工具处理与反馈机制。本文则专门分析 AX 的执行边界和控制权。

如何限制 Google AX 的出站网络访问？

为 Task 绑定只允许明确目标的 Gateway，再验证实际网络限制。 文档中的示例包含端口 443 上的 host: "*"。这代表广泛的 HTTPS 访问权限，不是仅允许自有模型和 Git 服务器的生产白名单。核对当前 Manifest 示例。

下面的 Gateway 仅用于说明配置，不是完整部署。请将示例主机名替换为由运营方控制、且沙箱能够解析和访问的端点。相关基础设施需要单独配置。

apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
  name: research-egress
spec:
  egress:
    allowlist:
      hosts:
        - host: llm-gateway.internal.example
          port: 443

将以下引用合并到现有 Task 的 spec 中。控制平面里一份没有被使用的 Gateway 资源，并不会限制该 Task。

gateway:
  name: research-egress
debug: false

我们的部署建议是：检查 GatewayReady，实际测试被禁止的目标，并在不需要受控调试时保持 debug: false。测试重定向、直接访问模型提供方、内部元数据端点及其他网络路径。这些是验收要求，不是我们已在 AX 中复现的漏洞。

被允许的主机名仍然代表较大的信任范围。工具服务器可能服务多个租户，也可能自己向外发送请求。因此，服务器仍需对每次请求做授权，并检查后续访问的目标。更完整的隔离评审可参考现有的 智能体沙箱安全检查清单。

Google AX 会自动阻止失控的 Token 支出吗？

不要假定当前 Task API 能强制执行累计 Token 或金额上限。 在本次核查的协议中，TaskSpec 的第 9 个字段已被保留；它此前名为 policies，用于预算和审批配置，注释明确说明目前已经移除。UsageStats 中仍有 Token 计数器，也仍有 PendingApproval 状态类型，但存在类型与计数器并不能证明存在有效的拦截流程。查看固定提交版本的 AX API 定义。

CPU 和内存上限约束的是本地计算资源。一个几乎不占 CPU 的循环，依然可能连续发送收费的模型请求。同样，单次回答的最大输出限制并不约束重试、并行子任务和重复调用的总费用。也不能因为存在与审批有关的状态字段，就认定业务审批已经成为不可绕过的关卡。

Google Cloud 同样区分“仅告警”预算与支出控制：alerts-only 预算不会自动停止使用或计费。文档另外提到针对受支持服务提供的预览版支出上限预算。但这两件事都不能证明，智能体调用的所有外部模型已经受到统一的任务级费用限制。阅读 Cloud Billing 对预算类型的区分。

把预算控制放在智能体无法修改的位置

我们建议使用由运营方控制的模型代理，并为主任务及其所有后代任务维护共享预算账本。每次放行请求前，原子地预留可确定上界的最大费用；请求完成后按实际用量结算，把重试和并行调用都计入，在余额不足时拒绝新请求。控制凭据和预算账本必须位于智能体不可写的环境之外。

同时设置总运行时限、重试次数、步骤数、并行子任务数量上限，并识别反复重复的动作。达到阈值后，停止放行新模型调用，再触发取消或挂起。已经获准的请求仍可能产生费用，因此应定义并测试最大超额，而不是承诺瞬间停止一切计费。工作区准备阶段使用的智能体也要计入预算，不能只计算最后的任务命令。

如需分析整体经济性，而不只是 AX 的控制机制，可阅读 AI 智能体每次行动的成本。

AX 挂起和恢复后，哪些状态会保留下来？

本次评审的 AX Runner 契约描述的是：恢复工作区，但创建新的进程树。 文档将 /workspace 定义为持久目录，并说明恢复时会把它还原到新容器中。不要据此假定内存中的 Python 对象、网络连接或尚未落盘的数据都能原样继续。阅读 Runner 生命周期与替换契约。

这一结论针对 AX 文档所描述的 Runner 集成方式，并不是对所有 Agent Substrate 后端最大快照能力的判断。验收应针对应用真正依赖的那一层，而不是借用另一层的能力宣传。

把对话或会话检查点、已完成操作的标识，以及重启所需的信息存放在持久路径中，并通过智能体支持的会话机制继续执行。文件系统快照无法撤回已经发出的邮件，也无法撤销已经提交的支付请求。外部写操作需要幂等键，以及持久保存的完成记录。

沙箱已经就绪，不代表业务任务已经完成

同一 Runner 契约还说明，任务命令退出后 Runner 仍会存活，控制平面目前不会回读该命令的退出状态。因此，应监控明确的完成事件或结果产物，而不只是 Running、Ready，或仍然响应的健康检查端点。成功退出和失败退出都需要测试。

Google AX 可以脱离 GCP 自托管吗？

现有部署路径并非只支持 GCP，但可迁移不代表开箱即用。 AX 快速入门需要 Kubernetes、容器镜像仓库、Redis，以及可访问的 Agent Substrate Control API。Agent Substrate 同时提供基于 kind 的本地开发路径，以及使用 Google Cloud 资源的 GKE 路径。项目也提醒它仍处于早期开发阶段、不适合生产使用，并且不是 Google 官方支持的产品。对照 Agent Substrate 的本地与 GKE 安装说明。

本地 Substrate 快速入门证明，底层运行时存在不依赖 GCP 的开发路径；它并不证明 AX、你的存储后端和安全配置已经一起通过完整的私有部署测试。本地执行智能体，也不意味着远程模型推理变成了本地推理。

这就是我们对“拥有自己的 AI”的运维定义。云端部署也可以保留实质控制权；自托管仍可能依赖外部模型、镜像仓库或凭据服务。应当有意识地选择这些取舍，而不是用服务器所在位置代替威胁建模。

AX 到底在哪些地方依赖 Antigravity？

需要重点检查的是基于目标的工作区准备。AX 默认 Runner 会把 Workspace 目标交给 Antigravity 智能体，这一步需要 GEMINI_API_KEY。文档给出的默认准备超时为十分钟，可通过 AX_BOOTSTRAP_TIMEOUT 调整。这个超时不是整个任务生命周期的预算上限。查看沙箱启动流程文档。

这比笼统地说“整个项目用 Antigravity 写成”更有实际价值。运行时文档证明的是准备阶段如何使用 Antigravity，而不是仓库中每个文件的编写过程。

为了获得更可控的环境，可以评估预构建镜像并省略目标驱动的引导步骤，或实现兼容的自定义 Runner。AX 要求可执行文件位于 /usr/local/bin/ax-task-runner；仅指定一个普通智能体镜像并不足够。替换前，应按 Runner 契约验证就绪端点、信号转发和持久状态处理。

Pi 编程智能体能使用 AX 的执行模型吗？

Pi 文档列出了交互、print/JSON、RPC 和 SDK 模式。这些接口可以作为集成入口，但不能证明已有开箱即用的 AX 适配器。查看 Pi 编程 Harness 文档。

一个合理的实验方案是：把 Pi 封装在 AX 兼容 Runner 后，通过 spec.command 启动，让模型请求经过外部预算控制，并将可恢复的会话状态保存在 /workspace。这是建议验证的集成设计，不是我们已部署的配置，也不是本文已确认受支持的官方集成。

你也可以不采用 AX，只借鉴职责分离：声明工作区，隔离执行，在进程外限制网络，将模型凭据和预算规则保留在运营方手中。价值在于可执行的控制边界，而不是复制一套云平台实现。

AX 试点在获得真实凭据之前，应该证明什么？

从可丢弃的仓库、合成数据，以及最低权限的模型凭据开始。下表是我们建议的验收标准，不是对当前项目已经通过这些测试的声明。

记录 AX 与 Substrate 的版本、Runner 镜像摘要、实际模型路径、Gateway 策略和观察结果。在 API 持续变化期间保留回退方案。一个规模不大但通过验收的实验，比没有证据支撑的大规模部署承诺更有用。

Wavect 的 AI 工程服务涵盖实现与生产加固。Twinsoft AI 案例代表独立的实施经验，不是 AX 参考部署。使用我们的 上线前 QA 检查清单把试点转化为验收证据，或与我们讨论智能体运行时及控制权要求。