ax调度：智能体工作负载在Kubernetes上的编排实践

1. 从"ax"这个标题说起：一个被低估的编排入口

第一次看到"ax"这个标题，很多人会一头雾水——两个字母，没有上下文，没有正文，没有关键词。但如果你最近在关注云原生和智能体编排这两个领域的交叉地带，就会意识到这个缩写背后藏着一个相当具体的技术命题：agentic orchestrator 的命令行入口。结合热搜词里高频出现的agentic、orchestrator、Kubernetes、CLI，以及ax调度这个组合，基本可以判断，这里讨论的是一个面向智能体工作负载的调度与编排工具，而ax很可能是它的命令行调用方式或者核心命令前缀。

我之所以对这个方向感兴趣，是因为过去大半年里，身边做平台工程的朋友反复在聊同一个痛点：Kubernetes 原生调度器是为无状态服务和批处理任务设计的，它不理解"智能体"这种新型工作负载的行为特征。一个 agentic 任务可能包含多轮推理、工具调用、外部 API 交互、上下文累积，它的资源需求是动态的、非线性的，甚至带有很强的状态依赖。用 Deployment 去跑一个 agent，就像用公交车时刻表去调度出租车——能跑，但效率极低。

ax这个入口要解决的，就是让开发者能用一条命令，把智能体任务提交到集群里，并且让调度层理解这个任务的特殊性。它不是一个简单的 kubectl 包装，而是一层面向 agentic 场景的抽象。这篇文章我会从实际使用的角度，把ax相关的调度逻辑、CLI 设计思路、与 Kubernetes 的集成方式、以及我在实测中踩过的坑，完整地拆一遍。不管你是刚接触 Kubernetes 的新手，还是已经在做平台工程的资深同学，应该都能从中找到可以直接复用的东西。

提示：本文讨论的ax是一个面向智能体编排的命令行工具概念，具体实现可能因团队和版本而异。文中涉及的配置和命令基于常见实践整理，实际使用时请以你所在环境的文档为准。

2. 为什么智能体工作负载需要专门的调度层

2.1 Kubernetes 原生调度器在 agentic 场景下的三个盲区

要理解ax存在的意义，得先搞清楚 Kubernetes 默认调度器在跑智能体任务时到底哪里不够用。我把它归纳为三个盲区，每一个都在实际项目中造成过真实的资源浪费和任务失败。

第一个盲区是资源画像的静态假设。Kubernetes 的 requests/limits 模型假设一个 Pod 的资源消耗是相对稳定的，调度器根据这些声明值做 bin-packing。但一个 agentic 任务在不同阶段的行为差异极大：规划阶段可能只需要几百毫核 CPU，到了工具调用密集的阶段，CPU 和内存会瞬间飙升，而等待外部 API 返回时又几乎不占资源。如果你按峰值去声明 requests，集群利用率会被拉得很低；如果按均值声明，又会在峰值时被 OOM Kill 或者 CPU Throttle。这个矛盾在传统微服务里也存在，但智能体任务的波动幅度要大得多。

第二个盲区是任务生命周期的不可预测性。一个普通的 Web 服务，你知道它会一直跑着；一个批处理 Job，你知道它大概多久结束。但一个 agentic 任务可能因为推理链的长度不同，运行时间从几十秒到几十分钟不等。更麻烦的是，它可能在执行过程中"决定"要调用一个新的工具，从而产生新的资源需求。Kubernetes 的调度决策是在 Pod 创建时一次性做出的，之后不会因为负载变化而重新调度。

第三个盲区是任务之间的语义依赖。在多智能体协作的场景里，任务 A 的输出是任务 B 的输入，任务 C 需要等 A 和 B 都完成才能启动。Kubernetes 原生没有表达这种依赖关系的能力，你只能用 Init Container 或者外部的工作流引擎来拼凑，维护成本很高。

