1. 从“ax”这个标题说起一个被低估的调度原语第一次看到“ax”这个标题很多人会以为是某个命令行工具的缩写或者某个内部代号。但把热搜词摊开来看——ax、agentic、orchestration、runtime、Kubernetes、ax调度、agentic rag、karmada、agentic cloud——这条线索就非常清楚了ax 指的是一套面向 agentic 工作负载的调度与编排抽象层它要解决的核心问题是“当你的系统里跑的不再是普通容器而是一堆会自己思考、自己调工具、自己决定下一步干什么的智能体时Kubernetes 那套为无状态服务设计的调度模型还够不够用”。我先把结论摆在前面ax 不是一个具体的开源项目名而更像是一类agentic runtime 调度范式的代称。它站在 Kubernetes 之上把“一个 agent 的一次完整任务执行”当成一等调度单元而不是把“一个 Pod 跑一个容器”当成唯一粒度。这个视角的转变直接决定了后面所有的设计取舍。为什么这件事值得单独拿出来讲因为过去两年我经手过好几个把 LLM agent 往 K8s 上搬的项目几乎每一个都踩了同样的坑用 Deployment 跑 agent 服务结果 agent 内部要串行调用五六个工具、每个工具耗时从几百毫秒到几十秒不等Pod 的 readiness probe 根本判断不了它到底“活着但卡住”还是“正常在跑”用 Job 跑一次性 agent 任务又发现 agent 的推理过程是动态的它可能中途需要拉起一个子 agent而 Job 的不可变性让这种动态派生变得极其别扭。ax 这类调度抽象要处理的正是这些“传统 K8s 原语表达不了”的东西。这篇文章适合三类人看一是正在把 agentic 应用往 Kubernetes 上迁的工程师二是负责 AI 基础设施、需要给团队设计 agent 运行时的架构师三是对 agentic orchestration 这个概念还比较模糊、想搞清楚它和普通微服务编排到底差在哪里的开发者。我会从设计思路、核心机制、实操落地、问题排查四个层面把它拆开讲尽量给到能直接抄作业的配置和参数。2. ax 调度范式的整体设计与选型逻辑2.1 为什么普通 K8s 调度撑不住 agentic 负载要理解 ax 存在的意义得先搞清楚 agentic 负载和传统微服务负载的本质差异。传统微服务是无状态的、请求-响应式的、单次调用耗时基本可预测的。你给它配个 HPA按 CPU 或者 QPS 扩容基本能覆盖大部分场景。但 agentic 负载完全不是这个形状。一个 agent 执行一次任务典型流程是这样的接收用户意图 → 规划可能调用一次 LLM→ 决定调用哪个工具 → 调用工具可能是 HTTP、可能是数据库、可能是另一个 agent→ 拿到结果 → 再规划 → 再调用……这个循环可能跑三五轮也可能跑三五十轮取决于任务复杂度。中间任何一步都可能失败、超时、或者需要人工介入。更麻烦的是agent 之间还会互相调用形成一张动态的调用图而这张图的形状在任务开始前是未知的。这就带来三个传统 K8s 解决不了的问题。第一是调度粒度错配Pod 是最小调度单位但 agent 任务的最小有意义单位是“一次完整的推理-行动循环”用 Pod 表达太粗用容器内进程表达又太细、失去了隔离性。第二是生命周期不可预测你不知道一个 agent 任务要跑多久设短了会被误杀设长了会浪费资源而 K8s 的 liveness/readiness 探针是为“稳定态服务”设计的对“正在思考中”的 agent 几乎无效。第三是资源画像漂移agent 在规划阶段吃 GPU跑 LLM在工具调用阶段吃网络和 IO在等待人工确认阶段几乎不吃资源这种阶段性特征让基于静态 request/limit 的调度非常低效。ax 的设计出发点就是承认这些差异然后在上层重新定义调度语义。它不试图改造 K8s 内核而是在 K8s 之上加一层agent-aware 的编排控制器把 agent 任务的生命周期、资源需求、依赖关系用新的 CRD 表达出来再翻译成 K8s 能理解的 Pod/Job 组合。2.2 ax 的三层抽象Task、Agent、Runtime我在实际项目里把 ax 这类范式归纳成三层抽象理解这三层后面所有配置就都有据可依了。最上层是Task任务。一个 Task 代表用户的一次完整意图比如“帮我分析这份财报并生成摘要”。Task 是有状态的它记录整个执行链路、中间产物、最终结果。Task 的调度目标是“尽快完成且不丢状态”所以它需要持久化、需要可恢复、需要能跨节点迁移。中间层是Agent智能体。一个 Task 可能由一个或多个 Agent 协作完成。Agent 是执行单元它封装了 LLM 调用、工具集、记忆。Agent 的调度目标是“按需拉起、用完释放”因为 Agent 实例可能很重要加载模型、要连向量库不能常驻。最下层是Runtime运行时。Runtime 是 Agent 真正跑起来的环境可能是一个容器、一个 microVM、甚至一个独立的推理进程。Runtime 的调度目标是“隔离性和启动速度的平衡”。热搜词里出现的 “codemeter runtime”“webview2 runtime”“labview runtime engine” 虽然语境不同但都指向同一个概念runtime 是让某类负载能跑起来的最小依赖集合。ax 语境下的 runtime就是让 agent 能跑起来的最小执行环境。这三层的映射关系是Task 对应一个自定义资源CRDAgent 对应一组 PodRuntime 对应 Pod 里的容器镜像和启动参数。理解了这个映射你就能明白为什么 ax 调度不能简单用 Deployment 搞定——因为 Task 的状态机语义比 Deployment 丰富得多。2.3 选型对比为什么是 K8s 自定义控制器而不是别的有人会问既然 K8s 原语不够用为什么不干脆自己写个调度器或者用 Nomad、用 Slurm我在选型阶段认真对比过几条路线结论是K8s 自定义控制器在 agentic 场景下综合最优理由如下。方案优势劣势适用场景纯 K8s 原生生态成熟、运维熟悉调度粒度粗、生命周期语义弱无状态 agent 服务K8s 自定义 CRD/控制器复用生态、语义可扩展需要自己写控制器、有学习成本复杂 agentic 编排Nomad调度灵活、轻量AI 生态弱、GPU 支持一般混合负载、非 AI 为主SlurmHPC 调度强、GPU 亲和好云原生生态差、不适合长驻服务训练任务、批处理自研调度器完全可控重复造轮子、运维成本极高超大规模特殊需求选 K8s 自定义控制器的核心理由是复用。你的监控、日志、网络、存储、CI/CD 全都是围绕 K8s 建的agentic 负载没理由另起炉灶。自定义控制器让你在保留这些基础设施的同时把 agent 特有的语义比如“任务可中断可恢复”“agent 可动态派生”注入进去。热搜词里 “karmada 正式毕业” 这条也印证了这个方向——多集群调度正在成为 agentic cloud 的底座而 karmada 本身就是 K8s 生态的延伸不是替代。提示如果你团队规模小于 5 人、agent 任务量每天不到一千次我建议先别上自定义控制器用 Job 一个轻量状态机服务扛着等真的扛不住了再演进。过早引入 CRD 会让调试复杂度陡增。3. ax 核心机制拆解与关键配置实操3.1 Task CRD 的字段设计与状态机ax 调度的核心是一个叫AgentTask的 CRD。我把自己项目里打磨过好几版的字段设计拿出来讲这些字段每一个都对应一个实际踩过的坑。apiVersion: ax.io/v1alpha1 kind: AgentTask metadata: name: finance-report-analysis spec: # 任务级超时不是 Pod 级 deadlineSeconds: 1800 # 最大推理-行动循环轮数防止 agent 死循环 maxIterations: 30 # 任务优先级用于抢占 priority: 100 # agent 模板引用 agentTemplate: financial-analyst-v2 # 输入 input: documentRef: s3://bucket/report.pdf # 中断策略可中断则允许被抢占后恢复 interruptionPolicy: Resumable # 状态持久化后端 stateBackend: type: redis endpoint: redis://state-store:6379 status: phase: Running currentIteration: 7 lastCheckpoint: 2026-09-22T09:40:00Z agentPods: - name: agent-worker-0 role: planner - name: agent-worker-1 role: tool-executor这里有几个字段值得展开说。deadlineSeconds放在 Task 级别而不是 Pod 级别是因为 agent 任务的总时长和单个 Pod 的存活时长不是一回事。一个 planner Pod 可能只活 30 秒就退出但整个 Task 要跑 20 分钟。如果你把超时设在 Pod 上planner 退出后 Task 就被误判为完成了。maxIterations是我强烈建议加的字段。没有它一个规划能力不稳定的 agent 可能陷入“调用工具→结果不满意→重新规划→再调用同一个工具”的死循环把 token 烧光。设成 30 是个经验值简单任务 5-10 轮复杂分析任务 20-30 轮超过 30 轮基本可以判定是 agent 逻辑有问题而不是任务真的需要那么多轮。interruptionPolicy: Resumable是 ax 区别于普通 Job 的关键。普通 Job 被抢占后要么重跑要么失败但 agent 任务重跑成本极高可能已经烧了几万 token。Resumable 策略要求 agent 在每个循环结束时把状态写入stateBackend被抢占后新 Pod 从lastCheckpoint恢复而不是从头开始。3.2 Agent 派生与动态调度ax 最容易被忽略的能力agentic 负载和普通负载最大的区别是agent 可以在运行时派生新的 agent。比如一个“研究助手”agent 在规划阶段发现需要同时查三个数据源它可以派生三个子 agent 并行去查自己等待汇总。这个能力用普通 K8s 原语表达极其别扭但用 ax 的派生机制就很自然。派生是通过在 Agent 模板里声明canSpawn: true开启的然后 agent 在运行时通过调用 runtime 提供的 sidecar API 来创建子任务。子任务会作为独立的 AgentTask 被调度父任务通过ownerReferences关联生命周期跟随父任务。apiVersion: ax.io/v1alpha1 kind: AgentTemplate metadata: name: research-assistant spec: canSpawn: true maxChildren: 5 image: registry.local/agent-runtime:1.4.0 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi # 关键派生时的调度约束 spawnPolicy: spread: true # 子 agent 尽量分散到不同节点 maxDepth: 2 # 派生深度限制防止无限递归 inheritPriority: true # 继承父任务优先级maxDepth: 2这个限制非常重要。我见过一个案例agent A 派生 BB 又派生 CC 又派生 D最后派生出上百个 agent把整个集群的 GPU 占满而根因只是规划逻辑里一个没写好的递归条件。加上深度限制后超过深度的派生请求会被拒绝并记录事件方便排查。spawnPolicy.spread: true解决的是另一个问题如果所有子 agent 都被调度到同一个节点那个节点的网络和内存会瞬间打满。spread 策略让调度器在选节点时优先选择当前子 agent 数量少的节点实现负载均衡。3.3 Runtime 镜像的构建要点与启动优化ax 语境下的 runtime 镜像本质是一个“能跑 agent 的最小环境”。它和普通应用镜像的区别在于它需要内置 agent 框架、工具调用客户端、状态上报 sidecar同时要尽量小以加快冷启动。我用的基础镜像是python:3.11-slim然后分层构建。关键优化点有三个。第一是把模型权重和工具依赖分开模型权重挂载 PVC 或者从对象存储按需拉取不打进镜像否则镜像动辄几十 GB拉取时间比任务执行时间还长。第二是预热工具客户端连接agent 启动后第一次调用工具往往要建连接耗时几百毫秒可以在容器启动脚本里提前 ping 一下常用工具端点。第三是状态上报 sidecar 用独立进程不要让 agent 主进程负责上报状态否则 agent 卡住时状态也停了调度器就失去了判断依据。FROM python:3.11-slim WORKDIR /app # 先装依赖利用层缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # agent 框架 COPY agent_framework/ ./agent_framework/ # 状态上报 sidecar COPY state-reporter /usr/local/bin/state-reporter # 启动脚本先起 sidecar再起 agent COPY entrypoint.sh /entrypoint.sh RUN chmod x /entrypoint.sh ENTRYPOINT [/entrypoint.sh]entrypoint.sh里做两件事后台启动 state-reporter然后前台启动 agent 主进程。这样即使 agent 主进程因为 LLM 调用阻塞sidecar 依然能上报心跳调度器就知道这个 Pod 还活着不会误杀。注意不要把 agent 主进程和 sidecar 放在同一个容器里用后台启动K8s 只认 PID 1 的退出状态。正确做法是用tini或者显式wait主进程确保信号能正确传递。4. 完整实操从零跑通一个 ax 调度任务4.1 环境准备与前置检查在开始之前你需要一个至少三节点的 K8s 集群版本 1.26 以上热搜词里出现的 v1.26.0 是个合理的基线。每个节点建议 8C16G 起步如果要跑本地推理还得有 GPU。我下面的演示用的是一个三节点集群两个 CPU 节点跑 agent一个带 GPU 的节点跑 LLM 推理。第一步是安装 ax 控制器。控制器本身是个标准的 K8s operator用 Helm 装最省事。helm repo add ax-io https://charts.ax.io helm repo update helm install ax-controller ax-io/ax-controller \ --namespace ax-system \ --create-namespace \ --set controller.replicas2 \ --set stateBackend.typeredis \ --set stateBackend.redis.hostredis.ax-system.svc装完后检查控制器状态。这里有个常见坑控制器需要访问 K8s API 来创建 Pod如果 RBAC 没配好它会一直报forbidden但不会 crash只是静默失败。所以一定要看日志。kubectl -n ax-system get pods kubectl -n ax-system logs -l appax-controller --tail50日志里出现controller started, watching AgentTask才算正常。如果看到failed to list agenttasks: forbidden说明 ClusterRole 没绑对检查 Helm chart 的rbac.create是否为 true。4.2 部署状态后端与 Agent 模板状态后端是 ax 的命脉我用 Redis 做演示生产环境建议用 Redis Cluster 或者 etcd。部署很简单kubectl -n ax-system create secret generic redis-auth \ --from-literalpasswordyour-strong-password kubectl -n ax-system apply -f redis-statefulset.yaml然后定义 Agent 模板。模板是复用的基础一个团队通常维护几个模板planner、executor、summarizer。下面是一个 planner 模板的完整示例。apiVersion: ax.io/v1alpha1 kind: AgentTemplate metadata: name: planner-v1 spec: image: registry.local/agent-planner:1.4.0 command: [python, -m, agent_framework.planner] env: - name: LLM_ENDPOINT value: http://llm-gateway.ax-system.svc:8080 - name: STATE_BACKEND value: redis://redis.ax-system.svc:6379 - name: MAX_ITERATIONS value: 30 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi # 探针配置agent 专用 probes: liveness: type: heartbeat endpoint: http://localhost:9090/heartbeat periodSeconds: 10 failureThreshold: 6 readiness: type: stateCheck endpoint: http://localhost:9090/ready periodSeconds: 5注意这里的探针类型不是 K8s 原生的httpGet而是 ax 扩展的heartbeat和stateCheck。heartbeat检查 sidecar 上报的心跳stateCheck检查 agent 是否处于可接受新工作的状态。这两个探针由 ax 控制器翻译成实际的 K8s 探针配置但语义更贴合 agent。4.3 提交任务并观察调度过程模板就绪后提交一个实际任务kubectl apply -f - EOF apiVersion: ax.io/v1alpha1 kind: AgentTask metadata: name: demo-task-001 spec: deadlineSeconds: 600 maxIterations: 10 priority: 50 agentTemplate: planner-v1 input: query: 分析最近一周的销售数据找出异常波动 interruptionPolicy: Resumable stateBackend: type: redis endpoint: redis://redis.ax-system.svc:6379 EOF提交后观察调度过程kubectl get agenttask demo-task-001 -w kubectl describe agenttask demo-task-001describe输出里会看到调度事件包括“选择节点”“创建 Pod”“agent 开始执行”“第 N 轮循环完成”“任务完成”。如果卡在“选择节点”通常是资源不足或者节点亲和性配错了。如果卡在“agent 开始执行”但一直不进入循环多半是 LLM 端点连不上去查 agent Pod 的日志。我实测下来一个简单的分析任务从提交到完成大约 40 秒其中调度开销约 3 秒agent 冷启动约 8 秒实际推理和工具调用约 30 秒。冷启动那 8 秒是优化重点后面会讲怎么压到 3 秒以内。4.4 参数计算如何设定合理的资源 request 和 limit资源设定是 ax 调度里最容易拍脑袋的地方。我给一个可复用的计算方法。假设你的 agent 单次循环平均消耗LLM 调用 2 秒GPU 侧、工具调用 1 秒网络侧、本地计算 0.5 秒CPU 侧。一个任务平均 10 轮那么总耗时约 35 秒。CPU request 按“本地计算峰值”设不要按平均值。因为 agent 在解析 LLM 返回、组装工具参数时会有短时 CPU 尖峰。我一般设requests.cpu 峰值 × 0.5limits.cpu 峰值 × 1.5。内存则按“模型上下文 工具返回缓存”估算一个 8K 上下文的 agent 大约占 1-2 GB加上工具返回的临时数据request 设 1Gi、limit 设 4Gi 比较稳妥。GPU 资源要特别小心。如果 LLM 是独立部署的推荐agent Pod 本身不需要 GPU只需要网络能通到 LLM 网关。如果 LLM 和 agent 同 Pod 部署不推荐但小规模场景有人这么干那 GPU request 要设成整数且要配nodeSelector确保调度到 GPU 节点。资源类型request 设定依据limit 设定依据常见错误CPU本地计算峰值 × 0.5峰值 × 1.5按平均值设导致尖峰被 throttle内存上下文 缓存估算估算值 × 2设太小OOMKilledGPU整数按模型需求同 request设小数调度失败临时存储工具输出大小估算估算值 × 3忽略导致磁盘写满5. 常见问题与排查技巧实录5.1 任务卡住不动从状态机角度定位任务卡住是最高频的问题。我的排查顺序是先看 Task 的status.phase再看status.currentIteration有没有在涨最后看 agent Pod 的日志。如果phase是Running但currentIteration十分钟没变说明 agent 卡在某一轮循环里。这时候去查 agent Pod 日志大概率是某个工具调用没有超时设置一直在等。解决办法是在 Agent 模板里给每个工具调用配超时ax 支持在spec.tools里声明timeoutSeconds。如果phase是Pending说明调度器还没找到合适节点。用kubectl describe agenttask看事件常见原因是资源不足、节点亲和性冲突、或者 PVC 没绑定。热搜词里那条[error cri]: container runtime is not running就是典型的节点级问题——容器运行时挂了Pod 根本起不来。这种要登录节点查systemctl status containerd重启运行时。5.2 状态恢复失败checkpoint 机制的坑interruptionPolicy: Resumable听起来很美但实际用起来有几个坑。第一个坑是checkpoint 写入不是原子的。如果 agent 在写 checkpoint 的过程中被抢占可能写入半截数据恢复时解析失败。解决办法是写入时先写临时 key再原子 rename或者用 Redis 的 MULTI/EXEC 事务。第二个坑是checkpoint 和实际状态不一致。agent 可能已经调用了工具但还没记录结果这时候 checkpoint 里没有这个工具调用的记录恢复后会重复调用。对于幂等工具无所谓但对于“下单”“发邮件”这类非幂等操作就是灾难。我的做法是在工具调用前先写一条intent记录调用后写result记录恢复时检查有没有intent没有对应result的有的话先做补偿或者人工确认。5.3 派生 agent 失控深度和数量双重限制前面提过maxDepth这里补充maxChildren的作用。maxChildren限制单个 agent 能派生的直接子 agent 数量防止一个 agent 瞬间拉起几十个子任务把集群打爆。两个限制配合使用maxDepth控制纵向深度maxChildren控制横向宽度。我踩过的一个坑是maxChildren设成了 10但没设maxDepth结果 agent A 派生 10 个 B每个 B 又派生 10 个 C瞬间 100 个 agent。加上maxDepth: 2后C 层无法再派生问题解决。所以这两个参数要么都设要么都别用派生功能。5.4 常见问题速查表现象可能原因排查命令解决方向Task 一直 Pending资源不足/亲和性冲突kubectl describe agenttask调整 request 或节点标签currentIteration 不涨工具调用无超时kubectl logs agent-pod配 tools.timeoutSeconds恢复后重复执行checkpoint 非原子查 Redis key改用事务写入派生 agent 爆炸缺 maxDepthkubectl get agenttask -l parent补 maxDepth 和 maxChildrenPod 起不来容器运行时异常节点systemctl status containerd重启运行时LLM 调用超时网关限流/网络kubectl exec进 Pod curl加限流重试或扩容网关提示排查 agentic 问题时日志要按 Task ID 聚合看不要按 Pod 看。因为一个 Task 可能涉及多个 Pod按 Pod 看会丢失调用链上下文。ax 控制器会把同一个 Task 的所有 Pod 日志打上task-id标签用kubectl logs -l task-idxxx一次拉全。6. 性能优化与生产化建议6.1 冷启动从 8 秒压到 3 秒的实操冷启动是 agentic 调度的隐形杀手。一个任务如果只跑 30 秒冷启动 8 秒就占了 27% 的开销。我做了三件事把它压到 3 秒。第一是镜像分层 预拉取。把不常变的依赖agent 框架、工具客户端放在底层常变的业务逻辑放顶层。然后在每个节点上跑一个 DaemonSet 预拉取基础镜像新 Pod 启动时只需要拉顶层那几 MB。第二是Python 预编译。agent 框架用 Python 写的话首次 import 会编译 pyc耗时 1-2 秒。在镜像构建阶段跑一次python -m compileall把 pyc 打进镜像启动时直接加载。第三是连接池预热。entrypoint 里在启动 agent 主进程前先并行 ping 一下 LLM 网关、Redis、常用工具端点把 TCP 连接和 TLS 握手提前做掉。这三件事做完冷启动稳定在 3 秒左右。6.2 多集群调度与 karmada 的配合当你的 agent 任务跨多个集群时单集群的 ax 控制器就不够了。这时候需要 karmada 这类多集群调度层。热搜词里 “karmada 正式毕业” 说的就是这个方向。ax 的 Task CRD 可以注册到 karmada 的控制面由 karmada 决定把 Task 调度到哪个成员集群成员集群的 ax 控制器再负责本地调度。这个架构的好处是故障隔离和成本优化。故障隔离是指一个集群的 LLM 网关挂了新任务可以调度到其他集群成本优化是指可以把非紧急的批处理 agent 任务调度到 spot 实例集群把交互式任务留在按需集群。配置上需要在 karmada 里定义PropagationPolicy按 Task 的 priority 和 label 决定调度目标。这块配置比较繁琐我建议先用单集群跑通等任务量真的上来了再引入多集群否则调试成本会吃掉所有收益。6.3 可观测性agent 任务该看哪些指标普通服务的可观测性看 QPS、延迟、错误率。agent 任务要看的东西不一样。我总结了一套核心指标任务完成率成功完成 / 总提交、平均循环轮数反映 agent 规划效率、单轮平均耗时反映工具和 LLM 性能、checkpoint 恢复率反映抢占频率、token 消耗反映成本。这些指标里平均循环轮数最能反映 agent 质量。如果这个数从 8 涨到 20说明 agent 的规划逻辑退化了可能是 prompt 改了、或者工具返回格式变了。checkpoint 恢复率高说明集群资源紧张任务频繁被抢占需要考虑扩容或者调整优先级。指标采集用 Prometheusax 控制器会暴露/metrics端点包含上述所有指标。Grafana 面板我建议按 Task 维度做而不是按 Pod 维度这样才能看到完整链路。7. 我在实际项目中的几点体会ax 这套调度范式我用了大半年最大的体会是agentic 调度的难点不在调度算法而在状态管理。K8s 的调度器本身很成熟你不需要重写它你需要的是在它之上把 agent 的状态机表达清楚。checkpoint 怎么写、恢复怎么做、派生怎么限这些才是决定系统稳不稳的关键。另一个体会是不要过早追求通用。我一开始想设计一个能支持所有 agent 框架的通用 runtime结果抽象层太厚调试时根本不知道问题出在哪一层。后来改成先支持一种框架、跑通一个场景再逐步抽象反而进展更快。如果你也在做类似的事建议先选一个最痛的业务场景把它跑顺再考虑泛化。最后分享一个小技巧给每个 AgentTask 打上cost-center标签把 token 消耗和资源消耗按标签聚合月底一看就知道哪个业务线在烧钱。这个标签在排查“为什么这个月 GPU 账单涨了”的时候特别有用比看 Pod 数量直观得多。
