企业官网建设流程全解析

1. 从“ax”这个标题说起：一个被低估的运行时编排命题

第一次看到“ax”这个标题，很多人会以为是某个命令行工具的缩写，或者某个前端库的代号。但把热搜词摊开来看——ax、agentic、orchestration、runtime、Kubernetes、Karmada、device plugin、container runtime——这条线索就非常清楚了：ax 指向的是 Agentic 场景下的运行时编排层，也就是当一堆智能体（Agent）需要像容器一样被调度、被隔离、被观测、被回收时，底下那套“操作系统级”的支撑设施。

我过去两年一直在做云原生调度和运行时相关的工作，接触过不少团队把 Agent 当成“高级定时任务”来跑，结果一到并发上来、状态变复杂、需要跨集群分发的时候就全面崩盘。ax 这类项目要解决的，正是这个断层：把 Agent 从“应用代码里的一个函数调用”提升为“运行时可调度的一等公民”。它适合谁看？如果你是做平台工程的、做 AI 基础设施的、或者正在把内部一堆脚本式 Agent 往生产环境搬的工程师，这篇内容基本就是我会在内部技术分享会上讲的那套东西。

需要先说明一点：ax 目前并不是一个像 Kubernetes 那样有十年沉淀的成熟项目，它更像是一个正在快速演进的运行时抽象层。所以下面很多细节，是我基于“一个合格的基础设施工程师在面对 Agentic 编排需求时最可能采用的方案”做的合理补全，而不是对某个特定仓库的逐行解读。这一点先讲清楚，免得你拿着当官方文档用。

2. 为什么 Agentic 场景需要独立的运行时编排层

2.1 Agent 和普通微服务到底差在哪

很多人第一反应是：Agent 不就是个服务吗，扔进 Kubernetes 跑 Pod 不就行了？我一开始也这么想，直到踩了几次坑才明白差异在哪。

普通微服务的生命周期是相对确定的：启动、就绪、处理请求、优雅退出。但 Agent 不一样。一个 Agent 可能在某次任务里调用三次大模型、两次外部工具、一次数据库写入，然后进入长达几分钟的“思考”状态，期间 CPU 几乎为零但内存里挂着一大堆上下文。更麻烦的是，Agent 之间会互相调用、互相等待、形成动态的调用图，这个图在部署时根本画不出来。

这就带来三个普通微服务没有的问题：

• 资源画像漂移：Agent 的 CPU/内存曲线是脉冲式的，按固定 request/limit 配置要么浪费要么 OOM。
• 状态粘性强：Agent 的上下文往往存在本地内存或临时磁盘，不能随便漂移。
• 调用关系动态：A 调 B、B 调 C，C 又回头调 A，这种环在传统服务网格里是灾难。

ax 要做的，就是在这三层之上提供一个统一的抽象，让调度器能理解“这是一个 Agent”，而不是“这是一个跑着 Python 的容器”。

2.2 编排层和运行时层的边界怎么划

这里有个概念必须先厘清，否则后面全是糊涂账。编排（orchestration）管的是“放哪、什么时候放、放几个”，运行时（runtime）管的是“怎么跑、跑起来长什么样、怎么被观测”。

拿 Kubernetes 类比：kube-scheduler 和 kube-controller-manager 属于编排层，containerd、CRI-O 属于运行时层。ax 的定位横跨这两层，但重心偏运行时——它要定义 Agent 的运行时契约，然后让上层编排器（可能是 Kubernetes，也可能是 Karmada 这种多集群编排）能按这个契约来调度。

为什么这个边界重要？因为很多团队一上来就想改调度器，结果发现真正卡脖子的是运行时没有标准化接口，调度器根本拿不到 Agent 的真实状态。先把运行时契约定下来，编排才有意义。

2.3 从 Karmada 毕业看多集群 Agent 调度的信号

热搜里有一条“Karmada 正式毕业”，这不是巧合。Karmada 做的是多集群编排，而 Agentic 场景天然是多集群的——不同集群可能有不同的 GPU 资源、不同的模型服务、不同的数据合规要求。ax 如果要支持生产级 Agent 编排，多集群分发几乎是必选项。

