基于Kubernetes的Agentic编排：用CLI调度多Agent任务实战-平芜编程栈

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

第一次看到“ax”这个标题，很多人会以为是某个命令行工具的缩写，或者某个内部代号。但把热搜词摊开来看——ax、agentic、orchestrator、Kubernetes、CLI——这几个词凑在一起，指向的其实是一个非常具体的东西：一个面向Agentic工作负载的编排调度入口，用CLI的方式把Kubernetes的能力暴露出来。

我最早接触这类工具是在做多Agent任务编排的时候。当时的需求很朴素：手头有一堆CLI形态的Agent（比如各种code cli、claude cli、codex cli），每个都能单独跑，但要让它们协同完成一个复杂任务，就得自己写调度逻辑。写到最后发现，我其实在重新发明一个简化版的Kubernetes调度器——有任务队列、有资源分配、有失败重试、有状态追踪。既然Kubernetes已经把这些问题解决得很好了，为什么不直接站在它上面？

“ax”这个标题背后的核心价值就在这里：它不是一个新造的调度系统，而是把Kubernetes原生的编排能力，包装成Agentic场景下可以直接用的CLI入口。你不需要懂Kubernetes的全部细节，但你能享受到它带来的调度、隔离、弹性、可观测性。适合谁来参考？三类人：一是正在做Agentic RAG或者多Agent协同的开发者；二是手里有一堆CLI工具想统一编排的运维；三是想理解“Agentic orchestrator”到底怎么落地的人。

这篇文章我会按实际搭建的顺序来讲：先拆设计思路，再讲核心细节，然后走一遍完整实操，最后把踩过的坑整理成排查表。全程基于我在真实环境里的操作记录，参数和命令都可以直接抄。

2. 整体设计与思路拆解：为什么是Kubernetes加CLI

2.1 为什么Agentic编排绕不开Kubernetes

先说一个反直觉的结论：Agentic场景对编排的要求，比传统微服务更接近Kubernetes的设计初衷。

传统微服务是无状态的，扩缩容相对简单。但Agentic任务不一样——每个Agent任务可能是有状态的、长时运行的、需要独占资源的。比如一个codex cli任务在跑代码生成，它需要CPU、需要网络、可能需要挂载特定的工作目录；同时另一个claude cli任务在跑文档分析，它需要的是不同的镜像和不同的环境变量。这种“每个任务一套独立环境”的需求，正好是Kubernetes的Pod模型最擅长的。

我试过用纯进程管理的方式跑多Agent，问题是：任务崩了要手动重启，资源冲突了要手动排队，日志散落在各个终端里。换成Kubernetes之后，这些问题变成了声明式的——你描述“我要什么”，而不是“我怎么一步步做”。这就是orchestrator的价值。

2.2 CLI作为入口的取舍逻辑

那为什么入口是CLI，而不是Web UI或者SDK？

这里有个很实际的考量。Agentic工作流的使用者，绝大多数是开发者，而开发者的工作环境就是终端。你让他为了跑一个Agent任务去打开浏览器、点按钮、填表单，这个体验是割裂的。CLI的好处是可组合——你可以把ax命令写进shell脚本，可以管道传给其他工具，可以在CI里直接调用。

但CLI也有代价：它不适合做复杂的可视化编排。所以“ax”这类工具的设计哲学通常是：CLI负责触发和查询，Kubernetes负责实际编排，两者通过声明式配置对接。你写一个YAML描述任务，ax把它提交给集群，然后你通过ax查询状态。这个分工很清晰。

提示：如果你之前用过codex cli或者claude cli，会发现它们的交互模式是“一问一答”。而ax这类编排入口是“提交-查询”模式，思维上要从交互式切换到批处理式。

2.3 方案选型对比：自研调度 vs 直接用Kubernetes

我把当时考虑过的三种方案列了个表，方便你判断自己的场景该选哪条路。

方案	开发成本	弹性能力	可观测性	适合场景
纯shell脚本+进程管理	低	无	差	单机、少量任务
自研调度器	高	需自己实现	需自己实现	有特殊调度需求
Kubernetes+CLI封装	中	原生支持	原生支持	多任务、需弹性

