Google AX深度解析：像Kubernetes管理容器一样编排Agent集群

最近花了不少时间在折腾AX，刚看到官方把它定位成「Kubernetes for Agents」的时候，说实话第一反应是这名字起得真敢。把文档完整刷完、示例真正跑起来之后，我的看法变了：这个类比不但不夸张，甚至可能是目前对Agent基础设施最准确的一句描述。

AX是Google开出来的Agent编排框架，核心思路是用声明式YAML来描述Agent集群里跑什么任务、任务之间怎么连接、数据怎么流转、失败怎么恢复。它解决的问题不是“一个Agent怎么跟大模型对话”，而是“几千几万个Agent同时在跑，谁负责任务调度、消息怎么不丢、流量怎么分配、故障怎么自愈”。如果你之前玩过LangChain、AutoGen这类应用层框架，会发现它们和AX压根不在一个层级——前者相当于写业务逻辑的代码库，后者是做容量编排和资源管理的系统底座。

这篇文章我打算按自己的理解，从背景动机、核心架构、YAML配置实战、大规模调度的原理、部署踩坑，再到横向对比，完整聊一遍AX。全程基于我实际动手的体会，没有“官网复读机”内容。

1. 为什么我会盯上AX——Agent编排的瓶颈根本不在“智能”

现在做Agent开发的人，99%的精力都花在提示词、工具调用、多轮记忆这些“智能层面”的事情上。可实际把Agent跑上生产环境的人，早晚会撞上另一堵墙：编排层。你写了100个Agent，每个都要独立启动、互相通信、共享数据、做失败重试，光是把这些进程管好就够喝一壶的，更别说资源分配和流量突增。

1.1 当下Agent框架的编排上限低得吓人

我最早接触的多Agent编排是在LangChain的Graph层面做的，比如定义一个顺序链，A跑完给B，B跑完给C。这种模式在几个Agent的时候很优雅，但到了几十个Agent、每个还有多副本的时候，问题就来了：

• 状态维护只能靠外部数据库，Agent之间互相等结果，谁挂了很难发现。
• 没有真正意义上的调度器，所有路由逻辑都写死在业务流程里，加一台机器、拆一个任务、换一个数据分片，都要改代码。
• 扩容基本靠手工，想在流量高峰期让某类Agent自动从2个副本变20个，LangChain这类框架给不出答案。

AutoGen和CrewAI也有类似问题，它们擅长组织“一场几个Agent的协作对话”，但不擅长管理“一群Agent组成的服务集群”。到了这个层面，需要的已经不是Agent框架，而是一个通用的工作负载编排系统。

1.2 AX要解决的是“整个集群”的问题

AX的出发点恰恰在这里。它脱胎于Google内部支撑Gemini等核心服务的Agent基础设施，长年面对的是海量离线推理、数据生成、模型评估这类重活。这些任务有共同特点：规模巨大、可并行、对单点失败容忍、需要把GPU/CPU资源用满。它从一开始就按“集群操作系统”的标准设计，目标是把Agent当作一种可调度的计算单元，像Kubernetes管理容器一样管理它们。

这一点在你跑通第一个Demo之后体会尤其明显。AX里你不关心某个Agent进程在哪台机器上，不关心它崩溃之后怎么重启，不关心消息是走HTTP还是gRPC——你只声明“我要跑什么、需要多少资源、结果去哪”，剩下全是系统的事。

2. “Kubernetes for Agents”到底类比的是什么——声明式API与控制循环

Kubernetes最核心的思想不是容器，而是“声明式终态+控制循环”。你提交一个期望状态（Deployment里写想跑3个副本），系统内一堆控制器不断对比“当前状态”和“期望状态”，有偏差就拨正。AX把这套哲学原封不动搬到了Agent世界。

2.1 声明式模型：从“写脚本”到“描述终态”

传统Agent跑批任务，大家习惯写一个脚本来控制流程：启动AgentA、等输出、拿输出喂给AgentB、失败就重试。这种命令式（Imperative）编排在规模小的时候没问题，但流程一旦变复杂，脚本会变成意大利面条，而且运行时的每一步都不能回溯、不好审计。

