Google开源声明式运行时ax 借K8s架构遏制Agent失控烧钱

AI技术投降派

大规模自主Agent的编排痛点无法靠更聪明的主管模型化解，必须依赖声明式API与控制器调谐机制重塑基础设施底座。

AI-assisted summary of agent烧钱没人管？Google给AI造了个K8s — original source. Check the original for full context.

Source published: 2026-10-25

Key ideas

• Google 开源自主 Agent 声明式编排运行时 google/ax，开源一周获 13,000 颗 Star，被社区称为“Agent 界的 Kubernetes”。 (0:00)
• ax 提出 Task、Workspace、Model 三大核心原语，支持用自然语言 goal 调度环境 Agent 自动配齐运行依赖，实现“给 Agent 铺桌子的是另一个 Agent”。 (0:00)
• 系统底层基于 Agent Substrate 与 gVisor 实现强沙箱隔离与网络围栏，并提供 suspend 检查点挂起与 resume 零冷启动恢复等运维能力。 (0:00)
• 项目当前处于 v0.3 重度开发期，依赖现成 K8s、Redis 与 Agent Substrate，是面向企业平台团队的重型基建，“支撑数十亿 Agent”仍为理论设计目标。 (5:00)

Detailed notes

## Background 该内容由 Bilibili UP 主“AI技术投降派”于 2026 年 10 月 25 日发布。视频聚焦 Google 新开源的自主 Agent 编排运行时项目 google/ax，深入解析其如何将 Kubernetes 的声明式设计理念整体迁移到 AI 基础设施层，以解决自主 Agent 无序循环烧钱、缺乏强隔离与状态累积等工程难题。

## TL;DR 视频深度剖析了被誉为“Agent 界 Kubernetes”的 Google 开源项目 ax。该运行时针对自主 Agent 既非无状态微服务又非批处理作业的特殊负载，抽象出 Task、Workspace 与 Model 三大核心声明式原语，并借助 gVisor 与单写者事件日志提供沙箱隔离、挂起断点接续及类似 kubectl 的运维体验。博主在肯定其继承云计算成熟方法论的同时泼下冷水，指出其依赖重型基建、处于频繁变更的早期阶段且百亿并发尚属设计愿景，最终断言声明式调谐而非“更聪明的主管 Agent”才是规训大规模并发智能体的大势所趋。

## Atmosphere & style 全片充斥着资深平台工程师的辛辣与从容，语调沉稳克制、见地敏锐。博主用“安静地把钱烧完”等极具画面感的黑幽默直击工程痛点，在剥离 GitHub Trending 爆火虚火的同时，将云计算底层哲学的优雅与早期开源项目的不成熟剖析得淋漓尽致。观感就像在机房夜聊中听一位架构老手拆解行业热点，既有被精妙抽象击中的通透快感，又有冷峻严谨的现实清醒。

