Google AX 深度解析：声明式编排数十亿 Agent 的运行时

1. 这个 AX 到底是个什么东西

Google 开源 AX 这件事，在技术社区里炸开锅的那天我正好在刷动态，第一反应是：又一个 agent 框架？但仔细看完仓库结构和几篇讨论之后，我意识到这东西跟市面上那些"帮你写 prompt 的 SDK"完全不是一个物种。AX 的核心定位是声明式编排数十亿 agent 的运行时，注意这几个词——声明式、数十亿、运行时。它不是在解决"怎么让一个 agent 跑起来"，而是在解决"怎么让海量 agent 在集群里有序、可观测、可调度地活着"。

说白了，如果你用过 Kubernetes 编排容器，那 AX 想做的事情就是把 agent 当成容器来编排。你写一份 YAML，描述你想要的 agent 拓扑、依赖关系、资源约束，剩下的调度、生命周期管理、故障恢复交给运行时。这个思路在容器领域已经被验证了十几年，现在被搬到 agent 编排上，难怪有人兴奋有人质疑。

适合谁来研究这个东西？我认为有三类人值得花时间：一是已经在做多 agent 系统、被调度和状态管理折磨过的后端工程师；二是想理解"agent 基础设施"这个方向会往哪走的架构师；三是单纯好奇"声明式"这套哲学能不能套到 AI 工作流上的技术爱好者。如果你只是想让一个 agent 帮你查天气，那 AX 属于杀鸡用牛刀，不用碰。

我先把结论放前面：AX 的价值不在于它现在有多好用，而在于它把"agent 编排"这个问题从"写代码调 API"提升到了"声明式描述期望状态"的抽象层级。这个抽象层级的变化，才是它值得被认真对待的原因。

2. 为什么"声明式"这三个字是整件事的核心

2.1 命令式编排的痛，做过的人都懂

在 AX 出现之前，绝大多数 agent 框架都是命令式的。什么叫命令式？就是你得一步步告诉程序该干什么：先初始化这个 agent，再调用那个工具，然后判断返回值，如果失败就重试，重试三次还失败就降级……这套逻辑写起来直观，但一旦 agent 数量上去、依赖关系变复杂，代码就会变成一团意大利面。

我踩过最典型的坑是状态管理。一个 agent 执行到一半挂了，它之前产生的中间状态怎么办？重试的时候是从头来还是从断点续？如果这个 agent 依赖上游三个 agent 的输出，而上游其中一个失败了，整条链路怎么处理？命令式代码里，这些逻辑全得你自己写，写到最后你会发现你其实在重新实现一个蹩脚的调度器。

声明式的思路完全反过来。你不描述"怎么做"，你描述"我要什么"。你写一份 YAML 说：我要一个由 A、B、C 三个 agent 组成的流水线，A 的输出喂给 B，B 和 C 并行，最后汇总。运行时拿到这份描述，自己去算怎么调度、怎么重试、怎么恢复。这就像你告诉 Kubernetes"我要三个副本的 nginx"，而不是自己写脚本去docker run三次再写个监控脚本盯着。

2.2 声明式带来的三个实际好处

第一个好处是幂等性。声明式描述的是期望状态，运行时的工作就是不断把实际状态往期望状态上靠。这意味着你重复提交同一份 YAML，结果是一样的，不会因为重复执行产生副作用。这在 agent 场景里特别重要，因为 agent 经常需要重试，幂等性能保证重试是安全的。

第二个好处是可观测性天然内建。因为运行时知道你的期望状态是什么，它就能告诉你"现在实际状态和期望状态差在哪"。哪个 agent 没起来、哪个依赖没满足、哪个资源超了，一目了然。命令式代码里，这些信息散落在各个日志里，排查起来要命。

第三个好处是关注点分离。写 agent 逻辑的人只管写 agent 逻辑，调度、扩缩容、故障恢复这些脏活交给运行时。团队里不同角色可以各司其职，不用每个人都懂全套调度逻辑。

提示：声明式不是银弹。它的代价是抽象层变厚，出问题时排查链路变长。你得接受"我看不到运行时内部在干什么"这件事，除非它提供了足够的可观测性接口。

