从Pod到Agent调度：Google AX如何解决AI Agent编排痛点

1. 从 Pod 调度到 Agent 调度：这个类比到底在说什么

第一次看到"让 Agent 像 Pod 一样被调度"这个说法，我脑子里第一反应是：又来了一个蹭 Kubernetes 概念的营销词。但仔细琢磨了一下 Google 开源 AX 这件事背后的逻辑，我发现这个类比其实相当精准，而且它指向的是一个真实存在的工程痛点——当你的系统里跑着几十上百个 AI Agent 的时候，你怎么管理它们的生命周期、资源分配和故障恢复？

先说结论：AX 想做的事情，本质上是把 Kubernetes 那套经过十年验证的调度哲学，搬到了 Agent 编排这个新战场上。Pod 是 K8s 里最小的调度单元，Agent 则是 AI 应用里最小的执行单元。两者面对的核心问题惊人地相似：你有一堆需要运行的工作负载，它们需要计算资源、需要互相通信、需要被监控、挂了需要重启、流量大了需要扩容。区别在于，Pod 跑的是容器，Agent 跑的是推理任务和工具调用链。

这篇文章适合谁看？如果你正在做 Agent 开发，手头管着超过五个 Agent 并且已经开始觉得"手动编排快把我逼疯了"，那这篇内容就是写给你的。如果你还在写单个 Agent 的 Demo，也可以先了解一下当规模上去之后会遇到什么问题，提前有个心理准备。我会从调度模型的设计思路讲起，拆解 AX 的核心机制，然后给出可落地的实操方案和踩坑经验。

需要提前说明的是，Google 开源 AX 这个项目本身还在快速迭代中，很多细节可能会变。但底层的调度思想和架构模式是相对稳定的，这也是我重点想聊的部分。我会基于公开信息和我在类似系统上的实践经验，补充大量"文档里不会写但实际会踩到"的细节。

2. 为什么 Agent 编排需要一套调度层

2.1 从"写一个 Agent"到"管一群 Agent"的鸿沟

大部分人接触 Agent 都是从写一个单体 Agent 开始的：定义一个 system prompt，挂几个 tool，接一个大模型 API，跑起来就完事了。这个阶段你根本不需要什么调度层，一个 Python 脚本就能搞定。

但当你开始做真实业务的时候，情况会迅速变复杂。我拿一个实际场景举例：假设你在做一个智能客服系统，背后不是一个 Agent，而是拆成了意图识别 Agent、知识检索 Agent、工单创建 Agent、情绪分析 Agent、回复生成 Agent 这么五个。每个 Agent 有自己的模型配置、有自己的工具集、有自己的超时策略。用户一个请求进来，需要按特定顺序调用其中几个，有些可以并行，有些必须串行。

这时候你会遇到什么问题？

• 资源争抢：五个 Agent 同时调用大模型 API，token 配额瞬间打满，请求开始排队甚至被限流。
• 故障传播：知识检索 Agent 挂了，整个链路全断，但你希望的是它能降级到一个简单的 FAQ 匹配。
• 状态管理：Agent 之间的上下文怎么传递？中间结果存哪里？失败了从哪一步重试？
• 弹性伸缩：白天请求量大需要多开几个回复生成 Agent，晚上没人用应该缩到零节省成本。
• 可观测性：用户投诉回复慢，你得知道是哪个 Agent 拖了后腿，是模型推理慢还是工具调用超时。

这些问题，说白了就是 K8s 当年解决的那类问题。Pod 调度器要处理资源配额、健康检查、滚动更新、自动扩缩容，Agent 调度层面对的是同一类挑战，只是调度的对象从容器变成了 AI 工作负载。

2.2 Pod 调度模型给 Agent 编排的三个关键启示

K8s 的调度模型之所以能成为事实标准，核心在于三个设计决策。我认为 AX 以及类似的 Agent 调度系统，都在不同程度上借鉴了这三点。