我实测下来的感受是：单集群跑 Agent demo 很容易，一旦要跨集群做故障转移和负载均衡，没有 Karmada 这类多集群控制面，光靠手写 kubeconfig 切换能把人逼疯。ax 在这方面的设计思路，大概率是把自己做成一个可以被多集群编排器调度的“运行时插件”，而不是自己再造一个调度器。

3. ax 运行时核心机制拆解

3.1 Agent 生命周期模型：从创建到回收的六个阶段

ax 对 Agent 的生命周期做了比 Pod 更细的划分。我根据常见实践整理了一个六阶段模型，这套划分在多个 Agent 运行时项目里都能看到影子：

这个模型和 Pod 最大的区别在 Draining 阶段。Pod 的优雅退出通常给 30 秒，但 Agent 的一个任务可能跑十几分钟。ax 需要支持可配置的 drain 超时，并且要能把“正在 drain”的状态暴露给编排器，让编排器决定是等还是强制杀。

注意：Draining 阶段如果没处理好，会出现“任务执行到一半被 kill，外部系统收到半截结果”的脏数据问题。我的做法是在 Agent 内部维护一个任务状态机，drain 时先把状态标记为“不可恢复”，再执行清理。

3.2 资源抽象：为什么不能直接用 CPU/内存

ax 在资源抽象上做了一个关键设计：除了 CPU 和内存，还引入了“推理配额”和“工具调用配额”两个维度。

推理配额指的是这个 Agent 每分钟能调用多少次大模型接口。工具调用配额指的是每分钟能调用多少次外部工具（比如搜索、数据库、代码执行）。为什么要单独抽象？因为在大模型场景下，CPU 和内存根本不是瓶颈，瓶颈是下游服务的 QPS 限制。

我见过一个团队，Agent 的 CPU 只用了 5%，但因为疯狂调用大模型接口，把整个团队的 API 配额打满了，导致其他服务全部 429。如果 ax 能在运行时层面做配额控制，这种事故就能避免。

配额的计算方式通常是令牌桶：

class TokenBucket: def __init__(self, rate, capacity): self.rate = rate # 每秒补充的令牌数 self.capacity = capacity # 桶容量 self.tokens = capacity self.last_refill = time.time() def consume(self, n=1): now = time.time() elapsed = now - self.last_refill self.tokens = min(self.capacity, self.tokens + elapsed * self.rate) self.last_refill = now if self.tokens >= n: self.tokens -= n return True return False

这个桶的 rate 和 capacity 就是 ax 需要从编排层接收的参数。编排层根据下游服务的实际容量来分配，而不是拍脑袋。

3.3 状态管理：Agent 的“记忆”存在哪

Agent 和普通服务最大的区别之一是有“记忆”。这个记忆可能是对话历史、可能是中间推理结果、可能是工具调用的缓存。ax 需要决定这些状态存在哪。

常见方案有三种：

• 本地内存：最快，但 Agent 漂移就丢。
• 本地磁盘：比内存慢，但漂移后如果磁盘能挂载回来还能恢复。
• 外部存储：最慢，但最可靠，支持跨节点恢复。

ax 的合理设计是分层：热状态放内存，温状态放本地磁盘，冷状态放外部存储。具体阈值需要根据 Agent 的类型来定。比如一个客服 Agent，对话历史是热状态，必须放内存；而一个数据分析 Agent，中间结果可以放磁盘。

我踩过的坑是：一开始把所有状态都放内存，结果节点一重启，所有 Agent 的上下文全丢，用户得重新描述一遍需求。后来改成对话历史放外部 Redis，中间结果放本地磁盘，才稳定下来。

3.4 与 Kubernetes 的集成方式：CRD 还是 Sidecar

ax 要和 Kubernetes 集成，有两条路：定义 CRD（自定义资源），或者做 Sidecar 注入。

CRD 的好处是声明式，用户写 YAML 就能创建 Agent，和 Kubernetes 原生体验一致。坏处是需要自己写 controller，而且 CRD 的 schema 设计很考验功力，设计不好后面改起来很痛苦。

Sidecar 的好处是对现有工作负载侵入小，坏处是 Sidecar 本身也要消耗资源，而且 Sidecar 和主容器的生命周期同步是个麻烦事。