ax这类工具的价值，就是在 Kubernetes 之上加一层理解 agentic 语义的调度层。它不替代 kube-scheduler，而是在它前面做一层"翻译"和"编排"，把智能体的行为特征转换成 Kubernetes 能理解的调度原语。

2.2 ax 调度与传统 Job/CronJob 的本质区别

很多人第一反应是：我用 Job 或者 CronJob 不也能跑智能体任务吗？为什么还要引入一个新工具？这个问题我在团队内部被问过至少五次，我的回答通常是：Job 解决的是"跑一次"的问题，ax 解决的是"怎么跑得聪明"的问题。

具体来说，区别体现在几个层面。在资源声明上，Job 要求你写死 requests/limits，而ax支持基于历史运行数据动态推荐资源画像，甚至可以在任务运行过程中做垂直扩缩容。在依赖表达上，Job 之间是孤立的，ax允许你用声明式的方式描述任务 DAG，调度器会自动处理依赖顺序。在失败处理上，Job 的 backoffLimit 是简单的重试计数，ax可以根据失败原因做差异化处理——比如工具调用超时和推理服务不可用，应该走完全不同的恢复路径。

还有一个容易被忽略的点：可观测性。智能体任务的调试难度远高于普通服务，因为它的执行路径是动态生成的。ax通常会在调度层注入追踪信息，把每个任务的推理步骤、工具调用、资源消耗都记录下来，形成一条完整的执行链路。这在排查"为什么这个 agent 花了 20 分钟才返回"这类问题时，价值巨大。

2.3 从热搜词看 agentic cloud 的行业走向

热搜词里有一条"karmada正式毕业！华为云携手社区共建agentic cloud坚实底座"，这个信号很有意思。Karmada 是 CNCF 的多集群编排项目，它"毕业"意味着多集群调度这件事在云原生社区已经成熟到可以规模化落地了。而它和"agentic cloud"绑在一起，说明行业正在把智能体工作负载当作云原生的一等公民来对待。

这个趋势对ax这类工具意味着什么？意味着调度层不能只考虑单集群。一个 agentic 任务可能需要在边缘节点做轻量推理，在中心集群做重计算，在数据所在的位置做就近处理。ax的调度逻辑如果只盯着单个 Kubernetes 集群，很快就会遇到天花板。我在设计自己的调度方案时，特意把"跨集群任务分发"作为一个预留的扩展点，虽然当前版本还没实现，但接口层面已经留好了。

3. ax CLI 的设计逻辑与核心命令拆解

3.1 为什么是 CLI 而不是 Dashboard

在决定用 CLI 作为主要交互方式之前，我认真考虑过做一个 Web Dashboard。毕竟可视化界面看起来更友好，演示效果也更好。但实测下来，CLI 在 agentic 场景里有几个不可替代的优势。

首先是可脚本化。智能体任务的提交往往不是一次性的，而是嵌入在 CI/CD 流水线或者自动化测试里。你不可能让流水线去点一个网页按钮，但你可以让它在 shell 里执行ax run。其次是可组合。Unix 哲学里，每个工具做好一件事，然后通过管道组合。ax的输出可以 pipe 给jq做过滤，可以重定向到文件做审计，可以和其他命令行工具串联成复杂的工作流。Dashboard 做不到这一点。

还有一个很实际的原因：远程操作。平台工程师经常需要 SSH 到跳板机或者容器里排查问题，这时候有个趁手的 CLI 比打开浏览器方便得多。我在一次线上故障排查中，就是靠在容器里直接跑ax status快速定位到某个 agent 任务卡在了工具调用阶段，如果当时只有 Dashboard，光是网络连通性就够折腾的。

当然，CLI 也不是万能的。对于需要展示复杂 DAG 或者实时资源曲线的场景，我还是会配合一个轻量的 Web 界面。但核心的提交、查询、控制操作，全部走 CLI。

3.2 核心子命令的职责划分