第一个启示：声明式而非命令式。你不需要告诉 K8s "先启动容器 A，再启动容器 B"，你只需要声明"我要 3 个副本的 A 和 2 个副本的 B，A 需要 2 核 4G，B 需要 1 核 2G"。调度器自己会算出最优的放置方案。对应到 Agent 场景，你不应该写代码去手动编排 Agent 的调用顺序，而应该声明"这个任务需要意图识别和知识检索的结果，两者可以并行，回复生成依赖前两者的输出"，调度层自动解析依赖关系并执行。

第二个启示：调度单元是最小粒度。Pod 之所以是 Pod 而不是直接调度容器，是因为有些容器必须在一起运行（比如 sidecar 模式）。Agent 也一样，有些 Agent 需要共享上下文或者必须部署在同一台机器上以减少网络延迟，调度层需要支持这种"绑定关系"。

第三个启示：控制器模式。K8s 的控制器不断对比"期望状态"和"实际状态"，然后采取行动消除差异。Agent 调度同样需要这种持续调谐的能力——某个 Agent 实例挂了，控制器发现实际状态偏离期望状态，自动拉起新的实例。

2.3 AX 在这个坐标系里的位置

Google 开源的 AX 项目，从目前公开的信息来看，定位是提供一个 Agent 执行和调度的框架层。它不像 LangChain 那样侧重 Agent 的构建和工具集成，也不像某些工作流引擎那样侧重 DAG 编排，而是把重心放在了"Agent 作为调度单元"这件事上。

我理解它的核心价值在于：给 Agent 定义了一套类似 Pod Spec 的声明式描述规范，然后提供了一个调度器来解析这些声明并管理 Agent 的生命周期。这意味着你可以用统一的方式描述"这个 Agent 需要什么模型、什么工具、多少并发、什么超时策略、失败后怎么重试"，然后交给调度层去执行。

这个思路的好处是，Agent 的开发者只需要关注 Agent 本身的逻辑，不需要操心它怎么被调度、怎么被监控、怎么被扩缩容。运维团队则可以用一套统一的调度策略管理所有 Agent，而不是每个 Agent 一套部署脚本。

3. AX 调度模型的核心机制拆解

3.1 Agent 描述规范：从 Pod Spec 到 Agent Spec

K8s 里用 YAML 定义 Pod Spec，AX 里对应的概念我称之为 Agent Spec。虽然具体的字段名可能不同，但核心信息维度是相通的。我根据实际做 Agent 编排的经验，整理了一个典型的 Agent 描述应该包含哪些内容：

这个表格不是 AX 的官方文档，而是我根据"一个合格的 Agent 调度系统应该具备什么"推导出来的。实际使用中，你不需要一次性把所有字段都填满，很多有合理的默认值。但理解每个维度的作用，能帮你在遇到问题时快速定位是哪个环节出了岔子。

3.2 调度器的决策逻辑：Agent 被放到哪里执行

Pod 调度器做决策时要考虑节点资源、亲和性规则、污点容忍等一堆因素。Agent 调度器的决策空间不太一样，因为 Agent 的执行环境可能是无服务器函数、可能是常驻进程、也可能是容器。但核心的决策逻辑是类似的：

第一步，解析依赖图。调度器拿到一个任务请求后，首先要搞清楚这个任务涉及哪些 Agent，它们之间的依赖关系是什么。是串行链、并行扇出、还是带条件分支的 DAG？这一步的产出是一个有向无环图，每个节点是一个 Agent 调用。

第二步，资源匹配。对图中每个 Agent 节点，检查当前可用的资源是否满足它的需求。这里的资源包括：模型 API 的速率限制余量、计算节点的 CPU/内存、并发槽位等。如果资源不够，Agent 进入等待队列。

第三步，放置决策。决定每个 Agent 在哪个执行环境上运行。如果两个 Agent 之间有大量数据传输，调度器可能倾向于把它们放在同一台机器上。如果某个 Agent 是计算密集型的，调度器会把它分配到 GPU 节点上。

第四步，执行与监控。Agent 开始执行后，调度器持续监控其状态。超时了触发重试，返回错误了触发降级，正常完成了则推进到下游节点。