自研调度器看起来最灵活，但实际做下来，光是处理“任务失败后如何优雅重试”这一个问题，就要写几百行代码。而Kubernetes的Job和CronJob原语已经把重试、超时、并发控制都做好了。站在巨人肩膀上的收益，远大于自己造轮子的成就感。

2.4 核心架构分层

整个ax的架构可以分成三层来理解：

接入层：CLI命令解析，把用户输入转换成Kubernetes API调用。这一层要处理的是参数校验、配置加载、认证信息注入。
编排层：Kubernetes的Deployment、Job、Service等资源对象。这一层负责实际的调度、生命周期管理、健康检查。
执行层：真正跑Agent任务的容器。每个容器里可能是一个codex cli，也可能是一个自定义的Agent运行时。

这个分层的好处是，每一层都可以独立替换。比如你不想用CLI了，可以换成SDK；不想用Kubernetes了，可以换成别的编排后端。只要接口约定清楚，上层不用改。

3. 核心细节解析与实操要点：把Agent任务塞进Pod里

3.1 Agent任务容器化的三个关键决策

把CLI形态的Agent塞进容器，不是简单写个Dockerfile就完事。有三个决策点必须想清楚。

第一个是基础镜像的选择。很多CLI工具依赖特定的运行时，比如Node.js、Python或者Go的二进制。我踩过的坑是：用alpine做基础镜像，结果某个CLI依赖glibc，跑起来直接报“unable to locate the required runtime components”。后来统一换成debian-slim，问题消失。镜像大一点没关系，稳定性优先。

第二个是工作目录的挂载策略。Agent任务经常需要读写文件，比如代码生成要写文件，文档分析要读文件。我的做法是给每个任务挂一个emptyDir作为工作目录，任务结束后自动清理。如果需要持久化结果，再单独挂一个PVC。这样既保证了任务间的隔离，又不会让临时文件堆积。

第三个是环境变量的注入方式。Agent任务通常需要API Key、模型地址这类配置。直接写在镜像里是禁忌，用ConfigMap和Secret是标准做法。但要注意，Secret挂载到环境变量时，如果值里有特殊字符，可能会被shell解析出错。我的经验是，能用文件挂载的就别用环境变量，让Agent自己去读配置文件。

3.2 资源请求与限制的参数计算

Kubernetes的resources字段是必须认真填的，填错了要么任务被OOM Kill，要么节点资源浪费。

以一个典型的codex cli任务为例，我实测下来的参数是：

resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "2000m"

为什么requests和limits差这么多？因为Agent任务的特点是启动时吃内存少，运行中可能突然飙升。比如代码生成任务，前期只是加载模型配置，内存占用低；一旦开始生成，内存会快速上涨。requests设小一点，让调度器容易找到节点；limits设大一点，给突发留足空间。

CPU的500m到2000m也是类似逻辑。500m是保证基本调度，2000m是允许突发计算。如果你的任务对延迟敏感，可以把requests调高，但代价是调度成功率下降。

注意：不要不填resources。不填的话，Kubernetes会按BestEffort处理，节点资源紧张时你的任务会第一个被驱逐。Agent任务往往跑得久，被驱逐的代价很高。

3.3 任务生命周期管理的细节

Agent任务的生命周期比普通Web服务复杂，因为它有明确的“开始”和“结束”。用Deployment管理是不合适的，因为Deployment假设容器是长期运行的。正确的选择是Job。

Job的关键参数是backoffLimit和activeDeadlineSeconds。前者控制失败重试次数，后者控制最长运行时间。

spec: backoffLimit: 3 activeDeadlineSeconds: 3600 template: spec: restartPolicy: Never

backoffLimit: 3意味着任务失败后最多重试3次。为什么是3次？因为Agent任务的失败通常分两类：一类是环境问题（网络抖动、依赖缺失），重试能解决；另一类是逻辑问题（输入错误、模型返回异常），重试也没用。3次是一个经验值，既能覆盖大部分瞬时故障，又不会让错误任务无限重试浪费资源。

activeDeadlineSeconds: 3600是一小时超时。这个值要根据你的任务类型调整。文档分析可能几分钟就够，代码生成可能要半小时。设太短会误杀正常任务，设太长会让卡死的任务占用资源。

3.4 日志与可观测性的落地方式

Agent任务的日志有个特点：输出量大且非结构化。一个codex cli任务可能输出几千行日志，里面混杂着模型思考、工具调用、错误信息。如果直接kubectl logs看，基本没法读。