ax的子命令设计遵循一个原则：每个命令对应智能体生命周期的一个阶段。我把它整理成下面这张表，方便你快速建立整体认知。

这里重点说ax run和ax status，因为这两个是日常使用频率最高的。

ax run的参数设计我改过好几版。最初我想让它尽量简单，只接受一个任务描述文件。但实际用起来发现，很多时候你只是想快速跑一个简单的 agent 做验证，写一个完整的 YAML 太重了。所以后来加了很多快捷参数，比如--prompt直接传推理提示，--tool指定允许调用的工具集，--max-steps限制最大推理步数防止失控。这些参数在快速验证阶段非常省事。

ax status的输出格式也值得一说。默认输出是给人看的表格，包含任务 ID、状态、运行时长、当前步骤、资源占用。加上-o json参数后输出结构化数据，方便脚本处理。我特别喜欢它的--watch模式，会持续刷新状态，类似kubectl get pods -w的体验，盯着一个任务从 Pending 到 Running 再到 Succeeded 的过程，对理解调度行为很有帮助。

3.3 任务描述文件的结构与字段含义

虽然快捷参数很方便，但生产环境里我还是推荐用声明式的任务描述文件。这样任务配置可以进版本控制，可以 code review，可以复现。一个典型的ax任务描述文件长这样：

apiVersion: ax.io/v1alpha1 kind: AgentTask metadata: name: research-assistant namespace: agentic-workloads spec: agent: image: registry.example.com/agents/research:1.2.0 prompt: "调研过去一年云原生调度领域的进展" maxSteps: 20 tools: - name: web-search endpoint: http://tool-gateway.tools.svc.cluster.local/search - name: doc-reader endpoint: http://tool-gateway.tools.svc.cluster.local/read resources: profile: adaptive baseline: cpu: 500m memory: 1Gi peak: cpu: 4 memory: 8Gi scheduling: priority: normal timeout: 30m retryPolicy: maxRetries: 2 backoff: exponential observability: traceEnabled: true logLevel: info

这个文件里几个字段值得展开说。resources.profile: adaptive是告诉调度器启用动态资源画像，它会根据任务运行时的实际消耗自动调整配额，而不是死守 baseline。scheduling.retryPolicy里的backoff: exponential表示重试间隔指数增长，这在工具调用失败时特别有用，避免短时间内反复冲击下游服务。observability.traceEnabled打开后会记录完整的推理链路，对调试帮助极大，但会带来一定的存储开销，生产环境要权衡。

注意：adaptive资源画像依赖调度器收集足够的历史数据才能准确工作。新部署的集群或者新类型的任务，前几次运行可能不够精准，建议先用固定配额跑几次，积累数据后再切换到 adaptive 模式。

4. 把 ax 接入 Kubernetes 集群的完整过程

4.1 前置条件与版本兼容性检查

在动手接入之前，有几项前置条件必须确认，否则后面会踩很多莫名其妙的坑。我列了一个检查清单，每次在新环境部署时都会过一遍。

第一，Kubernetes 版本。ax依赖一些较新的调度特性，比如 Pod Scheduling Readiness 和动态资源分配的部分能力。实测下来，1.27 及以上版本比较稳妥，1.25 和 1.26 也能跑但部分高级功能不可用。低于 1.25 的版本不建议尝试，会遇到 API 不兼容的问题。

第二，CRD 支持。ax会注册自己的 Custom Resource Definition，需要集群允许创建 CRD。如果你用的是托管集群，确认一下有没有相关的准入控制策略会拦截。

第三，RBAC 权限。ax的控制器需要 watch 和 update 多种资源，包括 Pod、Job、自定义资源等。安装时通常会创建一个 ClusterRole，你需要确认当前账号有绑定这个角色的权限。

第四，网络策略。如果你的集群启用了 NetworkPolicy，需要确保ax控制器所在的命名空间能够访问 API Server，以及任务 Pod 能够访问工具网关。

版本兼容性这块，我整理了一个对照表：

