Vking⋅AI - Kubernetes 不够用了？Google 开源 AX：给 AI 智能体造一个「编排层」

# Kubernetes 不够用了？Google 开源 AX：给 AI 智能体造一个「编排层」

9 月 22 日，Google 开源了一个叫 **AX** 的项目：一个「Kubernetes 风格」的编排器，但它的对象不是容器，而是**自治 AI 智能体**。两天之内，Oracle 又补了一记：用 OCI 的 Kubernetes 引擎演示了**1000 个智能体**如何跑在生产基础设施上。两条消息连起来看，一个信号很清楚——**智能体编排（Agent Orchestration）正在从「容器编排」里独立出来**。

一、为什么容器编排不够用了

AX 要解决的核心问题很直白：**AI 智能体不是普通应用**。Google 给出了四个维度的差异：

身份（Identity）：智能体代表用户或系统行事，需要**委托权限**和可追溯的归属；

状态（State）：智能体要跨步骤、跨会话、跨任务保留记忆，不只是请求级的临时状态；

调度（Scheduling）：智能体负载突发、长时运行、依赖工具，还经常在外部调用上「干等」；

资源管理（Resource）：智能体要在受控边界内访问模型、工具、API 和数据。

Kubernetes 当初是为「无状态/有状态应用」设计的，从来没想过要管理「会推理、会行动、会长期保持身份」的东西。AX 的做法，是把智能体基础设施当成**一等公民**来编排，而不是塞进某个 Pod 里跑。

二、Oracle 的对照组：1000 个智能体怎么落地

如果说 AX 在回答「智能体原生的编排器该长什么样」，Oracle 的演示则在回答「**在今天的 Kubernetes 上把智能体撑到 1000 个，会遇到什么**」。结论有三条：

持久化状态：每个智能体都需要能挺过重启、迁移和工具调用的记忆，无状态执行行不通；

身份与访问控制：每个智能体都要有独立身份、受限权限和审计轨迹——和人类用户的待遇一样；

共享存储：当智能体要读写同一份数据时，共享文件存储会变成协调层。

一句话：**跑一个智能体是 demo，跑一千个是基础设施问题**。

三、可观测性也被迫升级

同一天还有一条容易被忽略的消息：Percona 与 Coroot 打通了数据库监控与应用、网络、基础设施监控。为什么这事和智能体有关？因为 **AI 负载让「谁慢」变得模糊**：

一个智能体在等工具调用；

一个模型在等向量检索；

一个数据库在等锁——

三者表现出来都是「延迟升高」，但要修的东西完全不同。传统的「仪表盘」不够了，**跨层根因分析**正在成为刚需。

四、一个判断：基础设施的下一层是「智能体层」

把这三件事串起来看：编排（AX）、规模化落地（Oracle 1000 agents）、可观测（Percona × Coroot）——它们都在回答同一个问题：**当智能体从「一个函数」变成「一支数字队伍」，基础设施该长什么样**。

可能的技术演进路径是：容器编排到工作负载编排，再到**智能体编排**。Kubernetes 会不会被扩展来跑智能体？还是智能体基础设施会长成一个独立品类？这个问题，2026 年下半年才刚刚开始有答案。

小结

Google 的 AX 和 Oracle 的 1000 智能体演示，本质上都在说一件事：**别再把智能体当成「跑在容器里的应用」**。它们有身份、有记忆、有突发负载、有外部依赖。谁先把这套编排原语做出来，谁就握住了下一层基础设施的入口。