我的做法是分两步。第一步，在容器里把日志写到文件，同时输出到stdout。stdout的日志被Kubernetes收集，文件日志用于任务结束后的详细分析。第二步，用一个sidecar容器做日志的初步过滤和格式化，把关键事件（任务开始、任务结束、错误）提取出来，打上标签。

这样查询的时候，可以用标签快速定位，而不是全文搜索。比如查所有失败任务，只需要过滤event=error的日志。

3.5 配置文件的组织方式

ax的配置文件我建议分成三层：

全局配置：集群地址、认证信息、默认命名空间。放在~/.ax/config。
项目配置：任务模板、镜像地址、资源默认值。放在项目根目录的ax.yaml。
任务配置：单次任务的参数覆盖。通过命令行参数传入。

这样分层的好处是，全局配置一次配好不用动，项目配置跟着代码走，任务配置灵活调整。我见过有人把所有配置塞一个文件，结果换个项目就要改一堆东西，很容易出错。

4. 实操过程与核心环节实现：从零跑通一个Agent任务

4.1 环境准备与依赖检查

开始之前，确认三件事：Kubernetes集群可用、kubectl配置正确、ax CLI已安装。

kubectl cluster-info kubectl get nodes ax version

如果ax version报“unable to locate the binary or required runtime components”，通常是两个原因：一是二进制没加到PATH，二是依赖的运行时缺失。前者用which ax确认路径，后者检查系统是否有对应的动态库。

集群这边，我建议至少两个节点，这样调度有腾挪空间。单节点也能跑，但一个任务占满资源后，其他任务就得排队。

4.2 编写第一个任务描述文件

新建一个hello-agent.yaml，内容如下：

apiVersion: batch/v1 kind: Job metadata: name: hello-agent namespace: default spec: backoffLimit: 2 activeDeadlineSeconds: 600 template: spec: restartPolicy: Never containers: - name: agent image: your-registry/agent-runtime:latest command: ["/bin/sh", "-c"] args: - | echo "task started at $(date)" # 这里替换成你的Agent命令 echo "task finished at $(date)" resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "1Gi" cpu: "1000m" volumeMounts: - name: workdir mountPath: /workspace volumes: - name: workdir emptyDir: {}

这个模板的关键点：restartPolicy: Never配合Job使用，任务结束就结束，不会重启；emptyDir提供临时工作目录；资源限制给了合理的范围。

4.3 提交任务并观察调度过程

提交命令很简单：

kubectl apply -f hello-agent.yaml

提交后，用三个命令观察状态：

kubectl get jobs kubectl get pods -l job-name=hello-agent kubectl describe pod <pod-name>

get jobs看整体状态，get pods看具体实例，describe pod看调度详情。如果Pod一直处于Pending，describe里的Events会告诉你原因——可能是资源不足，可能是镜像拉取失败，可能是节点选择器不匹配。

我实测下来，最常见的Pending原因是资源不足。这时候要么调低requests，要么加节点。不要直接调高limits，limits不影响调度，只影响运行时的上限。

4.4 查看日志与结果提取

任务跑完后，日志这样看：

kubectl logs <pod-name>

如果任务有输出文件，需要先从Pod里拷出来：

kubectl cp <pod-name>:/workspace/output.json ./output.json

注意，kubectl cp要求Pod还在运行。如果任务已经结束，Pod可能已经被清理。所以我的做法是，在任务结束前把结果写到挂载的PVC里，或者用sidecar把结果上传到对象存储。emptyDir的数据在Pod删除后就没了，这点一定要记住。

4.5 批量任务的编排方式

单个任务跑通后，下一步是批量。有两种方式：一是用Job的completions和parallelism参数，让Kubernetes自动管理并发；二是用CronJob做定时触发。

spec: completions: 10 parallelism: 3

这表示总共要完成10个任务，同时最多跑3个。Kubernetes会自动调度，一个完成就补一个。这种方式适合任务之间独立的场景。

如果任务之间有依赖，比如任务B要等任务A完成，那就需要更复杂的编排。这时候可以考虑用Kubernetes的Init Container，或者引入工作流引擎。ax这类工具通常会在CLI层面提供依赖声明，底层还是翻译成Kubernetes的资源依赖。

