Google AX：暂停恢复、重启成本与自托管

返回

Kevin Riedl

12 分钟 阅读 · 2026年9月20日
最近审核 2026年10月15日

下一篇

一个智能体已经花了 30 美元，进程却突然消失。已经完成的工作，你还得再付一次钱。这是故障恢复问题。另一种浪费是智能体大部分时间都在等待，却一直占用计算资源。这是空闲容量问题。Google AX 与两者都有关系，但一句宣传语并不能同时解决两者。

AX 也叫 Agent Executor，是 Google 以 Apache 2.0 许可证发布的智能体任务编排器。它运行在 Agent Substrate 之上，使用类似 Kubernetes 的 YAML 和命令。它的价值是把智能体执行作为基础设施来管理，而不是再发明一个推理框架。查看固定版本的 AX 项目介绍与开发状态警告。

核查日期：2026年10月15日。AX 版本为 22954f64bb29，Agent Substrate 版本为 6edd1fccfc9d。本文是源码与架构分析，不是部署实测或吞吐量基准测试。30 美元的例子是假设场景，不是 Wavect 测得的 AX 成绩。

Google AX 现在编排哪些资源？

当前 API 有三种核心资源：Task、Workspace 和 Model。早期介绍中的第四种资源 Gateway，已不在本文核查的 AX 接口定义中。资源描述的是配置，并不自动提供围绕它的所有运行保障。

一个 Task 可以对应整个智能体作业，也可以只对应一次委派操作。通过 spec.workspaces 可以绑定多个工作区；第一个工作区会成为命令的工作目录。AX 当前的资源与生命周期概念。

与九月的 AX 示例相比，有哪些变化？

不要直接部署旧的四资源配置。本次更新替换了早期 Gateway 示例，并修正了执行契约。迁移前，应一起固定 CLI、控制平面和 runner 的版本。

配置应以接口定义为准，而不是照搬 manifests 指南中尚未修改的“四种类型”字样。当前定义也不再包含我们九月文章所解释的旧 Task 策略保留字段。查看当前 AX API 定义。

AX 真的是“智能体版 Kubernetes”吗？

这个比喻便于理解，但 AX 不会替代 Kubernetes。智能体控制框架，也就是 harness，负责推理与工具决策。AX 负责声明任务和管理生命周期。Agent Substrate 提供沙箱执行，Kubernetes 则管理底层 worker 基础设施。

当前 AX server 在分布式锁保护下直接与 Substrate 协调，并将资源状态保存在 Redis。它不会为每个短生命周期任务都创建一个 Kubernetes 自定义资源。设计文档也明确说明 Task 不可变。阅读更新后的 AX 控制平面架构。

因此，“每个集群数十亿工作负载”应理解为项目的设计目标，而不是已验证可以同时运行数十亿个活跃智能体。任务记录、挂起的 actor、运行中的沙箱和模型请求是不同的计量单位。评估容量时，先确定自己到底需要多少并发。

关于推理循环、工具权限与编排基础设施之间的完整分工，请参阅我们的 智能体 harness 工程指南。这里聚焦 AX 的执行与恢复边界。

AX 暂停和恢复时，究竟会保留什么？

当前 AX runner 的文档描述的是工作区文件恢复，而不是对整个进程原封不动地继续执行的承诺。Substrate 为 /workspace 创建快照，恢复时把它交给新的容器。因此文件可以保持不变，但进程树是新的。

runner 作为 PID 1 运行。停止或暂停时，它会把 SIGTERM 转发给命令的进程组，等待宽限期，再结束剩余进程。应用必须在退出前把恢复所需的状态写入持久化位置。不能只把会话留在 Python 变量里，就认为它一定会回来。AX runner 的启动、持久化与关闭契约。

这与 Substrate 自身描述的完整状态快照能力并不相同。底层运行时可以支持保存 RAM，不代表上层 AX runner 的每条恢复路径都自动具有相同语义。应该验证实际版本组合，而不是把两份功能列表拼成一项保证。

有序暂停也不等于突然崩溃。worker 在写检查点前被终止、网络中断，或外部操作成功后响应丢失，都需要单独测试。外部动作还需要幂等键、结果核对和持久化作业记录。恢复容器不能撤销已经发送的邮件。

另一个容易忽略的边界是：命令退出后，runner 仍会继续运行。当前控制平面不会从容器读取命令退出码。Ready 和 WorkspaceReady 不是业务完成证明。应增加明确的完成事件、结果文件或监督器协议。