这套逻辑听起来跟 Airflow 之类的 DAG 调度器很像，但关键区别在于：Agent 调度器需要处理不确定性。传统 DAG 里每个任务的执行时间是相对可预测的，但 Agent 调用大模型的时间可能从几百毫秒到几十秒不等，返回结果也可能是非确定性的。调度器需要为此设计更灵活的超时策略和重试机制。

3.3 生命周期管理：Agent 的"生老病死"

Pod 有 Pending、Running、Succeeded、Failed 等状态，Agent 也需要类似的状态机。我在实际项目中总结的 Agent 生命周期状态包括：

• Pending：Agent 已被调度但尚未开始执行，可能在等待资源或等待上游依赖完成。
• Initializing：Agent 正在加载模型、初始化工具连接、准备上下文。
• Running：Agent 正在执行推理或工具调用。
• Waiting：Agent 在等待外部事件，比如等待人工审核、等待异步工具返回。
• Succeeded：Agent 正常完成，输出已传递给下游。
• Failed：Agent 执行失败，根据重试策略决定是否重新调度。
• Degraded：Agent 以降级模式运行，比如用更小的模型或跳过某些非关键步骤。

状态之间的转换需要明确的触发条件。比如从 Running 到 Failed 的触发条件可能是：推理超时、工具调用返回错误、输出格式校验不通过。从 Failed 到 Pending 的转换则需要检查重试次数是否超过上限。

这里有个容易踩的坑：Agent 的"失败"和"超时"需要区分对待。超时可能只是模型响应慢，重试一次大概率能成功；但如果是工具调用返回了明确的错误（比如 API Key 失效），重试再多次也没用，应该直接进入降级流程。我在项目里就遇到过因为没区分这两种情况，导致一个失效的 API Key 被重试了十几次，白白浪费了十分钟的情况。

4. 把 AX 跑起来：从零搭建 Agent 调度环境的实操路径

4.1 环境准备中最容易忽略的三个细节

假设你已经决定要尝试 AX 或者类似的 Agent 调度框架，在动手之前，有三件事必须先确认好，否则后面会反复返工。

第一，模型 API 的速率限制和并发能力。这是最容易被低估的瓶颈。很多人在本地测试时用一两个 Agent 跑得好好的，一上生产环境开了十个并发就全部超时。你需要提前搞清楚：你的模型服务商允许的 QPS 是多少？TPM（每分钟 token 数）上限是多少？超过限制后是排队还是直接拒绝？这些参数直接决定了你的调度器能开多大的并发窗口。

第二，Agent 之间的数据传递方式。小数据量（几 KB 的文本）直接通过调度器的上下文传递没问题，但如果 Agent 之间要传递大量数据（比如检索回来的几十个文档），就需要一个共享的存储层。我通常会用 Redis 做中间结果的缓存，Agent 之间传递的是存储键而不是实际数据。这样做的另一个好处是，Agent 失败重试时不需要重新计算上游的结果。

第三，超时和重试的全局策略。不要每个 Agent 单独设置超时，而是定义一个全局的超时预算，然后按比例分配给各个 Agent。比如整个任务必须在 30 秒内完成，那么意图识别给 3 秒、知识检索给 10 秒、回复生成给 15 秒，留 2 秒的缓冲。这样能避免某个 Agent 超时导致整个任务失败。

4.2 定义第一个 Agent Spec：从最简单的开始

我建议从最简单的单 Agent 任务开始，先跑通整个调度链路，再逐步增加复杂度。一个最简的 Agent Spec 大概长这样（以 YAML 为例，具体字段名以实际框架为准）：

agent: name: intent-classifier model: provider: google name: gemini-pro temperature: 0.1 max_tokens: 256 input: schema: type: object properties: user_query: type: string output: schema: type: object properties: intent: type: string enum: [faq, complaint, order, other] resources: max_concurrency: 5 timeout_seconds: 5 retry: max_attempts: 2 backoff: exponential

这个 Spec 定义了一个意图分类 Agent，用 Gemini Pro 模型，温度设成 0.1 是因为分类任务需要确定性输出，max_tokens 设成 256 是因为分类结果很短不需要更多。超时 5 秒，最多重试 2 次。

定义好之后，通过调度器的 CLI 或 API 提交这个 Spec，调度器会创建一个 Agent 实例并开始监听请求。你可以用 curl 发一个测试请求验证链路是否通畅。