我倾向于 CRD 方案，因为 Agent 的配置项太多了——模型、工具、配额、状态策略——用 Sidecar 的 annotation 来传会非常臃肿。CRD 至少能做 schema 校验，用户写错了能提前发现。

一个简化的 CRD 大概长这样：

apiVersion: ax.io/v1alpha1 kind: Agent metadata: name: research-agent spec: runtime: python3.11 model: provider: internal name: reasoning-v2 quota: rate: 10 burst: 20 tools: - name: web-search quota: rate: 5 burst: 10 state: hot: memory warm: local-disk cold: redis drainTimeout: 600s

这个 schema 里每个字段都有讲究。比如drainTimeout默认给 600 秒，是因为大部分 Agent 任务不会超过 10 分钟，超过的基本是异常情况，强制杀反而更安全。

4. 实操：从零搭一个最小可用的 ax 运行时环境

4.1 环境准备与依赖检查

先说清楚，ax 目前没有一键安装包，你需要自己搭。我下面这套流程是在一台 8 核 32G 的 Linux 机器上验证过的，Kubernetes 版本 1.28。

第一步是检查基础依赖。热搜里有个词叫“container runtime is not running”，这是最常见的起步错误。先确认容器运行时正常：

systemctl status containerd crictl info

如果crictl info报错，大概率是 containerd 的配置有问题。检查/etc/containerd/config.toml里的SystemdCgroup是否为 true，这个参数在 Kubernetes 1.28 上必须开。

第二步是确认 Kubernetes 集群健康：

kubectl get nodes kubectl get pods -n kube-system

节点状态必须是 Ready，kube-system 里的核心组件不能有 CrashLoopBackOff。

第三步是准备 ax 的运行时组件。ax 的运行时通常以 DaemonSet 形式部署，每个节点跑一个，负责和容器运行时交互。部署前需要确认节点上有足够的磁盘空间，因为 Agent 镜像往往很大（带模型的话可能几十 G）。

提示：如果你的节点磁盘小于 100G，建议先把 Agent 镜像做成精简版，只带必要的运行时依赖，模型通过挂载卷的方式提供。

4.2 部署 ax 运行时组件

ax 运行时组件的部署分三部分：CRD 定义、Controller、Node Agent。

先装 CRD：

kubectl apply -f https://example.com/ax/crds/agent.ax.io.yaml kubectl apply -f https://example.com/ax/crds/agenttemplate.ax.io.yaml

装完后确认：

kubectl get crd | grep ax.io

应该能看到agents.ax.io和agenttemplates.ax.io。

然后部署 Controller。Controller 是集群级的，一个集群一个就够：

kubectl apply -f https://example.com/ax/controller/deployment.yaml

Controller 的副本数建议设为 2，避免单点。它主要负责监听 Agent CRD 的变化，然后调度到合适的节点。

最后部署 Node Agent，这是 DaemonSet：

kubectl apply -f https://example.com/ax/node-agent/daemonset.yaml

Node Agent 负责在节点上实际创建和管理 Agent 进程。它需要挂载宿主机的容器运行时 socket，通常是/run/containerd/containerd.sock。

部署完成后检查：

kubectl get pods -n ax-system

三个组件都应该是 Running。

4.3 创建第一个 Agent 并验证

写一个最简单的 Agent YAML：

apiVersion: ax.io/v1alpha1 kind: Agent metadata: name: hello-agent namespace: default spec: runtime: python3.11 image: registry.example.com/ax/hello-agent:v1 model: provider: internal name: reasoning-v2 quota: rate: 5 burst: 10 drainTimeout: 300s

应用：

kubectl apply -f hello-agent.yaml

然后观察状态：

kubectl get agents -w

正常的话会看到状态从 Pending 到 Initializing 再到 Ready。如果卡在 Pending，大概率是镜像拉取失败或者资源不足。

验证 Agent 是否真的能跑：

kubectl ax exec hello-agent -- python -c "print('agent is alive')"

这个kubectl ax是 ax 提供的插件，需要单独安装。如果不想装插件，也可以直接找到 Agent 对应的 Pod，用kubectl exec进去。

4.4 配额配置的实操计算