## Bulletin - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Google 开源自主 Agent 声明式编排运行时 google/ax，开源一周获 13,000 颗 Star，被社区称为“Agent 界的 Kubernetes”。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) ax 提出 Task、Workspace、Model 三大核心原语，支持用自然语言 goal 调度环境 Agent 自动配齐运行依赖，实现“给 Agent 铺桌子的是另一个 Agent”。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) 系统底层基于 Agent Substrate 与 gVisor 实现强沙箱隔离与网络围栏，并提供 suspend 检查点挂起与 resume 零冷启动恢复等运维能力。 - [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) 项目当前处于 v0.3 重度开发期，依赖现成 K8s、Redis 与 Agent Substrate，是面向企业平台团队的重型基建，“支撑数十亿 Agent”仍为理论设计目标。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) 自主 Agent 具有自发规划、扇出子任务、累积内部状态及容易陷入循环无限消耗 API 额度的特征，云基础设施层此前一直缺乏对应的工作负载运行时承载。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Google 开源的 google/ax 定位为高吞吐、声明式的 Agent 编排运行时，由 Go 社区知名工程师 rakyll 操刀并在内部打磨半年，吉祥物为美西螈。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) ax 的设计将编排下沉到基础设施层，CLI 与操作习惯全面对齐 kubectl，用户编写 YAML 声明后即可通过 reconciler 自动调谐现实与期望状态。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Task 原语被设计为极轻量廉价的最小隔离执行单元，刻意不预先建模 Agent 拓扑，放手让 Agent 运行时根据推理解析自行分叉与扇出任务树。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Workspace 原语解耦冷启动准备，其 goal 字段支持自然语言描述，在首次启动时自动拉起环境 Agent 装配运行依赖与技能包。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Model 原语将大模型端点、API 密钥与超参数抽象为集群全局资源，换 Key 或版本更新无需侵入修改具体业务代码。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) 运维控制支持 ax suspend 生成 checkpoint 挂起以控制成本，ax resume 实现断点接续，并可借助 ax ssh 与 ax watch 深入沙箱进行调试观测。 - [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) v0.3 架构由 API 前端、调谐器与沙箱 Task Runner 组成，以 single-writer 事件日志为底座，借助 gVisor 与网络围栏防范不可信代码逃逸。 - [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) Google 解决 Agent 治理问题的策略并非凭空造词，而是将云计算十年验证成功的声明式 API、控制器调谐与最小原语组合方法论直接复用。 - [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) ax 并非个人开箱即用工具，其依赖 Kubernetes、Agent Substrate 和镜像仓库等全套重基建，且 v0.3 阶段仍存在频繁的破坏性接口变更风险。 - [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) 多 Agent 办公室或主管 Agent 属于“造更聪明的老板”的命令式管理，而 ax 的声明式调谐在应对规模化并发 Agent 时具有更高的工程稳定性。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=0s) Google 开源声明式 Agent 编排运行时 ax：给 AI 造的 Kubernetes

当企业尝试把一个自主 AI Agent 放到真实集群里运行时，往往会直面一系列失控的工程灾难：它会自行规划、委派、重试，一个任务不够就直接扇出（fan-out）一堆子任务；它在运行中不断累积内部状态，要求强隔离环境，同时疯狂调用外部大模型接口与工具服务器。而最切中痛点的一条是：“如果没有人看着，它会在一个循环里安静地把钱烧完。”这种工作负载既不同于无状态微服务，又无法套用跑完即走的批处理作业，现有的云基础设施层一直缺少对应的承载形态。9 月下旬，Google 正式开源项目 `google/ax`，其核心定位非常纯粹——“高吞吐、声明式的 Agent 编排运行时”，终极目标是单集群跑数十亿个自主 Agent 工作负载。开源一周内项目收获 13,000 颗 Star，登上 GitHub Trending 榜首，社区也直接送其外号为“Agent 界的 Kubernetes”。该项目由 Go 语言社区知名工程师 rakyll 操刀，于 3 月立项并在 Google 内部打磨半年，吉祥物则选定为一只美西螈（Axolotl）。

```mermaid flowchart TD accTitle: ax 架构与工作流示意图 accDescr: 展示用户通过 ax CLI 声明资源，交由 API 前端、调谐器和沙箱 Task Runner 进行调度的链路流程

subgraph User["用户接口层"] YML["YAML 声明文件\n(Task / Workspace / Model)"] CLI["ax CLI\n(ax apply / watch / suspend / resume / ssh)"] end

subgraph ControlPlane["控制平面 (Control Plane)"] API["API 前端"] Log["Single-Writer 事件日志"] Rec["调谐器 (Reconciler)"] end

subgraph DataPlane["执行平面 (Data Plane)"] Runner["Task Runner (沙箱执行器)"] Substrate["Agent Substrate\n(gVisor 隔离 + 网络围栏)"] EnvAgent["环境准备 Agent\n(根据 goal 铺设环境)"] TaskExec["目标 Agent 任务实例"] end

YML --> CLI CLI --> API API --> Log Log --> Rec Rec -->|"状态调谐与调度"| Runner Runner --> Substrate Substrate --> EnvAgent EnvAgent -->|"完成依赖装配"| TaskExec ```

目前的 Agent 框架大多专注于单个 Agent 的思考逻辑与工具调用，编排和环境搭建基本靠各个框架各自重复造轮子，隔离全靠自行折腾，跑多少实例更是“全凭运气”。ax 的核心思想是将这层编排全面下沉到基础设施运行时。使用者只需编写一个 YAML 文件声明 Task、Workspace 和 Model 三类资源，接着执行 `ax apply`，ax 就会负责把任务调度到沙箱里、挂接工作区并注入模型凭证。所有运维命令完全对齐 `kubectl` 的使用习惯（`apply`、`get`、`describe`、`watch`、`delete`），甚至作用域也沿袭 namespace 命名为 `atespace`。