声明式（Declarative）是反过来的：你不管“过程”，只描述“终态”。比如“我要1个任务流，先用AgentA做意图分类，产生1000条中间结果，然后让100个AgentB并发处理这些结果，最后把输出汇总到Channel里”。至于中间谁先跑谁后跑、需要多少Pod、并发数怎么控制，AX的调度器通过依赖分析自己推断。

Kubernetes用户对这个模式很熟悉，但对纯做AI应用的人来说，这是一个需要切换的思维习惯。我之前写过一个数据清洗流程，用命令式脚本写了400多行，轮到AX里只写了60行YAML，且任何一个环节出问题，系统会自己重试，不用我在脚本里手写各种异常捕获。

2.2 控制循环、Registry、Scheduler和消息总线

AX的控制平面由几个核心服务构成，和Kubernetes的控制平面组件几乎一一对应：

里面最关键的是Scheduler和Message Bus。Scheduler不只是一个简单的“分配器”，它手里拿着整个系统的资源清单、队列深度、节点负载，能用多种策略把任务调度到最合适的地方。Message Bus则负责保证消息投递的可靠性——消息不会是简单的“发出去就不管”，而是带确认机制、可重放、可延迟绑定，这些对分布式Agent协作来说要命地重要。

2.3 技术栈与组件分工：Rust控制平面+多语言Worker

AX的实现有点特别，控制平面用了Rust来写，Worker侧则保留Python/Go/Rust等多种语言接入能力（gRPC接口）。Rust在这里主要为了高并发、低延迟和内存安全——Agent集群的调度器每秒要处理海量事件，Go不是不行，但Rust在确定性性能和资源占用上更狠。

这种分工带来的好处是：做系统的人有一层稳定高效的骨架，做AI业务的人继续用自己熟悉的语言写Agent逻辑，不必为了接入AX学习一套新语言。我自己是用Python写的Worker，体验下来基本无痛：项目里引入AX的Python SDK，实现一个服务类，注册好方法后打包成镜像，剩下的交给平台。

3. YAML实战：Agent、Eval、Channel怎么写

看文档是一回事，真正把YAML写出来跑通又是另一回事。AX里最常用的是三类资源：Agent（部署单元定义）、Eval（编排任务流）、Channel（消息与数据通道）。下面是我实际跑通的简化示例，字段以官方发布版本为准，但整体结构应该能看出设计逻辑。

3.1 Agent定义：先声明“有什么资源”

一个Agent定义在AX里不是“实现代码”，而是“部署工具”。它描述的是这个Agent怎么跑起来，需要多少副本，用哪个镜像，暴露什么端口。

apiVersion: axis/v1 kind: Agent metadata: name: sentiment-analyzer spec: deployment: replicas: 3 template: containers: - name: worker image: my-registry/sentiment-analyzer:latest ports: - name: grpc containerPort: 50051 resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "2"

注意这里replicas不是写死的，AX支持后面通过自动扩缩容策略动态调整。你在YAML里写的3，相当于声明了一个“推荐水位”，实际运行中控制循环会结合队列长度、CPU使用率等因素把它拉高或压低。

3.2 Eval编排：graph和sections如何应对规模

Eval是AX的编排核心，相当于Kubernetes里的Deployment+Job组合体。它里面描述整个任务流：第一步做什么、第二步怎么分发、哪些步骤可以并行、哪些必须串行。

apiVersion: axis/v1 kind: Eval metadata: name: review-classification-eval spec: graph: - id: step1-classify agent: sentiment-analyzer - id: step2-summarize agents: - summarizer - topic-tagger sections: - name:>apiVersion: axis/v1 kind: Channel metadata: name: processed-tasks spec: routing: type: replicated replicas: 3 subscriber: - agent: downstream-worker

Channel的关键特性是可配置投递语义。默认是至少一次投递，消息在Channel里持久化，消费者消费成功后要返回确认，否则消息会重新投递给其他消费者。这套机制保证了在Agent崩溃或重启后不会丢消息。

实际使用中我踩过一个小坑：Channel的消费者并发度如果设置过高，下游Agent处理不过来，队列会积压。后来在Agent定义里加了队列积压阈值触发的自动扩容策略，才算匹配上生产节奏。

4. 十亿级任务是怎么压出来的——调度、分片与容量规划