4.3 多 Agent 编排：依赖关系的声明与执行

单 Agent 跑通之后，下一步是定义多 Agent 的依赖关系。在 AX 的模型里，这通常通过一个"工作流"或"任务"的声明来实现。我用一个客服场景举例：

workflow: name: customer-service-pipeline steps: - id: classify agent: intent-classifier input: user_query: "{{trigger.user_query}}" - id: retrieve agent: knowledge-retriever depends_on: [classify] condition: "{{classify.output.intent}} == 'faq'" input: query: "{{trigger.user_query}}" - id: generate agent: response-generator depends_on: [retrieve] input: context: "{{retrieve.output.documents}}" query: "{{trigger.user_query}}" - id: escalate agent: human-escalation depends_on: [classify] condition: "{{classify.output.intent}} == 'complaint'"

这个工作流定义了四个步骤：先分类，如果是 FAQ 就走检索加生成，如果是投诉就直接升级到人工。调度器解析这个声明后，会自动处理依赖关系——retrieve 必须等 classify 完成才能开始，generate 必须等 retrieve 完成。

这里的关键设计点是condition 字段。它让工作流具备了条件分支的能力，而不是一条路走到黑。在实际业务中，这种分支逻辑非常常见，没有它的话你就得写一堆 if-else 来手动控制 Agent 的调用。

4.4 验证调度是否正常工作：几个必测的场景

环境搭好之后，不要急着上生产，先跑几个关键场景验证调度器的行为是否符合预期：

场景一：正常链路。发一个 FAQ 类的问题，确认 classify → retrieve → generate 三个 Agent 依次执行，最终返回合理的回复。

场景二：条件分支。发一个投诉类的问题，确认走了 classify → escalate 路径，retrieve 和 generate 没有被触发。

场景三：Agent 超时。人为把 retrieve Agent 的超时设成 1 秒（正常需要 3 秒），确认调度器在超时后触发了重试，重试仍然超时后是否走了降级逻辑。

场景四：并发压力。同时发 20 个请求，观察调度器是否按照 max_concurrency 限制了对模型 API 的并发调用，有没有出现请求被限流的情况。

场景五：Agent 崩溃。手动 kill 掉一个正在执行的 Agent 进程，确认调度器检测到了异常并重新调度了该 Agent。

这五个场景覆盖了调度器最核心的能力。如果都能通过，说明基本链路是可靠的。

5. 实操中踩过的坑与排查思路

5.1 Agent 无限重试导致雪崩

这是我踩过的最严重的一个坑。有一次上线了一个新版本的检索 Agent，代码里有个 bug 导致它在某些输入下会抛异常。调度器的重试策略配置的是"最多重试 5 次"，看起来不多对吧？但问题是，这个 Agent 的调用量很大，每秒有几十个请求进来，每个请求失败后重试 5 次，瞬间就把模型 API 的配额打满了。更糟的是，重试的请求又失败了，继续重试，形成了正反馈循环。

根因分析：重试策略没有区分"可重试错误"和"不可重试错误"。代码 bug 导致的异常属于不可重试错误，重试再多次结果都一样。调度器应该识别这类错误并直接标记为 Failed，而不是傻傻地重试。

修复方案：在 Agent Spec 里增加错误分类配置：

retry: max_attempts: 3 retryable_errors: - TIMEOUT - RATE_LIMIT - NETWORK_ERROR non_retryable_errors: - INVALID_INPUT - AUTH_FAILED - INTERNAL_ERROR

同时增加一个全局的熔断机制：如果某个 Agent 在 1 分钟内的失败率超过 50%，调度器自动暂停该 Agent 的调度，发送告警，等待人工介入。

5.2 上下文传递中的序列化陷阱

Agent 之间传递的上下文数据需要序列化和反序列化。大部分时候这没问题，但当你传递的数据里包含特殊字符、二进制数据或者循环引用时，就会出问题。

我遇到过一个案例：知识检索 Agent 返回的文档里包含了用户上传的 PDF 中的原始字节数据，序列化时因为编码问题导致数据损坏，下游的生成 Agent 拿到了一堆乱码。排查这个问题花了整整一个下午，因为错误信息只显示"生成结果异常"，没有指向数据传递环节。