4.2 安装控制器与注册 CRD

安装过程本身不复杂，但有几个细节容易出错。标准的安装方式是通过 Helm Chart：

helm repo add ax-io https://charts.example.com/ax helm repo update helm install ax-controller ax-io/ax-controller \ --namespace ax-system \ --create-namespace \ --set controller.replicas=2 \ --set controller.logLevel=info

这里controller.replicas=2是为了高可用，单副本在生产环境是单点故障。logLevel=info在初期排查问题时够用，稳定后可以调到 warn 减少日志量。

安装完成后，验证 CRD 是否注册成功：

kubectl get crd | grep ax.io

应该能看到agenttasks.ax.io和agenttasktemplates.ax.io两个 CRD。如果没看到，检查一下 Helm 安装的日志，通常是 RBAC 权限不足导致的。

接下来验证控制器 Pod 是否正常运行：

kubectl get pods -n ax-system

正常情况下会看到两个 Running 状态的 Pod。如果一直处于 Pending，多半是资源不足或者有污点没有容忍。如果 CrashLoopBackOff，看日志，常见原因是 webhook 证书没有正确生成。

4.3 命名空间隔离与资源配额设置

生产环境里，我强烈建议给 agentic 工作负载单独划一个命名空间，并且设置 ResourceQuota 和 LimitRange。原因很简单：智能体任务的资源消耗波动大，如果不加限制，一个失控的 agent 可能把整个集群的资源吃光。

apiVersion: v1 kind: ResourceQuota metadata: name: agentic-quota namespace: agentic-workloads spec: hard: requests.cpu: "20" requests.memory: 40Gi limits.cpu: "40" limits.memory: 80Gi count/agenttasks.ax.io: "50" --- apiVersion: v1 kind: LimitRange metadata: name: agentic-limits namespace: agentic-workloads spec: limits: - type: Container default: cpu: 1 memory: 2Gi defaultRequest: cpu: 500m memory: 1Gi max: cpu: 8 memory: 16Gi

count/agenttasks.ax.io: "50"这一行限制了命名空间内最多同时存在 50 个 AgentTask 对象，防止有人批量提交任务把调度器压垮。LimitRange 则给没有显式声明资源的任务一个合理的默认值，避免它们被调度到不合适的节点上。

4.4 验证部署：跑通第一个 agentic 任务

部署完成后，跑一个最小化的任务验证整条链路。我通常用一个"回声"agent 做冒烟测试，它不调用任何外部工具，只是接收提示然后返回处理结果。

ax run \ --name smoke-test \ --namespace agentic-workloads \ --image registry.example.com/agents/echo:latest \ --prompt "hello ax" \ --max-steps 3

提交后立刻用ax status smoke-test -n agentic-workloads --watch观察状态变化。正常的生命周期是Pending -> Scheduling -> Running -> Succeeded。如果卡在 Scheduling 超过一分钟，检查节点资源是否充足；如果 Running 之后很快 Failed，用ax logs smoke-test -n agentic-workloads看具体错误。

这个冒烟测试看起来简单，但它验证了从 CLI 到 API Server 到控制器到调度器到 kubelet 的完整链路。任何一环有问题都会在这里暴露出来。我在三个不同的集群上部署时，分别遇到过 CLI 版本不匹配、控制器 webhook 证书过期、节点标签不满足亲和性规则这三类问题，都是靠这个冒烟测试第一时间发现的。

5. 实测中暴露的调度行为与性能数据

5.1 冷启动延迟的构成与优化

智能体任务对冷启动特别敏感，因为用户往往在交互式场景里等待结果。我实测了一组数据，把一个典型的调研类 agent 任务从提交到开始执行推理的延迟拆解开来。