- **三原语设计之 Task（最小隔离执行单元）**：ax 刻意不对 Agent 的形状进行预先建模，因为 Agent 的执行路径无法预测，它随时可能根据推理解析自行分叉重试或扇出子任务。因此 Task 被设计得极其轻量与廉价，“便宜到可以随便创建，随便隔离，随便挂起，随便扔掉”。一颗任务树长出多少节点完全由 Agent 自己组合，每个节点统一分配相同规格的沙箱、生命周期与工具集。 - **三原语设计之 Workspace（解耦冷启动）**：将拉取 Git 代码库、挂载数据、注入 MCP 服务器与工具技能包等高频准备工作抽离为声明式资源，一次配置到处绑定。其中最为精妙的是引入了 `goal` 字段——开发者可写一句自然语言指令（例如“确保 Go 工具链可用并且从源码构建”），在首次启动时，运行时会直接唤起另一个专门的环境 Agent 将依赖配齐，演变出“给 Agent 铺桌子的，是另一个 Agent”的自动化流程。 - **三原语设计之 Model（集群级模型资源抽象）**：将模型端点、API 密钥、超参数与版本号提升为集群原生资源。团队更换 Key、更新模型版本只需单次 `ax apply` 全局生效，无需逐一修改业务层代码或任务清单。 - **运维控制与底座架构**：针对累积状态的 Agent 工作负载，ax 提供了针对性的控制指令：空闲或待命时执行 `ax suspend` 生成检查点（checkpoint）后挂起，需要唤起时调用 `ax resume` 实现零冷启动的断点接续；需要调试时执行 `ax ssh` 直接登录开启了 Debug 模式的沙箱内部探查，配合 `ax watch` 流式追踪状态变迁。v0.3 架构分为 API 前端、调谐器（Reconciler）与沙箱化任务执行器（Task Runner）三部分，底层通过单写者（single-writer）事件日志做事件溯源，沙箱层基于 Google 开源的 Agent Substrate 结合 gVisor 实现强隔离与网络围栏，防止不可信代码逃逸。

---

[05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) 对 ax 的三个核心判断与工程冷水

面对 ax 掀起的声浪，视频从工程实践与方法论演进的角度给出了三个关键判断，并在热潮中浇下了理性的冷水：

第一个判断是“问题是真的，姿势是老的”。Agent 具备高额消耗（烧钱）、需要强安全隔离、内部存在累积状态三大特性，导致它既非无状态的微服务，也非纯粹的离线批处理，云基础设施层此前确实缺少这样一个专有组件。而 Google 的应对思路并未另起炉灶发明陌生概念，而是将云计算行业十年间沉淀出的最成熟、最稳固的方法论搬了过来：“Google 的答案不是发明新东西，是把云计算十年攒下的最成功的方法论，声明式 API、控制器调谐、最小原语加组合，整体搬迁。这个选择本身就是品味。K8s 用十年学会了管进程，ax 想直接继承这份遗产。”

第二个判断则是给开发者泼的一盆工程冷水。虽然架构愿景宏大，但项目仍处于极早期阶段： - **开发状态与兼容性风险**：README 明确标注项目处于“重度开发期（Heavy Development）”，在首个稳定版本发布前会频繁引入破坏性变更（Breaking Changes），当前版本仅为 v0.3。 - **严苛的部署门槛**：普通独立开发者或个人玩家无法即开即用，其底座依赖于现成的 Kubernetes 集群、Google Agent Substrate、Redis 集群以及容器镜像仓库，本质上是交付给专业平台工程（Platform Engineering）团队使用的重型基建。 - **口号与实测差距**：官方提及的“单集群支撑数十亿自主 Agent 任务”目前仅是理论层面的顶层设计目标，而非生产级压测下的实测战绩；此外社区内部对“Agent 界的 K8s”这一赞誉也存在分歧，部分声音认为 ax 仅管到了资源调度与安全隔离层，本身不参与认知与智能决策，尚未建立起类似 K8s 的事实行业标准生态位。

