# 谷歌 AX 要跑十亿任务？先给失控循环装个熔断器

**Summary:** 谷歌 AX 能隔离、暂停和恢复智能体任务，但其预览版未建立累积作业预算或公开十亿任务基准。我建议先用一个可逆工作负载，在外部支出和停止边界后进行试点。

- Canonical: https://markhuang.ai/zh/news/google-ax-billion-task-budget-boundary
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-21
- Section: News
- Tags: 谷歌 AX, AI 智能体, 智能体基础设施, Kubernetes, 成本控制
- Source: [Agent Executor](https://agentexecutor.io/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![大量隔离的智能体任务胶囊环绕着一个被拦截屏障挡住的失控循环任务](https://cdn.markhuang.ai/news/google-ax-billion-task-budget-boundary/hero.webp)

*规模化是这套叙事最抓人的部分。但真正上线时，你操心的永远是那个会死循环、会烧钱、恢复后还会出问题的任务。*

谷歌的 [Agent Executor 网站](https://agentexecutor.io/)现在把 AX 包装成声明式运行时，能沙箱智能体任务、准备工作区、限制网络，还能在单个集群里扩展到数十亿任务。项目想做的事很明确：让长时间跑的智能体不再像脆弱的脚本，而是变成运维能查、能挂、能恢复的工作负载。

方向是对的。谷歌 2026 年 5 月 20 日推出 AX 时，讲的就是智能体作业能跑几小时甚至几天，遇到中断、客户端断连、人工审批就挂掉。但我对规模的宣传始终存疑。我不会先问 AX 能不能协调十亿任务，而是问：一个任务在重复烧钱或做不可逆操作之前，能不能被及时停掉？

把进程关进沙箱，模型账单不会封顶，邮件发出去了也收不回来，付款和部署也一样。AX 能划出有用的边界，但边界上到底会发生什么，还得运维自己来证明。

## 运行时管不到智能体的判断

AX 不是新模型，也不是规划框架。它给运维提供了四种资源：隔离执行的 `Task`、放代码仓库和工具的 `Workspace`、管网络策略的 `Gateway`、配模型提供商的 `Model`。这种分层我很买账——编排的事归编排，不该跟这个月正流行的智能体框架绑死。

[谷歌云发布文章](https://cloud.google.com/blog/products/ai-machine-learning/agent-executor-googles-distributed-agent-runtime)提到了用事件日志和快照做恢复、单写者会话状态、客户端重连、轨迹分支。这些都是智能体不再像一个短 API 请求之后才会暴露的问题，AX 给出了务实的应对。

代码仓库也把部署成本摆在了明面上。快速入门要 Kubernetes、Redis、容器镜像仓库、`ko`，还要能访问 Agent Substrate API。这是给已经有控制平面的团队准备的基础设施。如果我的工作负载只是几个短小、可逆的作业，引入这套东西反而会增加运维负担。

## 十亿任务的说法是目标，而非证据

落地页声称 AX 能在单个集群里跑数十亿任务。但底层执行层 Agent Substrate 给出的数字要具体得多也小得多：README 写的是 500 毫秒以内完成恢复、每秒 500 次以上的暂停或恢复激活，以及一个在八个物理 Pod 上复用约 250 个有状态 actor 的可复现 demo。

这些数字能帮你理解架构，但不能证明所有 AX 工作负载都能跑到标题那个量级。我翻了一遍公开材料，没有任何一份把"十亿任务"跟一个有代表性的基准测试、工作负载组合、故障率或成本区间挂上钩。[AX 代码仓库](https://github.com/google/ax)自己也提醒了：核心概念、协议和规范在稳定版之前都可能变。

早期项目定个高目标没问题，我不会拿它当容量规划。我自己做基准，会用我实际要跑的智能体、模型延迟、工具流量、工作区大小和恢复模式。一个全在空转的大集群，跟一个全在写文件、调付费模型的大集群，完全是两回事。

> **Info:**
>
> 我会从一个受控的工作负载开始，逐步往外扩。第一个验收标准不是峰值任务数，而是运维能不能拒绝一次调用、花光预算、挂起作业、恢复状态，并且不重复执行外部操作。

## 沙箱无法停止计费器

AX 自己的网站就写着"智能体可能在循环里烧钱"。这种坦率很少见，也正好点出了我最在意的那个缺口。[Wavect 9 月 20 日的源码审查](https://wavect.io/blog/google-ax-agent-executor-security-self-hosting/)发现，被审查的 `TaskSpec` 已经不再暴露之前的预算和审批策略字段了。代码里有用量计数器，但计数器只是事后告诉你花了多少，不是事前拦你的准入控制。

所以我会把花钱的上限放在任务外面。每一次模型调用都得经过运维控制的网关——网关知道这个任务属于哪个父作业，按累计额度扣预算，把重试和子任务也算进去，预算花完就直接拒绝。任务手里不该有能绕开这道闸门的凭据。

网络策略也得用同样的眼光看。主机名白名单能挡住大范围的公网访问，但白名单里的工具照样能替智能体干大事。AX 能封住路由，可工具本身还是得有自己的授权、幂等键和审计日志。

这跟我之前看那个[跑了 24 小时小企业的智能体](https://markhuang.ai/news/gpt-5-6-sol-optimized-the-score)得出的结论一样：自主权要拆成权限和预算，让它们各管各、各自兜底。一条笼统的指令，替代不了一道智能体自己改不了的边界。

## 恢复路径得经得起恶意测试

"持久化执行"听着挺靠谱，直到你发现"持久化"这个词背后藏着两种不同的承诺。AX 的运行器文档说 `/workspace` 在暂停和恢复后会保留，但任务本身会回到一个全新的容器里，进程树也是新的。文档还说，控制平面目前不会从容器回读命令的退出状态。

这意味着我的智能体必须自己持久化足够的状态才能正确恢复，而我的监控进程需要一个比"运行器还活着"更强的完成信号。我会在工具请求和响应之间杀掉任务，在它暂停时撤销凭据，在外部写入已经成功后再恢复它。文件恢复只是验收标准的一部分。作业必须知道哪些事已经做过了，并且不再做第二遍。

## 先跑一个无聊的试点，再谈集群

我会用合成数据、一次性的代码仓库、低权限的模型凭据来试点 AX。AX 和 Agent Substrate 的版本我会锁死，因为接口还在变。然后我会逐项测试：硬性成本上限、网络拒绝、凭据撤销、失败命令上报、暂停与恢复、回滚到上一版运行时。

如果 AX 都扛住了，这个项目确实有它的价值。四种资源模型足够简单，把执行和智能体框架拆开，团队换模型时就不用每次都重建运维层。

但规模要按这个顺序去挣。先证明一个智能体能安全地失败。再证明十个智能体能正确共享预算和凭据。第十亿个任务是基础设施问题；第一个失控循环是产品问题——而且它来得快得多。