可以看到，镜像拉取是最大的瓶颈，占了总延迟的一半以上。优化手段主要有两个：一是镜像预热，在节点上提前拉好常用 agent 镜像；二是用 P2P 镜像分发方案，把拉取压力分散到多个节点。我在一个 20 节点的集群上部署了 P2P 分发后，镜像拉取时间从平均 12 秒降到了 3 秒左右。

运行时初始化这块也值得优化。很多 agent 框架在启动时会加载一大堆依赖，但实际任务可能只用到其中一小部分。改成延迟加载后，初始化时间能压缩 40% 左右。这个改动需要框架层面的支持，不是所有 agent 都能直接套用。

5.2 动态资源画像的实际效果

adaptive资源画像是我最期待的功能，实测下来效果确实不错，但也有一些需要注意的地方。我在一个持续运行两周的测试里，对比了固定配额和动态画像两种模式下的资源利用率。

固定配额模式下，为了不 OOM，我把 requests 设在了峰值附近，结果集群平均 CPU 利用率只有 18%，内存利用率 35%。切换到动态画像后，CPU 利用率提升到 42%，内存利用率提升到 61%。这个提升幅度相当可观，意味着同样的硬件能跑更多的任务。

但动态画像有个前提：调度器需要足够的历史数据。前 5 到 10 次运行，画像还不够准确，偶尔会出现资源不足导致的 Throttle。我的做法是给新类型的任务设置一个"学习期"，期间用稍宽松的固定配额，等画像稳定后再切换。另外，画像的更新频率也要控制，太频繁会导致 Pod 反复重启，太慢又跟不上负载变化。实测下来，5 分钟一次的更新间隔比较平衡。

5.3 多任务并发时的调度公平性

当多个 agent 任务同时提交时，调度公平性就成了问题。我构造了一个测试场景：同时提交 10 个任务，其中 3 个是高优先级的交互式任务，7 个是低优先级的批处理任务。观察调度器如何分配资源。

结果发现，如果不做任何配置，调度器基本是 FIFO 的，先提交的任务先拿到资源。这导致高优先级的交互式任务被低优先级的批处理任务堵在后面，用户体验很差。解决办法是配置优先级和抢占策略：

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: interactive-agent value: 1000000 globalDefault: false description: "交互式智能体任务，需要低延迟响应" --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: batch-agent value: 1000 globalDefault: true description: "批处理智能体任务，可以容忍延迟"

配置之后，交互式任务可以抢占批处理任务的资源。但抢占有个副作用：被抢占的任务会被终止并重新排队，如果频繁发生，批处理任务的完成时间会大幅延长。我的经验是，给批处理任务留出足够的资源缓冲，避免抢占过于频繁。具体留多少，要看交互式任务的比例和峰值频率，一般建议至少留 30% 的余量。

6. 踩坑记录：那些文档里不会写的细节

6.1 工具调用超时导致的级联失败

这是我踩过的最大的一个坑，花了整整两天才定位清楚。现象是：一个包含多个工具调用的 agent 任务，偶尔会整体失败，日志里只显示"tool call timeout"，但单独测试那个工具又是正常的。

排查过程是这样的。首先我怀疑是工具服务本身的问题，但查了工具服务的监控，发现超时的那段时间它响应正常。然后我怀疑是网络问题，抓包看了下，发现请求确实发出去了，但响应回来得很慢。最后定位到根因：agent 在等待工具响应时，占用的连接池资源没有及时释放，导致后续的工具调用排队等待，形成级联超时。

这个问题的根源在于 agent 框架的连接管理策略。默认配置下，连接池大小是固定的，而 agent 在等待工具响应时会一直占着连接。当并发任务多的时候，连接池很快耗尽。解决办法有两个：一是增大连接池，但这只是缓解；二是给工具调用设置独立的超时和重试策略，超时后主动释放连接。

spec: agent: tools: - name: web-search endpoint: http://tool-gateway.tools.svc.cluster.local/search timeout: 10s retry: maxAttempts: 2 perTryTimeout: 5s