经验教训：Agent 之间传递的数据应该尽量是纯文本或结构化数据（JSON），避免传递二进制。如果确实需要传递文件，用对象存储的 URL 来引用，而不是把文件内容塞进上下文。另外，在调度器的配置里开启上下文大小限制，超过限制的数据自动转存到外部存储。

5.3 模型版本升级导致的输出格式变化

这个问题比较隐蔽。你的 Agent Spec 里定义了输出 schema，比如要求返回 JSON 格式的{"intent": "faq"}。一切运行正常，直到模型服务商悄悄升级了模型版本，新版本对 prompt 的理解略有不同，有时候会返回{"intent": "FAQ"}（大写）或者{"intent": "faq", "confidence": 0.9}（多了字段）。

如果你的下游 Agent 严格按 schema 解析，遇到大小写不匹配就会失败。这种问题在测试环境很难发现，因为测试环境的模型版本可能还没更新。

应对策略：第一，在 Agent Spec 里锁定模型版本，不要用latest这种浮动标签。第二，输出解析要宽容——大小写不敏感、忽略多余字段、对缺失字段提供默认值。第三，在调度层增加输出校验环节，不符合 schema 的输出触发告警而不是直接失败。

5.4 排查链路：从告警到根因的完整过程

当调度系统出问题时，你需要一套系统的排查方法。我通常按这个顺序来：

1. 看调度器的全局状态面板：有多少 Agent 在运行、多少在等待、多少失败了。如果失败数突然飙升，说明是系统性问题而不是个别请求的问题。
2. 定位失败的 Agent：是哪个 Agent 在失败？是所有的 Agent 都失败还是特定某个？如果是特定的，问题大概率在这个 Agent 本身。
3. 查看该 Agent 的详细日志：错误信息是什么？是超时、是返回错误、还是输出格式不对？错误信息通常会指向具体的原因。
4. 检查上游依赖：如果 Agent 本身没问题，检查它的上游 Agent 是否返回了异常数据。顺着依赖链往上查。
5. 检查外部依赖：模型 API 是否正常？工具调用的第三方服务是否可用？网络是否有抖动？
6. 复现问题：用相同的输入在测试环境复现，确认问题是否稳定出现。如果测试环境无法复现，可能是环境差异导致的。

这套流程看起来简单，但在压力大的时候很容易跳步。我的建议是把排查步骤写成一个 checklist，出问题时照着走，避免遗漏。

6. Agent 调度与 K8s 调度的本质差异

6.1 不确定性：Agent 调度最大的挑战

Pod 调度面对的是一个确定性系统：容器需要多少 CPU、多少内存是明确的，容器的启动时间是可预测的，容器的行为是确定的。Agent 调度面对的是一个充满不确定性的系统。

同一个 Agent，同样的输入，两次调用的结果可能不同（大模型的非确定性）。执行时间可能从 500 毫秒到 30 秒不等。资源消耗也不是固定的——同样长度的输入，模型可能消耗 1000 个 token 也可能消耗 2000 个。

这种不确定性意味着 Agent 调度器不能照搬 K8s 的调度算法。K8s 可以用 bin-packing 算法把 Pod 紧凑地塞进节点，因为 Pod 的资源需求是已知的。Agent 调度器需要更保守的策略，预留更多的资源缓冲，并且要能动态调整。

6.2 有状态 vs 无状态：Agent 的上下文困境

K8s 调度 Pod 时假设 Pod 是无状态的（或者状态被外部化到了 PVC 或数据库）。但 Agent 天然是有状态的——它需要维护对话历史、中间结果、工具调用的上下文。

这给调度带来了额外的约束：你不能随便把一个 Agent 从一个节点迁移到另一个节点，因为它的状态可能还在原来的节点上。解决方案通常有两种：一是把 Agent 的状态外部化到 Redis 或数据库中，让 Agent 本身变成无状态的；二是使用 sticky session，保证同一个会话的请求总是路由到同一个 Agent 实例。