2.3 为什么是 YAML 而不是别的

热词里"yaml文件""yaml格式""yolov10 yaml文件怎么创建"这些搜索词扎堆出现，说明很多人对 YAML 本身就有困惑。AX 选 YAML 作为描述语言，我觉得是深思熟虑的。YAML 的可读性好，非程序员也能看懂大概；它天然支持嵌套结构，适合描述 agent 之间的层级和依赖；而且 Kubernetes 生态已经把 YAML 这套玩得很熟了，大家有认知基础。

但 YAML 的坑也不少。缩进敏感、类型推断诡异（yes会被解析成布尔值这种经典坑）、大文件难维护。AX 用 YAML 描述 agent 拓扑，意味着你得接受这些坑。我的经验是，写复杂 YAML 一定要配 schema 校验，不然一个缩进错误能让你 debug 半天。

3. AX 的核心概念拆解

3.1 Agent 作为一等公民

在 AX 的世界观里，agent 是一个被运行时管理的实体，就像 Pod 之于 Kubernetes。每个 agent 有自己的生命周期：创建、运行、完成、失败、销毁。运行时负责在这些状态之间做转换，并在异常时采取行动。

这里有个关键设计：agent 是无状态的（至少运行时假设它是无状态的）。agent 的状态存在外部，运行时只负责调度。这个设计让水平扩展变得容易——想加 agent 就加，不用考虑状态迁移。但代价是，如果你的 agent 逻辑本身需要维护复杂状态，你得自己想办法外置。

3.2 编排图与依赖关系

AX 用图来描述 agent 之间的关系。节点是 agent，边是依赖。这个图可以是有向无环图（DAG），也可以有循环（用于迭代场景）。运行时根据这个图来决定执行顺序：没有依赖的 agent 可以并行跑，有依赖的必须等上游完成。

我实测下来，DAG 这种模型对大多数批处理式的 agent 流水线是够用的。但如果你要做那种"agent 之间互相协商、动态决定下一步"的场景，DAG 就有点僵。AX 据说支持动态图，但动态图的调度复杂度会指数级上升，这块我还没深入验证。

3.3 运行时与调度器

运行时是 AX 的心脏。它要做的事情包括：解析 YAML、构建执行图、分配资源、调度 agent、监控状态、处理失败、收集指标。这一套下来，复杂度不比一个轻量级容器编排器低。

调度策略是运行时最核心的部分。AX 默认的调度策略我理解是类似"就绪即调度"——只要一个 agent 的依赖都满足了，就把它扔到可用的执行槽里。但实际生产环境里，你可能需要更复杂的策略：优先级调度、资源感知调度、亲和性调度等等。这些 AX 是否都支持，得看具体版本。

4. 从零理解 AX 的执行模型

4.1 一次完整的执行流程

假设你写了一份 YAML，描述了一个三步流水线：抓取数据、处理数据、生成报告。AX 拿到这份描述后，大致会经历这么几个阶段。

第一阶段是解析与校验。运行时读 YAML，检查语法、校验 schema、确认引用的资源都存在。这一步失败的话，直接报错，不会进入执行。

第二阶段是构建执行图。运行时把 YAML 里的声明转换成内部的图结构，计算出哪些节点可以并行、哪些必须串行、关键路径是哪条。

第三阶段是调度与执行。运行时按图调度 agent，每个 agent 被分配到一个执行单元（可能是线程、进程、容器，取决于配置）。执行过程中，运行时持续监控状态。

第四阶段是状态收敛。如果有 agent 失败，运行时根据重试策略决定是重试、跳过还是终止整条流水线。如果一切顺利，所有 agent 完成后，运行时汇总结果。

第五阶段是清理。释放资源，收集指标，把执行记录归档。

4.2 状态是怎么被管理的

这是我觉得 AX 最值得研究的部分。声明式系统的核心是"状态收敛循环"——运行时不断对比期望状态和实际状态，然后采取行动消除差异。

具体到 agent 场景，期望状态可能是"这三个 agent 都成功完成"，实际状态可能是"agent A 完成，agent B 运行中，agent C 等待中"。运行时看到这个差异，就知道该去推进 B 和 C。如果 B 失败了，实际状态变成"B 失败"，运行时根据策略决定是重试 B 还是标记整条流水线失败。