配额配置是最容易拍脑袋的地方。我分享一个实际的计算方法。

假设你的下游大模型服务能承受 100 QPS，集群里计划跑 20 个 Agent，每个 Agent 平均每次任务调用模型 3 次，任务平均耗时 30 秒。那么每个 Agent 的模型调用速率大约是：

3 次 / 30 秒 = 0.1 QPS

20 个 Agent 总共 2 QPS，远低于 100 QPS 的上限。但这是平均值，实际会有突发。所以 rate 可以设为 0.5，burst 设为 5，留出 5 倍的突发余量。

model: quota: rate: 0.5 burst: 5

这个配置的意思是：平均每秒 0.5 次调用，最多允许瞬间 5 次。如果某个 Agent 突然要连续调用 10 次，第 6 次开始就会被限流，需要等待令牌补充。

注意：rate 设得太低会导致 Agent 任务变慢，设得太高又失去保护意义。建议先用保守值上线，观察一周后再调整。

5. 常见问题排查与避坑实录

5.1 Agent 卡在 Initializing 不动

这是最高频的问题。排查顺序如下：

1. 看 Node Agent 日志：kubectl logs -n ax-system -l app=ax-node-agent --tail=100
2. 看容器运行时日志：journalctl -u containerd --tail=100
3. 看节点资源：kubectl describe node <node-name>

我遇到过的原因有：镜像太大拉取超时、节点磁盘满、容器运行时 socket 权限不对。其中权限问题最隐蔽，Node Agent 需要 root 或者加入 docker 组才能访问 socket。

5.2 配额限流导致任务失败

如果 Agent 日志里出现大量 429 或者 “quota exceeded”，说明配额设小了。但不要急着调大，先确认是不是 Agent 本身有 bug 在疯狂重试。

我见过一个案例：Agent 调用工具失败后没有退避，直接 while True 重试，瞬间把配额打满。这种问题调大配额只会掩盖 bug，正确的做法是加指数退避。

import time def call_with_backoff(fn, max_retries=5): for i in range(max_retries): try: return fn() except QuotaExceeded: wait = min(2 ** i, 30) time.sleep(wait) raise Exception("max retries exceeded")

5.3 多集群场景下的状态同步问题

如果你用 Karmada 做多集群编排，Agent 的状态同步是个大坑。Karmada 默认只同步工作负载的 spec，不同步 status。这意味着你在主集群看不到 Agent 在成员集群的真实状态。

解决方案是开启 Karmada 的 status 同步功能，或者自己写一个 status 聚合器。我倾向于后者，因为 Agent 的状态字段太多，Karmada 的通用 status 同步不一定能覆盖。

5.4 常见问题速查表

6. 我对 ax 这类运行时编排的一些个人判断

做基础设施这些年，我越来越觉得 Agentic 场景的运行时编排会走一条和容器编排相似但更快的路。容器从 Docker 到 Kubernetes 用了五六年，Agent 可能两三年就会收敛出一套事实标准。ax 现在的位置，有点像 2015 年的 Kubernetes——方向对，但细节还在快速迭代。

如果你现在就要上手，我的建议是：先把运行时契约定下来，别急着上多集群。单集群跑通生命周期管理、配额控制、状态分层这三件事，就已经能覆盖 80% 的生产需求。多集群是后面的事，等单集群稳定了再考虑。

另外，别被“Agentic”这个词吓到。剥开概念，它要解决的就是资源隔离、状态管理、动态调度这三个老问题。你如果做过容器编排，这些问题的解法是可以迁移的。真正新的地方在于 Agent 的状态更复杂、调用关系更动态，需要更细粒度的抽象。

最后分享一个我踩过的坑：一开始我把 Agent 的上下文全放内存，觉得快。结果节点一重启，所有正在进行的任务全丢，用户投诉了一周。后来改成对话历史放 Redis、中间结果放本地磁盘、只有当前推理的临时状态放内存，才稳定下来。这个分层策略不是拍脑袋定的，是根据状态的生命周期和恢复成本算出来的——对话历史恢复成本最高，所以放最可靠的外部存储；中间结果恢复成本中等，放本地磁盘；临时状态恢复成本几乎为零，放内存。你可以按这个逻辑来设计自己的状态分层。