1. 从ax这个标题说起一个被低估的运行时缩写第一次看到ax这个标题绝大多数人的反应是懵的——两个字母没有正文没有关键词没有摘要只有一串热搜词在旁边晃悠agentic、orchestration、runtime、Kubernetes。这种信息量极低的输入恰恰是最考验拆解能力的场景。因为ax本身不是一个完整的产品名它更像是一个代号、一个缩写或者某个更大系统里的一个模块名。我先把结论摆在前面结合热搜词里反复出现的 agentic、orchestration、runtime、Kubernetes以及karmada 正式毕业agentic cloud 坚实底座这类语境ax最合理的解读方向是——面向 Agentic 工作负载的编排运行时Agentic eXecution runtime它要解决的问题是当一堆 AI Agent 需要被调度、被编排、被隔离、被观测时底层的运行时该怎么设计。这不是一个玩具项目而是一个典型的云原生基础设施命题。为什么我敢这么判断因为热搜词里同时出现了runtime、Kubernetes、agentic rag、orchestration这几个词它们不是随机拼凑的。runtime是底层执行环境Kubernetes是调度底座orchestration是编排逻辑agentic是上层负载形态。这四个词串起来就是一条完整的从底到上的技术栈。而ax作为标题极可能是这条栈里那个执行层的代号。这篇文章我打算这么写先把这个缩写背后的领域讲清楚再拆解 Agentic 运行时到底难在哪然后落到 Kubernetes 上的具体编排设计接着讲实测中会踩的坑最后聊聊这套东西的边界和扩展方向。适合谁看如果你在做 AI Agent 平台、在折腾 K8s 上的自定义调度、或者单纯对Agent 怎么被管起来这件事好奇这篇都能给你一些能直接抄的干货。提示本文对ax的解读基于热搜词语境和云原生领域的常见实践做合理推演具体项目细节以实际代码仓库为准。凡是我补充的实现细节都会明确标注这是基于常见实践的推演。2. Agentic 负载和传统微服务到底差在哪2.1 传统编排假设的崩塌从无状态短请求到有状态长会话Kubernetes 这套编排体系最初是为无状态、短生命周期、请求-响应式的微服务设计的。一个 Pod 起来处理几个请求被干掉再起一个新的这套模型跑了十年非常成熟。它的核心假设是实例之间可以随意替换状态存在外部存储里请求之间互不干扰。但 Agentic 负载把这套假设全打破了。一个 AI Agent 的典型生命周期是这样的它可能跑几分钟到几小时中间要维护对话上下文、工具调用历史、中间推理状态它可能主动发起对外部工具的调用而不是被动等请求它可能因为一次工具调用失败而需要重试整个推理链它甚至可能在执行过程中生出子 Agent 去并行处理子任务。这些特性叠加起来就是一个有状态、长会话、动态派生、外部依赖重的负载形态。我举个具体的例子。假设你有一个负责自动处理客户工单的 Agent它接到一个工单后要先检索知识库RAG再调用内部 API 查订单状态然后根据结果决定是自动回复还是转人工。整个过程可能持续 30 秒到 5 分钟中间任何一步失败都要回滚或重试。如果你用传统的 Deployment 去跑它会遇到几个直接的问题Pod 被驱逐时上下文全丢、并发请求打满单个实例、工具调用的超时和 K8s 的探针机制打架。这就是为什么需要一套专门的运行时。2.2 为什么ax这类运行时必须独立存在有人会问我直接用 K8s 的 Job 或者 StatefulSet 不就行了为什么要单独搞一个运行时这个问题的答案藏在编排粒度这四个字里。传统 K8s 的编排粒度是Pod一个 Pod 是一个调度单元。但 Agentic 场景下真正需要被编排的粒度可能是一次 Agent 会话、一个推理步骤、甚至一次工具调用。这些粒度比 Pod 小得多也动态得多。一个 Agent 会话可能横跨多个 Pod比如推理在一个 Pod、工具执行在另一个 Pod也可能在一个 Pod 里跑完但需要精细的资源隔离。ax这类运行时的价值就是在这两个粒度之间架一层抽象对上它暴露会话任务步骤这样的概念对下它把这些概念翻译成 K8s 能理解的 Pod、Service、ConfigMap。这层抽象不是多余的它解决的是语义鸿沟问题——K8s 不懂什么是Agent 会话而 Agent 框架不懂什么是Pod 亲和性。2.3 一张表看清两种负载的核心差异维度传统微服务Agentic 负载生命周期秒级到分钟级分钟级到小时级状态无状态为主强状态上下文敏感调用模式被动响应主动发起工具调用失败处理重试单次请求重试整个推理链派生行为无动态派生子 Agent资源特征CPU/内存平稳突发性 GPU/内存峰值观测重点QPS、延迟推理链、工具调用成功率这张表不是学术分类而是我在实际设计调度策略时的决策依据。比如突发性 GPU 峰值这一条直接决定了你不能用固定的 resource request 去申请 GPU而要考虑弹性伸缩和排队机制。再比如重试整个推理链这一条意味着你的幂等性设计不能只做在 API 层要做到工具调用层。3. 把 Agent 塞进 Kubernetes编排层的关键设计3.1 自定义资源定义让 K8s 认识Agent这个概念Kubernetes 最强大的扩展机制是 CRDCustom Resource Definition。要让 K8s 理解 Agentic 负载第一步就是定义自己的资源类型。基于常见实践一个 Agentic 运行时通常会定义这么几类 CRDAgentSession代表一次完整的 Agent 会话包含会话 ID、上下文引用、超时策略、资源配额。AgentTask代表会话里的一个子任务可以嵌套支持 DAG 依赖。ToolInvocation代表一次工具调用记录工具名、参数、超时、重试策略。AgentPool代表一组可复用的 Agent 实例类似 Deployment 但面向 Agent 语义。定义这些 CRD 的核心考量是可观测性和可恢复性。可观测性指的是你能通过kubectl get agentsessions直接看到所有活跃会话的状态可恢复性指的是当某个 Pod 挂掉时控制器能根据 CRD 里记录的状态重建会话而不是从头开始。这里有个容易踩的坑CRD 的 status 字段设计。很多人一开始只记录成功/失败结果排查问题时完全不知道卡在哪一步。我的建议是status 里至少要包含当前步骤、已完成的步骤列表、最后一次工具调用的结果、重试次数。这些信息在排查Agent 为什么卡住时是救命的。3.2 调度策略为什么默认调度器不够用K8s 默认调度器考虑的是 CPU、内存、节点亲和性这些维度。但 Agentic 负载的调度需求更复杂第一GPU 的碎片化利用。一个 Agent 可能只需要 2GB 显存做推理但默认调度器按整卡调度浪费严重。解决方案是用 MIGMulti-Instance GPU或者时间片共享把 GPU 切细。第二会话亲和性。同一个会话的多个步骤最好调度到同一节点减少上下文传输开销。这需要自定义调度器或者用 Pod Affinity 配合会话 ID 做标签。第三优先级抢占。交互式 Agent用户等着回复和批处理 Agent后台跑的优先级完全不同需要抢占机制保证交互式的响应时间。我实测下来最实用的组合是默认调度器 自定义调度器扩展Scheduler Framework 优先级类PriorityClass。默认调度器处理基础资源匹配自定义扩展处理会话亲和性PriorityClass 处理抢占。三者配合能覆盖 90% 的场景。3.3 状态管理上下文到底该存在哪Agent 的上下文对话历史、推理中间态存哪是个绕不开的问题。三个选项各有取舍存内存最快但 Pod 一挂就没了不适合长会话。存外部数据库可靠但每次读写都有网络开销高频访问时是瓶颈。存本地持久卷 定期同步折中方案本地读写快定期同步到远端做备份。我的经验是分层存储最靠谱热上下文最近几轮对话放内存温上下文本次会话历史放本地卷冷上下文跨会话记忆放外部数据库。这样既保证了性能又保证了可靠性。具体实现上可以用 Redis 做热层Local PV 做温层PostgreSQL 或向量库做冷层。注意本地持久卷的方案在节点故障时会丢数据所以同步频率要调好。我一般设成每 30 秒或每 10 轮对话同步一次具体看业务对丢失的容忍度。4. 实测中那些文档不会告诉你的坑4.1 探针机制和长会话的冲突K8s 的 liveness probe 和 readiness probe 是为短请求设计的。默认配置下如果一个 Pod 30 秒没响应健康检查就会被重启。但 Agent 会话可能正在跑一个 5 分钟的推理这时候探针超时Pod 被重启整个会话就废了。解决方案不是简单地把探针超时调大那样会掩盖真正的问题。正确的做法是区分进程活着和会话健康。进程活着用 liveness probe 检查比如检查进程是否存在会话健康用 readiness probe 检查比如检查是否能接受新会话。正在跑长会话的 Podreadiness 可以标记为 NotReady不接受新会话但 liveness 保持健康不重启。具体配置上liveness probe 用 exec 检查进程readiness probe 用 HTTP 检查一个/health端点这个端点返回当前活跃会话数超过阈值就返回 503。这样 K8s 就不会把新会话调度过来但也不会杀掉正在跑的会话。4.2 工具调用的超时和重试比想象中难搞Agent 调用外部工具时超时和重试的逻辑很容易写错。最常见的错误是在错误的层级做重试。比如工具调用超时了你在 HTTP 客户端层重试但这次重试可能触发工具的副作用比如重复下单造成数据不一致。正确的做法是在工具调用层做幂等 在编排层做重试。工具本身要支持幂等键idempotency key编排层根据幂等键判断是否已经执行过避免重复副作用。重试策略上用指数退避 抖动避免重试风暴。我踩过的一个具体坑某个工具调用超时后重试结果工具实际上已经执行成功了只是响应慢。重试导致操作执行了两次。后来加了幂等键并且在编排层记录每次调用的状态才解决。这个坑的教训是超时不等于失败分布式系统里这两者必须分开处理。4.3 资源配额和突发峰值的矛盾Agentic 负载的资源使用是脉冲式的大部分时间 CPU 和内存占用很低但推理时会突然飙高。如果你按峰值申请资源利用率极低如果按均值申请峰值时会被 OOM Kill。我的做法是用 Burstable QoS 合理的 request/limit 比例。request 设成均值的 1.2 倍limit 设成峰值的 1.5 倍。这样调度时按 request 算保证基本资源运行时可以 burst 到 limit应对峰值。同时配合 VPAVertical Pod Autoscaler做动态调整让它根据历史数据自动优化 request 值。但 VPA 有个坑它会重启 Pod 来应用新的资源值。对于长会话的 Agent重启意味着会话中断。所以 VPA 要用updateMode: Initial或者Off只在 Pod 创建时应用不动态重启。或者干脆用 HPA 做水平扩展避免垂直调整。4.4 排查链路一次Agent 卡住的完整定位过程我遇到过一次典型的Agent 卡住问题排查过程值得分享。现象是某个会话一直处于 Running 状态但没有任何进展日志也没有新输出。第一步kubectl describe agentsession id看 status 字段。发现当前步骤是等待工具调用返回已经等了 10 分钟。第二步kubectl get toolinvocations找到对应的工具调用记录。发现状态是 Pending没有开始执行。第三步检查工具执行器的 Pod 状态。发现 Pod 是 Running 的但 CPU 占用为 0说明它在等什么。第四步kubectl logs看工具执行器日志。发现它在等一个外部 API 的响应而这个 API 的地址配置错了导致连接一直挂起。第五步修复配置重启工具执行器。会话恢复继续执行。这个链路的关键是逐层下钻从会话到任务到工具调用到 Pod 到日志。每一层都有对应的 CRD 和状态记录才能快速定位。如果当初 CRD 设计得粗糙只记录成功/失败这个排查可能要花几小时。5. 从单集群到多集群Agentic 编排的扩展边界5.1 为什么单集群迟早不够用单集群跑 Agentic 负载会遇到几个天花板。第一是资源天花板GPU 资源有限Agent 数量一多就排不上队。第二是故障域天花板单集群故障所有 Agent 全挂。第三是合规天花板不同地区的 Agent 可能要求数据不出境必须分集群部署。这时候就需要多集群编排。热搜词里出现的 Karmada就是解决这个问题的典型方案。它的思路是用一个控制面管理多个成员集群把 Agentic 负载按策略分发到不同集群。5.2 多集群调度的三个核心策略基于常见实践多集群调度 Agentic 负载时通常用这三种策略按资源分发哪个集群 GPU 空闲就调度到哪最大化利用率。按地域分发用户在哪Agent 就调度到最近的集群降低延迟。按合规分发数据敏感度高的 Agent 固定在特定集群不跨域。这三种策略可以组合。比如一个全球部署的客服 Agent可以按地域分发到各区域集群同时每个区域内部按资源分发。实现上Karmada 的 PropagationPolicy 和 OverridePolicy 可以表达这些策略。5.3 跨集群状态同步的难点多集群最大的难点不是调度而是状态同步。一个 Agent 会话如果在集群 A 开始中途因为资源不足迁移到集群 B上下文怎么带过去工具调用的幂等键怎么保证跨集群唯一我的做法是状态集中存储执行分布。所有会话状态存在一个中心化的存储里比如跨集群的 Redis 或数据库执行时从中心拉取状态执行完写回。这样迁移时不需要搬数据只需要在新集群重新拉取状态。幂等键用全局唯一的 UUID配合中心存储做去重。这个方案的代价是中心存储成为瓶颈和单点。所以实践中通常做分片按会话 ID 哈希分片每个分片一个存储实例。这样既保证了全局唯一性又避免了单点。6. 这套东西的边界什么时候不该用6.1 简单场景别过度设计不是所有 Agent 都需要这么重的编排。如果你只是跑一个单轮的问答 Agent或者一个简单的 RAG 查询用 Serverless 函数或者一个简单的 Deployment 就够了。上 CRD、上自定义调度器、上多集群纯属杀鸡用牛刀。判断标准很简单如果你的 Agent 会话不超过 30 秒没有跨步骤状态没有动态派生那就别用这套。直接用一个 HTTP 服务包起来前面挂个负载均衡足够了。6.2 团队能力匹配问题这套方案对团队能力有要求。你需要有人懂 K8s 的扩展机制CRD、Controller、Scheduler Framework有人懂分布式状态管理有人懂 Agent 框架。如果团队里没人有这些经验强行上马会陷入搭起来容易维护起来要命的困境。我的建议是渐进式演进先用最简单的 Deployment 跑起来验证业务价值等业务量上来了再逐步引入 CRD、自定义调度、多集群。每一步都解决一个具体的痛点而不是为了技术而技术。6.3 成本账要算清楚多集群、GPU 共享、中心化存储这些都是有成本的。多集群意味着多套控制面GPU 共享意味着复杂的隔离机制中心化存储意味着额外的网络和存储开销。在业务量不大的时候这些成本可能超过收益。我一般会算一笔账单集群能撑多久如果按当前增长速度单集群还能撑一年那就先别搞多集群把精力放在优化单集群利用率上。等真的撑不住了再考虑扩展。技术选型要跟着业务节奏走不能反过来。7. 我在实际折腾中攒下的几条经验第一条CRD 的 status 设计要舍得花时间。这是整个系统可观测性的基础。我见过太多项目CRD 定义得很漂亮status 就一个 phase 字段结果出问题时两眼一抹黑。多花两天设计 status能省下后面无数个排查的夜晚。第二条探针配置要区分进程健康和会话健康。这个坑我踩过不止一次。默认配置下长会话必被误杀。改成 exec 检查进程 HTTP 检查会话容量问题就解决了。第三条幂等键要贯穿整个调用链。从会话 ID 到任务 ID 到工具调用 ID每一层都要有唯一标识并且这个标识要能透传到最底层的工具。这样任何一层重试都能靠幂等键去重。第四条别急着上多集群。单集群的利用率优化空间往往比想象中大。先把 GPU 共享、弹性伸缩、优先级抢占这些做好可能就够撑很久了。多集群是最后的手段不是第一选择。第五条状态存储要分层。热温冷三层各司其职。全放内存不可靠全放数据库太慢分层是唯一解。分层的关键是同步策略同步频率要根据业务对丢失的容忍度来定没有标准答案。这套东西说到底核心就一句话Agentic 负载需要一套懂会话语义的编排层而 K8s 原生不懂所以要在中间加一层翻译。这层翻译做得好不好决定了你的 Agent 平台是能撑起生产流量还是只能跑跑 Demo。至于ax具体是哪个项目的代号等它的代码仓库公开了上面这些设计思路你拿去对照大概率能对上七八成。