★ FEATURED ARTICLE 1. 从“ax”这个标题说起一个被低估的运行时编排切口第一次看到“ax”这个标题很多人会以为是某个命令行工具的缩写或者某个内部代号。但把热搜词摊开来看——agentic、orchestration、runtime、Kubernetes、Karmada、codemeter runtime、webview2 runtime、container runtime is not running——这些词拼在一起指向的其实是一个非常具体的工程命题在 Kubernetes 之上如何为 agentic 工作负载提供一个可编排、可观测、可复现的运行时层。“ax”在这里我更愿意把它理解为一个“轴”axis的隐喻它不是一个完整的平台而是一条贯穿 agent 调度、运行时隔离、依赖注入和生命周期管理的轴线。你把它插在哪里哪里的 agent 就能被统一编排你不插每个 agent 就是一座孤岛各自带着自己的 runtime 依赖、各自的启动脚本、各自的日志格式。这篇文章适合三类人看第一类是在 Kubernetes 上跑过普通微服务、但还没碰过 agentic 工作负载的工程师第二类是被 “container runtime is not running” 这类报错折磨过、想搞清楚 runtime 分层的人第三类是想把 agent 从“本地脚本”推进到“集群化编排”的团队技术负责人。我会从设计思路讲到实操细节再到踩坑记录尽量把每个“为什么”都说清楚。提示本文里的“ax”是一个抽象层命名你可以把它替换成你团队内部的项目代号核心逻辑不变。2. 为什么 agentic 工作负载需要独立的 orchestration runtime2.1 普通微服务和 agent 的本质差异普通微服务的生命周期是相对确定的启动、监听端口、处理请求、优雅退出。Kubernetes 的 Deployment、Service、HPA 这套组合拳就是为这种模型设计的。但 agentic 工作负载不一样它的核心特征是决策链不确定——一个 agent 可能在运行过程中动态调用工具、派生新的子 agent、修改自己的执行计划甚至根据中间结果决定要不要继续。这就带来一个直接问题Kubernetes 原生对象描述的是“期望状态”而 agent 需要的是“期望能力”。你没法用一个 ReplicaSet 去描述“这个 agent 需要能访问向量库、能调用代码解释器、能在超时后自动降级”。所以必须在 Kubernetes 之上再加一层 orchestration runtime把能力声明翻译成具体的 Pod 模板、Sidecar 注入和资源配额。我试过直接用裸 Deployment 跑 agent结果是每个 agent 的 Dockerfile 里都塞了一堆 Python 依赖和模型文件镜像动辄几个 GB启动一次要等两三分钟。更麻烦的是当 agent 需要调用外部工具时你得手动挂载 ConfigMap 或者 Secret完全没有统一入口。这就是“ax”要解决的问题把 agent 的运行时依赖从镜像里剥出来变成可编排的声明式配置。2.2 运行时分层的必要性从 container runtime 到 agent runtime热搜词里反复出现 “container runtime is not running” 和 “no lm runtime found for model format gguf”这两个报错其实暴露了同一个问题运行时是有层级的上层依赖下层下层没起来上层一定报错。在 Kubernetes 里这个层级大致是这样的层级组件示例职责容器运行时containerd、CRI-O拉镜像、起容器、管 cgroup编排运行时kubelet、kube-scheduler调度 Pod、维持期望状态应用运行时Python venv、JVM、Node提供语言级执行环境Agent 运行时ax runtime管理工具调用、记忆、决策循环很多团队出问题是因为把 agent 运行时和容器运行时混在一起谈。比如 “container runtime is not running” 是 containerd 没起来跟 agent 逻辑一点关系都没有“no lm runtime found for model format gguf” 是应用运行时缺了推理后端跟 Kubernetes 调度也没关系。搞清楚每一层负责什么排查问题时才能快速定位。2.3 为什么选 Kubernetes 作为底座而不是自研调度有人会问agent 调度这么特殊为什么不自己写一个调度器我的经验是除非你的规模到了需要自研存储和网络的程度否则 Kubernetes 提供的 Pod 生命周期、健康检查、资源隔离、滚动更新这几样东西已经能覆盖 80% 的需求。自研调度器最大的坑不是调度算法而是故障恢复和状态一致性——节点挂了怎么办、Pod 卡在 Terminating 怎么办、镜像拉取失败怎么重试这些 Kubernetes 都帮你处理了。“ax”的定位就是在 Kubernetes 之上做一层薄薄的 orchestration不重复造轮子只补 Kubernetes 缺的那部分agent 能力声明、工具注入、记忆挂载和决策链追踪。Karmada 最近正式毕业这件事也说明多集群编排正在成为 agentic cloud 的基础设施而单集群内的 agent 编排用 Kubernetes 原生能力加一层自定义控制器就够了。3. ax runtime 的核心设计能力声明与依赖注入3.1 用 CRD 描述 agent 能力而不是镜像ax 的核心设计决策是agent 的能力用 Custom Resource 描述而不是写死在镜像里。我定义了一个叫AgentRuntime的 CRD大致长这样apiVersion: ax.io/v1alpha1 kind: AgentRuntime metadata: name: research-agent spec: baseImage: python:3.11-slim tools: - name: web-search endpoint: http://tool-websearch:8080 - name: code-interpreter endpoint: http://tool-codeinterp:8080 memory: vectorStore: redis://memory-redis:6379 maxContextTokens: 8192 runtime: type: langgraph checkpoint: s3://ax-checkpoints/research-agent resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi这样做的直接好处是镜像可以做得非常薄只装语言运行时和 ax 的 agent SDK工具和记忆全部通过 Sidecar 或者外部服务注入。镜像从几个 GB 降到几百 MB启动时间从两三分钟降到十几秒。更重要的是同一个镜像可以跑不同的 agent 配置不需要为每个 agent 单独构建镜像。3.2 Sidecar 注入模式的选择init container 还是 ambient工具注入有两种常见模式一种是 init container 在 Pod 启动前把工具二进制或者配置拉下来另一种是 Sidecar 常驻agent 通过 localhost 调用。我两种都试过最后选了 Sidecar 为主、init container 为辅的混合模式。init container 适合做一次性准备比如拉取模型权重、初始化向量库索引、生成配置文件。这些操作只需要执行一次放在 init container 里不会占用主容器的生命周期。Sidecar 适合做持续服务比如 web-search 代理、code interpreter、日志收集。agent 通过localhost:8080调用 Sidecar不需要走 Service延迟更低也不需要额外的网络策略。注意Sidecar 模式下agent 容器和 Sidecar 共享网络命名空间端口不能冲突。我踩过一次坑agent 自己监听了 8080Sidecar 也监听 8080结果 Sidecar 起不来Pod 一直 CrashLoopBackOff。后来统一规定 agent 主进程用 9000 以上端口Sidecar 用 8000 以下再没出过问题。3.3 记忆层的挂载策略为什么不用 emptyDiragent 的记忆层是它和普通微服务最大的区别。普通微服务是无状态的agent 是有状态的——它需要记住之前的对话、工具调用结果、中间决策。Kubernetes 里挂载存储有几种选择emptyDir、hostPath、PVC、ConfigMap。emptyDir 最简单但 Pod 重启就丢hostPath 绑定节点调度不灵活ConfigMap 有大小限制不适合存向量。ax 的选择是短期记忆用 emptyDir 定期 checkpoint 到对象存储长期记忆用外部向量库。具体来说agent 运行时把当前会话的上下文写在 emptyDir 里每 N 步或者每次工具调用后把 checkpoint 写到 S3 兼容的对象存储。如果 Pod 挂了新 Pod 从最近的 checkpoint 恢复不会丢失整个决策链。长期记忆比如用户偏好、历史知识放在独立的向量库里通过 Sidecar 或者直接 HTTP 调用访问。这个策略的代价是需要在 agent SDK 里实现 checkpoint 逻辑好处是 Pod 变成“可抛弃”的调度器可以随便把它挪到任何节点不需要考虑本地状态。4. 实操在 Kubernetes 上部署 ax runtime 的完整流程4.1 环境准备与前置检查在开始之前先确认你的集群满足几个条件。我用的是 Kubernetes v1.26.0这是热搜词里出现的版本也是目前比较稳定的一个版本。你需要一个可用的 Kubernetes 集群至少 3 个 worker 节点每个节点 4C8G 以上containerd 作为容器运行时确认systemctl status containerd是 running一个 S3 兼容的对象存储用于 checkpoint一个 Redis 实例用于短期记忆和工具注册先跑一遍 preflight 检查这是我从 kubeadm 的 preflight 逻辑里抄来的思路# 检查容器运行时 crictl info | grep -i runtimeType # 检查节点资源 kubectl top nodes # 检查存储类 kubectl get storageclass # 检查 DNS kubectl run -it --rm debug --imagebusybox --restartNever -- nslookup kubernetes.default如果crictl info报 “container runtime is not running”先别急着往下走把 containerd 修好再说。我见过太多人跳过这一步后面 Pod 起不来又回头查浪费几个小时。4.2 安装 ax controller 和 CRDax controller 是一个标准的 Kubernetes controller用 Kubebuilder 生成骨架核心逻辑是 watchAgentRuntime资源然后 reconcile 出对应的 Deployment、Service、ConfigMap 和 Sidecar 注入配置。# 安装 CRD kubectl apply -f https://raw.githubusercontent.com/ax-project/ax/main/config/crd/bases/ax.io_agentruntimes.yaml # 部署 controller kubectl apply -f https://raw.githubusercontent.com/ax-project/ax/main/config/manager/manager.yaml # 确认 controller 起来 kubectl get pods -n ax-systemcontroller 起来后它会监听所有命名空间里的AgentRuntime资源。你创建一个AgentRuntime它就会在同一个命名空间里生成对应的 Deployment。这里有个细节controller 生成的 Deployment 名字是ax-agentruntime-nameService 名字是ax-agentruntime-name-svc方便你后续做网络策略。4.3 编写第一个 AgentRuntime 配置我拿一个最简单的 research agent 举例它需要 web-search 和 code-interpreter 两个工具记忆用 Redischeckpoint 用 MinIO。apiVersion: ax.io/v1alpha1 kind: AgentRuntime metadata: name: research-agent namespace: default spec: baseImage: ghcr.io/ax-project/agent-base:python3.11 tools: - name: web-search image: ghcr.io/ax-project/tool-websearch:latest port: 8080 - name: code-interpreter image: ghcr.io/ax-project/tool-codeinterp:latest port: 8081 memory: vectorStore: redis://redis.default:6379 checkpoint: endpoint: http://minio.default:9000 bucket: ax-checkpoints accessKeySecret: minio-credentials runtime: type: langgraph maxSteps: 50 timeoutSeconds: 300 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4Gi应用这个配置kubectl apply -f research-agent.yaml kubectl get agentruntime research-agent -o yaml kubectl get pods -l ax.io/agentresearch-agent正常情况下你会看到三个容器在同一个 Pod 里agent 主容器、web-search Sidecar、code-interpreter Sidecar。agent 主容器通过localhost:8080和localhost:8081调用工具。4.4 验证运行时和排查启动问题Pod 起来后先看日志kubectl logs -l ax.io/agentresearch-agent -c agent --tail100 kubectl logs -l ax.io/agentresearch-agent -c web-search --tail50如果 agent 容器报 “no lm runtime found for model format gguf”说明你的 agent 配置里指定了本地模型但基础镜像里没装推理后端。解决办法是在baseImage里换一个带 llama.cpp 或者 vLLM 的镜像或者在tools里加一个推理 Sidecar。如果 Sidecar 报 “could not find the webview2 runtime”那是 Windows 容器的问题Linux 集群不会遇到。但如果你确实在混合集群里跑记得给 Windows 节点打上 taint别让 Linux agent 调度过去。5. 编排层的关键细节从单 agent 到多 agent 协作5.1 agent 之间的通信模式单 agent 跑通之后下一步就是多 agent 协作。ax 支持两种通信模式直接调用和消息队列。直接调用就是 agent A 通过 HTTP 调用 agent B 的 Service适合同步、短链路的场景。消息队列用 Redis Stream 或者 NATS适合异步、长链路、需要解耦的场景。我一般建议如果两个 agent 的交互是“请求-响应”模式用直接调用如果是“发布-订阅”或者“流水线”模式用消息队列。直接调用的延迟低但耦合度高消息队列解耦好但需要处理消息顺序和重复消费。5.2 决策链追踪与可观测性agent 的决策链追踪是个容易被忽略但非常重要的点。普通微服务出问题你看调用链就知道哪一步慢了。agent 出问题你可能连它为什么调用某个工具都不知道。ax 的做法是在 agent SDK 里埋点每次决策、每次工具调用、每次记忆读写都打一个 span通过 OpenTelemetry 导出到 Jaeger 或者 Tempo。from ax.runtime import AgentRuntime from ax.tracing import trace runtime AgentRuntime.from_env() trace(decision) def decide_next_action(context): # agent 决策逻辑 pass trace(tool_call) def call_tool(tool_name, params): # 工具调用逻辑 pass这样你就能在 Jaeger 里看到完整的决策链agent 收到输入 - 检索记忆 - 决定调用 web-search - 拿到结果 - 决定调用 code-interpreter - 生成最终回答。哪一步耗时最长、哪一步出错一目了然。5.3 资源配额与并发控制agent 的资源消耗和普通微服务不一样。普通微服务是稳态的CPU 和内存曲线比较平。agent 是脉冲式的决策的时候 CPU 飙高等工具返回的时候又降下来。如果按峰值配资源浪费按均值配又容易 OOM。我的做法是requests 按均值配limits 按峰值的 1.5 倍配同时用 HPA 基于自定义指标比如队列长度做扩缩容。ax controller 会在生成的 Deployment 里加上ax.io/agent-metrics的 annotationPrometheus 通过这个 annotation 抓取 agent 的队列长度和决策延迟HPA 根据这些指标决定要不要加 Pod。提示agent 的 HPA 不要用 CPU 作为主要指标因为 agent 大部分时间在等 IOCPU 利用率很低。用队列长度或者待处理任务数更准确。6. 常见问题与排查技巧实录6.1 启动阶段的高频报错报错信息根因解决办法container runtime is not runningcontainerd 或 CRI-O 没起来systemctl restart containerd检查/etc/containerd/config.tomlno lm runtime found for model format gguf基础镜像缺推理后端换带 llama.cpp 的镜像或加推理 Sidecarcould not find the webview2 runtimeWindows 容器缺 WebView2只在 Windows 节点跑或换 Linux 镜像unable to locate the codex cli binaryagent SDK 没装全检查 baseImage 的 entrypoint确认 PATH[ERROR CRI]: container runtime is not runningkubelet 连不上 CRI检查 kubelet 的--container-runtime-endpoint6.2 运行阶段的典型问题问题一agent 卡在某个工具调用上不返回。这种情况多半是工具 Sidecar 挂了但 agent 没有超时机制。解决办法是在 agent SDK 里给每个工具调用加超时超时后走降级逻辑。ax 的默认超时是 30 秒可以在AgentRuntime的runtime.timeoutSeconds里改。问题二checkpoint 写入失败导致 Pod 重启后状态丢失。先检查 MinIO 的凭证 Secret 是否存在再检查 bucket 权限。我遇到过 Secret 名字写错一个字母排查了半小时。建议在 controller 里加一个 preflight 检查Secret 不存在就直接拒绝创建。问题三多 agent 协作时消息重复消费。如果用 Redis Stream 做消息队列记得用 consumer group并且在处理完消息后显式 ACK。ax 的 SDK 里封装了ack和nack但如果你自己写消费逻辑很容易漏掉。6.3 性能调优的独家经验第一Sidecar 的资源限制要单独配。很多人只配了 agent 主容器的 resourcesSidecar 用默认值结果 Sidecar 被 OOM killagent 跟着挂。我的做法是给每个 Sidecar 配requests: 100m/128Milimits: 500m/512Mi足够跑工具代理了。第二checkpoint 频率不要太高。每步都 checkpoint 会拖慢 agent而且对象存储的写入费用也不低。我的经验是每 5 步或者每 30 秒 checkpoint 一次平衡性能和可靠性。第三用 PodDisruptionBudget 保护 agent Pod。agent 是有状态的滚动更新的时候如果一次杀掉太多会导致大量 checkpoint 恢复。给每个AgentRuntime配一个 PDBminAvailable: 50%更新的时候一批一批来。7. 从单集群到多集群ax 的扩展路径单集群跑通之后下一步自然是多集群。Karmada 正式毕业这件事给了一个很好的信号多集群编排的标准化程度越来越高。ax 的扩展思路是把AgentRuntime作为 Karmada 的 FederatedResource通过 PropagationPolicy 决定哪些 agent 跑在哪些集群。比如你可以规定research agent 跑在 GPU 集群code-interpreter 跑在 CPU 集群记忆层跑在存储优化集群。Karmada 负责把AgentRuntime分发到目标集群ax controller 在各自集群里 reconcile 出具体的 Pod。跨集群的 agent 通信通过 Karmada 的 MultiClusterService 暴露agent A 在集群 1agent B 在集群 2互相调用就像在同一个集群里一样。这个路径的难点不在技术而在网络延迟和故障域。跨集群调用比同集群调用慢一个数量级如果 agent 的决策链里有大量跨集群工具调用整体延迟会很难看。我的建议是把交互频繁的 agent 放在同一个集群跨集群只做粗粒度的任务分发。8. 我个人在实际操作中的几点体会ax 这套东西我前后迭代了三个版本踩过的坑比写过的代码还多。最大的体会是不要试图用一套配置覆盖所有 agent。早期我想做一个“万能 AgentRuntime”结果配置项膨胀到几十个没人看得懂。后来改成“基础配置 场景化 overlay”research agent 一套、coding agent 一套、data agent 一套每套只暴露必要的配置项维护成本降了一大半。另一个体会是运行时的问题80% 出在依赖没对齐。agent 镜像里的 Python 版本、工具 Sidecar 的协议版本、checkpoint 的格式版本这三者必须对齐。我现在的做法是在AgentRuntime里加一个version字段controller 在 reconcile 的时候检查版本兼容性不兼容直接报错不让它跑到运行阶段再炸。最后分享一个小技巧用kubectl debug进 agent Pod 排查问题的时候记得加--targetagent不然你进的是 Sidecar 的命名空间看不到 agent 主进程的文件系统。这个细节很小但能省你不少时间。
阅读完成 · 觉得有帮助？