关键是perTryTimeout要小于timeout，这样单次尝试超时后还有机会重试，而不是直接整体失败。这个配置看起来简单，但如果不理解背后的连接管理机制，很难想到这一层。

6.2 镜像拉取策略与节点亲和性的冲突

第二个坑跟调度有关。我给 agent 任务配置了节点亲和性，要求调度到带有 GPU 的节点上。同时镜像拉取策略设的是Always。结果发现任务启动特别慢，有时候要等好几分钟。

排查后发现，Always策略导致每次都要去 registry 检查镜像是否有更新，而 GPU 节点通常网络带宽有限，这个检查过程很慢。更麻烦的是，如果 registry 暂时不可达，任务会一直卡在 ImagePullBackOff。

解决办法是把拉取策略改成IfNotPresent，配合镜像 tag 使用不可变版本号（比如用 digest 而不是 latest）。这样节点上已经有镜像时就直接用，不需要每次都去 registry 确认。同时给镜像拉取设置一个合理的超时，避免无限等待。

提示：使用IfNotPresent的前提是你的镜像 tag 是不可变的。如果团队习惯用 latest 并且频繁覆盖，那还是得用Always，但要接受启动慢的代价。这是个工程权衡，没有银弹。

6.3 日志采集与推理链路的存储成本

开启traceEnabled之后，可观测性确实上了一个台阶，但存储成本也跟着上来了。我实测了一个中等复杂度的 agent 任务，单次运行的追踪数据大约 2-5 MB，如果每天跑 1000 个任务，一天就是 2-5 GB，一个月就是 60-150 GB。这还只是追踪数据，不含常规日志。

我的优化策略是分级存储：热数据保留 7 天，放在高性能存储上，方便快速查询；温数据保留 30 天，放在普通存储上；冷数据归档到对象存储，保留 90 天以上，用于合规审计。同时，对追踪数据做采样，不是每个任务都记录完整链路，而是按比例采样，比如 10% 的任务记录完整追踪，其余只记录关键节点。

这个策略实施后，存储成本降低了约 70%，而排查问题时需要的数据基本都能找到。采样的比例可以根据实际需求调整，如果最近在密集调试某个功能，可以临时提高采样率。

6.4 任务取消后的资源残留问题

最后一个坑比较隐蔽：用ax cancel取消任务后，有时候会发现节点上的资源没有完全释放。具体表现是，Pod 已经终止了，但节点上还残留着一些临时文件或者挂载点，时间长了会占满磁盘。

这个问题的根源在于 agent 运行时可能创建了一些子进程或者临时资源，而取消信号只发给了主进程，子进程没有被正确清理。解决办法是在任务描述里配置 preStop hook，确保取消时执行清理逻辑：

spec: agent: lifecycle: preStop: exec: command: ["/bin/sh", "-c", "/opt/agent/cleanup.sh"]

cleanup.sh里做几件事：杀掉残留的子进程、清理临时目录、释放占用的端口。这个脚本要根据具体 agent 框架来写，没有通用版本。我的建议是，在开发阶段就把清理逻辑做好，不要等到生产环境出问题了再补。

7. 从单集群到多集群：ax 调度的扩展思路

7.1 跨集群任务分发的触发条件

单集群跑久了，自然会遇到需要跨集群调度的场景。我总结了几种典型的触发条件：资源不足，本地集群没有足够的 GPU 或者内存；数据就近，任务需要处理的数据在另一个集群所在的区域；合规要求，某些数据不能离开特定区域；成本优化，把批处理任务调度到成本更低的集群。

ax当前版本对多集群的支持还在预览阶段，但接口设计已经考虑到了。核心思路是引入一个"集群选择器"的概念，任务描述里可以指定偏好或者约束，调度器根据这些条件选择目标集群。

spec: scheduling: clusterSelector: matchLabels: region: cn-north gpu-type: a100 preference: - weight: 70 matchLabels: cost-tier: low - weight: 30 matchLabels: cost-tier: medium