我倾向于第一种方案，虽然实现起来麻烦一些，但它让调度器有了更大的灵活性。第二种方案在 Agent 实例崩溃时会导致会话丢失，用户体验很差。

6.3 成本模型：Token 就是新的 CPU

在 K8s 里，调度器优化的是 CPU 和内存的利用率。在 Agent 调度里，最贵的资源是 token。每次 Agent 调用都在消耗 token，而 token 是直接跟钱挂钩的。

这意味着 Agent 调度器需要把成本作为一个核心的调度维度。比如：当有两个 Agent 都能完成同一个任务时，调度器应该选择 token 消耗更少的那个。当系统负载高时，调度器可以自动降级到更便宜的模型。当任务不紧急时，调度器可以把请求排队到 token 价格较低的时段执行。

这些策略在 K8s 里没有对应物，是 Agent 调度特有的。我在项目里实现过一个简单的成本优化策略：给每个 Agent 标记一个"成本等级"，调度器在资源紧张时优先调度低成本等级的 Agent，高成本的 Agent 进入等待队列。效果还不错，高峰期能省下大概 30% 的 token 开销。

7. 从单机到集群：Agent 调度的规模化路径

7.1 什么规模需要引入调度层

不是所有项目都需要 Agent 调度层。我的经验是，当你的系统满足以下任意两个条件时，就该考虑引入调度层了：

• Agent 数量超过 5 个，且它们之间有复杂的依赖关系
• 日均 Agent 调用次数超过 10000 次
• 需要同时使用多个模型服务商，且需要在它们之间做负载均衡
• 有明确的 SLA 要求，比如 99% 的请求必须在 10 秒内完成
• 需要精细的成本控制和资源配额管理

如果只是两三个 Agent 串行调用，用一个简单的 Python 脚本加 asyncio 就够了，引入调度层反而增加复杂度。

7.2 渐进式演进：从脚本到调度层的平滑过渡

我推荐的演进路径是这样的：

阶段一：单体脚本。所有 Agent 写在一个 Python 文件里，用函数调用串联。这个阶段的目标是验证业务逻辑，不需要考虑调度。

阶段二：模块化 + 简单编排。把每个 Agent 拆成独立的模块，用一个简单的编排器（比如一个 YAML 配置加一个执行引擎）来管理调用关系。这个阶段开始有了 Agent Spec 的雏形。

阶段三：引入调度层。当 Agent 数量增多、需要动态扩缩容、需要多租户隔离时，引入正式的调度框架。这个阶段需要把之前的编排逻辑迁移到调度层的声明式配置中。

阶段四：多集群调度。当单集群的资源不够用，或者需要在多个区域部署以满足延迟要求时，引入跨集群的调度层。这个阶段的复杂度会大幅上升，需要仔细设计数据同步和故障转移策略。

大部分项目停留在阶段二或阶段三就够了。阶段四通常是大型企业的需求。

7.3 多租户场景下的隔离策略

如果你的 Agent 调度平台需要服务多个团队或业务线，隔离就是一个必须解决的问题。隔离的维度包括：

• 资源隔离：每个租户有独立的 token 配额和并发上限，一个租户的流量高峰不能影响其他租户。
• 数据隔离：租户 A 的 Agent 不能访问租户 B 的数据，上下文传递需要严格的权限校验。
• 故障隔离：租户 A 的 Agent 崩溃不能导致租户 B 的 Agent 受影响，需要独立的执行环境或至少独立的进程空间。
• 可观测性隔离：每个租户只能看到自己的 Agent 的运行状态和日志。

在 K8s 里，这些隔离通过 Namespace、ResourceQuota、NetworkPolicy 等机制实现。Agent 调度层需要提供类似的机制。我在项目里用的是一个简化的模型：每个租户一个独立的调度队列，队列之间按权重分配资源，跨队列的 Agent 调用需要显式授权。

8. 一些实战中的配置建议和参数参考

8.1 超时参数的设置逻辑

超时设置太短会导致正常请求被误杀，太长会导致故障时资源被长时间占用。我的经验值是这样的：

