1. 从“ax”这个标题说起一个被低估的运行时编排切口“ax”这个标题乍看像某个命令行工具的缩写或者某个内部项目的代号。但把热搜词摊开来看——agentic、orchestration、runtime、Kubernetes、Karmada、agentic cloud、agentic rag——这条线索就非常清楚了它指向的是面向智能体Agent场景的运行时编排层也就是在 Kubernetes 之上把“智能体”当成一等公民来调度、编排、治理的那套东西。我最早接触这类需求是在一个内部平台项目里。当时团队想把几个 LLM 驱动的自动化任务串起来一个负责抓取和清洗数据一个负责推理和生成一个负责校验和回写。最开始大家用脚本硬串跑得挺欢但一旦任务量上来、节点变多、某个环节超时或崩溃整个链路就变成一团乱麻。那时候我就意识到Agent 编排和传统微服务编排根本不是一回事。传统微服务是无状态、短生命周期、行为可预测的而 Agent 是有状态、长生命周期、行为带随机性的。你没法用同一套调度假设去套它们。“ax”这个切口本质上就是在回答一个问题当你的工作负载从“服务”变成“智能体”Kubernetes 这套底座还够用吗需要补什么这篇文章我会从运行时、编排、调度、可观测性几个层面把这条链路拆开讲清楚。适合已经在用 Kubernetes、正在往 Agent 方向演进的后端工程师、平台工程师以及想搞清楚“agentic cloud”到底在说什么的技术负责人。读完你至少能判断自己团队现在这套东西离“能跑 Agent”还差哪几块。2. 为什么 Agent 场景需要一套新的运行时编排思路2.1 传统 Kubernetes 编排假设在 Agent 场景下的三个失效点Kubernetes 的设计哲学是“声明式 控制器循环 无状态优先”。这套东西在微服务时代几乎无往不利但放到 Agent 场景里有三个假设会直接失效。第一个失效点是生命周期假设。Kubernetes 默认 Pod 是短命的、可随时替换的。但一个 Agent 可能已经积累了上下文、缓存了中间推理结果、持有外部会话状态。你把它当无状态 Pod 杀掉重建等于把它的“记忆”清零。这不是配置问题是模型层面的不匹配。第二个失效点是调度粒度假设。Kubernetes 调度的是 PodPod 里跑什么它不关心。但 Agent 调度关心的是“这个任务该给哪个 Agent”“这个 Agent 当前负载如何”“它手里的工具链是否可用”。调度决策需要感知 Agent 的语义状态而不是只看 CPU 和内存。第三个失效点是失败语义假设。Kubernetes 的失败处理是重启、驱逐、重新调度。但 Agent 失败可能是“推理结果不可信”“工具调用返回异常”“上下文超长被截断”。这些失败需要的是重试策略调整、降级路径切换、人工介入标记而不是简单重启。注意如果你的 Agent 目前还是“无状态函数 外部存储”的形态那 Kubernetes 原生能力基本够用。但一旦 Agent 开始持有内部状态、动态选择工具、多轮交互上面三个失效点就会陆续暴露。2.2 Agentic Orchestration 和传统 Workflow 编排的本质区别很多人第一反应是“这不就是工作流编排吗Airflow、Argo Workflows 不都能干”。我一开始也这么想后来踩了坑才明白区别在哪。传统 Workflow 编排的是确定性 DAG。节点是什么、边怎么连、执行顺序如何在提交时就已经确定。Airflow 的 DAG、Argo 的 Workflow本质都是“先画图再执行”。Agentic Orchestration 编排的是动态决策图。下一步走哪个分支不是预先画好的而是 Agent 在运行时根据当前上下文、工具返回结果、甚至模型自身的推理来决定的。你没法在提交时就把图定死因为图本身是运行时生成的。这就带来一个核心矛盾Kubernetes 的声明式模型要求你描述“最终状态”但 Agent 的运行时行为是“过程涌现”的。解决这个矛盾就是“ax”这类运行时编排层要干的事。它需要在 Kubernetes 的声明式外壳下嵌入一个能感知 Agent 语义状态的运行时。2.3 从 Karmada 毕业看多集群 Agent 调度的信号热搜里有一条“Karmada 正式毕业”这不是巧合。Karmada 解决的是多集群调度和联邦问题。当你的 Agent 分布在多个集群、多个区域甚至多个云上时单集群的 Kubernetes 调度器就不够用了。Karmada 的毕业意味着多集群编排这件事在社区里已经成熟到可以生产落地。而 Agent 场景天然就是多集群的推理集群、工具集群、数据集群可能物理隔离不同区域的 Agent 需要就近调度合规要求可能强制某些 Agent 只能在特定区域运行。所以“ax”这个切口如果往深了看它不只是单集群内的 Agent 编排而是跨集群、跨区域的 Agent 运行时治理。这也是为什么热搜里同时出现了 Kubernetes 和 Karmada——前者是底座后者是扩展。3. 核心组件拆解一个 Agent 运行时到底需要什么3.1 运行时层Agent Runtime 和 Container Runtime 的关系热搜里有一条报错很典型“container runtime is not running”。这是 Kubernetes 节点上容器运行时没起来。但在 Agent 场景里我们说的“runtime”往往是两层容器运行时和Agent 运行时。容器运行时containerd、CRI-O负责跑容器这是 Kubernetes 的地基。Agent 运行时负责跑 Agent 的逻辑循环接收任务、加载上下文、调用模型、选择工具、执行动作、回写结果。这两层是嵌套关系Agent 运行时跑在容器里容器跑在容器运行时上。我见过不少团队把这两层混在一起结果排查问题时完全找不到北。比如 Agent 行为异常你以为是模型问题其实是容器被 OOM Kill 了你以为是调度问题其实是 Agent 运行时自己的队列堵了。分层排查是基本功先确认容器运行时健康再确认 Agent 运行时健康最后才看模型和工具。3.2 编排层从 Pod 编排到 Agent 编排的映射把 Agent 映射到 Kubernetes 资源上有几种常见做法各有取舍。映射方式实现手段优点缺点Agent as Pod每个 Agent 一个 Pod隔离性好资源限制清晰状态难保持扩缩容粒度粗Agent as Deployment一组同构 Agent 副本易扩缩容滚动更新方便不适合有状态 AgentAgent as StatefulSet带稳定标识的 Agent状态可持久化网络标识稳定运维复杂度高Agent as CRD自定义资源 控制器语义贴合可扩展性强开发成本高需要写控制器我个人的经验是无状态 Agent 用 Deployment有状态 Agent 用 StatefulSet需要复杂生命周期管理的用 CRD。不要一上来就上 CRD那是给自己找麻烦。先用 Deployment 跑通等真的遇到 Deployment 表达不了的需求再考虑自定义资源。3.3 调度层Agent 感知调度需要哪些额外信号Kubernetes 默认调度器看的是资源请求、亲和性、污点容忍。Agent 调度还需要额外信号Agent 能力标签这个 Agent 会哪些工具、支持哪些模型、擅长哪类任务上下文负载当前上下文窗口用了多少还剩多少余量工具可用性依赖的外部工具当前是否健康会话亲和性同一个会话的请求尽量落到同一个 Agent 实例这些信号没法直接塞进 Kubernetes 原生调度器通常的做法是写一个调度扩展Scheduler Extender或者自定义调度器。Karmada 在多集群层面也提供了类似的扩展点。实操心得调度扩展不要做太重。我见过一个团队把模型推理延迟也塞进调度决策结果调度器自己成了瓶颈。调度决策应该是轻量的、基于缓存的重逻辑放到 Agent 运行时里做。4. 实操落地从零搭一个最小 Agent 编排原型4.1 环境准备与依赖确认先确认底座健康。这一步看起来废话但我踩过的坑里有一半是底座没弄好。# 确认容器运行时 systemctl status containerd crictl info # 确认 Kubernetes 节点状态 kubectl get nodes -o wide kubectl get pods -A | grep -v Running # 确认 Karmada 控制面如果用了多集群 kubectl --context karmada-host get pods -n karmada-system如果看到 “container runtime is not running”先别急着往下走。检查 containerd 配置、cgroup 驱动是否和 kubelet 一致。这个报错在 Debian 系和 Ubuntu 系上表现还不太一样Debian 上常见的是 cgroup 驱动不匹配。4.2 定义 Agent 的自定义资源我用一个简化版的 CRD 来示意。真实生产里字段会更多但核心结构就这些。apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: agents.ax.example.com spec: group: ax.example.com versions: - name: v1alpha1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: model: type: string tools: type: array items: type: string maxContextTokens: type: integer sessionAffinity: type: boolean scope: Namespaced names: plural: agents singular: agent kind: Agent shortNames: - ag这个 CRD 定义了 Agent 的模型、工具列表、上下文上限、是否开启会话亲和。字段不多但足够表达一个 Agent 的核心身份。4.3 编写 Agent 控制器核心逻辑控制器干的事就是监听 Agent 资源变化确保对应的运行时工作负载存在且健康。我用 Python 的 kopf 框架示意因为它写起来最直观。import kopf import kubernetes kopf.on.create(ax.example.com, v1alpha1, agents) def create_agent(spec, name, namespace, **kwargs): model spec.get(model, default) tools spec.get(tools, []) max_ctx spec.get(maxContextTokens, 8192) # 生成 Deployment deployment { apiVersion: apps/v1, kind: Deployment, metadata: {name: fagent-{name}, namespace: namespace}, spec: { replicas: 1, selector: {matchLabels: {app: fagent-{name}}}, template: { metadata: {labels: {app: fagent-{name}}}, spec: { containers: [{ name: agent-runtime, image: ax/agent-runtime:latest, env: [ {name: MODEL, value: model}, {name: TOOLS, value: ,.join(tools)}, {name: MAX_CONTEXT_TOKENS, value: str(max_ctx)}, ], resources: { requests: {cpu: 500m, memory: 1Gi}, limits: {cpu: 2, memory: 4Gi}, } }] } } } } api kubernetes.client.AppsV1Api() api.create_namespaced_deployment(namespacenamespace, bodydeployment)这段逻辑的核心是Agent 资源是“意图”Deployment 是“实现”。用户只描述想要一个什么样的 Agent控制器负责把它翻译成 Kubernetes 能跑的工作负载。这就是声明式编排在 Agent 场景的落地方式。4.4 会话亲和与状态保持的实现会话亲和是 Agent 编排里最容易做错的地方。Kubernetes Service 默认是轮询同一个会话的请求会被打到不同 Pod 上上下文就断了。我的做法是用StatefulSet Headless Service让每个 Agent 实例有稳定的网络标识然后在入口层做会话路由。apiVersion: v1 kind: Service metadata: name: agent-headless spec: clusterIP: None selector: app: agent-runtime ports: - port: 8080入口层根据 session id 做一致性哈希把同一会话的请求固定到同一个 Pod。这个哈希表可以放在 Redis 里也可以放在入口网关的内存里。我倾向于放 Redis因为入口网关可能多副本内存哈希表对不齐。注意会话亲和和自动扩缩容是天然矛盾的。扩缩容会改变 Pod 集合哈希环会变部分会话会漂移。解决办法是给会话加 TTL或者用一致性哈希的虚拟节点减少漂移比例。这个坑我在生产环境踩过扩缩容一次一批会话上下文全丢。5. 可观测性与问题排查Agent 跑起来之后怎么盯5.1 Agent 场景下需要额外采集哪些指标Prometheus 默认采集的指标在 Agent 场景下不够用。除了 CPU、内存、网络你还需要上下文窗口使用率当前用了多少 token离上限还有多远工具调用成功率按工具维度拆分哪个工具老失败推理延迟分布P50、P95、P99模型推理的尾延迟往往很夸张会话中断率多少会话因为超时、错误、上下文溢出而中断重试次数分布哪些 Agent 在疯狂重试这些指标没法从容器层面直接拿到需要 Agent 运行时主动暴露。我通常会在 Agent 运行时里埋一个 metrics endpoint用 Prometheus 的 client library 暴露自定义指标。5.2 常见报错速查表报错信息根因处理方式container runtime is not running容器运行时未启动或 cgroup 不匹配检查 containerd 状态和 cgroup 驱动no lm runtime found for model format gguf模型格式与运行时后端不匹配确认推理后端支持该格式或转换模型could not find the webview2 runtime桌面端依赖缺失安装对应运行时组件unable to locate the codex cli binaryCLI 未安装或 PATH 不对确认安装路径并加入 PATHOOMKilled内存限制过小或上下文泄漏调大 limit检查上下文释放逻辑这张表是我从实际排查记录里整理出来的覆盖了热搜里出现的大部分报错。核心思路是先分层再定位。容器层的问题看 kubelet 和容器运行时日志Agent 层的问题看运行时日志和自定义指标模型层的问题看推理后端日志。5.3 上下文溢出和工具调用超时的处理策略上下文溢出是 Agent 场景的高频问题。模型上下文窗口就那么大多轮对话加上工具返回结果很容易撑爆。我的处理策略是三层第一层是预防。在 Agent 运行时里做 token 计数接近上限时主动触发摘要或截断。摘要用一个小模型做成本低。第二层是降级。溢出时不是直接报错而是切换到更短的上下文策略只保留最近 N 轮或者只保留系统提示和最后一轮。第三层是兜底。真的溢出了返回一个明确的错误码让上游决定是重试还是人工介入。不要静默截断静默截断会让 Agent 行为变得不可预测。工具调用超时类似。工具调用要有独立的超时预算不能和模型推理共用一个超时。工具超时后要有重试策略但重试次数要限制否则会放大下游压力。6. 多集群与 Agentic Cloud 的演进方向6.1 Karmada 在多集群 Agent 调度中的角色Karmada 的核心价值是把多个 Kubernetes 集群当成一个逻辑集群来用。在 Agent 场景里这意味着你可以把推理密集型 Agent 调度到 GPU 集群把工具密集型 Agent 调度到通用计算集群把数据敏感型 Agent 限制在特定区域集群在集群故障时自动迁移 Agent 工作负载Karmada 的 PropagationPolicy 可以表达这些调度意图。比如把带agent-type: inference标签的 Agent 调度到有 GPU 的集群。apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: inference-agent-policy spec: resourceSelectors: - apiVersion: ax.example.com/v1alpha1 kind: Agent labelSelector: matchLabels: agent-type: inference placement: clusterAffinity: clusterNames: - gpu-cluster-1 - gpu-cluster-2这段配置的意思是所有带agent-type: inference标签的 Agent只调度到 GPU 集群。这就是多集群 Agent 调度的基本玩法。6.2 Agentic RAG 对运行时提出的新要求Agentic RAG 是热搜里的另一个关键词。传统 RAG 是“检索一次生成一次”Agentic RAG 是“检索、评估、再检索、再生成”的循环。这对运行时提出了新要求检索步骤要可编排每次检索是一个独立的运行时步骤可以重试、可以降级评估步骤要可观测检索质量好不好要有指标循环要有终止条件不能无限循环要有最大轮次和收敛判断这些要求意味着 Agent 运行时不能只是一个“请求-响应”的壳它需要内建步骤编排能力。这也是为什么我说“ax”这个切口本质上是运行时编排而不是简单的 Agent 托管。6.3 从单集群到 Agentic Cloud 的演进路径我给一条务实的演进路径分四步第一步单集群跑通。用 Deployment 或 StatefulSet 跑 Agent把基本生命周期管理做起来。第二步引入自定义资源。当 Deployment 表达不了你的需求时上 CRD 和控制器。第三步多集群调度。当单集群资源不够、或者有区域合规要求时引入 Karmada。第四步运行时治理。把可观测性、调度策略、失败处理、成本控制都收敛到运行时层形成统一的 Agent 治理平面。这四步不用一次做完但每一步都要想清楚下一步的接口。我见过太多团队第一步就用 CRD结果控制器写了一堆业务逻辑反而没跑通。先用最简单的方式跑通再逐步抽象这是我在多个项目里验证过的节奏。7. 一些踩坑之后的个人体会Agent 编排这件事最难的从来不是技术选型而是心智模型的转变。你习惯了 Kubernetes 那套“声明式、无状态、可替换”的思维突然要面对“有状态、动态决策、上下文敏感”的 Agent会很不适应。我自己的体会是把 Agent 当成“有记忆的服务”来对待。它有状态所以要考虑状态持久化和迁移它有记忆所以要考虑上下文管理和溢出它会做决策所以要考虑决策的可观测性和可干预性。这三条想清楚了技术方案自然就出来了。还有一个坑是过度编排。不是所有 Agent 都需要复杂的编排层。如果你的 Agent 就是“接收请求、调用模型、返回结果”那一个 Deployment 加一个 Service 就够了。编排层的复杂度应该和 Agent 的复杂度匹配不要为了架构而架构。最后分享一个实用技巧给每个 Agent 加一个“健康探针”但探针逻辑不要只检查进程存活要检查 Agent 的核心能力是否可用。比如检查模型是否可调用、工具是否可达、上下文是否可读写。这样 Kubernetes 的 liveness probe 才能真正反映 Agent 的健康状态而不是“进程还在但已经废了”。这个技巧帮我在生产环境提前发现了好几次模型后端挂掉但 Agent 进程还活着的情况。