4.6 资源清理与成本控制

任务跑完不清理，集群里会堆积一堆Completed的Pod。虽然它们不占CPU和内存，但占etcd存储，时间长了会影响集群性能。

清理命令：

kubectl delete job hello-agent

或者设置自动清理：

spec: ttlSecondsAfterFinished: 3600

这表示任务完成后一小时自动删除。这个值不要设太小，否则任务刚结束就被删，你想查日志都来不及。一小时是个合理的窗口。

5. 常见问题与排查技巧实录

5.1 任务一直Pending的排查路径

Pending是最常见的问题，排查顺序如下：

现象	可能原因	排查命令	解决方法
Pending	资源不足	`kubectl describe pod`	调低requests或加节点
Pending	镜像拉取失败	`kubectl describe pod`	检查镜像地址和密钥
Pending	节点选择器不匹配	`kubectl get nodes --show-labels`	调整nodeSelector
Pending	PVC未绑定	`kubectl get pvc`	检查存储类配置

我遇到最多的是资源不足。特别是集群里跑了很多其他任务时，你的Agent任务可能一直排不上。这时候describe pod的Events里会明确写“Insufficient cpu”或“Insufficient memory”。

5.2 任务被OOM Kill的识别与处理

OOM Kill的表现是Pod状态变成OOMKilled，退出码137。用kubectl describe pod能看到。

处理方式有两种：一是调高memory limit，二是优化Agent的内存使用。我建议先调高limit观察，如果调高后还是被杀，说明Agent有内存泄漏，需要从代码层面解决。

调高limit的时候要注意，不能超过节点的可用内存。如果节点只有4Gi，你设8Gi的limit，Pod根本调度不上去。

5.3 日志丢失的预防措施

日志丢失通常发生在两个时刻：任务崩溃时和Pod被清理时。

预防措施：一是用--previous参数看崩溃前的日志，kubectl logs <pod> --previous；二是配置日志收集，把stdout的日志实时转发到外部存储；三是设置合理的ttlSecondsAfterFinished，给自己留出查日志的时间。

我踩过的坑是，任务失败后急着重新提交，结果把失败的Pod覆盖了，日志也没了。后来养成习惯，失败任务先kubectl logs存档，再重新提交。

5.4 镜像拉取慢的优化

Agent镜像通常比较大，因为要打包运行时和依赖。拉取慢会拖长任务启动时间。

优化方式：一是用镜像仓库的缓存，确保节点上已经有基础镜像；二是用imagePullPolicy: IfNotPresent，避免每次都拉；三是把大镜像拆成基础镜像和任务镜像，基础镜像预拉取。

5.5 并发任务互相干扰的处理

多个Agent任务同时跑，可能出现资源争抢。表现是任务变慢、超时增多。

处理方式：一是用ResourceQuota限制命名空间的总资源；二是用PriorityClass给重要任务更高优先级；三是用PodAntiAffinity让任务分散到不同节点。

affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: agent-task topologyKey: kubernetes.io/hostname

这段配置的意思是，尽量让agent-task的Pod不在同一个节点上。preferred表示是偏好而非强制，这样调度更灵活。

5.6 常见问题速查表

问题	快速定位	解决方向
任务不启动	`kubectl get events`	看调度事件
任务启动慢	`kubectl describe pod`	看镜像拉取耗时
任务中途失败	`kubectl logs --previous`	看崩溃前日志
任务结果丢失	检查挂载配置	改用PVC或外部存储
任务重复执行	检查backoffLimit	调低重试次数
集群变慢	`kubectl top nodes`	清理Completed任务

6. 工具选型与生态衔接：ax在Agentic栈里的位置

6.1 与codex cli、claude cli的关系

很多人会混淆ax和codex cli、claude cli这类工具。它们不是竞争关系，而是不同层次的东西。

codex cli和claude cli是Agent运行时，它们负责实际执行任务——生成代码、分析文档、调用工具。ax是编排层，它负责决定“什么时候跑哪个Agent、跑几个、跑在哪”。你可以把codex cli打包成镜像，然后用ax提交到Kubernetes上跑。

这个分层的好处是，你可以随时替换Agent运行时。今天用codex cli，明天想换成别的，只要接口兼容，编排层不用改。

6.2 与Karmada等多集群方案的衔接

