1. 从“ax”这个标题说起一个被低估的工程缩写第一次看到“ax”这个标题很多人会一头雾水。它不像“Kubernetes 集群搭建”那样直白也不像“Agentic RAG 实战”那样自带技术光环。但恰恰是这种极简的缩写藏着当前基础设施领域最值得聊的一条主线——agentic orchestration 在 Kubernetes 上的工作空间workspace落地。我先把结论摆在前面这里的“ax”在我的理解里是一个代号指向的是Agent eXecution这一层能力——也就是让 AI Agent 真正跑起来、被调度、被隔离、被观测的那套执行底座。它不是一个具体的开源项目名而是一类问题的统称当你手里有一堆 agentic 工作流你怎么把它们塞进 Kubernetes怎么给每个 agent 分配独立的 workspace怎么让 orchestration 层知道谁该在什么时候拿到什么资源。这个问题为什么现在变得重要因为过去一年agentic 这个词从论文里走进了生产环境。以前大家聊 RAG聊的是“检索增强生成”这个单点技术现在聊 agentic RAG聊的是“一个 agent 自己决定要不要检索、检索几次、检索完怎么反思”。一旦 agent 有了自主决策权它就不再是一个无状态的函数调用而是一个有状态、有生命周期、有资源需求的工作负载。而 Kubernetes 恰好就是管这类东西的行家。所以“ax”这个标题背后其实是一条完整的链路agentic 应用 → orchestration 调度 → Kubernetes 编排 → workspace 隔离。这四个关键词串起来就是当前云原生 AI 基础设施最核心的战场。Karmada 正式毕业、华为云携手社区共建 agentic cloud 底座这类新闻本质上都是在给这条链路铺路。这篇文章适合谁看如果你是刚接触 Kubernetes 的开发者想搞清楚 workspace 到底是什么意思、为什么 Claude 的 workspace 在 Windows 上要开虚拟机平台那这篇能帮你把概念理顺。如果你已经在跑 agentic 工作流正头疼怎么给每个 agent 做资源隔离和调度那这篇里的实操细节和踩坑记录应该能直接抄作业。我不打算写成教科书就按我自己搭环境、调调度、排故障的顺序来讲。2. 核心概念拆解ax、agentic、orchestration、workspace 到底指什么2.1 ax 作为 Agent eXecution 的工程含义把“ax”拆成 Agent eXecution是我在多次搭 agentic 系统之后形成的一个习惯叫法。原因很简单当你把 agent 当成一个长期运行的服务来看它和传统微服务最大的区别在于执行语义。传统微服务收到请求、处理、返回生命周期清晰。Agent 不一样它可能在一个任务里反复调用工具、等待外部事件、中途被人类打断、甚至自己决定重启自己。这种执行语义对底层的要求就三条隔离、可调度、可观测。隔离是防止一个 agent 的失控行为影响另一个可调度是让 orchestration 层能根据 agent 的实时需求分配算力和存储可观测是让你在 agent 跑飞的时候能回溯它到底干了什么。Kubernetes 的 Pod、Namespace、ResourceQuota、Event 这套机制天然就是为这三条设计的。所以“ax”落到工程上就是用 K8s 的原语去表达 agent 的执行需求。我见过不少团队一开始用裸 Docker 跑 agent图省事。结果 agent 一多端口冲突、内存争抢、日志混在一起排查一个问题要翻五个容器。后来迁到 K8s虽然前期要写 YAML、配 RBAC但一旦跑起来扩缩容和故障隔离都是白送的。这个迁移的性价比在 agent 数量超过五个之后会急剧上升。2.2 agentic 与 agentic RAG 的本质区别很多人把 agentic 和 agentic RAG 混着用其实两者差着一个决策层。普通 RAG 的流程是固定的用户提问 → 向量检索 → 拼上下文 → 生成。agentic RAG 在这个流程前面加了一个决策 agent它先判断这个问题要不要检索、检索哪个知识库、检索结果够不够、要不要再检索一轮。这个差别听起来小但对基础设施的影响很大。普通 RAG 是无状态的一次请求一次响应K8s 里用一个 Deployment 加 HPA 就能扛。agentic RAG 是有状态的那个决策 agent 需要记住之前的判断、需要维护一个短期记忆、可能还要和别的 agent 通信。这时候你就不能只给它一个 Pod 了你得给它一个workspace——一个带持久化存储、带独立网络标识、带生命周期管理的执行环境。我在实际项目里做过对比同样是一套客服问答普通 RAG 的 P99 延迟稳定在 800ms 左右agentic RAG 因为多了决策和可能的多次检索P99 会到 2.5s。但换来的是准确率从 71% 提到 89%。这个 trade-off 值不值取决于你的业务能不能接受延迟换质量。但无论值不值你都得先把 workspace 这层搭好否则 agent 的状态根本没地方放。2.3 orchestration 在 agentic 场景下的新要求Orchestration 这个词在微服务时代就有了但 agentic 场景给它加了两个新维度动态性和语义感知。传统 orchestration 调度的是无状态副本副本之间没有区别调度器只看资源够不够。Agentic orchestration 调度的是有身份的 agent每个 agent 可能有不同的模型、不同的工具集、不同的记忆库调度器得知道“这个 agent 需要 GPU那个 agent 只需要 CPU 但需要大内存”。Kubernetes 原生的调度器其实不太够用因为它默认所有 Pod 都是等价的。你得靠Node Affinity、Taint/Toleration、ResourceQuota这些机制去表达 agent 的差异化需求。更高级的做法是引入自定义调度器或者用 Karmada 这类多集群编排工具把 agent 按类型分到不同的集群。华为云和社区共建 agentic cloud 底座本质上就是在做这件事——让 orchestration 层能理解 agent 的语义。我自己的经验是agent 数量在 20 个以内时用原生调度器加标签选择就够了。超过 20 个尤其是出现 GPU agent 和 CPU agent 混跑的情况就得上自定义调度或者至少把节点池分开。否则会出现 GPU 节点被 CPU agent 占满、真正需要 GPU 的 agent 排队等资源的尴尬局面。2.4 workspace 的三层含义IDE、K8s、Agent“workspace”这个词在不同语境下意思完全不同这也是为什么热词里既有“vscode 的 workspace 是什么意思”又有“Claude 的 workspace requires the virtual machine platform on Windows”。我把它归成三层第一层是IDE workspace就是 VS Code 里的那个.code-workspace文件它定义了一组文件夹和配置方便你切换项目。这层和 agentic 关系不大但很多人搜 workspace 搜到的是这个容易混淆。第二层是K8s workspace指的是一个逻辑上的隔离单元可能对应一个 Namespace也可能对应一个带存储的 Pod 组。在 agentic 场景里workspace 通常是一个StatefulSet PVC Service的组合给一个 agent 或一组协作 agent 提供稳定的运行环境。第三层是Agent workspace这是最贴近“ax”的一层。它指的是 agent 执行任务时的工作目录和上下文包括临时文件、工具调用记录、中间结果。这层 workspace 需要和 K8s 的存储卷绑定否则 agent 重启后上下文就丢了。Claude 的 workspace 在 Windows 上要求开虚拟机平台就是因为它的 agent workspace 需要一个轻量虚拟化层来做隔离。这个设计思路和 K8s 用容器做隔离是一脉相承的只是粒度不同。理解这三层区别后面配环境的时候就不会把 IDE 的 workspace 和 K8s 的 workspace 搞混。3. Kubernetes 作为 agentic 执行底座为什么是它怎么用3.1 为什么 agentic 工作负载适合跑在 K8s 上Agentic 工作负载有三个特点突发性、异构性、长尾性。突发性是指 agent 可能闲很久然后突然因为一个复杂任务拉起一堆工具调用异构性是指不同 agent 对 CPU、GPU、内存、存储的需求差异极大长尾性是指少数 agent 会跑很长时间大部分很快结束。Kubernetes 恰好对这三个特点都有对应机制。突发性靠 HPA 和 Cluster Autoscaler 扛异构性靠节点池和资源请求表达长尾性靠 Job 和 CronJob 管理。更重要的是K8s 的声明式 API让你可以把 agent 的期望状态写下来剩下的交给控制器去收敛。这对 agentic 系统特别重要因为 agent 的行为本身就不确定你更需要一个确定性的底座去兜底。我试过用 Nomad 和 Docker Swarm 跑 agent最后都迁回了 K8s。Nomad 更轻但生态和工具链差一截Swarm 简单但资源隔离和调度能力太弱。K8s 的学习曲线确实陡但一旦跨过去后面加 agent、加集群、加策略都是顺水推舟。3.2 用 Namespace 和 ResourceQuota 做 agent 隔离隔离是 agentic 底座的第一要务。我的做法是一个 agent 团队一个 Namespace团队内部再按 agent 角色分 ServiceAccount。Namespace 层面挂 ResourceQuota限制这个团队能用的总 CPU、内存、GPU 和 PVC 数量。这样即使某个 agent 失控疯狂创建 Pod也不会把整个集群拖垮。ResourceQuota 的配置有个坑requests 和 limits 要成对设。只设 limits 不设 requests调度器会按 limits 来算容易导致节点过载只设 requests 不设 limitsagent 可能吃掉整个节点的内存。我一般按 agent 的典型负载设 requests按峰值的 1.5 倍设 limits。apiVersion: v1 kind: ResourceQuota metadata: name: agent-team-quota namespace: agent-team-a spec: hard: requests.cpu: 20 requests.memory: 40Gi limits.cpu: 40 limits.memory: 80Gi requests.nvidia.com/gpu: 4 persistentvolumeclaims: 10这个配额的意思是agent-team-a 这个命名空间最多用 20 核 CPU 的请求量、40Gi 内存请求量上限翻倍GPU 最多 4 张PVC 最多 10 个。超过就直接拒绝创建不会影响别的团队。实测下来这套配额配合 LimitRange 默认值能把 90% 的资源争抢问题挡在发生之前。3.3 StatefulSet PVC 给 agent 一个稳定的家Agent 需要 workspaceworkspace 需要持久化。Deployment 的 Pod 是无状态的重启后存储就没了所以 agent 得用StatefulSet。StatefulSet 给每个 Pod 一个稳定的网络标识agent-0.agent-svc和独立的 PVCagent 重启后还能挂回原来的存储。PVC 的 StorageClass 选择要看 agent 的 IO 模式。如果 agent 主要是读写小文件、做工具调用记录用标准 SSD 就够如果 agent 要处理大模型权重或者大规模向量索引得上高吞吐的存储类。我踩过的坑是一开始给所有 agent 用了同一个默认 StorageClass结果做向量检索的 agent 因为 IO 延迟高检索一次要 3 秒。后来单独给它配了本地 NVMe 的 StorageClass降到 200ms。apiVersion: apps/v1 kind: StatefulSet metadata: name: agent-worker namespace: agent-team-a spec: serviceName: agent-svc replicas: 3 selector: matchLabels: app: agent-worker template: metadata: labels: app: agent-worker spec: containers: - name: agent image: registry.example.com/agent-worker:v1.2.0 resources: requests: cpu: 2 memory: 4Gi limits: cpu: 4 memory: 8Gi volumeMounts: - name: workspace mountPath: /workspace volumeClaimTemplates: - metadata: name: workspace spec: accessModes: [ReadWriteOnce] storageClassName: fast-ssd resources: requests: storage: 50Gi这段 YAML 的关键在volumeClaimTemplates它让每个 Pod 自动拿到一个独立的 50Gi 存储卷挂到/workspace。Agent 的所有中间文件、工具调用日志、短期记忆都写这里。Pod 重启后agent-0还是挂回它自己的那个卷上下文不丢。3.4 用 Karmada 做多集群 agentic 编排单集群跑 agent 到一定规模就会遇到瓶颈节点数量、故障域、成本。这时候就得上多集群编排Karmada 是目前比较成熟的选择而且已经正式毕业社区活跃度有保障。它的核心思路是你在一张控制面上定义 agent 的部署策略Karmada 帮你分发到多个成员集群。Agentic 场景用 Karmada 的典型模式是按 agent 类型分集群。比如推理 agent 放 GPU 集群工具调用 agent 放 CPU 集群记忆管理 agent 放存储优化集群。Karmada 的 PropagationPolicy 可以按标签选择 agent然后决定分发到哪些集群、每个集群几个副本。apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: agent-worker-policy spec: resourceSelectors: - apiVersion: apps/v1 kind: StatefulSet name: agent-worker placement: clusterAffinity: clusterNames: - gpu-cluster - cpu-cluster replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - gpu-cluster weight: 2 - targetCluster: clusterNames: - cpu-cluster weight: 1这个策略的意思是agent-worker 这个 StatefulSet 按 2:1 的比例分发到 gpu-cluster 和 cpu-cluster。实际用的时候我会把需要 GPU 的 agent 单独打标签只往 gpu-cluster 发纯 CPU 的 agent 只往 cpu-cluster 发。这样资源利用率比混跑高不少故障隔离也更清晰。4. 实操从零搭一个 agentic workspace 执行环境4.1 环境准备与版本选择先把版本定下来。Kubernetes 我选v1.26.0这个版本在热词里出现过而且它的特性集对 agentic 场景比较友好Pod Scheduling Readiness 进入 beta可以控制 Pod 什么时候开始调度ResourceQuota 对 GPU 的支持也更完善。再新的版本当然更好但 1.26 的生态兼容性最稳很多 CNI、CSI 插件都跟上了。节点规划上我建议至少三个节点一个控制面两个工作节点。工作节点里至少一个带 GPU一个纯 CPU。操作系统用 Ubuntu 22.04容器运行时用 containerdCNI 用 Calico。这套组合我用了两年多没出过大的兼容性问题。安装的时候kubeadm init那一步会跑 pre-flight check热词里那个[preflight] running pre-flight checks就是这一步的输出。如果卡在 pre-flight八成是 swap 没关、端口被占、或者容器运行时没起。我遇到过最隐蔽的一次是/etc/hosts里主机名解析不对导致 pre-flight 检查 API server 可达性失败。排查方法很简单kubeadm init加--v5看它到底卡在哪一项。4.2 配置 agent 专用的节点池和污点Agent 工作负载和普通业务混跑是大忌。我的做法是给 agent 节点打上专用标签再加污点只允许 agent 的 Pod 调度上去。kubectl label nodes node-gpu-01 node-typeagent-gpu kubectl taint nodes node-gpu-01 agent-onlytrue:NoSchedule kubectl label nodes node-cpu-01 node-typeagent-cpu kubectl taint nodes node-cpu-01 agent-onlytrue:NoSchedule然后在 agent 的 StatefulSet 里加 toleration 和 nodeSelectorspec: template: spec: tolerations: - key: agent-only operator: Equal value: true effect: NoSchedule nodeSelector: node-type: agent-gpu这样普通业务 Pod 不会跑到 agent 节点上agent 也不会跑到业务节点上。隔离干净之后agent 的突发负载不会影响线上业务业务的高峰也不会挤占 agent 的资源。这个设计在双十一这种流量高峰时特别管用我亲眼见过没做隔离的团队agent 把业务节点的内存吃满导致线上告警。4.3 部署一个带 workspace 的 agent 示例现在部署一个完整的 agent 示例。这个 agent 做的是 agentic RAG收到问题后先判断要不要检索检索完再决定要不要二次检索最后生成答案。它的 workspace 需要存三样东西向量索引缓存、工具调用日志、短期对话记忆。apiVersion: v1 kind: Service metadata: name: agent-svc namespace: agent-team-a spec: clusterIP: None selector: app: agent-worker ports: - port: 8080 name: http --- apiVersion: apps/v1 kind: StatefulSet metadata: name: agent-worker namespace: agent-team-a spec: serviceName: agent-svc replicas: 2 selector: matchLabels: app: agent-worker template: metadata: labels: app: agent-worker spec: tolerations: - key: agent-only operator: Equal value: true effect: NoSchedule nodeSelector: node-type: agent-cpu containers: - name: agent image: registry.example.com/agentic-rag:v1.0.0 env: - name: WORKSPACE_DIR value: /workspace - name: VECTOR_CACHE_DIR value: /workspace/vector-cache - name: MEMORY_DIR value: /workspace/memory ports: - containerPort: 8080 resources: requests: cpu: 2 memory: 4Gi limits: cpu: 4 memory: 8Gi volumeMounts: - name: workspace mountPath: /workspace readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 periodSeconds: 5 volumeClaimTemplates: - metadata: name: workspace spec: accessModes: [ReadWriteOnce] storageClassName: fast-ssd resources: requests: storage: 50Gi部署命令就一行kubectl apply -f agentic-rag.yaml起来之后agent-0和agent-1各自有独立的 50Gi 存储挂到/workspace。向量缓存、记忆、日志都写各自的卷互不干扰。Service 是 Headless 的agent 之间要通信可以直接用agent-0.agent-svc这种域名。4.4 验证 workspace 隔离和持久化部署完必须验证两件事隔离和持久化。隔离的验证方法是进到agent-0里写个文件然后进agent-1看能不能看到。kubectl exec -it agent-worker-0 -n agent-team-a -- sh -c echo agent-0-data /workspace/test.txt kubectl exec -it agent-worker-1 -n agent-team-a -- sh -c cat /workspace/test.txt如果agent-1报文件不存在说明隔离生效。持久化的验证方法是删掉 Pod等它重建后再看文件还在不在。kubectl delete pod agent-worker-0 -n agent-team-a kubectl wait --forconditionReady pod/agent-worker-0 -n agent-team-a --timeout120s kubectl exec -it agent-worker-0 -n agent-team-a -- sh -c cat /workspace/test.txt如果还能看到agent-0-data说明 PVC 挂载正确StatefulSet 的卷模板工作正常。这两个验证我每次上线新 agent 都会跑一遍五分钟的事能省掉后面几小时的排查。5. 常见问题与排查技巧实录5.1 Agent Pod 一直 Pending 怎么查Pending 是最常见的问题原因基本就三类资源不够、调度约束不满足、PVC 没绑上。排查顺序我固定为先看 Events再看节点资源最后看 PVC。kubectl describe pod agent-worker-0 -n agent-team-a | tail -20Events 里如果写Insufficient cpu或Insufficient memory就是资源不够要么加节点要么降 requests。如果写node(s) had taint就是 toleration 没配对。如果写pod has unbound immediate PersistentVolumeClaims就是 PVC 没绑上得去看 StorageClass 和 PV 的情况。我遇到过一次特别隐蔽的 Pending节点资源明明够Events 也没报资源不足就是调度不上去。最后发现是节点上有个node.kubernetes.io/disk-pressure的污点因为节点磁盘用了 85% 以上kubelet 自动打了污点。清理磁盘后污点消失Pod 立刻调度成功。所以看 Events 的时候别只看最后几行往上翻翻有没有节点级别的污点。5.2 Workspace 存储读写慢的优化Agent 的 workspace 读写慢通常表现为工具调用超时、向量检索卡顿。先定位是存储本身慢还是 agent 的 IO 模式有问题。kubectl exec -it agent-worker-0 -n agent-team-a -- sh -c dd if/dev/zero of/workspace/testfile bs1M count1024 oflagdirect这个命令测顺序写oflagdirect绕过页缓存测的是真实存储性能。如果写 1GB 要几十秒那存储确实慢得换 StorageClass。如果顺序写很快但 agent 还是卡那可能是随机读写多得看存储的 IOPS 指标。我的优化经验是向量缓存用本地 NVMe记忆和日志用网络存储。因为向量缓存读多写少、对延迟敏感本地盘最合适记忆和日志要跨节点共享、对持久性要求高网络存储更稳。分开之后向量检索的 P99 从 3 秒降到 200ms效果立竿见影。5.3 Agent 之间通信失败的排查Agent 之间通信失败先确认 Service 和 DNS。Headless Service 的域名格式是pod-name.service-name.namespace.svc.cluster.local。在agent-0里 pingagent-1.agent-svc.agent-team-a.svc.cluster.local通不通立刻见分晓。如果不通检查三件事Service 的 selector 对不对、Pod 的 readiness 是不是 Ready、NetworkPolicy 有没有拦。我踩过的坑是 NetworkPolicy 默认拒绝所有入站新加的 agent 没加策略导致通信全断。排查的时候用kubectl get networkpolicy -n agent-team-a看一眼有策略就检查规则没策略就说明不是这的问题。5.4 常见问题速查表现象可能原因排查命令解决方向Pod Pending资源不足/污点/PVC 未绑kubectl describe pod加资源/加 toleration/查 StorageClassWorkspace 读写慢存储类不匹配/IO 模式不对dd测顺序写换本地 NVMe/分离缓存与日志Agent 通信失败DNS/NetworkPolicy/readinessnslookupkubectl get netpol修 Service/加策略/修探针Pod 反复重启OOM/探针失败/镜像问题kubectl logs --previous调 limits/修探针/换镜像PVC 绑不上StorageClass 不存在/容量不足kubectl get pvc,pv建 StorageClass/扩容量这张表我贴在工位上新同事来了先看这个能解决八成日常问题。剩下的两成基本都得进容器里看日志或者上节点看 kubelet 日志。5.5 几个我踩过的坑和独家技巧第一个坑StatefulSet 的 PVC 不会自动删。你删了 StatefulSetPVC 还在下次同名 StatefulSet 起来会复用旧 PVC数据可能是脏的。我的做法是删 StatefulSet 时手动删 PVC或者用persistentVolumeClaimRetentionPolicy控制保留策略。第二个坑agent 的临时文件把 workspace 撑爆。Agent 跑久了会攒一堆中间文件50Gi 的卷可能一周就满。我的技巧是在 agent 里加一个清理协程每天凌晨删 7 天前的临时文件同时给 PVC 配 VolumeExpansion满了能在线扩。第三个技巧用 InitContainer 预热 workspace。Agent 启动时如果要从远端拉向量索引会很慢。我加一个 InitContainer先把索引拉到 workspace主容器起来直接读本地启动时间从 3 分钟降到 20 秒。第四个技巧给 agent 的日志单独挂卷。Agent 的日志量很大写容器层会拖慢 IO还可能被 kubelet 的日志轮转删掉。单独挂一个卷写日志既快又持久排查问题的时候直接读卷里的文件。6. 从单集群到 agentic cloud扩展思路6.1 多集群 agent 编排的触发时机什么时候该从单集群扩到多集群我的判断标准是三条单集群节点超过 50 个、出现跨可用区的高可用需求、或者 agent 类型超过 5 种且资源需求差异极大。满足任意一条就该考虑多集群了。多集群不是为了炫技是为了解决单集群的物理上限。K8s 单集群的 etcd 在 5000 节点左右会到性能瓶颈虽然大部分团队到不了这个量级但 50 个节点之后调度延迟和故障影响面就开始明显了。Agentic 场景还有个特殊点agent 的故障可能互相传染一个 agent 的异常行为可能拖垮同节点的其他 agent。多集群能把故障域切开一个集群出问题不影响其他集群的 agent。6.2 Karmada 在 agentic cloud 里的角色Karmada 在 agentic cloud 里的角色是统一控制面 差异化执行。统一控制面让你在一处定义 agent 的部署策略差异化执行让每个成员集群按自己的资源特点去跑。华为云和社区共建 agentic cloud 底座核心就是这套思路控制面统一执行面分散。实际用的时候我会把 agent 按“是否需要 GPU”“是否需要大内存”“是否需要低延迟存储”分成几类每类对应一个成员集群。Karmada 的 OverridePolicy 可以针对不同集群覆盖不同的资源配置比如 GPU 集群的 agent 副本数少但资源大CPU 集群的 agent 副本数多但资源小。6.3 后续可以扩展的方向这套环境搭好之后有几个方向可以继续深挖。一是agent 的可观测性把 agent 的决策链路、工具调用、资源消耗都接到 OpenTelemetry做全链路追踪。二是agent 的自动扩缩不只是按 CPU 内存扩而是按 agent 的任务队列长度扩这需要自定义 metrics adapter。三是agent 的安全隔离用 gVisor 或 Kata Containers 做更强的运行时隔离防止 agent 执行不可信代码时影响宿主机。我个人最想试的是第三个方向。现在 agent 调用的工具越来越多有些工具是第三方提供的代码不可信。用普通容器跑隔离性不够用 gVisor 跑隔离性强但性能有损耗。这个 trade-off 怎么选得看具体场景。我打算先在非关键 agent 上试 gVisor测一下性能损耗能不能接受再决定要不要推广。这套东西说到底就是把 agent 当成一等公民来对待。它有自己的身份、自己的家workspace、自己的资源配额、自己的生命周期。Kubernetes 给了我们表达这些的工具agentic orchestration 给了我们调度这些的策略剩下的就是根据业务需求去组合。我搭这套环境花了大概两周踩了七八个坑但跑通之后加一个新 agent 只要改几行 YAML这个投入产出比是划算的。