当 Kubernetes 遇上 Agent：Google 开源 ax，给自治智能体一个声明式调度器

一个不舒服的事实

你写了一个很棒的 coding agent。它能在沙箱里跑测试、改代码、提交 PR。你把它部署到 Kubernetes 上，以为一切万事大吉——然后第二天醒来发现：

• 它在凌晨 3 点循环调用了 2000 次 Claude API，烧掉了 800 美元
• 它把一个测试数据库的连接串泄露到了 GitHub Issue 里
• 它卡在一个死循环里，占着 CPU 不放，状态全在内存里，kill 掉就全丢了
• 它试图访问内网的一个服务，那个服务根本不该被它碰到

Kubernetes 没做错什么。它只是被设计来跑"无状态微服务"和"跑完即止的批处理任务"的。而 Agent 是一种全新的工作负载——它有状态、它跑得久、它会花你的钱、它会自己决定访问什么网络资源。这四条里任何一条都打破了 K8s 的基本假设。

2026 年 9 月 22 日，Google 开源了 ax，一个专门为 Agent 工作负载设计的声明式调度器。上线一天涨了 2324 stars。它做了一件很简单的事：把 Agent 当成一等公民，给它 K8s 那套声明式 API，但每一块都为 Agent 重新设计过。

四个原语，不是四个容器

K8s 的核心原语是 Pod、Deployment、Service、Ingress。ax 的核心原语是另外四个，每一个都对应 Agent 的一个独特痛点：

这四个原语写成 YAML，长得像 K8s 但语义完全不同：

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
    - repo: https://github.com/golang/go.git
      branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspaces:
    - name: golang
      goal: "Ensure that Go tool chain is available and is built from source"
  debug: true   # lets you `ax ssh` into the sandbox

ax apply -f task.yaml，然后 ax watch task test 看着它起来，ax ssh test -- ls -al /workspace 直接钻进沙箱里看它在干什么。这套交互对任何用过 kubectl 的人来说零学习成本。

suspend/resume：Agent 的"存档点"

最让我眼前一亮的功能是 ax suspend 和 ax resume。

想象一个 Agent 跑了 4 小时，已经分析了一个大型代码库的 30%——这时候它要等一个人类决策。在传统架构里你有两个选择：

1. 让它继续占着资源等（烧钱）
2. kill 掉，等人类决策完了从头跑（更烧钱，而且可能跑不出同样的结果）

ax 的 suspend 会checkpoint Actor 的状态，把整个 Task 暂停，释放 CPU/内存。resume 的时候从 checkpoint 恢复，Agent 继续从 30% 那里开始。这就像游戏里的"存档点"——你不用每次都从第一关打起。

这个功能在 K8s 里没有对应物。K8s 的 Pod 被 evict 后状态全丢。StatefulSet 保留了存储但没保留进程状态。ax 的 suspend/resume 是为 Agent 这种"长时间、有状态、可能需要人类介入"的工作负载专门设计的。

Gateway：把"烧钱循环"关在笼子里

Agent 最危险的不是它做错事，而是它在一个错误循环里反复调用付费 API。一个 bug 导致 Agent 每 3 秒调一次 GPT-4，一晚上就是 9600 次调用，按 $0.03/1K input tokens 算，一晚上烧掉几百美元轻轻松松。

ax 的 Gateway 原语把出站流量锁死在一个显式白名单里。Agent 只能访问你明确允许的 host。这意味着：

• 你可以让 Agent 访问 api.anthropic.com 但不能访问 api.openai.com（强制走某一个 LLM provider）
• 你可以让 Agent 访问 GitHub 但不能访问你的内网数据库
• 你可以让 Agent 访问 registry.npmjs.org 但不能访问你的私有 npm registry

这比 K8s 的 NetworkPolicy 更严格——NetworkPolicy 控制的是 Pod 之间的网络，Gateway 控制的是 Agent 能接触到的"外部世界"。对一个会自己写代码、自己跑命令的 Agent 来说，这个区别至关重要。

底座：Agent Substrate

ax 不是从零造的。它跑在 Agent Substrate 之上——一个专门为 Agent 沙箱执行设计的底座。Agent Substrate 提供：

• 沙箱化执行环境（CPU/内存隔离）
• 文件系统隔离
• 网络命名空间
• 进程隔离

ax 在这之上加了声明式 API、调度、状态管理、网络策略。这个分层很像 K8s 跑在 containerd 之上——containerd 管容器生命周期，K8s 管调度和编排。

为什么 2324 stars 一天？

因为这是第一个把 Agent 当一等公民的调度器。

过去两年，Agent 框架百花齐放——LangChain、AutoGen、CrewAI、OpenAI Agents SDK——但这些都是单机框架。它们解决的是"一个 Agent 怎么思考"，没解决"一千个 Agent 怎么在集群里跑"。

当你只有 10 个 Agent，你用框架就够了。当你有 10000 个 Agent，每个都在跑不同的任务，每个都要访问不同的 LLM，每个都要不同的工具集，每个都要不同的网络策略——你需要的是调度器。

ax 的出现标志着 Agent 基础设施进入了"集群时代"。就像 2015 年 Docker 出现后大家发现"容器多了需要编排"，2026 年 Agent 多了大家发现"Agent 多了需要调度"。

它没解决的问题

ax 不是银弹。它有几个明显的局限：

1. 依赖 K8s：ax 跑在 K8s 之上，你需要一个 K8s 集群才能用。对小团队来说门槛偏高。
2. 只解决执行层：ax 不管 Agent 怎么思考、怎么规划。它是一个执行环境，不是 Agent 框架。
3. 早期阶段：README 明确说"we are still actively refining our core concepts"，v1alpha1 意味着 API 可能大改。
4. Agent Substrate 依赖：需要部署 Agent Substrate Control API，这是另一个组件。

但作为一个"Agent 集群调度"的第一次严肃尝试，ax 已经把所有关键问题摆到了桌面上：状态管理、网络隔离、成本控制、声明式 API。接下来无论谁做 Agent 基础设施，都得回答 ax 提出的这些问题。

一个类比收尾

如果你用过 Kubernetes，你会觉得 ax 像是"K8s 但每一个原语都为 Agent 重新设计过"。如果你没用过 K8s，可以这样理解：

• ax 之于 Agent，就像操作系统之于进程
• Task 是进程，Workspace 是进程的运行环境（环境变量、挂载的文件）
• Gateway 是防火墙规则，Model 是进程能用的计算资源
• suspend/resume 是进程的"冻结"和"解冻"

Agent 不是微服务，不是批处理任务，不是函数。它是一种新的工作负载，需要新的调度器。ax 是这个调度器的第一个严肃实现。

项目地址：google/ax
底座：agent-substrate/substrate
许可证：Apache 2.0
语言：Go