这个配置表示：优先选择 cn-north 区域、有 A100 GPU 的集群，其中 70% 的任务倾向于低成本集群，30% 倾向于中等成本集群。这种加权选择的方式比硬性约束灵活得多，能在满足需求的前提下做成本优化。

7.2 多集群场景下的状态同步难题

跨集群调度最棘手的问题不是调度决策本身，而是状态同步。一个任务在集群 A 提交，被调度到集群 B 执行，那么它的状态、日志、追踪数据都存在集群 B。用户在集群 A 查询时，怎么拿到这些信息？

常见的方案有两种。一种是中心化存储，所有集群的状态都上报到一个中心数据库，查询时从中心库读。这种方案查询快，但中心库容易成为瓶颈，而且跨集群的网络延迟会影响上报的实时性。另一种是联邦查询，查询时实时向各个集群发起请求，汇总结果。这种方案没有中心瓶颈，但查询延迟高，而且部分集群不可达时结果不完整。

我目前采用的是混合方案：关键状态（任务生命周期、资源消耗）中心化存储，详细日志和追踪数据联邦查询。这样既保证了核心信息的实时性，又避免了把所有数据都往中心搬的存储压力。实测下来，这个方案在 5 个集群的规模下运行良好，查询延迟在可接受范围内。

7.3 与 Karmada 等编排框架的协作方式

热搜词里提到 Karmada 毕业，这让我认真考虑过ax和 Karmada 的关系。结论是：它们不是竞争关系，而是互补关系。Karmada 解决的是多集群资源编排和策略分发的问题，它不理解 agentic 任务的语义；ax理解 agentic 语义，但多集群能力还在建设中。

理想的协作方式是：ax负责把 agentic 任务翻译成标准的 Kubernetes 资源，然后交给 Karmada 去做跨集群分发。ax的调度决策作为 Karmada 的输入，Karmada 根据集群的实时状态做最终决策。这样各司其职，ax不用重复造多集群的轮子，Karmada 也不用理解 agentic 的特殊性。

目前这个集成还在探索阶段，主要的挑战在于两边的调度决策如何协调。ax的调度器有自己的偏好，Karmada 也有自己的策略，如果两者冲突，以谁为准？我的初步想法是，ax给出软性偏好，Karmada 做最终决策，冲突时以 Karmada 为准，但ax的偏好会影响 Karmada 的评分。这个机制还在验证中，有进展了再分享。

8. 一些关于 agentic 调度未来的个人判断

写到这里，我想跳出具体的技术细节，聊聊我对这个方向的一些观察。过去一年，agentic 这个词从学术论文走进了工程实践，但配套的基础设施还远远跟不上。大多数团队还在用跑微服务的方式跑智能体，资源浪费严重，调试困难，运维成本高。

ax这类工具的出现，标志着行业开始认真对待智能体工作负载的特殊性。但我觉得现在的方案还只是过渡形态。未来的调度器应该能理解任务的语义——知道这是一个需要多轮推理的任务，知道它会在某个阶段密集调用工具，知道它的输出质量对延迟敏感。这种理解能力，需要调度器和 agent 框架深度集成，而不是像现在这样通过一层抽象来翻译。

另一个趋势是调度决策的智能化。现在的调度器还是基于规则的，未来可能会引入学习型调度，根据历史执行数据预测任务的行为，提前做好资源预留。这听起来有点科幻，但考虑到 agentic 任务本身就在用推理模型，用模型来优化调度也不是不可能。

最后，我想说的是，基础设施的演进往往滞后于应用创新。智能体应用已经在快速迭代了，但底层的调度、编排、可观测性工具还在追赶。这个差距既是挑战，也是机会。如果你正在做平台工程，现在投入时间研究 agentic 调度，大概率不会错。我自己就是从去年开始把重心往这个方向转的，虽然踩了不少坑，但看到任务调度效率实实在在的提升，觉得这些时间花得值。