亚秒级恢复，是否等于零冷启动和零空闲成本？

不是。这是三件需要分别衡量的事。Substrate 项目报告恢复耗时低于 500 ms，每秒可执行超过 500 次暂停/恢复激活。它的演示还展示了约 250 个有状态 actor 在 8 个物理 Pod 之间复用。这些是项目方提供的数据，不是我们测得的 AX 端到端性能。Substrate 的性能表述、演示与当前兼容性说明。

恢复基础设施的时间，不等于应用给出下一个有用结果的时间。后者还可能包含 worker 排队、快照读取、进程启动、会话加载、工具连接和模型响应。测试时应分别记录恢复到可用状态的延迟，以及恢复到首个有用结果的延迟。

挂起的 actor 可以不再独占活跃 CPU 和内存，但集群、worker 池、Redis、控制平面、快照存储、网络和运维不会因此全部免费。模型请求在本地智能体等待时仍可能产生费用。基础设施空闲成本和 Token 成本是两笔不同的账。

还要区分明确的命令与自动策略。AX 文档提供 ax suspend 和 ax resume；自动空闲检测与暂停，连同任务 Token/超时预算和审批策略，仍列在路线图中。存在命令，不代表空闲策略已经启用。确认哪些 AX 能力仍属于路线图项目。

恢复能力究竟能节省多少重启成本？

应该计算中断后重复执行的工作，而不是把整个原始任务都算成损失。有效检查点可以减少重做，但不能退回已经消耗的推理费用。支持暂停也不能单独证明崩溃恢复能力。

假设一个月有 1,000 个作业，其中 10% 各发生一次中断。如果每个受影响作业都重复 30 美元的模型与工具工作，重做成本就是 3,000 美元。如果经过测试的恢复机制把每次重做降到 3 美元，总重做成本就降为 300 美元。这意味着避免了 2,700 美元的重做，并不意味着安装 AX 必然节省这么多钱。

如果新增运行时、快照与运维成本为 600 美元，在其他变化成本之前，这个场景还剩 2,100 美元。这些都是以 USD 计价的假设，不是提供商报价或客户业绩。改进必须在突然故障下得到验证，不能只根据一次正常暂停来推算。

完整的成本方法，包括人工审核和验收通过的结果，请看 智能体每次操作成本指南。使用同一套账目，判断恢复改进是否真正降低了每个合格结果的总成本。

如何不花模型 Token，先测试 AX 文件恢复？

从一个可丢弃的工作区和只等待的无害进程开始。下面的示例使用当前配置字段，不包含模型调用、仓库凭据或基于目标的环境准备，但仍会消耗基础设施资源。将示例与当前 manifests 参考文档对照。

前提是已经安装兼容的 AX/Substrate 组合与 CLI，并有授权的集群访问权限。将以下内容保存为 task.yaml。这里刻意设置 debug: true，用于隔离的诊断任务，因为 SSH 会开放执行命令和访问文件的能力。不要把它当成面向公网或生产环境的默认设置。

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: recovery-lab
spec:
  files:
    - path: README.txt
      content: "Disposable recovery test. No model calls."
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: recovery-lab-001
spec:
  workspaces:
    - name: recovery-lab
      path: /workspace/recovery-lab
  command: ["python3", "-c", "import time; time.sleep(3600)"]
  debug: true

提交配置，等待 Ready 为真。使用 Ctrl+C 停止持续观察。这只会结束 watch，不会停止任务。

ax apply -f task.yaml
ax watch task recovery-lab-001

在启动之后写入标记，再暂停和恢复。任务命令本身不会重新创建这个文件，因此之后读到它，才能检查持久化，而不是误把再次初始化当成恢复成功。

ax ssh recovery-lab-001 -- sh -c 'printf "%s\n" "checkpoint-before-suspend" > /workspace/recovery-lab/recovery-marker.txt'
ax suspend task recovery-lab-001
ax resume task recovery-lab-001
ax watch task recovery-lab-001

再次等待 Ready，用 Ctrl+C 停止观察，然后读取标记：

ax ssh recovery-lab-001 -- cat /workspace/recovery-lab/recovery-marker.txt

预期输出为 checkpoint-before-suspend。通过这项检查，只能说明这个文件在一次有序暂停与恢复中保留下来。它不能证明 RAM 恢复、突然崩溃后的持久性，或外部动作的安全重试。我们没有在此环境运行这项集群测试。