当任务规模大到单集群扛不住时，就需要多集群编排。Karmada这类项目解决的就是这个问题——它把多个Kubernetes集群聚合成一个逻辑集群，你提交任务时不用关心具体跑在哪个集群。

ax这类CLI工具如果要支持多集群，通常的做法是在配置里指定多个集群的context，然后根据任务标签路由。这个能力在Agentic场景下很有用，因为不同集群可能有不同的硬件配置，比如有的集群有GPU，有的没有。

6.3 选型时的三个判断标准

面对一堆编排工具，怎么选？我的判断标准是三条：

是否声明式：声明式意味着你描述目标状态，系统负责达成。命令式意味着你要写每一步。Agentic任务复杂多变，声明式更合适。
是否可观测：任务跑起来后，你能不能看到它在干什么、卡在哪、为什么失败。可观测性差的工具，排查问题会很痛苦。
是否可扩展：今天跑10个任务，明天跑1000个，工具能不能平滑扩展。这取决于底层架构，Kubernetes在这方面有天然优势。

6.4 一个容易被忽略的细节：CLI的认证管理

CLI工具要访问Kubernetes API，就需要认证。认证方式有kubeconfig、ServiceAccount Token、证书等。

我的建议是，本地开发用kubeconfig，CI环境用ServiceAccount。ServiceAccount的好处是权限可以精细控制，而且不会因为个人证书过期导致任务失败。

配置ServiceAccount的步骤：

kubectl create serviceaccount ax-runner kubectl create rolebinding ax-runner-binding \ --clusterrole=edit \ --serviceaccount=default:ax-runner

然后把生成的Token配置到ax的认证文件里。注意，Token是有有效期的，要设置自动轮换。

7. 性能调优与规模化实践

7.1 调度延迟的优化

调度延迟是指从提交任务到Pod开始运行的时间。这个时间在规模化场景下会变得明显。

优化手段：一是预拉镜像，减少拉取时间；二是设置合理的requests，让调度器快速找到节点；三是用PodPriority，让重要任务优先调度。

我实测下来，预拉镜像能减少80%的启动时间。具体做法是在每个节点上跑一个DaemonSet，提前把常用镜像拉下来。

7.2 大规模任务下的etcd压力

Kubernetes的所有状态都存在etcd里。任务数量大时，etcd的写入压力会上升。

缓解方式：一是设置ttlSecondsAfterFinished，及时清理Completed的Job；二是避免频繁更新Job状态，比如不要用轮询的方式查状态，改用watch；三是etcd单独部署在高性能磁盘上。

7.3 成本控制的几个实用技巧

Agent任务跑在云上，成本是实打实的。几个控制技巧：

用Spot实例：Agent任务通常可以容忍中断，用Spot实例能省不少钱。配合tolerations和nodeSelector使用。
设置资源上限：用ResourceQuota限制命名空间的总资源，防止某个项目失控。
定时清理：用CronJob定期清理Completed和Failed的Job。
监控告警：对资源使用率设告警，超过阈值时及时介入。

7.4 从单集群到多集群的演进路径

如果任务量增长到单集群扛不住，演进路径通常是：

单集群多节点：先加节点，这是最简单的扩展。
多命名空间隔离：用命名空间隔离不同团队的任务。
多集群联邦：用Karmada这类工具做跨集群编排。
混合云：部分任务跑在私有云，部分跑在公有云。

每一步演进都有代价，不要过早优化。我见过团队在只有几十个任务的时候就上多集群，结果运维复杂度暴涨，得不偿失。

8. 安全与权限的边界处理

8.1 Agent任务的权限最小化

Agent任务在容器里跑，默认有容器的权限。但有些任务可能需要访问Kubernetes API，这时候就要给ServiceAccount。

原则是最小权限。任务只需要读Pod状态，就只给get和list权限，不要给create和delete。用Role和RoleBinding做命名空间级别的权限控制。

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: agent-tasks name: task-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]

8.2 敏感信息的注入方式

API Key、数据库密码这类敏感信息，绝对不要写在镜像里，也不要用明文环境变量。

正确做法是用Secret，然后以文件形式挂载到容器里。Agent运行时从文件读取，而不是从环境变量读取。这样即使有人能kubectl describe pod，也看不到敏感值。