这个循环的难点在于并发控制。多个 agent 同时改变状态时，怎么保证不冲突？AX 应该用了类似乐观锁或者事件队列的机制，但具体实现我没看到源码，不好下结论。

4.3 失败处理的设计哲学

命令式代码里，失败处理是显式写的 try-catch。声明式系统里，失败处理是策略驱动的。你可以在 YAML 里声明：这个 agent 失败了重试三次，重试间隔指数退避；如果三次都失败，标记为致命错误，终止整条流水线。

这种策略驱动的失败处理，好处是统一、可配置、不用每个 agent 都写一遍。坏处是灵活性受限，遇到策略覆盖不到的特殊情况，你还是得想办法绕。

注意：重试策略一定要配超时。我见过太多因为重试没有超时导致任务卡死、资源耗尽的案例。指数退避 + 最大重试次数 + 全局超时，这三件套缺一不可。

5. 手把手：一份 AX YAML 该怎么写

5.1 最小可用示例的结构

虽然我没法给你一份官方文档级别的完整示例，但基于声明式编排的通用模式，一份 AX YAML 大概长这样：顶层是版本和元信息，然后是 agent 定义区，每个 agent 有名字、镜像或执行入口、资源需求、依赖列表，最后是编排策略区，定义重试、超时、并发度这些。

写这份 YAML 的时候，我建议你从最小可用开始。先定义两个 agent，一个依赖另一个，跑通了再加复杂度。一上来就写几十个 agent 的拓扑，出错了你根本不知道从哪查。

5.2 关键字段的含义与取值

agent 的name字段是唯一标识，命名要有意义，别用agent1agent2这种，后期维护会疯。dependsOn字段声明依赖，值是一个列表，列出所有上游 agent 的名字。resources字段声明资源需求，包括 CPU、内存，可能还有 GPU。

retryPolicy字段控制重试行为，通常包含maxAttempts、backoff、timeout三个子字段。backoff可以是固定间隔，也可以是指数退避。timeout是单次执行的超时，不是总超时，这点容易搞混。

5.3 参数计算：资源怎么估

资源估算是个经验活。我的做法是：先给一个宽松的值跑一遍，用监控数据看实际峰值，然后按峰值的 1.5 倍设限。CPU 密集型 agent 给 1-2 核，内存密集型看数据量，GPU 密集型按显存需求给。

并发度这个参数要特别小心。并发度设太高，资源争抢导致整体变慢；设太低，资源闲置。我的经验值是，并发度设为可用执行槽的 70%-80%，留点余量给系统本身和突发流量。

5.4 一个容易忽略的细节：命名空间

如果你的 AX 集群是多租户的，命名空间隔离一定要做。不同团队的 agent 放在不同命名空间，避免互相干扰。命名空间还能用来做资源配额，防止一个团队把整个集群吃满。这个设计是从 Kubernetes 抄来的，实践证明有效。

6. 跟 Kubernetes 到底像在哪、不像在哪

6.1 像的地方：控制循环与期望状态

AX 和 Kubernetes 最像的地方是控制循环（control loop）这个模式。Kubernetes 的控制器不断对比期望状态和实际状态，AX 的运行时也是。这个模式的好处是自愈能力强——不管中间出什么岔子，只要期望状态不变，系统最终会收敛过去。

另一个像的地方是资源抽象。Kubernetes 抽象了计算、存储、网络，AX 抽象了 agent 的执行单元、状态存储、消息传递。这种抽象让上层不用关心底层细节，但也意味着底层出问题时上层很难直接干预。

6.2 不像的地方：agent 是有"智能"的

容器是无状态的、确定性的——同样的输入，同样的输出。agent 不是。agent 内部可能调用大模型，同样的输入可能得到不同的输出。这给编排带来了新问题：你怎么定义"成功"？怎么判断一个 agent 的输出是"对的"？

Kubernetes 里，容器退出码非零就是失败。AX 里，agent 跑完了但输出质量差，算成功还是失败？这个问题没有标准答案，得靠你在 agent 逻辑里自己定义成功标准，然后通过某种方式反馈给运行时。