这些数字不是绝对的，需要根据你的实际模型和业务场景调整。设置好之后，一定要用真实流量压测验证，观察 P99 延迟是否在超时阈值之内。

8.2 重试策略的黄金法则

重试不是万能的，错误的重试策略比不重试更糟糕。我的建议：

• 最多重试 2-3 次，超过这个次数说明问题不是偶发的，重试解决不了。
• 使用指数退避，第一次重试等 1 秒，第二次等 2 秒，第三次等 4 秒。避免瞬间大量重试打垮下游。
• 区分错误类型，只对可重试的错误进行重试（超时、限流、网络抖动），对不可重试的错误（参数错误、认证失败）直接失败。
• 设置重试预算，整个任务的重试次数不超过某个上限，避免一个任务无限重试占用资源。

8.3 监控指标：你需要盯住哪些数字

Agent 调度系统的监控指标应该包括：

• 调度延迟：从请求进入到 Agent 开始执行的时间，反映了调度器的决策速度。
• 执行延迟：Agent 从开始执行到完成的时间，按 Agent 类型分别统计。
• 成功率：成功完成的 Agent 调用占比，按 Agent 类型和错误类型分别统计。
• 重试率：触发重试的调用占比，突然升高说明有系统性问题。
• Token 消耗：按 Agent、按租户、按时间段统计 token 使用量，用于成本核算。
• 队列深度：等待调度的 Agent 数量，反映了系统的负载压力。
• 资源利用率：模型 API 的配额使用率、计算节点的 CPU/内存使用率。

这些指标应该接入统一的监控面板，设置合理的告警阈值。我的经验是，调度延迟和重试率是最灵敏的两个指标，它们通常在用户感知到问题之前就会发出信号。

8.4 一个容易忽略的细节：Agent 的冷启动

如果你的 Agent 需要加载模型权重或建立数据库连接，冷启动时间可能很长。调度器在扩缩容时需要考虑到这一点——缩容太激进会导致后续请求触发冷启动，延迟飙升。

解决方案是保持一个最小实例数（比如 2 个），并且设置一个"冷却期"——缩容后如果短时间内又有请求进来，快速恢复到之前的规模。这个策略在 K8s 的 HPA 里叫 stabilization window，Agent 调度器也需要类似的机制。

9. 我对 Agent 调度这件事的一些个人判断

折腾了这么多 Agent 编排和调度的事情，我最大的体会是：调度层的价值不在于它能让 Agent 跑起来，而在于它能让 Agent 在出问题时优雅地失败。一个没有调度层的系统，Agent 挂了就是挂了，用户看到的是错误页面。一个有调度层的系统，Agent 挂了可以重试、可以降级、可以熔断，用户可能根本感知不到。

Google 开源 AX 这件事，我觉得信号意义大于实际意义。它说明 Agent 调度正在从一个"每个团队自己造轮子"的阶段，走向"有标准化框架可用"的阶段。这对整个行业来说是好事——就像 K8s 统一了容器编排一样，Agent 调度也需要一个事实标准，让大家不用重复造轮子。

但我也要泼一盆冷水：Agent 调度比容器调度复杂得多，因为不确定性太大了。K8s 花了几年时间才稳定下来，Agent 调度框架的成熟可能也需要类似的时间。现在入局的话，要做好踩坑的准备，但也要看到，早期积累的经验在后期会非常有价值。

如果你现在正在做 Agent 相关的项目，我的建议是：不要等一个完美的调度框架出现，先用简单的编排逻辑把业务跑起来，同时把 Agent 的接口定义清楚（输入输出 schema、超时策略、重试策略），这样将来迁移到正式的调度框架时，成本会低很多。接口定义清楚了，换调度层就是换一个执行引擎的事，Agent 本身的代码不需要大改。

最后分享一个我在实际项目中验证过的小技巧：给每个 Agent 的响应里加一个_meta字段，记录这次调用的模型版本、token 消耗、执行时间。这个字段不参与业务逻辑，但在排查问题和做成本分析时非常有用。调度层可以自动收集这些元数据，生成报表。这个做法看起来不起眼，但当你需要向老板解释"为什么这个月 token 费用涨了 50%"的时候，你会感谢自己当初加了这个字段。