volumes: - name: secrets secret: secretName: agent-secrets volumeMounts: - name: secrets mountPath: /etc/agent-secrets readOnly: true

8.3 网络隔离的配置

Agent任务可能需要访问外部API，也可能只需要内部通信。用NetworkPolicy控制流量。

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agent-netpol spec: podSelector: matchLabels: app: agent-task policyTypes: - Egress egress: - to: - namespaceSelector: {} ports: - protocol: TCP port: 443

这段配置允许Agent任务访问所有命名空间的443端口，其他流量被阻断。根据实际需求调整。

8.4 镜像安全扫描

Agent镜像里打包了运行时和依赖，可能包含已知问题。上线前做一次扫描是必要的。

扫描工具可以用Trivy或者Clair，集成到CI流程里。扫描不通过的镜像不允许推送到生产仓库。

9. 我踩过的坑与实操心得

9.1 不要用latest标签

我早期图省事，镜像都用latest标签。结果有一次更新了镜像，所有新任务都用了新版本，但新版本有个bug，导致大批任务失败。回滚的时候发现，latest已经被覆盖了，旧版本找不回来。

教训：永远用明确的版本标签，比如agent-runtime:v1.2.3。这样回滚就是改个标签的事。

9.2 超时时间要留余量

activeDeadlineSeconds设得太紧，正常任务会被误杀。我一开始设了300秒，结果代码生成任务经常跑到一半就被终止。

后来改成先观察正常任务的耗时分布，取P99值再乘以1.5作为超时时间。这样既不会误杀，又能及时清理卡死的任务。

9.3 日志要带上下文

Agent任务的日志如果只有一行“task failed”，排查起来很痛苦。我的做法是，每条日志都带上任务ID、时间戳、阶段标记。

echo "[$(date)] [task-$TASK_ID] [phase-1] starting model call"

这样出问题时，可以快速定位是哪个任务的哪个阶段出的错。

9.4 资源限制要实测

不要凭感觉填resources。我的做法是，先给一个宽松的限制，跑一批任务，然后用kubectl top pod看实际使用量，再根据实际值调整。

实测下来，Agent任务的CPU使用通常是波动的，峰值可能是平均值的3到5倍。内存相对平稳，但也要留20%的余量。

9.5 失败重试要有上限

backoffLimit不设或者设太大，会导致失败任务无限重试，浪费资源。我见过一个配置错误的任务重试了上百次，把集群资源耗光了。

建议设3到5次。同时配合告警，重试次数超过阈值时通知人工介入。

9.6 定期清理是必须的

Completed的Job和Pod不清理，etcd会越来越大，最终影响集群性能。我现在的做法是，用CronJob每天凌晨清理一次，保留最近7天的记录。

kubectl delete jobs --field-selector status.successful=1

这条命令删除所有成功的Job。失败的Job保留，方便排查。

9.7 文档要跟着配置走

配置改了，文档没改，是团队协作里最常见的坑。我的做法是，把配置和文档放在同一个仓库，改配置的时候强制更新文档。用CI检查，配置变更但文档没变更时，阻止合并。

这个习惯看起来麻烦，但省去了无数次“为什么和文档写的不一样”的沟通成本。

10. 后续可以这样扩展

如果这套基础跑通了，有几个方向可以继续深入。

一是引入工作流引擎。当任务依赖变得复杂时，单纯的Job编排不够用。可以考虑Argo Workflows这类工具，它支持DAG依赖、条件分支、循环。

二是做成本可视化。把每个任务的资源消耗换算成钱，按团队、按项目统计。这样能直观看到钱花在哪，优化有的放矢。

三是接入Agentic RAG。把检索增强生成的能力封装成Agent任务，用ax编排。这样检索、生成、验证可以拆成不同的任务，各自独立扩缩容。

四是多租户隔离。如果多个团队共用集群，需要做更细的隔离——资源配额、网络策略、镜像仓库权限，都要按租户配置。

我个人在实际操作中的体会是，Agentic编排这件事，难点不在技术，而在边界划分。哪些逻辑放在Agent里，哪些放在编排层，哪些放在Kubernetes里，想清楚了，实现就是水到渠成。想不清楚，就会陷入“什么都自己做”的泥潭。ax这类工具的价值，就是帮你把边界划清楚——CLI管触发，Kubernetes管调度，Agent管执行，各司其职。