保存所需证据后，只删除上面创建的可丢弃资源。以下命令会删除测试任务及其工作区定义：

ax delete task recovery-lab-001
ax delete workspace recovery-lab

AX Gateway 移除后，网络访问由哪里控制？

不要继续套用旧版 AX Gateway 示例。本文核查的 Task 接口中没有 gateway 绑定。应在实际执行或网络层设计出站限制，并验证这些限制确实作用于任务对应的 actor。

Substrate 当前出站文档描述了按策略控制的 HTTP(S)、DNS 限制，以及对 WebSocket、正向代理 CONNECT 和其他 TCP 流量的阻断。这是需要与已安装版本核对的协议契约，不是 AX YAML 的捷径。如果某个 SDK 或 MCP 传输依赖运行时不允许的连接方式，就会影响兼容性。查看 Substrate 出站流量规则。

测试允许的模型和工具端点、拒绝的目的地、重定向、直接访问提供商，以及凭据撤销。即使服务器域名被允许，仍要保留请求级授权：一个允许访问的 hostname 不代表有权读取其所有租户或文档。这些是建议的检查，不是我们复现的漏洞。更完整的边界请看 智能体沙箱安全检查清单。

AX 会自动拦住失控的 Token 账单吗？

本文核查的 Task 接口没有声明整个作业的累计金额或 Token 上限。UsageStats 和 PendingApproval 的存在不能证明预算已被强制执行。CPU 限制也无法限制远程模型账单。

应使用独立控制的模型请求准入层。把环境准备、子任务与重试归入同一个持久化作业 ID。并发调用获准前先预留预算，完成后核对实际用量，达到上限时拒绝新调用。已经获准的请求仍可能产生费用，因此应规定可测量的在途超额边界，而不是承诺瞬间停止且绝不超支。

能够撤销凭据或阻止新请求的控制组件，应位于智能体可写工作区之外。提示词中写一句“请遵守预算”，不是费用控制机制。

不使用 Google Cloud，也能自托管 AX 吗？

存在非 GCP 的开发路径，但生产可移植性需要另行验证。Substrate 提供本地 kind 与 GKE 快速入门。AX 需要可访问的 Substrate 控制 API、自身控制平面与 Redis，以及合适的 runner 镜像。在本地运行基础设施，仍然可以调用远程推理。

Substrate 当前 README 说明它尚未达到 1.0，不保证向后兼容。AX 也警告可能出现重大不兼容变化，其路线图仍包括对 Substrate actor API 的迁移。应选择一起测试过的版本，而不是假设两个仓库各自的最新版必然兼容。

每个任务都必须使用 Antigravity 吗？

不是。文档中的默认 runner 会在工作区绑定含有 goal 时调用 Antigravity。该路径需要 GEMINI_API_KEY，默认准备超时为十分钟，可用 AX_BOOTSTRAP_TIMEOUT 修改。没有 goal、环境已准备好的任务可以避开这条特定路径。同一文档把元数据监听放在回环地址，并要求命令读取 AX_METADATA_URL。查看当前沙箱启动与元数据契约。

Pi 或其他自定义智能体框架呢？

应将其视为需要验证的集成，而不是本文已经确认开箱即用的 AX 适配器。自定义镜像必须提供 /usr/local/bin/ax-task-runner，读取 AX_TASK_YAML 和 AX_WORKSPACES_YAML，准备持久化工作区、报告可用状态并监督关闭流程。还要单独验证 harness 的会话保存位置和恢复行为。

拥有代码仓库，只是掌控 AI 的一部分。你还应能检查执行过程、导出状态、选择推理提供商、撤销权限，并迁出当前部署。仅仅知道它运行在哪朵云上，并不能回答这些问题。

AX 试点上线前，必须证明什么？

先使用合成任务和可丢弃系统。以下是我们建议的验收门槛，不是 AX 已在我们环境中通过的测试。

每次测试都记录 AX/Substrate 版本、runner 镜像摘要、模型路由、策略配置与结果。只有空闲容量和恢复收益经过测量，足以抵消平台运维工作时，才值得采用 AX。对于任务短、成本低的小型智能体集群，额外基础设施可能还不是当前最需要的投入。

Wavect 的 AI 工程服务覆盖集成与生产加固。Twinsoft AI 案例展示的是独立的交付经验，不是 AX 参考部署。你可以用 上线前 QA 清单组织验收证据，或 与我们讨论智能体重启成本和运行时需求。