第三个判断指出了 Agent 编排范式的未来演进方向。此前行业流行的多 Agent 办公室、主管 Agent（Supervisor Agent）方案普遍落入命令式管理的巢穴，其底层逻辑是“造一个更聪明的老板去管一群员工”；ax 所代表的则是声明式管理路径，使用者只需描述最终期望状态，把现实与预期的差值抹平工作交给调谐器。当系统规模扩张至几十乃至上百个 Agent 并发运行时，声明式管理在可靠性上具有压倒性优势，因为“管住 100 个 Pod 的，是声明式 API 加控制器，而不是某只更聪明的 Pod”。

面对文章开头那只失控烧钱的 Agent，现在的工业界正在用成熟的 Kubernetes 蓝图为它搭建安全围栏，而在这个精心设计的笼子里，“给 Agent 铺桌子的还是另一只 Agent”。

## Notable quotes > [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) 管住 100 个 Pod 的，是声明式 API 加控制器，而不是某只更聪明的 Pod。

> [05:00](https://www.bilibili.com/video/BV1Qsp76bEzx?t=300s) Google 的答案不是发明新东西，是把云计算十年攒下的最成功的方法论，声明式 API、控制器调谐、最小原语加组合，整体搬迁。

## Mentioned Google, ax, Kubernetes, rakyll, Agent Substrate, gVisor, Redis, Model Context Protocol

## Video description 把一个 AI agent 放进公司集群里跑：它自己规划、自己委派、自己扇出子任务；它累积状态、需要严格隔离、不停调模型接口；而最现实的一条——没人看着，它会在一个循环里安静地把钱烧完。这种工作负载既不是无状态微服务，也不是跑完即走的批处理，基础设施层一直没为它准备位置。九月下旬，Google 开源了回答这个问题的项目：google/ax，高吞吐、声明式的 agent 编排运行时，目标是单集群跑数十亿个自主 agent。社区外号更直白——agent 界的 Kubernetes。一周 13.4k 星，GitHub Trending 登顶。

用过 K8s 的人会会心一笑：写 YAML 声明三样东西，ax apply 一下，get、describe、watch、delete 全套 kubectl 形状 CLI，连作用域都叫 atespace。三个原语解决三个痛点：Task 是最小隔离执行单元，刻意不建模 agent 的形状——树要多大 agent 自己组合，每个节点拿到同样的沙箱和生命周期；Workspace 治冷启动，Git 仓库、MCP 服务器、技能包声明一次到处绑定，最有意思的是 goal 字段——写一句人话"确保 Go 工具链可用"，首次启动时运行时把这句话交给另一个 agent 去装环境，给 agent 铺桌子的，是另一个 agent；Model 把模型配置变成集群资源，换密钥换版本一次 apply 全局生效。

运维体验也是 K8s 味：ax suspend 把状态 checkpoint 后暂停、ax resume 断点接续、ax ssh 直接进沙箱看 agent 干活、ax watch 流式盯状态。v0.3 拆成三服务：API 前端 + reconciler 调谐器 + 沙箱 task runner，底下垫着 single-writer 事件日志，沙箱跑在 Google 系开源的 Agent Substrate 上，gVisor 级隔离加网络围栏。作者是 Go 社区老面孔 rakyll，三月立项内部打磨半年，吉祥物一只美西螈。

三个判断：①问题是真的，姿势是老的——烧钱、隔离、有状态确实缺一块基础设施，而 Google 的答案不是发明新东西，是把声明式 API、控制器调谐、最小原语加组合这套云计算十年最成功的方法论整体搬迁，这个选择本身就是品味；②冷水——README 自己挂着"重度开发期，稳定前有破坏性变更"（当前 v0.3）；上手要 K8s 集群 + Agent Substrate + Redis + 镜像仓库，给平台团队用的，个人玩家看个热闹；"数十亿"是设计目标不是实测；"agent 界的 K8s"这个外号社区也有争论；③值得记住的模式：多 agent 办公室和主管 agent 是命令式管理——造一个更聪明的老板；ax 是声明式管理——只描述期望状态，让调谐器收拾现实。管到上百个 agent 时大概率后者赢，因为管住一百个 pod 的，是声明式 API 加控制器，而不是某只更聪明的 pod。

参考：github.com/google/ax · agentexecutor.io · docs/concepts.md

[Source](https://www.bilibili.com/video/BV1Qsp76bEzx)