Agent 调度这件事过去一年我一直在跟。从最早自己写脚本轮询任务队列到后来用各种编排框架把 Agent 塞进工作流里踩的坑不算少。核心痛点其实一直没变Agent 是有状态的、长生命周期的、资源占用不确定的但我们却一直用无状态服务的思路去管它。Google 这次开源的 AX最吸引我的一个点就是它把 Agent 的调度抽象拉到了和 Pod 同一个层级——不是在 Pod 里跑一个 Agent 进程而是Agent 本身就是被调度的基本单元。这个思路转变值得好好拆一拆。1. 为什么 Agent 调度不能照搬微服务的路子1.1 Agent 和普通微服务在调度需求上的本质差异先说一个我自己的真实经历。去年我做一个多 Agent 协作的内容生成系统三个 Agent 分别负责检索、写作、审核。一开始我用的是最朴素的方式——每个 Agent 打包成一个 HTTP 服务扔进容器编排平台用 Service 做负载均衡。跑了两周就出问题了。问题出在哪普通微服务的调度假设是请求来了就处理处理完就释放实例之间完全对等随时可以扩缩容。但 Agent 不是这样的。一个正在执行多轮推理的 Agent它的上下文是有状态的中途换一个实例接手上下文就断了。更麻烦的是Agent 的执行时间波动极大——简单任务可能几百毫秒复杂任务可能跑几分钟甚至更久。你用微服务那套基于 QPS 的自动扩缩容策略根本对不上。AX 的设计思路正是冲着这个差异去的。它把 Agent 的生命周期管理、状态保持、资源配额这些维度从应用层自己想办法提升到了调度层原生支持。这就好比以前你在 Pod 里跑一个数据库得自己搞主从、自己搞故障转移后来有了 Operator这些东西变成了调度平台的一等公民。AX 对 Agent 做的事情逻辑上是一样的。1.2 像 Pod 一样被调度到底意味着什么这句话拆开来看包含三层含义。第一层是声明式描述。你用 YAML 描述一个 Agent 需要什么——需要多少算力、需要访问哪些工具、需要挂载什么记忆存储、期望的副本数是多少。调度器读这个描述负责把它变成实际运行的实例。你不需要写代码去启动一个 Agent你只需要声明我要一个具备某种能力的 Agent。第二层是生命周期托管。Agent 挂了自动重启Agent 卡死了自动超时回收Agent 需要升级时滚动替换。这些在 Pod 层面已经非常成熟的能力被平移到了 Agent 层面。第三层是资源感知调度。这是最有价值的一层。Agent 对资源的需求和普通服务不一样——它可能突然需要大量显存做推理也可能长时间处于等待外部 API 返回的空闲状态。AX 的调度器需要理解这种脉冲式的资源曲线而不是简单地按 CPU/内存的静态配额来分配。注意把 Agent 当 Pod 调度不等于 Agent 就是 Pod。Agent 的调度单元里封装了更多语义——比如工具调用的权限边界、记忆的持久化策略、多 Agent 之间的通信拓扑。这些是 Pod 模型里没有的AX 在 Pod 的基础上做了扩展。1.3 从编排到调度的认知升级我观察到很多团队在做 Agent 系统时第一反应是找一个编排框架——把 Agent 当成工作流里的一个节点用 DAG 来描述执行顺序。这个思路在简单场景下能用但一旦 Agent 数量上去、交互关系变复杂DAG 就变成了意大利面条。AX 带来的认知升级是不要试图在应用层解决调度问题。编排框架擅长的是定义执行顺序而调度器擅长的是在资源约束下决定谁在什么时候在哪里跑。这两件事应该分开。Agent 之间的协作逻辑用编排来描述Agent 实例的放置和伸缩用调度器来管。各司其职系统才不会被自己的复杂度压垮。2. AX 的调度模型拆解从声明到运行2.1 Agent 描述文件里到底该写什么虽然 AX 的具体 API 还在演进但基于我对同类系统的实践一个 Agent 的声明式描述通常需要包含以下几类信息。我把它整理成了一张表方便对照理解。描述维度典型字段作用说明身份标识name, namespace, labels唯一标识 Agent支持按标签做批量调度策略能力声明capabilities, tools声明这个 Agent 能调用哪些工具、具备哪些技能资源需求cpu, memory, accelerator声明算力需求支持脉冲式资源的峰值声明状态存储memoryVolume, checkpointPolicy指定记忆持久化的位置和检查点策略调度约束affinity, priority, maxConcurrency控制 Agent 之间的亲和性、优先级和并发上限生命周期timeout, retryPolicy, ttl定义超时、重试和存活时间这里我想特别说一下能力声明这个字段。在微服务里你声明的是我暴露什么接口在 AX 里你声明的是我具备什么能力。这个区别很微妙但很重要。接口是固定的能力是可以组合的。调度器可以根据能力声明自动把需要某种能力的任务路由到对应的 Agent 上而不需要你手动配置路由规则。2.2 调度器如何决定一个 Agent 该放在哪调度决策的核心是一个多目标优化问题。我用一个简化模型来说明。假设集群里有 N 个节点每个节点有可用的 CPU、内存、加速器资源。现在有一个 Agent 请求要调度它声明了资源需求 R。调度器需要从满足 R 的节点集合中选出一个最优的节点。什么叫最优不同策略下定义不同资源利用率优先选剩余资源最少的节点把负载压实留出大块空闲资源给未来的大 Agent。性能优先选网络延迟最低、加速器性能最好的节点适合对延迟敏感的 Agent。成本优先选单位算力成本最低的节点适合批处理类的 Agent。亲和性优先选和它需要通信的其他 Agent 在同一节点或同一机架的节点减少跨节点通信开销。AX 的调度器据我理解是支持策略组合的你可以给不同的 Agent 打上不同的调度策略标签。这比一刀切的调度器要灵活得多。2.3 状态保持Agent 调度里最容易被低估的难题我见过太多团队在 Agent 调度上翻车翻车点几乎都集中在状态保持上。普通 Pod 是无状态的调度器可以随意把它从一个节点挪到另一个节点。但 Agent 不行。一个正在执行任务的 Agent它的上下文、它的中间结果、它和外部工具的会话状态都是绑定的。你把它挪走这些状态要么丢失要么需要复杂的迁移逻辑。AX 对这个问题的处理思路我推测是检查点加恢复的模式。Agent 在关键节点把自己的状态写入持久化存储调度器在需要迁移时从最近的检查点恢复。这个模式在流处理系统里很成熟搬到 Agent 场景下同样适用。实操中有一个关键决策检查点的频率。太频繁写入开销大影响 Agent 执行效率太稀疏故障恢复时丢失的进度多。我的经验是把检查点绑定在工具调用完成这个事件上比较合理——因为工具调用通常是一个自然的边界状态相对稳定而且工具调用本身就有网络开销多一次状态写入的边际成本不高。2.4 多 Agent 协作时的调度拓扑单个 Agent 的调度相对简单难的是多个 Agent 协作时的调度。这里有两种典型拓扑。一种是中心化拓扑有一个主 Agent 负责任务分解和结果汇总多个从 Agent 负责执行子任务。调度器需要保证主 Agent 和从 Agent 之间的通信延迟足够低通常会把它们调度到同一节点或同一可用区。另一种是去中心化拓扑Agent 之间是对等关系通过消息传递协作。这种拓扑下调度器更关注的是整体负载均衡而不是特定 Agent 之间的亲和性。AX 对这两种拓扑应该都有支持具体用哪种取决于你的业务场景。我的建议是如果任务分解逻辑复杂用中心化如果 Agent 数量多且交互模式不固定用去中心化。不要为了追求架构先进而强行去中心化中心化在大多数场景下更可控。3. 把 AX 跑起来环境准备与第一个 Agent3.1 集群侧的前置条件在部署 AX 之前你需要一个可用的容器编排集群。这里不展开讲集群怎么搭假设你已经有了。需要确认的几件事集群版本要足够新因为 AX 可能用到了较新的调度器扩展接口。如果 Agent 需要 GPU节点上要装好对应的设备插件。网络插件要支持自定义的调度策略某些老旧的网络方案可能不兼容。存储类要提前配好Agent 的检查点需要持久化存储。我踩过的一个坑是存储类的访问模式。Agent 的检查点写入通常是单节点写入、多节点读取的模式如果你用的是只支持单节点读写的存储类迁移时会失败。建议用支持 ReadWriteMany 的存储方案。3.2 安装 AX 组件安装过程本身不复杂但有几个细节值得注意。AX 通常包含三个核心组件调度器扩展、Agent 运行时、控制面 API。调度器扩展需要和集群原有的调度器协同工作安装时要确认版本兼容性。# 假设 AX 提供了 helm chart helm repo add ax-repo https://example.com/ax-charts helm repo update # 安装前先看看默认 values确认调度器配置 helm show values ax-repo/ax ax-values.yaml # 重点关注 scheduler 相关的配置项 # 比如是否启用抢占、是否启用亲和性调度安装完成后用kubectl get pods -n ax-system确认组件都跑起来了。如果调度器扩展没起来后面所有 Agent 都会卡在 Pending 状态。3.3 写第一个 Agent 描述文件下面是一个我根据常见实践整理的 Agent 描述文件示例。字段名可能和 AX 实际的有出入但结构逻辑是通用的。apiVersion: ax.example.com/v1 kind: Agent metadata: name: research-agent labels: capability: retrieval tier: backend spec: # 能力声明 capabilities: - web-search - document-parse - summarize # 资源需求 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi # 状态存储 memory: volumeName: agent-memory checkpoint: trigger: on-tool-call maxCheckpoints: 10 # 调度约束 scheduling: strategy: balanced affinity: agentAffinity: - matchLabel: capability: writing topology: same-node # 生命周期 lifecycle: timeout: 300s retryPolicy: maxRetries: 3 backoff: exponential这个文件里我觉得最值得琢磨的是scheduling.strategy和affinity这两块。strategy: balanced表示用均衡策略调度器会在资源利用率和性能之间取一个折中。affinity则声明了这个检索 Agent 希望和写作 Agent 调度到同一节点减少它们之间的通信延迟。3.4 提交并观察调度过程提交之后用kubectl get agents查看状态。你会看到 Agent 从 Pending 变成 Scheduling 再变成 Running。如果卡在 Pending用kubectl describe agent research-agent看事件通常能看到调度失败的原因。我遇到过的调度失败原因主要有三类资源不足、亲和性冲突、存储卷挂载失败。资源不足最好解决加节点或者调低资源声明就行。亲和性冲突比较隐蔽往往是因为两个 Agent 互相声明了亲和但集群拓扑满足不了。存储卷挂载失败通常是存储类配置问题。提示第一次跑的时候建议先把亲和性约束去掉确认基础调度能通再逐步加上约束。这样出问题时容易定位是基础调度的问题还是约束的问题。4. 调度策略调优从能跑到跑得好4.1 资源声明的艺术请求值和限制值怎么定资源声明是调度器做决策的依据声明得不准调度质量就无从谈起。我的经验是分三步走。第一步先跑一批样本任务采集实际资源曲线。不要凭感觉写资源声明。用一个监控工具把 Agent 执行期间的 CPU、内存、显存曲线记录下来。你会发现 Agent 的资源曲线和普通服务完全不同——它有明显的峰值和低谷。第二步请求值按 P50 定限制值按 P99 定。请求值是调度器用来做放置决策的定得太高会导致资源浪费定得太低会导致节点过载。按 P50 定请求值意味着调度器按典型负载来分配资源。限制值按 P99 定是为了防止个别任务把节点资源吃光。第三步定期回顾和调整。Agent 的行为会随着模型更新、工具变化而改变资源曲线也会变。建议每个月回顾一次资源声明的准确性。4.2 亲和性与反亲和性什么时候该让 Agent 靠在一起亲和性策略是一把双刃剑。用得好能显著降低通信延迟用不好会导致调度死锁。我总结了一个简单的判断规则需要频繁通信的 Agent用亲和性。比如主 Agent 和它的直接下属 Agent它们之间的消息传递频率高放在同一节点能省掉大量网络开销。互相竞争的 Agent用反亲和性。比如两个都需要大量显存的 Agent放在同一节点会互相抢资源不如分开。无直接交互的 Agent不加约束。让调度器自由发挥通常能得到更好的整体利用率。有一个坑我要特别提醒亲和性约束不要形成环。A 亲和 BB 亲和 CC 又亲和 A这种环会导致调度器无法找到满足所有约束的放置方案。AX 的调度器应该能检测到这种环并报错但最好在设计阶段就避免。4.3 优先级与抢占让关键 Agent 先跑在生产环境里不是所有 Agent 都同等重要。用户直接触发的 Agent 比后台批处理的 Agent 优先级高这是常识。AX 的优先级和抢占机制就是为这个场景设计的。优先级用整数表示数值越大优先级越高。当一个高优先级 Agent 因为资源不足无法调度时调度器会尝试驱逐一些低优先级的 Agent 来腾出资源。这个机制很强大但也很危险——如果优先级设置不当可能导致低优先级 Agent 被反复驱逐永远跑不完。我的建议是优先级层级不要超过三级。比如 P0 是用户交互类P1 是准实时类P2 是批处理类。层级太多调度决策会变得难以预测。另外给批处理类 Agent 设置一个最小存活时间防止它刚启动就被驱逐。4.4 监控调度质量哪些指标值得盯调度质量不能靠感觉要靠指标。我日常盯的指标有这么几个指标名称含义健康范围参考调度延迟从 Agent 提交到开始运行的时间P95 小于 5 秒调度失败率因资源或约束无法调度的比例小于 1%节点资源碎片率节点上无法被利用的资源占比小于 15%抢占次数单位时间内发生的抢占事件数越低越好突增需排查检查点恢复成功率从检查点恢复的成功比例大于 99%这些指标里我最看重的是节点资源碎片率。碎片率高说明调度策略过于保守资源没被充分利用。碎片率低但调度失败率高说明策略过于激进节点过载了。两者要平衡着看。5. 那些文档里不会写的踩坑记录5.1 Agent 启动风暴一次让我半夜爬起来的事故有一次我们做了一次批量任务一次性提交了 200 个 Agent。结果调度器瞬间被压垮整个集群的调度延迟从秒级飙升到分钟级。更糟的是已经运行的 Agent 因为调度器无响应健康检查开始失败触发了连锁重启。事后复盘根因是没有做提交限流。调度器再强也有处理能力的上限。200 个 Agent 同时涌入调度队列被打满正常的健康检查请求都排不进去。解决方案是在提交侧加一个令牌桶限流器控制 Agent 的提交速率。同时给调度器配置一个队列长度上限超过上限的请求直接拒绝而不是无限排队。这个教训让我明白调度系统的稳定性一半靠调度器本身一半靠上游的流量控制。5.2 检查点写入把存储打爆另一个坑和检查点有关。我们有个 Agent 执行时间特别长检查点策略设的是每完成一次工具调用就写一次。结果这个 Agent 在一次执行中调用了上百次工具写入了上百个检查点把存储卷写满了。修复方案有两个层面。一是在 Agent 描述里加上maxCheckpoints限制超过数量的旧检查点自动清理。二是在存储侧设置配额和告警快满的时候提前通知。这两个措施缺一不可——前者防止单个 Agent 写爆后者防止多个 Agent 合起来写爆。5.3 亲和性配置导致的大面积 Pending前面提到过亲和性成环的问题我实际遇到过。当时我们给五个 Agent 配了链式亲和A 亲和 BB 亲和 CC 亲和 DD 亲和 EE 又亲和 A。在小集群上测试时没问题因为所有 Agent 都能调度到同一节点。上了大集群反而出问题了——大集群的节点多调度器倾向于把 Agent 分散到不同节点但亲和性又要求它们在一起两个目标冲突导致部分 Agent 永远 Pending。这个问题的教训是亲和性约束在小集群上测试通过不代表在大集群上没问题。集群规模越大调度器的自由度越高约束冲突的可能性也越大。测试时要用和生产同等规模的集群或者至少在测试环境里模拟大规模节点。5.4 版本升级时的 Agent 兼容性AX 本身在快速迭代升级 AX 版本时已经运行的 Agent 可能不兼容新版本。我们有一次升级后发现旧版本创建的 Agent 无法被新版本调度器识别全部变成了孤儿。应对策略是升级前先确认 Agent API 版本的兼容性。如果 API 有破坏性变更需要先把现有 Agent 迁移到新 API 版本再升级调度器。AX 应该提供了版本转换工具升级前仔细读 release notes不要盲目升级。6. 从 AX 看 Agent 基础设施的演进方向6.1 调度层正在成为 Agent 系统的核心竞争力过去大家做 Agent注意力都在模型和提示词上。但随着 Agent 数量增多、任务变复杂调度层的能力开始成为瓶颈。一个调度得好的系统能用同样的硬件跑出两倍的任务吞吐一个调度得差的系统硬件再多也白搭。AX 的出现说明这个判断正在成为行业共识。把 Agent 调度抽象成和 Pod 调度同级的原语意味着 Agent 基础设施正在从手工作坊走向工业化。这个趋势对做 Agent 应用的团队是好事——你不需要自己造调度轮子了可以把精力放在业务逻辑上。6.2 多 Agent 协作会倒逼调度语义的丰富现在的调度语义主要还是围绕单 Agent 的资源需求设计的。但多 Agent 协作场景下调度器需要理解的东西更多Agent 之间的依赖关系、通信模式、数据流向、失败传播路径。我推测 AX 后续会在这方面做扩展。比如支持Agent 组的概念把一组协作紧密的 Agent 作为一个调度单元整体做放置决策。再比如支持数据亲和性把需要访问同一份数据的 Agent 调度到离数据近的地方。6.3 对普通开发者的实际影响如果你只是写单个 AgentAX 对你的直接影响不大。但如果你在做多 Agent 系统或者你的 Agent 需要长时间运行、需要弹性伸缩那 AX 值得认真研究。我的建议是先用起来再深入。找一个非关键的业务场景把 Agent 迁移到 AX 上跑一跑感受一下声明式调度带来的便利。跑通之后再逐步把关键业务迁过去。不要一上来就全量迁移调度系统的坑需要在实践中一个个踩过去。7. 我个人的几条实操建议第一从简单开始逐步加约束。先把 Agent 跑起来确认基础调度没问题再一个一个加上亲和性、优先级、检查点这些高级特性。每加一个特性观察一段时间确认稳定了再加下一个。第二资源声明宁松勿紧。请求值定低了节点会过载影响所有 Agent定高了浪费一些资源但系统稳定。在不确定的时候宁可定高一点。等采集到足够的监控数据再逐步收紧。第三给调度器留余量。不要让集群的资源利用率长期跑在 90% 以上。调度器需要一定的空闲资源来做腾挪资源太满调度失败率和抢占次数都会飙升。我的经验是把目标利用率控制在 70% 到 80% 之间。第四监控要覆盖调度链路。不要只监控 Agent 本身的运行状态还要监控调度器的队列长度、调度延迟、失败原因分布。调度链路上的问题往往比 Agent 本身的问题更难排查。第五定期做故障演练。主动杀掉一些 Agent看看检查点恢复是否正常主动制造资源紧张看看抢占机制是否符合预期。调度系统的可靠性是练出来的不是配出来的。这套东西我还在持续摸索AX 本身也在快速演进。但有一点我越来越确定Agent 调度这件事值得当成一门专门的学问来对待。它不像写提示词那样有即时反馈但它的影响是系统性的——调度做得好整个 Agent 系统的天花板都会高很多。
