1. 从 Pod 到 Agent一次调度范式的迁移第一次看到“让 Agent 像 Pod 一样被调度”这个说法我的反应是终于有人把这件事讲明白了。过去两年Agent 开发几乎成了所有技术团队的必修课但绝大多数人卡在同一个地方——单个 Agent 跑得挺欢一旦要上规模、要并发、要容错整个系统就开始散架。你写一个 Agent 处理客服工单再写一个 Agent 做数据分析第三个 Agent 负责代码审查它们各自有各自的记忆、工具、模型配置和生命周期最后你发现自己在维护一堆互不相干的脚本而不是一个系统。Google 这次开源的 AX 项目核心思路非常直接把 Agent 当作集群里的一个调度单元来对待就像 Kubernetes 里的 Pod 一样。Pod 是 K8s 调度的最小单位它封装了容器、存储、网络、生命周期策略调度器只关心“把这个 Pod 放到哪个节点上跑”。AX 做的事情类似——它把 Agent 封装成一个标准化的执行单元调度层不关心你这个 Agent 内部用的是哪个模型、调了哪些工具、记忆存在哪里它只关心资源需求、优先级、依赖关系和运行状态。这个思路为什么重要因为 Agent 开发和传统微服务有一个本质区别Agent 是有“状态”和“不确定性”的。一个 HTTP 服务收到请求处理完返回响应生命周期清晰。但一个 Agent 可能跑着跑着需要调用外部工具工具返回慢了它要等等的时候它占着资源它可能因为模型输出不稳定需要重试它可能中途需要人工介入。这些特性让传统的进程管理、线程池、任务队列都不太够用。而 Pod 的调度模型恰好提供了几个关键能力资源隔离、生命周期管理、健康检查、重启策略、亲和性调度。把这些能力搬到 Agent 上很多问题就迎刃而解了。这篇文章适合两类人看。一类是已经在做 Agent 开发、但被规模化问题困扰的工程师你们会看到一套完整的调度思路和落地细节。另一类是做平台、做基础设施的同行你们会理解为什么 Agent 调度不能简单套用现有的任务队列方案。我会从架构设计、核心概念、实操配置、问题排查几个维度展开尽量把每个设计决策背后的“为什么”讲清楚。2. AX 的核心设计思路拆解2.1 为什么不是简单的任务队列很多人第一反应是Agent 调度不就是个任务队列吗提交任务Worker 拉取执行完了返回结果。Celery、DolphinScheduler、XXL-JOB 这些不都能干我一开始也这么想直到踩了几个坑才明白差异在哪。任务队列的假设是任务是短生命周期的、无状态的、执行时间可预测的。但 Agent 完全不符合这些假设。一个 Agent 可能执行 200 毫秒就返回也可能跑 20 分钟等一个外部 API它可能有内部状态需要跨多次调用保持它可能因为模型输出的随机性导致每次执行路径不同。更关键的是Agent 之间有依赖关系。Agent A 的输出是 Agent B 的输入Agent B 又可能触发 Agent C。这种依赖不是简单的 DAG 能描述的因为依赖关系可能在运行时动态产生。任务队列处理静态 DAG 没问题但处理动态依赖就很吃力。AX 的设计借鉴了 K8s 调度器的思路声明式 控制器循环。你声明你想要的 Agent 状态副本数、资源限制、依赖关系AX 的控制器不断对比实际状态和期望状态然后采取行动。这个模型的好处是无论 Agent 执行过程中发生什么异常控制器都会把它拉回期望状态。2.2 Agent 作为调度单元的几个关键抽象AX 把 Agent 抽象成几个核心概念我逐个拆解一下。AgentSpec描述一个 Agent 的期望状态。包括镜像用哪个 Agent 运行时、资源请求CPU、内存、GPU、环境变量模型 API Key、工具配置、依赖关系需要哪些其他 Agent 先就绪、重启策略失败后重试几次、超时时间。这个 Spec 是声明式的你不需要告诉 AX “怎么跑”只需要告诉它“跑成什么样”。AgentInstanceAgentSpec 的一个具体执行实例。类似于 Pod 和 Deployment 的关系。一个 AgentSpec 可以创建多个 AgentInstance每个 Instance 有独立的生命周期和状态。Instance 的状态包括 Pending、Running、Succeeded、Failed、Unknown和 Pod 的状态机几乎一致。Scheduler负责把 AgentInstance 分配到具体的执行节点上。调度决策考虑的因素包括节点资源余量、Agent 的资源请求、亲和性规则比如某些 Agent 必须和特定的工具服务在同一节点、优先级。调度器不关心 Agent 内部逻辑只做资源匹配。Controller监控 AgentInstance 的状态对比期望状态执行纠正操作。比如一个 Instance 失败了Controller 根据重启策略决定是重启还是标记为 Failed。如果 AgentSpec 声明了 3 个副本Controller 会确保始终有 3 个健康的 Instance 在跑。RuntimeAgent 的实际执行环境。AX 支持多种 Runtime包括本地进程、容器、甚至远程执行器。Runtime 负责加载 Agent 代码、注入配置、管理生命周期钩子。这套抽象的价值在于它把 Agent 的“业务逻辑”和“运维逻辑”彻底分开了。你写 Agent 的时候只关心它要做什么调度、重试、扩缩容、健康检查这些事交给 AX。2.3 和 K8s 调度模型的异同既然对标 Pod那就得说清楚哪些地方像、哪些地方不像。相似的地方资源模型request/limit、生命周期状态机、控制器模式、声明式 API、标签选择器、亲和性调度。如果你熟悉 K8s看 AX 的配置会有很强的既视感。不同的地方也很明显。第一Agent 的执行时间方差极大K8s 的调度器假设 Pod 一旦调度上去就会长期运行但 Agent 可能几秒就结束调度开销占比很高。AX 对此做了优化支持“快速路径”调度对于短生命周期的 Agent 减少调度决策的复杂度。第二Agent 对模型服务的依赖是强耦合的。一个节点上跑 10 个 Agent它们可能都在调同一个模型 API这时候瓶颈不在 CPU 而在 API 限流。AX 的调度器需要考虑“模型服务容量”这个维度这是 K8s 原生调度器没有的。第三Agent 的状态管理更复杂。Pod 的状态主要存在 etcd 里但 Agent 可能需要持久化对话历史、工具调用记录、中间结果。AX 提供了状态存储的抽象层支持多种后端本地文件、对象存储、数据库调度器在迁移 Agent 时需要确保状态可迁移。3. 核心概念与配置实操3.1 AgentSpec 的完整字段解析写一个 AgentSpec 是使用 AX 的第一步。我拿一个实际场景举例一个负责代码审查的 Agent需要读取 Git 仓库、调用静态分析工具、最后用模型生成审查意见。apiVersion: ax.io/v1alpha1 kind: AgentSpec metadata: name: code-review-agent labels: team: platform tier: analysis spec: runtime: container image: registry.internal/code-review-agent:v1.2.0 command: [python, -m, agent.main] resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi env: - name: MODEL_ENDPOINT value: http://model-gateway.internal/v1 - name: GIT_TOKEN valueFrom: secretKeyRef: name: git-credentials key: token dependencies: - name: static-analyzer required: true - name: git-proxy required: false restartPolicy: OnFailure maxRetries: 3 timeoutSeconds: 600 concurrency: 5 stateStore: type: objectstore config: bucket: agent-state prefix: code-review/逐字段说。runtime指定执行环境可选 container、process、remote。image和command定义怎么启动 Agent。resources的 request 和 limit 和 K8s 语义一致request 用于调度决策limit 用于运行时限制。env支持直接赋值和从 Secret 引用。这里有个坑Agent 通常需要多个 API Key如果全部用 Secret 引用Pod 启动时挂载 Secret 会有延迟。我的做法是把不敏感的配置直接写 env敏感的用 Secret并且把 Secret 提前创建好。dependencies定义 Agent 之间的依赖。required: true表示必须等依赖就绪才能启动false表示尽力而为。这个机制解决了一个大问题Agent A 需要调用 Agent B 的服务但 B 还没启动A 启动就会失败。有了依赖声明AX 会按拓扑顺序启动。restartPolicy支持 Always、OnFailure、Never。对于一次性任务型 Agent用 OnFailure对于常驻服务型 Agent用 Always。maxRetries限制重试次数防止无限重启。concurrency控制同一个 AgentSpec 下同时运行的 Instance 数量。这个参数很关键设太小吞吐不够设太大可能压垮下游服务。我的经验是从小往大调先设 2观察下游压力再逐步增加。stateStore定义状态存储。Agent 的状态可能包括对话历史、工具调用缓存、中间计算结果。AX 支持 local、objectstore、database 三种类型。生产环境建议用 objectstore 或 databaselocal 只适合开发调试。3.2 调度策略配置从默认到自定义AX 的默认调度策略是“资源最优”即选择资源余量最充足的节点。但实际场景往往需要更精细的控制。节点亲和性某些 Agent 需要 GPU必须调度到有 GPU 的节点。affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: accelerator operator: In values: [nvidia-a100, nvidia-h100]Agent 间亲和性Agent A 和 Agent B 通信频繁放在同一节点可以减少网络延迟。podAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 podAffinityTerm: labelSelector: matchLabels: app: static-analyzer topologyKey: kubernetes.io/hostname反亲和性同一 Agent 的多个副本不要放在同一节点避免单点故障。podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: code-review-agent topologyKey: kubernetes.io/hostname优先级与抢占关键业务的 Agent 优先级高资源紧张时可以抢占低优先级的 Agent。priorityClassName: high-priority preemptionPolicy: PreemptLowerPriority这里有个实操心得优先级不要设太多层级3 到 4 层就够了。层级太多会导致调度决策复杂化而且运维时很难判断哪个 Agent 该被抢占。我通常设 critical、high、normal、low 四档。3.3 状态管理与生命周期钩子Agent 的状态管理是 AX 区别于普通任务队列的核心能力之一。AX 提供了几个生命周期钩子让你在关键节点注入逻辑。preStartAgent 启动前执行。可以用来拉取最新代码、初始化数据库连接、预热模型。postStartAgent 启动后执行。可以用来注册服务发现、上报健康状态。preStopAgent 停止前执行。可以用来保存状态、释放资源、通知下游。postStopAgent 停止后执行。可以用来清理临时文件、发送执行报告。这些钩子用脚本或 HTTP 回调实现。我一般用 HTTP 回调因为脚本在不同 Runtime 下兼容性不好。状态存储的配置也有讲究。stateStore的type选 objectstore 时需要配置 bucket 和 prefix。prefix 建议按 Agent 名称和实例 ID 分层比如code-review/instance-001/这样便于排查和清理。状态同步策略有两种实时同步和检查点同步。实时同步每次状态变更都写存储一致性高但开销大。检查点同步每隔 N 秒或每 M 次操作写一次开销小但可能丢失少量状态。我的建议是对话类 Agent 用实时同步因为对话历史不能丢计算类 Agent 用检查点同步中间结果丢了可以重算。4. 完整实操从零部署一个 Agent 集群4.1 环境准备与依赖安装假设你有一台开发机想本地跑通 AX 的完整流程。以下是步骤。第一步安装 AX CLI。AX 提供了二进制包和包管理器两种方式。我推荐用包管理器升级方便。# macOS brew install ax-cli # Linux curl -fsSL https://ax.io/install.sh | bash # 验证 ax version第二步启动本地调度器。AX 自带一个单机模式的调度器适合开发和测试。ax scheduler start --mode standalone --port 8080这个命令会启动调度器、控制器和本地 Runtime。生产环境需要分布式部署但开发阶段单机足够。第三步准备 Agent 镜像。如果你用 container Runtime需要先构建镜像。Dockerfile 大概长这样FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, -m, agent.main]构建并推送到本地 registrydocker build -t localhost:5000/code-review-agent:v1.2.0 . docker push localhost:5000/code-review-agent:v1.2.0第四步创建 Secret。Agent 需要的敏感信息通过 Secret 注入。ax secret create git-credentials --from-literaltokenghp_xxxxxxxx ax secret create model-credentials --from-literalapi-keysk-xxxxxxxx4.2 编写并提交第一个 AgentSpec把前面的 AgentSpec 保存为code-review-agent.yaml然后提交。ax apply -f code-review-agent.yaml提交后AX 会做几件事验证 Spec 格式、检查依赖是否满足、创建 AgentInstance、调度到合适节点、启动 Runtime。查看状态ax get agents ax get instances ax describe agent code-review-agentax describe会输出详细信息包括调度决策、资源使用、最近事件。如果 Agent 没起来先看 Events 部分通常能找到原因。4.3 验证调度与执行结果Agent 跑起来后怎么验证它真的在工作第一看日志。ax logs code-review-agent --follow第二看指标。AX 暴露了 Prometheus 格式的指标包括调度延迟、执行时长、成功率、资源使用率。curl http://localhost:8080/metrics第三手动触发一次执行。AX 支持通过 CLI 或 API 触发 Agent 执行。ax invoke code-review-agent --input {repo: https://git.internal/project, pr: 123}第四检查状态存储。如果 Agent 写了状态去 objectstore 里确认。ax state get code-review-agent --instance instance-0014.4 扩缩容与滚动更新Agent 集群跑起来后扩缩容是常态。AX 支持手动和自动两种方式。手动扩缩容ax scale code-review-agent --replicas 10自动扩缩容需要配置 HPAHorizontal Pod Autoscaler类似的规则apiVersion: ax.io/v1alpha1 kind: AgentAutoscaler metadata: name: code-review-autoscaler spec: targetRef: name: code-review-agent minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: External external: metric: name: queue_depth target: type: AverageValue averageValue: 50这个配置的意思是CPU 利用率超过 70% 或者队列深度超过 50 时扩容最少 2 个副本最多 20 个。滚动更新是另一个高频操作。更新 Agent 镜像时AX 默认采用滚动更新策略先启动新版本的 Instance等它健康后再停掉旧版本。ax set image code-review-agentregistry.internal/code-review-agent:v1.3.0更新过程中可以用ax rollout status查看进度。如果新版本有问题可以回滚ax rollout undo code-review-agent5. 常见问题与排查技巧实录5.1 调度失败Agent 一直 Pending这是最常见的问题。Agent 提交后一直处于 Pending 状态说明调度器找不到合适的节点。排查思路按顺序来第一看资源是否足够。ax describe instance id会显示调度失败的原因通常是Insufficient cpu或Insufficient memory。如果集群资源确实不够要么扩容节点要么降低 Agent 的资源请求。第二看亲和性规则是否矛盾。比如你要求 Agent 调度到有 GPU 的节点同时又要求反亲和性不能和某个 Agent 同节点但那个 Agent 已经占满了所有 GPU 节点就会死锁。解决方法是放宽亲和性约束或者增加节点。第三看依赖是否满足。如果 Agent 声明了required: true的依赖但依赖一直没就绪Agent 会一直等。用ax get dependencies查看依赖状态。第四看配额。如果集群配置了资源配额Agent 可能因为超出配额而无法调度。ax describe quota可以查看。5.2 Agent 频繁重启如何定位根因Agent 频繁重启通常有几个原因OOM Kill内存超限被系统杀掉。看ax describe instance的 Last State如果是OOMKilled需要调大内存 limit或者优化 Agent 的内存使用。Agent 常见的内存问题是对话历史无限增长需要设置历史截断策略。健康检查失败AX 默认每 10 秒检查一次 Agent 健康状态连续 3 次失败就重启。如果 Agent 启动慢健康检查可能误判。解决方法是调大initialDelaySeconds和failureThreshold。依赖服务不可用Agent 启动时需要连接模型服务或数据库如果连不上就崩溃。这种情况需要配置preStart钩子做依赖检查或者用dependencies声明依赖。代码 BugAgent 代码有未捕获的异常。看日志定位具体错误。排查重启问题我习惯先看ax describe instance的 Events再看日志最后看指标。Events 告诉你“发生了什么”日志告诉你“为什么”指标告诉你“有多严重”。5.3 状态丢失Agent 重启后上下文消失Agent 重启后状态丢失通常是因为状态存储配置有问题。第一确认stateStore配置正确。如果用的是 local 存储Agent 重启后状态确实会丢因为 local 存储绑定在节点上。生产环境必须用 objectstore 或 database。第二确认状态同步策略。如果用的是检查点同步且检查点间隔太长重启时可能丢失最近的状态。可以调小间隔或者在preStop钩子里强制同步一次。第三确认状态键的命名。如果多个 Instance 共用同一个状态键会互相覆盖。状态键应该包含 Instance ID。第四确认存储后端可用。如果 objectstore 挂了状态写入会失败。AX 默认会重试但重试失败后 Agent 可能继续运行而不报错。建议配置状态写入失败时的告警。5.4 性能瓶颈调度延迟过高调度延迟是指从 Agent 提交到实际开始执行的时间。如果延迟过高用户体验会很差。调度延迟高的原因通常有调度器负载高Agent 提交频率太高调度器处理不过来。解决方法是增加调度器副本或者优化调度算法。节点资源碎片化集群资源总量够但分散在各个节点上没有单个节点能满足 Agent 的资源请求。解决方法是启用资源碎片整理或者调整 Agent 的资源请求。镜像拉取慢Agent 镜像大节点拉取耗时长。解决方法是优化镜像大小或者配置镜像预热。依赖等待Agent 在等依赖就绪。解决方法是优化依赖启动顺序或者把非关键依赖设为required: false。我实测下来调度延迟在 100 毫秒以内算优秀500 毫秒以内可接受超过 1 秒就需要优化了。5.5 常见问题速查表问题现象可能原因排查命令解决方案Agent 一直 Pending资源不足、亲和性矛盾、依赖未就绪ax describe instance扩容节点、放宽亲和性、检查依赖Agent 频繁重启OOM、健康检查失败、依赖不可用ax describe instance、ax logs调大内存、调整健康检查参数、修复依赖状态丢失存储配置错误、同步策略不当ax state get改用 objectstore、调小同步间隔调度延迟高调度器负载高、资源碎片化ax metrics增加调度器副本、整理资源碎片Agent 执行超时模型响应慢、工具调用卡住ax logs调大 timeout、优化工具调用扩缩容不生效Autoscaler 配置错误、指标不可用ax describe autoscaler检查指标源、调整阈值6. 生产环境落地的几个关键决策6.1 单集群还是多集群Agent 集群的部署规模取决于业务量。我的建议是初期用单集群等 Agent 数量超过 500 个或者跨地域部署需求出现时再考虑多集群。单集群的优点是管理简单、调度全局最优。缺点是单点故障风险、跨地域延迟。多集群可以解决这些问题但引入了集群间调度、状态同步、统一监控等复杂度。如果决定上多集群AX 提供了联邦调度模式。每个集群跑一个调度器上层有一个全局调度器做跨集群决策。全局调度器只做粗粒度调度比如按地域、按业务线细粒度调度交给本地调度器。6.2 模型服务的容量规划Agent 对模型服务的依赖是强耦合的。一个节点上跑 50 个 Agent如果它们同时调模型 API很可能触发限流。容量规划的思路是先估算单个 Agent 的模型调用频率和 token 消耗再乘以并发数得到总的模型服务需求。然后根据模型服务的吞吐能力决定 Agent 的并发上限。AX 的调度器支持“模型服务容量”感知。你可以在节点上打标签标记它连接的模型服务容量调度器会避免把太多 Agent 调度到容量不足的节点。nodeSelector: model-capacity: high6.3 安全与隔离Agent 执行的是代码代码可能有安全风险。AX 提供了几层隔离机制。Runtime 隔离container Runtime 提供进程级隔离remote Runtime 提供网络级隔离。生产环境建议用 container 或 remote。网络隔离Agent 默认只能访问声明的依赖服务其他网络访问被阻断。需要额外访问权限时通过 NetworkPolicy 显式开放。Secret 管理敏感信息通过 Secret 注入不写在 Spec 里。Secret 支持加密存储和访问审计。资源隔离通过 request/limit 限制 Agent 的 CPU、内存、GPU 使用防止单个 Agent 耗尽节点资源。6.4 监控与告警体系Agent 集群的监控比传统服务复杂因为 Agent 的行为更不确定。我建议监控以下几个维度调度层指标调度成功率、调度延迟、Pending 数量、节点资源利用率。执行层指标Agent 执行时长分布、成功率、重启次数、超时次数。业务层指标Agent 处理的请求量、模型调用次数、token 消耗、工具调用成功率。告警规则调度失败率超过 5% 告警、Agent 重启次数超过阈值告警、模型调用错误率超过阈值告警、状态存储写入失败告警。告警渠道建议用企业微信或钉钉和现有的运维体系打通。AX 支持 Webhook 告警配置起来很简单。alerting: webhooks: - url: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx events: [AgentFailed, ScheduleFailed, StateStoreError]7. 我踩过的坑和实测有效的技巧说几个文档里不会写、但实际用起来很关键的点。第一个坑Agent 的启动时间被低估。很多 Agent 启动时要加载模型、初始化向量数据库、建立连接池启动时间可能长达几十秒。如果健康检查的initialDelaySeconds设得太小Agent 还没启动完就被判定为失败然后重启陷入死循环。我的做法是先用ax logs观察 Agent 从启动到就绪的实际时间然后把这个时间乘以 1.5 作为initialDelaySeconds。第二个坑状态存储的写入放大。Agent 每次工具调用都写状态如果工具调用频繁状态存储的写入量会非常大。我遇到过一个 Agent 每秒写 100 次状态把 objectstore 的 QPS 打满了。解决方法是合并状态写入比如每 10 次工具调用写一次或者用本地缓存 定期刷盘。第三个坑依赖声明过度。一开始我把所有依赖都设为required: true结果一个非关键依赖挂了整个 Agent 集群都起不来。后来改成核心依赖用required: true非核心依赖用required: falseAgent 启动时检查非核心依赖不可用就降级运行。第四个坑扩缩容的抖动。自动扩缩容如果阈值设得太敏感会导致频繁扩缩容也就是“抖动”。比如 CPU 阈值设 70%Agent 在 70% 上下波动就会反复扩缩容。解决方法是加冷却时间cooldown period扩容后等 5 分钟再评估缩容后等 10 分钟再评估。第五个坑日志量爆炸。Agent 的日志比传统服务多得多因为 Agent 会打印模型输入输出、工具调用参数、中间推理过程。如果不加控制日志量可能每天几十 GB。我的做法是日志分级DEBUG 级别只在开发环境开生产环境用 INFO对模型输入输出做脱敏和截断日志保留时间设为 7 天超期自动清理。实测有效的技巧用标签做成本分摊。给每个 Agent 打上团队、项目、环境标签然后按标签统计资源消耗和模型调用量。这样每个团队能清楚看到自己的成本优化起来有依据。labels: team: platform project: code-review environment: production cost-center: eng-001另一个技巧灰度发布。新版本 Agent 不要一次性全量替换先跑 10% 的流量观察 24 小时没问题再逐步扩大。AX 的滚动更新支持maxSurge和maxUnavailable参数可以控制灰度节奏。strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 0maxUnavailable: 0表示更新过程中不允许有不可用的 Instance保证服务不中断。这套东西跑下来我的体会是Agent 调度不是简单的技术问题它涉及到资源管理、状态一致性、成本控制、安全隔离多个维度。AX 提供的是一套框架和抽象但具体怎么用还需要结合自己的业务场景去调。我见过太多团队把 Agent 当脚本跑最后维护成本高到无法承受。早点把调度层建起来后面会省很多事。