AX敢打出“十亿级Agent任务”的口号，靠的不是单一组件的性能，而是调度策略、数据并行、容量管理三个层面协同。

4.1 路由与分层：本机优先队列

先看一个具体场景：你有一万个Agent副本分布在50台机器上，每个任务来了，调度器怎么决定派给谁？如果所有任务都走中心调度器，调度器就是瓶颈。AX的解法是分层路由：消息先在本机队列里匹配可用的空闲Worker，本机没有空闲再上报到可用区级调度器，跨可用区的流量通过区域级调度器协调。

这种“本机优先，逐级上报”的思路相当于给消息路由做了三级缓存，绝大多数任务在机器本地就被消费了，跨机器的消息只占少数。我在跑压测时观察到的效果是：单节点Agent数量越多，本地命中率越高，网络开销占比明显下降。

4.2 Sharder数据并行和Map-Reduce式拆分

数据并行是十亿级任务的核心引擎。AX里的Sharder会把一个大的输入数据集按指定维度切分，默认支持哈希、范围、轮询三种分片方式。每个分片就是一个独立计算单元，调度器把分片分配给空闲Agent副本，消费完的分片标记完成，所有分片完成后进入下一个聚合阶段。

如果你熟悉MapReduce，会发现AX这套和它并没有本质区别——第一步把任务Map出去并行处理，第二步把结果Reduce回来聚合。区别在于AX的MapReduce不是给纯数据计算用的，而是给“有状态、会调用外部工具、要跟语言模型交互”的Agent做编排用的，这中间多出很多状态同步和断点恢复的逻辑。

4.3 容量规划与失败恢复的粗粒度设计

在这类系统里，资源预估比实时调优更重要。AX的容量规划机制允许你给某个Eval声明最大并发、总预算和优先级。调度器做的是一个近似最优的资源分配，而不是实时逐任务调整。

它还有个设计叫Choke Point——阻塞检查点。当任务的某个阶段必须等所有上游分片完成才能继续时，这个点就是全流程的“汇聚闸门”。AX在Choke Point会做持久化快照，某个下游Agent崩溃后，调度器不是从头重跑整个任务流，而是只重放崩溃节点未完成的部分。这个设计对节约成本意义很大，尤其是当每个任务背后都在调用付费大模型API的时候。

我在测试里专门kill过一个正在跑任务的Worker进程，观察到的结果是：同一Eval里已完成的几十个分片结果全部保留，系统只为丢失的那几个分片重新调度了新Worker来执行，整个恢复过程在数秒内完成，没有全量重跑。

5. 上手跑通AX的完整过程——从单机示例到多节点

开源项目光看文档永远记不牢，真正碰一遍才能理解架构的细节。下面是我部署AX和跑通第一个示例的完整过程，基本涵盖新手最容易卡住的几个环节。

5.1 环境准备：千万别忽略CRD和镜像拉取

我本地的环境是Ubuntu 22.04，Docker和Kubernetes集群已经就绪。AX官方提供了一套manifests，可以直接通过kubectl apply部署控制平面。

git clone https://github.com/google/ax.git cd ax kubectl apply -f manifests/

这一步会把CRD、控制平面服务（Registry、Scheduler、Message Bus）全部装进集群。然后我顺手建了测试用的命名空间，把Worker运行需要的镜像格式确认好。这里有一个容易踩的坑：如果你直接用集群自带的默认StorageClass，Message Bus的数据持久化可能会因为存储驱动不匹配而失败。我后来在Manifest里显式指定了StorageClass，问题才解决。

另一个坑是镜像拉取策略。我的Worker镜像放在本地方仓库，节点上如果没有提前拉取，Pod会一直卡在ImagePullBackOff。建议部署前先用kubectl create secret docker-registry把仓库凭证配好，或者把镜像tag改成IfNotPresent，保证本地优先。

5.2 第一个Agent deployment和Eval

我在本地写了一个极简Python Worker，做的事情是接收一个文本输入，返回文本长度。用AX的Python SDK封装后，构建成镜像：

import asyncio from ax.sdk import Agent class LenWorker(Agent): async def handle(self, request): return {"length": len(request.text)} agent = LenWorker() agent.run()

然后部署Agent和Eval：

