1. 从 Pod 到 Agent一次调度范式的迁移Google 这次开源 AX 项目在圈子里讨论度不低。我第一时间把仓库拉下来跑了一遍又翻了翻它的设计文档越看越觉得有意思——它做的事情本质上是把 Kubernetes 里那套已经被验证了十年的 Pod 调度模型搬到了 Agent 编排这个新战场上。先说清楚 AX 是什么。AX 是 Google 开源的一个 Agent 执行与调度框架核心主张就一句话让 Agent 像 Pod 一样被声明、被调度、被观测。你写一份类似 Pod Spec 的 YAML描述这个 Agent 要什么模型、要多少并发、依赖哪些工具、超时多久、失败怎么重试然后交给 AX 的调度层它负责把 Agent 分配到合适的执行节点上跑起来。这件事解决什么问题现在做 Agent 开发的人应该都有体会单个 Agent 跑通不难难的是几十上百个 Agent 同时在线还要管它们的生命周期、资源占用、失败重试、依赖编排。大家现在的做法五花八门有的用 Airflow 硬套有的自己写个任务队列有的干脆用 Celery 凑合。这些方案能用但都不原生——它们不理解 Agent 这种长时运行、需要外部工具、可能反复调用大模型、状态需要保持的负载特征。AX 的价值就在于它把 Agent 当成一等公民来对待。适合谁来参考我觉得三类人最该看一是正在做 Agent 平台化、需要管理大量 Agent 实例的团队二是熟悉 K8s 生态、想把这套心智模型迁移到 AI 负载上的工程师三是做多 Agent 协作编排、被调度问题折磨过的开发者。哪怕你暂时不用 AX它这套声明式 Agent的思路也值得借鉴。下面我按自己的理解把 AX 的设计思路、核心机制、实操要点和踩坑经验完整拆一遍。2. AX 的整体设计思路与方案选型2.1 为什么是像 Pod 一样而不是像函数一样这是理解 AX 的第一个关键点。市面上大多数 Agent 框架走的是函数调用路线——你定义一个函数里面写 Agent 的逻辑调用它就执行。这种模式适合单次、短时、无状态的任务但 Agent 的真实负载恰恰相反。一个典型的 Agent 任务可能是这样的接收用户请求调用大模型规划步骤然后调用三四个外部工具中间可能等待人工确认最后汇总结果。整个过程可能持续几分钟甚至几小时中间会占用模型配额、网络连接、内存里的对话上下文。这跟一个 Pod 的生命周期像不像太像了。Pod 模型的核心优势在于三点声明式描述、调度器解耦、生命周期可观测。AX 把这三条都继承了过来。你不再写我要先调 A 再调 B的命令式代码而是声明这个 Agent 需要这些能力调度器去决定怎么满足。这个转变看着小实际影响很大——它让 Agent 的编排从写代码变成了写配置运维和开发的分工一下子就清晰了。我个人的判断是这个选型背后有个很现实的考量Google 内部有大量 K8s 的积累把 Agent 塞进已有的调度心智模型里学习成本和迁移成本都最低。对使用者来说如果你团队里有人懂 K8s上手 AX 会非常快。2.2 调度层与执行层的分离设计AX 在架构上做了明确的分层这一点值得单独说。它把系统拆成**调度层Scheduler和执行层Executor**两大部分中间通过一套声明式的 Spec 通信。调度层负责什么接收 Agent 的声明做资源匹配决定这个 Agent 该在哪个执行节点上跑处理优先级、抢占、重试这些调度逻辑。执行层负责什么真正把 Agent 跑起来管理它的运行时状态调用模型和工具上报心跳和结果。这种分离的好处跟 K8s 里 kube-scheduler 和 kubelet 的关系一模一样。调度层可以独立演进执行层可以水平扩展两者通过标准接口对接。实际部署时你可以只跑一个调度器挂多个执行节点也可以把执行节点分布到不同机器上按能力打标签。提示如果你只是想本地跑通 demoAX 提供了单进程模式调度和执行在一个进程里省去部署麻烦。但生产环境一定要拆开否则调度层会成为单点。2.3 与现有 Agent 框架的定位差异这里得说清楚 AX 和 LangChain、AutoGen 这些框架的区别不然容易混淆。LangChain 这类框架解决的是Agent 内部逻辑怎么写比如怎么串 prompt、怎么调工具、怎么管理记忆。AX 解决的是Agent 作为一个整体怎么被管理和调度。打个比方LangChain 是教你写一个函数的语法AX 是管这些函数怎么在集群里跑、谁先跑、跑挂了怎么办。两者不冲突甚至可以叠加使用——你用 LangChain 写 Agent 的内部逻辑用 AX 管它的部署和调度。我实测下来AX 对底层 Agent 实现是相对开放的它不强制你用某个特定框架。只要你的 Agent 能暴露成它约定的接口就能被调度。这个设计挺聪明避免了跟现有生态正面竞争。3. 核心机制拆解与实操要点3.1 Agent Spec声明式描述的关键字段AX 的核心是一份 Agent Spec格式上借鉴了 Pod Spec 的写法。我把它最关键的几个字段拆开讲这些都是实操中必须搞明白的。资源声明部分你需要告诉调度器这个 Agent 要什么。跟 Pod 要 CPU 内存不同Agent 要的是模型配额、并发槽位、工具访问权限。比如modelQuota字段声明这个 Agent 需要哪个模型的多少调用额度concurrency声明它能同时处理几个请求。这些字段直接决定调度器能不能把它安排下去。生命周期部分包括timeout、retryPolicy、gracefulShutdown。Agent 任务经常超时所以超时策略特别重要。AX 支持分级超时——单步超时、整体超时分开配。重试策略也做了细化可以指定哪些错误类型重试、重试几次、退避算法是什么。依赖声明部分这是 Agent 特有的。一个 Agent 可能依赖某个工具服务、某个知识库、某个上游 Agent 的输出。AX 用dependsOn字段表达这些依赖调度器会做拓扑排序保证依赖先就绪。apiVersion: ax/v1 kind: Agent metadata: name: research-agent spec: modelQuota: model: gemini-pro tokensPerMinute: 10000 concurrency: 4 timeout: step: 60s total: 30m retryPolicy: maxAttempts: 3 backoff: exponential dependsOn: - tool: web-search - agent: planner-agent这份 Spec 的写法懂 K8s 的人看一眼就明白。不懂的人把它当成一份给调度器看的说明书就行——你告诉它你要什么它负责满足。3.2 调度策略从资源匹配到亲和性调度器拿到 Spec 之后怎么决定把 Agent 放到哪个执行节点AX 的调度逻辑分两个阶段跟 K8s 的 filter-then-score 模式一致。第一阶段是过滤把不满足硬性条件的节点筛掉。比如节点上没有你要的模型访问权限或者剩余并发槽位不够直接排除。第二阶段是打分对剩下的节点按亲和性、负载均衡、数据本地性等维度排序选最高分的。这里有个 Agent 特有的调度维度值得说模型亲和性。如果某个执行节点本地缓存了某个模型的权重或者跟模型服务在同一区域调度到那里延迟会低很多。AX 支持给节点打标签然后在 Spec 里声明亲和性偏好。spec: affinity: modelAffinity: preferred: local-cache nodeAffinity: requiredLabels: region: cn-north实操中我建议初期别把亲和性配得太复杂先用默认的负载均衡策略跑起来观察瓶颈在哪再针对性加亲和性规则。一上来就配一堆约束很容易出现没有节点满足条件导致 Agent 一直 pending 的情况。3.3 执行层的运行时管理执行层拿到调度结果后负责把 Agent 真正跑起来。这部分有几个实操要点。状态保持。Agent 跟无状态函数最大的区别是它有状态——对话历史、中间结果、工具调用记录。AX 的执行层会为每个 Agent 实例维护一个运行时上下文支持持久化到外部存储。如果你的 Agent 需要跨重启保持状态得在 Spec 里声明statePersistence配置。心跳与健康检查。执行层会定期向调度层上报心跳报告 Agent 的运行状态。如果心跳断了调度层会认为这个实例失联触发重调度。这里要注意Agent 任务可能长时间在等模型响应心跳机制得跟业务逻辑解耦别让一个慢请求把整个实例判死。优雅退出。当调度层决定回收一个 Agent 实例时会先发信号让它处理完手头的请求再退出。这个gracefulShutdown的时长要按你 Agent 的最长单步耗时来配配短了会丢任务。注意执行层的并发槽位是硬限制。如果你声明concurrency: 4但实际同时来了 10 个请求多出来的会排队。排队队列的长度也要在 Spec 里配否则可能无限堆积把内存撑爆。4. 完整实操流程从零跑通一个 AX Agent4.1 环境准备与依赖安装我按自己的实操顺序讲一遍你可以跟着走。首先需要 Python 3.10 以上AX 目前对 3.9 支持不完整。然后装 AX 的 SDKpip install ax-agent-sdk如果你要跑完整的调度执行分离模式还需要一个可用的模型服务端点。AX 本身不绑定特定模型但需要你配置模型访问凭证。我测试时用的是本地部署的模型服务配置方式是在环境变量里指定端点export AX_MODEL_ENDPOINThttp://localhost:8080/v1 export AX_MODEL_API_KEYyour-key单进程模式最简单一条命令就能起ax run --mode standalone --spec ./research-agent.yaml这条命令会启动一个内嵌的调度器和执行器把你的 Agent 跑起来。适合开发调试阶段用。4.2 编写第一个 Agent Spec我拿一个资料检索 Agent举例它的工作是接收查询、调用搜索工具、汇总结果。Spec 这样写apiVersion: ax/v1 kind: Agent metadata: name: research-agent namespace: default spec: runtime: image: ax-python:3.10 entrypoint: research_agent.main:run modelQuota: model: gemini-pro tokensPerMinute: 10000 concurrency: 4 timeout: step: 60s total: 30m retryPolicy: maxAttempts: 3 backoff: exponential retryOn: - model_timeout - tool_error tools: - name: web-search endpoint: http://search-svc:9000 statePersistence: enabled: true backend: redis ttl: 24h几个字段的实操说明runtime.entrypoint指向你 Agent 的入口函数格式是模块:函数。tools里声明的工具执行层会注入到 Agent 的运行时环境里你在代码里直接按名字调用就行。statePersistence开了之后Agent 的上下文会自动存到 Redis重启不丢。4.3 提交与观测 Agent 运行状态Spec 写好后提交给调度器ax apply -f research-agent.yaml提交后可以用ax get agents看状态。状态流转跟 Pod 很像Pending表示在等调度Running表示在跑Succeeded表示正常结束Failed表示失败。想看详情用ax describe agent research-agent会列出调度决策、资源占用、最近的事件。ax get agents NAME STATUS NODE AGE research-agent Running node-01 2m如果卡在 Pending八成是资源不满足。用ax describe看 Events 部分会告诉你为什么没调度成功比如no node has enough model quota。4.4 参数计算并发与配额怎么定这块是实操中最容易拍脑袋的地方我分享下自己的计算方法。并发数怎么定先估算单个请求的平均处理时长比如 30 秒。再看你的目标 QPS比如峰值 0.5每 2 秒一个请求。那么需要的并发数 QPS × 平均时长 0.5 × 30 15。但这是理论值实际要考虑模型调用的波动建议乘以 1.5 的安全系数配 20 左右。模型配额怎么定单个请求平均消耗 2000 tokens峰值 QPS 0.5那么每分钟消耗 0.5 × 60 × 2000 60000 tokens。所以tokensPerMinute至少配 60000留点余量配 80000。超时怎么定单步超时按 P99 耗时来配别按平均值否则长尾请求全被砍。整体超时按最长合理任务链来配比如一个任务最多 10 步每步 P99 是 60 秒那整体超时至少 600 秒配 30 分钟是留了充足余量。这些数字不是拍出来的是算出来的。我见过太多人并发配 100结果模型配额只够 10 个并发用剩下 90 个全在等配额白白占着槽位。5. 常见问题与排查技巧实录5.1 调度失败类问题速查调度失败是最常见的一类问题我把踩过的坑整理成表现象可能原因排查方法解决方式Agent 一直 Pending模型配额不足ax describe看 Events调低 concurrency 或申请更多配额Pending 且提示无匹配节点亲和性约束太严检查 nodeAffinity 配置放宽 required 为 preferred调度成功但立即 Failed入口函数路径错看执行层日志核对 entrypoint 格式反复重调度心跳超时检查执行节点负载调大心跳间隔或扩容我遇到最坑的一次是 Agent 一直 Pending查了半天发现是dependsOn里声明的一个工具服务根本没部署。调度器很老实依赖不满足就不调度但报错信息不够直白得自己去 Events 里翻。5.2 运行时异常与重试策略调优运行时异常分两类可重试的和不可重试的。AX 默认把模型超时、工具调用失败归为可重试把参数错误、权限错误归为不可重试。这个分类你可以覆盖但要想清楚。我踩过一个坑把工具调用的所有错误都配成可重试结果一个参数写错的请求被重试了 3 次白白浪费了 3 次模型调用。后来改成只重试网络类错误参数类错误直接失败省了不少配额。重试的退避算法也有讲究。指数退避适合模型服务偶发过载的场景但如果你的错误是持续性的比如工具服务挂了指数退避会让重试间隔越来越长反而拖慢失败感知。这种场景用固定间隔重试更合适。提示重试次数别配太多。3 次是个比较平衡的值再多的话一个坏请求会占用槽位很久影响其他请求。5.3 状态持久化的坑开了statePersistence之后Agent 的上下文会存到外部存储。这里有几个坑。第一TTL 别配太短。Agent 任务可能跨小时TTL 配 1 小时的话长任务跑到一半状态就没了。建议按你最长任务时长的 2 倍来配。第二状态存储的读写延迟会计入 Agent 的处理时长。如果 Redis 跟执行节点跨区域每次读写几十毫秒累积起来很可观。尽量让状态存储跟执行节点同区域。第三并发写同一个状态键会冲突。如果你的 Agent 有多个并发实例共享状态得在应用层做锁AX 不管这个。5.4 独家避坑经验分享几条文档里不会写、但实操中很关键的经验。先单进程跑通再上集群。很多人一上来就搭调度执行分离的环境结果配置问题排查起来特别费劲。先用 standalone 模式把 Agent 逻辑跑通确认没问题了再拆开部署。给 Agent 打标签别只靠名字。生产环境 Agent 多了之后按名字找很痛苦。AX 支持给 Agent 打 label用ax get agents -l teamresearch这种命令筛选效率高很多。监控调度延迟不只是任务延迟。任务延迟是业务指标调度延迟是系统指标。如果调度延迟突然升高说明调度器压力大了得扩容。这个指标很多人不关注等到任务大面积 Pending 才发现。Spec 用 Git 管起来。Agent Spec 本质是配置配置就该进版本控制。改了什么、谁改的、什么时候改的一目了然。回滚也方便。6. 这套模型能走多远我的判断AX 把 Agent 当 Pod 调度这个思路我认为方向是对的但落地效果取决于几个因素。一是生态。K8s 的调度模型能成功很大程度是因为有海量的 controller、operator、CRD 生态。AX 现在还很早期工具链、监控、调试的配套都不完善。它能不能长出一个类似的生态是决定它天花板的关键。二是 Agent 负载的特殊性。Pod 是无状态的调度相对简单。Agent 有状态、有长时任务、有复杂的依赖关系这些特性会让调度逻辑比 Pod 复杂得多。AX 现在的调度策略还比较基础真正复杂的场景比如多 Agent 协作、动态依赖能不能撑住得看后续演进。三是使用门槛。声明式配置降低了运维复杂度但提高了开发者的心智负担。写 YAML 描述 Agent 行为对习惯了写代码的人来说一开始会不适应。这个门槛能不能降下来影响它的普及速度。我个人的态度是现在就把 AX 用到生产环境风险偏高但拿它做技术预研、理解声明式 Agent这个方向非常值得。它代表了一种思路——把 AI 负载纳入成熟的工程体系来管理而不是每个团队自己造轮子。这个思路我觉得会越来越主流。最后分享一个小技巧如果你现在用的是自研的 Agent 调度方案不妨对照 AX 的 Spec 设计看看自己的配置项缺了什么。很多时候把配置项补全的过程就是发现系统设计盲点的过程。我照着 AX 的字段清单过了一遍自己的系统补了三个之前没考虑的调度维度收益不小。