6.3 借鉴与超越

AX 明显借鉴了 Kubernetes 的很多设计，但它也针对 agent 场景做了调整。比如对长时运行 agent 的支持、对动态拓扑的支持、对 agent 间通信的支持，这些都是容器编排器不需要考虑的。

我觉得 AX 能不能成，关键看它能不能在"借鉴 Kubernetes"和"针对 agent 特化"之间找到平衡。太像 Kubernetes，会水土不服；太特化，会失去通用性。

7. 实际部署时会遇到的那些坑

7.1 冷启动延迟

agent 的冷启动比容器慢得多，因为可能要加载模型、初始化上下文。如果你的流水线里有很多短时 agent，冷启动延迟会累积成很大的开销。我的做法是保持一个 warm pool，让常用 agent 常驻，减少冷启动。

7.2 状态存储的选择

AX 需要外部状态存储来记录 agent 的执行状态。选什么存储很关键。Redis 快但持久性弱，PostgreSQL 持久但慢，etcd 适合小状态但不适合大吞吐。我的经验是，执行状态用 Redis，最终结果用对象存储，审计日志用 PostgreSQL，各司其职。

7.3 可观测性的搭建

声明式系统的可观测性比命令式更重要，因为你不能靠读代码理解系统在干什么。指标、日志、追踪三件套都得配齐。指标看整体健康度，日志查具体事件，追踪看单次执行的完整链路。缺一个，排查问题时都会抓瞎。

7.4 版本兼容性

AX 还在快速迭代，版本之间的兼容性可能有问题。我的建议是锁定版本，升级前先在测试环境跑一遍完整流水线，确认没问题再上生产。别追新，稳定压倒一切。

8. 常见问题速查与排查思路

8.1 agent 一直处于 Pending 状态

这是最常见的问题。原因通常有三个：依赖没满足、资源不够、调度器卡住。排查顺序是：先看依赖的 agent 状态，再看集群资源余量，最后看调度器日志。如果是依赖问题，等上游完成就行；如果是资源问题，要么加资源要么降需求；如果是调度器问题，重启调度器组件。

8.2 agent 反复重启

反复重启通常意味着 agent 逻辑本身有问题，或者健康检查配置太严。先看 agent 日志，确认是崩溃还是被健康检查杀掉。如果是崩溃，修逻辑；如果是健康检查，放宽阈值。还有一种可能是资源限制太紧，agent 被 OOM Killer 干掉，这种情况要加内存。

8.3 流水线整体卡住不动

整条流水线卡住，通常是某个关键 agent 卡住了，导致下游全部等待。排查方法是找到那个"运行中但长时间没进展"的 agent，看它的日志和资源使用。可能是死锁，可能是外部依赖超时，也可能是 agent 内部逻辑有 bug。

8.4 输出不符合预期但没报错

这是 agent 场景特有的问题。agent 跑完了，退出码是 0，但输出是垃圾。这种情况运行时帮不了你，得在 agent 逻辑里加输出校验。我的做法是，关键 agent 的输出必须过一遍校验器，校验不过就当失败处理，触发重试或告警。

提示：给 agent 定义明确的成功标准，比什么都重要。没有成功标准，声明式编排就失去了收敛的目标。

9. 我对 AX 这类方案的一些个人判断

折腾了这段时间，我最大的体会是：声明式编排 agent 这个方向是对的，但 AX 现在还在很早期。它的概念模型清晰，但工程实现上还有很多粗糙的地方。如果你现在就想上生产，我建议再等等，或者只在小范围非关键业务上试水。

另一个体会是，agent 编排的难点不在编排本身，而在 agent 的"不确定性"。容器编排之所以成功，是因为容器的行为是确定的。agent 的行为不确定，这让所有基于"期望状态"的假设都变得脆弱。AX 能不能解决这个问题，或者至少缓解这个问题，是它能否走远的关键。

最后分享一个我自己的用法：我把 AX 当成一个"agent 流水线的描述语言"来用，而不是一个完整的运行时。我用它来描述拓扑，但执行还是走我自己的调度器。这样我既能享受声明式描述的好处，又不用完全依赖 AX 的运行时。这个折中方案目前跑得还不错，供你参考。