kubectl apply -f agent.yaml kubectl apply -f eval.yaml kubectl get agents kubectl get evals

跑起来之后可以通过kubectl logs观察Worker日志，也可以在Message Bus的监控面板里看到任务的分发情况。第一次看到任务被自动切分、批量调度到多个Worker副本时，说实话还是挺有成就感的——这就和Kubernetes滚动升级100个Pod给人的感觉一样。

5.3 常见坑：Redis、Worker镜像和CRD冲突

• Redis版本兼容性：AX的Message Bus在某些版本依赖Redis的Stream特性，Redis版本太老会直接报错。我一开始用的Redis 5，后面升到7才算稳定。
• 多个Eval共享Agent副本：如果你同时提交多个Eval，资源不足时调度器不会排队等待，而是直接标记Pending。这个状态下日志往往看不出问题，你需要在Registry里查Pending原因。
• CRD字段校验：AX的CRD注解严格，字段少写一个下划线都会导致apply被拒。建议提交前先用官方提供的schema校验工具检查一遍，省得反复试错。
• 控制平面与Worker的时间同步：我遇到过任务一直处于调度中，查半天发现是节点时钟漂移，消息时间戳错乱导致确认消息被丢弃。用chrony同步了节点时间后恢复。

6. AX和LangChain/AutoGen/CrewAI到底什么关系——不在一个层级

每次聊到AX，都会有人问“这和LangChain哪个好”。这其实是典型的概念混淆。LangChain是应用开发框架，帮你封装大模型调用、提示词模板、工具集成；AX是基础设施层，解决的是Agent服务的部署、编排、调度、治理问题。非要比的话，LangChain相当于一个Java Web框架，AX相当于一个应用服务器。

有些人觉得可以不用AX，照着LangGraph的逻辑自己写一套“集群版”，凌晨三点爬起来救火之后大概率会回来拥抱AX。这不是说LangGraph不好，而是它们解决的问题不一样——就像你不会用Spring Boot来替代Kubernetes一样。

7. 哪些场景值得上AX，以及哪些场景别急着碰

AX不是万能银弹，它面向的是“大规模、可并行、重状态”的Agent任务。有些场景上了它，是给自己添乱。

7.1 适合AX的场景

第一类是离线批量数据处理。比如每天几百万条评论的情感分析、内容审核、标签提取，输入数据天然可切分，任务可并行度极高，AX正好发挥调度优势。

第二类是Agent评估与推理流水线。做大模型评估时经常要跑海量评测集，每个评测样本需要独立环境、独立上下文，跑完再聚合分数。这个场景下AX的分片+Choke Point机制是刚需。

第三类是复杂的Agent流水线服务。比如“意图分类→调用工具→结果摘要→语义检查→格式化输出”，中间任何一步需要横向扩缩容，AX的Channel通信和自动扩容能让这条流水线稳定扛住流量波动。

7.2 不适合AX的场景

如果是单Agent、交互式、短会话场景（比如一个聊天机器人后端），或者你的Agent数量长期不超过几十个，引入AX纯属过度设计。它有完整的一套Kubernetes和集群基础设施要维护，成本不低。

另外，如果你的Agent执行本身依赖大量有状态会话且不易分片，AX的调度优势会被冲淡。毕竟它擅长的还是“可拆成小任务、小任务尽量独立”的业务形态。

8. 上手之后我对这套模式的一些真实感受

前前后后折腾AX也有一段时间，有几个点确实超出了我一开始的预期。第一是声明式YAML的优势只有真正把业务流程从命令式脚本里解放出来之后才有体感——代码量变少只是一部分，更重要的是你可以像看Kubernetes对象一样审视整个Agent流水线，哪个Agent副本漂移了、哪个分片积压了、消息卡在哪一层，全都有迹可循。第二是分片级恢复带来的成本节约，在大模型API按次计费的背景下，崩溃后只重跑丢失的任务分片，而不是整条流水线重来，省下的钱相当可观。

最后分享一个小建议：如果准备试试AX，不要一上来就冲生产。先在测试集群里把官方示例跑通，然后拿你现有的一个批处理任务做迁移试点，重点观察一下消息总线积压情况、调度器决策延迟和Worker资源利用率这几个指标。踩过了小坑再放大规模，会顺畅很多。