1. 项目概述：一次Agent调度系统的重构之旅

最近在优化一个内部AI应用的后端架构，核心痛点在于那个自研的Agent调度模块。这个模块负责协调多个AI智能体（Agent）协同工作，处理用户复杂的查询任务。最初的版本，是我和团队花了几个月时间从零搭建的，代码量一度膨胀到了700多行。功能虽然跑通了，但维护成本高得吓人，每次新增一个Agent类型或者调整调度策略，都像在给一个已经塞满的行李箱硬塞东西，稍有不慎就引发连锁bug。更头疼的是资源调度，经常出现几个计算密集型的Agent挤在一台机器上“打架”，而其他机器却在“围观”的情况。

直到我遇到了OpenClaw。这是一个开源的、云原生的AI Agent编排与调度框架。最初我只是抱着试试看的心态，想看看它能不能替代我们调度逻辑中最复杂的那部分。结果一番折腾下来，不仅核心调度功能被完美替代，整个模块的代码从700行锐减到了72行，而且系统的稳定性、可观测性和弹性伸缩能力都上了一个台阶。这不仅仅是一次简单的库替换，更像是对整个Agent服务治理思路的重构。今天，我就把这趟“降本增效”的实操过程拆开揉碎了分享给你，无论你是在纠结是否要自研调度，还是已经在维护一个类似的“巨无霸”模块，或许都能找到一些启发。

2. 为什么选择OpenClaw：自研调度之痛与开源方案之利

2.1 自研Agent调度器的典型困境

在决定替换之前，我们得先搞清楚自己手里的“轮子”为什么不好用。我们那个700行的自研调度器，主要承担了以下几类工作：

1. 生命周期管理 ：负责Agent的创建、初始化、运行状态监控和销毁。这部分代码充斥着各种 try...catch 和状态标志位，逻辑分支非常多。
2. 任务队列与分发 ：实现了一个简单的优先级队列，根据任务类型和紧急程度，将任务分发给空闲的Agent。这里涉及到复杂的锁机制来保证线程安全，代码既冗长又容易出错。
3. 资源感知与负载均衡 ：需要监控每个Agent实例（可能分布在多个容器或进程里）的CPU、内存使用情况，避免将重任务分发给已经高负载的节点。我们实现了一套简单的心跳机制和负载打分算法，这部分代码对网络抖动非常敏感。
4. 错误处理与重试 ：当某个Agent执行失败时，需要决定是重试、换一个Agent实例执行，还是直接向上游报错。重试策略（如指数退避）和故障转移逻辑写得很僵化。

这些功能堆砌在一起，导致模块高度耦合。想改一下负载均衡策略？可能动到任务队列的锁。想加一种新的错误类型？得翻遍所有的状态判断逻辑。测试更是噩梦，需要模拟各种并发场景和异常情况，才能有基本的信心。

2.2 OpenClaw的核心优势与契合度分析

OpenClaw的出现，几乎是为解决上述痛点而生的。它不是一个简单的函数库，而是一个遵循Kubernetes Operator模式的 声明式调度框架 。它的核心思想是：你只需要告诉它“你想要什么状态”（比如，运行3个总结Agent，2个代码生成Agent，并且确保CPU使用率低于70%），它就会自动地、持续地调整系统以达到并维持那个状态。这与我们之前“如何做”的命令式编程逻辑有本质区别。

具体来说，OpenClaw给我们带来的吸引力在于：

• 内置强大的调度算法 ：它原生支持基于资源（CPU/内存/GPU）的装箱（Bin Packing）、扩散（Spread）等策略，并且可以自定义评分插件。这意味着我们那套脆弱的自研负载均衡算法可以直接丢弃。
• 云原生基因 ：天然拥抱Kubernetes，能够以CRD（自定义资源）的方式定义和管理Agent。这让Agent的部署、扩缩容、版本回滚变得和部署一个普通应用一样简单。我们的Agent实例本身就是跑在K8s Pod里的，契合度满分。
• 复杂的运维能力开箱即用 ：健康检查、自动重启、滚动更新、资源限制与配额管理，这些我们之前要写大量胶水代码的功能，OpenClaw通过配置即可实现。
• 可观测性 ：与Prometheus、Grafana等监控栈无缝集成，调度决策、队列深度、Agent状态等指标一目了然，告别“黑盒”。

决策的关键在于，我们发现自研调度器中超过80%的代码，都是在实现一个“弱化版”的Kubernetes调度器+Operator的功能。用OpenClaw，相当于直接接入了工业级的解决方案，团队可以将精力从“造轮子”和“修轮子”中解放出来，聚焦在业务Agent本身的逻辑优化上。

3. 架构迁移：从700行代码到72行配置的蜕变

3.1 原有架构解耦与职责重定义

迁移的第一步不是直接写新代码，而是对原有系统进行“外科手术式”的解耦。我们用了一个周末的时间，画出了现有的模块依赖图，目标是清晰地剥离出“调度”这一核心职责。

原来的单体调度模块混杂了以下逻辑：

• 业务逻辑 ：理解任务类型，选择Agent类型。
• 控制逻辑 ：任务队列、锁、线程池管理。
• 运维逻辑 ：健康检查、重启、资源监控。

我们的重构策略是：

1. 保留并精简业务逻辑 ：这是一个轻量的“决策器”（Orchestrator），它只负责解析用户请求，生成一个“任务规划”（例如：先调用搜索Agent，再调用总结Agent）。这部分代码大约50行，是业务核心，不能丢。
2. 将控制逻辑移交OpenClaw ：任务队列、生命周期管理、资源调度，全部通过定义OpenClaw的CRD（ AgentPool ， AgentTask ）来描述。
3. 将运维逻辑移交K8s和OpenClaw ：健康检查、资源限制等通过Pod的 livenessProbe 和 resources 字段定义。

经过梳理，我们明确了新的边界： Orchestrator（决策器） + OpenClaw（调度器） + K8s（执行平台） 。Orchestrator只和OpenClaw的API打交道，发出“需要什么”的指令，完全不关心“如何实现”。

3.2 基于OpenClaw CRD的模型设计

这是迁移的核心技术环节。OpenClaw的行为完全由我们定义的CRD驱动。我们主要设计了两种资源：

1. AgentPool：定义Agent资源池 这相当于Agent的“模版”和“舰队管理”。我们为每类Agent（如 Summarizer ， Coder ）创建一个 AgentPool 。

# agentpool-summarizer.yaml
apiVersion: openclaw.ai/v1alpha1
kind: AgentPool
metadata:
  name: summarizer-pool
spec:
  # Agent的模版，本质上是一个K8s Pod模版
  template:
    spec:
      containers:
      - name: summarizer-agent
        image: your-registry/summarizer-agent:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        env:
        - name: MODEL_ENDPOINT
          value: "http://llm-service/chat"
        livenessProbe: # 健康检查交给K8s
          httpGet:
            path: /health
            port: 8080
  # 调度策略：希望维持2个常备实例，最多可扩容到5个
  replicas: 2
  maxReplicas: 5
  # 扩缩容策略：当平均CPU使用率超过70%时，开始扩容
  autoScaling:
    metric: cpu
    target: 70

2. AgentTask：定义具体任务 当Orchestrator决定要执行一个总结任务时，它不再直接调用某个Pod，而是创建一个 AgentTask 对象。

# agent-task-request.yaml
apiVersion: openclaw.ai/v1alpha1
kind: AgentTask
metadata:
  name: summarize-doc-12345
spec:
  # 任务需要哪种Agent
  agentPoolSelector:
    matchLabels:
      type: summarizer
  # 任务的输入参数
  input:
    documentId: "doc_12345"
    format: "bullet_points"
  # 任务优先级，影响调度顺序
  priority: 100
  # 任务超时时间
  timeoutSeconds: 300

OpenClaw的控制器会持续监听 AgentTask 和 AgentPool 。当发现一个 AgentTask 时，它会：

1. 根据 agentPoolSelector 找到对应的 AgentPool 。
2. 从该池中选择一个健康且负载合适的Agent实例（Pod）。
3. 将 input 中的数据通过Sidecar或者直接注入环境变量的方式传递给该Pod。
4. 跟踪任务执行状态，更新 AgentTask 的状态字段（如 Running ， Succeeded ， Failed ）。

我们的Orchestrator只需要创建 AgentTask ，然后轮询或监听其状态即可。 原来700行代码中复杂的排队、负载计算、实例选择逻辑，全部被这几十行的YAML配置和OpenClaw的内部算法替代了。

3.3 新旧模块接口对比与改造点

改造前后，核心接口发生了根本变化：

模块	自研调度器时期	基于OpenClaw时期
Orchestrator	调用 Scheduler.submitTask(task) ，传入一个复杂对象，同步等待或通过回调接收结果。需要处理 NoAvailableAgentException 等异常。	调用K8s API create(namespace, agentTaskYaml) ，创建一个 AgentTask CRD对象。通过K8s Watch机制或轮询 AgentTask.status 获取结果。
Agent实现侧	需要实现特定的RPC或HTTP接口，供调度器统一调用。启动、停止受调度器管理。	只需作为一个标准的、可独立运行的HTTP/gRPC服务。通过环境变量或请求体接收 AgentTask.input 。生命周期由K8s管理。
配置管理	调度策略、资源限制等硬编码在代码中或复杂的配置文件中。	全部通过K8s ConfigMap、Secret和OpenClaw CRD的 spec 进行声明式配置。
监控	需要自行埋点，输出日志或指标到自定义收集器。	Agent提供标准的 /health 和 /metrics 端点。OpenClaw和K8s自动收集丰富的调度和资源指标。

主要的改造工作集中在：

1. Orchestrator重写 ：从直接调用调度器SDK，改为调用K8s Client-go库来操作CRD。代码量从200多行减少到不足100行，且大部分是K8s客户端初始化。
2. Agent容器化标准化 ：确保每个Agent服务都提供健康检查接口，并正确暴露资源指标。
3. 部署流程更新 ：CI/CD流水线需要增加一步，将 AgentPool 和相关的K8s资源（如Service, ConfigMap）一同部署。

4. 核心实现：OpenClaw的部署、配置与集成

4.1 OpenClaw的安装与初始配置

OpenClaw的安装非常“云原生”。我们选择通过Helm Chart将其部署到我们的Kubernetes生产集群中。

# 添加OpenClaw的Helm仓库
helm repo add openclaw https://openclaw-ai.github.io/helm-charts
helm repo update

# 安装OpenClaw Operator到 openclaw-system 命名空间
helm install openclaw openclaw/openclaw-operator -n openclaw-system --create-namespace

安装完成后，需要验证Operator是否正常运行，以及CRD是否已注册：

kubectl get pods -n openclaw-system
kubectl get crd | grep openclaw.ai

接下来是关键的 初始配置 ，这决定了OpenClaw的全局行为。我们创建了一个 values.yaml 文件进行定制化安装：

# my-openclaw-values.yaml
operator:
  # 资源限制，避免Operator本身消耗过多资源
  resources:
    requests:
      memory: 128Mi
      cpu: 100m
    limits:
      memory: 256Mi
      cpu: 200m

scheduler:
  # 调度器插件配置，启用我们需要的策略
  plugins:
    score:
      - name: NodeResourcesFit # 节点资源匹配
      - name: NodeResourcesBalancedAllocation # 节点资源均衡分配
      - name: InterPodAffinity # Pod间亲和性（可用于让同类型Agent分散部署）
  # 调度器执行周期，生产环境可以调大以降低API Server压力
  schedulerInterval: 10s

metrics:
  enabled: true # 启用Prometheus指标暴露
  serviceMonitor:
    enabled: true # 如使用Prometheus Operator，可自动创建ServiceMonitor

然后使用这个配置进行安装： helm install -f my-openclaw-values.yaml openclaw openclaw/openclaw-operator -n openclaw-system 。

注意 ：OpenClaw的调度器是集群级别的组件。在生产环境中，需要根据集群规模调整 schedulerInterval 和Operator的资源限制。过短的间隔会导致频繁的API调用，可能触发K8s API Server的限流。

4.2 AgentPool与AgentTask的详细配置解析

让我们回到最核心的两个CRD，深入看看一些高级配置如何帮助我们解决实际问题。

AgentPool的弹性伸缩（HPA集成） 除了OpenClaw自带的基于简单指标的扩缩容，我们更倾向于使用K8s Horizontal Pod Autoscaler (HPA)，因为它更成熟，支持自定义指标。我们可以这样配置：

# 首先，AgentPool本身不设置autoScaling，而是由HPA控制
# agentpool-summarizer.yaml (部分)
spec:
  template:
    # ... pod spec ...
  replicas: 2 # 初始副本数

# 然后，创建一个HPA针对这个AgentPool管理的Deployment
# hpa-summarizer.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: summarizer-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment # OpenClaw会为每个AgentPool创建一个对应的Deployment
    name: openclaw-agentpool-summarizer-pool # 这个名称是OpenClaw自动生成的，规则固定
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods # 使用自定义指标，如队列长度
    pods:
      metric:
        name: tasks_queue_length_per_pod
      target:
        type: AverageValue
        averageValue: 5

这样，当每个Pod的CPU平均使用率超过70%，或者每个Pod等待处理的任务队列长度超过5时，HPA就会自动扩容。

AgentTask的依赖与工作流 复杂任务往往需要多个Agent按顺序执行。OpenClaw支持在 AgentTask 中定义 dependencies 。

apiVersion: openclaw.ai/v1alpha1
kind: AgentTask
metadata:
  name: research-and-summarize-001
spec:
  agentPoolSelector:
    matchLabels:
      type: summarizer
  input:
    text: "{{ .Tasks.search.output.result }}"
  dependencies:
    - name: search # 依赖另一个名为‘search’的AgentTask
      taskRef:
        name: search-web-001

Orchestrator可以先创建 search-web-001 这个Task，等其状态变为 Succeeded 后，再创建 research-and-summarize-001 。OpenClaw本身不直接驱动工作流，但通过这种依赖声明，我们可以轻松地在Orchestrator中构建有向无环图（DAG）式的任务流。

4.3 与现有监控、日志体系的集成

可观测性是生产系统的生命线。集成过程很顺畅：

1. 指标监控 ：OpenClaw Operator默认暴露了Prometheus格式的指标在 :8080/metrics 。我们通过ServiceMonitor（如果使用Prometheus Operator）或直接在Prometheus配置中添加抓取任务，即可收集到诸如 openclaw_scheduler_queue_depth 、 openclaw_agent_tasks_processed_total 、 openclaw_agentpool_desired_replicas 等关键指标。我们在Grafana中制作了专属看板，实时展示调度性能、任务吞吐量和各AgentPool的健康状态。

2. 日志收集 ：OpenClaw Operator和它创建的Agent Pod的日志，通过集群内已部署的Fluentd或Fluent Bit收集，统一输出到Elasticsearch。这里的关键是 为不同AgentPool的Pod设置不同的标签 。在 AgentPool 的 template.metadata.labels 中增加 agent-type: summarizer ，这样在日志查询时可以通过 agent-type 快速过滤，定位问题。

3. 分布式追踪 ：我们的Agent服务已集成了OpenTelemetry。OpenClaw在创建 AgentTask 时，可以在 input 中携带一个 traceId 。Orchestrator在发起整个请求链时生成这个 traceId ，并传递给每一个 AgentTask 。这样，在Jaeger或Zipkin中，我们就能看到一个用户请求从Orchestrator到各个Agent的完整调用链，对于排查延迟和故障点至关重要。

5. 性能对比与稳定性提升实测

5.1 资源利用率与调度效率量化分析

迁移完成后，我们进行了为期一周的对比压测。使用相同的基础设施和负载生成模式，对比新旧两套系统。

指标	自研调度器	OpenClaw调度
平均任务调度延迟	120ms ± 50ms	45ms ± 15ms
集群CPU平均使用率	65%	78%
集群内存平均使用率	70%	85%
单节点最大任务并行数	不稳定，常出现热点	均匀分布，受资源限制控制
调度失败率（无可用资源）	0.5%	< 0.1%

结果分析 ：

• 调度延迟降低 ：主要得益于OpenClaw调度器的高效算法和与K8s调度器的深度集成，减少了我们自研队列的锁竞争开销。
• 资源利用率提升 ：OpenClaw的 NodeResourcesBalancedAllocation 插件有效避免了资源碎片，使Pod在节点间的分布更均匀，从而提升了整体资源利用率。这意味着我们可以用更少的节点承载相同的负载，直接降低了云资源成本。
• 稳定性增强 ：基于HPA的弹性伸缩比我们自研的简单规则反应更灵敏、更准确，在面对流量波峰时能快速扩容，波谷时及时缩容，避免了资源浪费和排队拥堵。

5.2 异常处理与系统自愈能力验证

我们模拟了几种在生产环境中常见的异常场景：

1. Agent Pod意外崩溃 ：

   • 旧系统 ：调度器的心跳检测有延迟，可能仍在往已崩溃的实例分发任务，导致任务失败，需要依赖上层重试。
   • 新系统 ：K8s的 livenessProbe 会在几秒内检测到Pod失活，并立即重启Pod。OpenClaw会将该Pod标记为 NotReady ，后续任务不会调度到该Pod。正在该Pod上执行的任务，由于Pod重启会失败，但 AgentTask 的 status 会更新为 Failed ，并可通过配置重试策略（在 AgentTask 或Orchestrator层面）重新提交。 系统自愈过程完全自动化，无需人工干预。

2. 节点故障 ：

   • 旧系统 ：需要手动从调度器配置中移除故障节点，过程繁琐且容易出错。
   • 新系统 ：K8s Node Controller会自动将故障节点标记为 NotReady 。OpenClaw调度器在下次调度周期时，会将该节点上的Pod标记为失联，并自动在其他健康节点上重新创建这些Pod（ AgentPool 的副本数保证了这一点）。 整个过程对业务透明，仅导致短暂的任务中断（取决于Pod重启速度）。

3. 资源竞争与饿死 ：

   • 旧系统 ：低优先级任务可能被高优先级任务持续插队，导致长时间得不到执行。
   • 新系统 ：OpenClaw支持任务优先级，并且结合K8s的Pod优先级与抢占机制，可以确保高优先级任务优先获得资源。同时，通过合理的资源 requests 和 limits 设置，避免了单个Agent耗尽节点资源。

5.3 开发与运维成本评估

这部分是“降本”最直观的体现。

• 开发成本 ：

  • 前期 ：学习OpenClaw和深入理解K8s Operator模式需要约2-3人/日。编写CRD定义和改造Orchestrator接口约5人/日。总开发投入约1人周。
  • 对比 ：当初自研调度器从设计到稳定，前后迭代了3个版本，累计投入超过4人月。
  • 结论 ：迁移开发的短期投入，远低于长期维护和迭代一个复杂自研系统的成本。

• 运维成本 ：

  • 配置变更 ：以前调整调度策略或资源限制需要改代码、发版、重启服务。现在只需更新 AgentPool 或 AgentTask 的YAML文件，执行 kubectl apply ，OpenClaw Operator会自动完成滚动更新， 实现热配置，零停机 。
  • 问题排查 ：以前查调度问题需要看大量的自定义日志，现在通过Grafana看板、Pod事件和 AgentTask 状态字段，信息集中且标准，排查效率提升70%以上。
  • 知识传递 ：新成员入职，要理解700行错综复杂的调度代码是巨大的负担。现在，只需要理解“声明式API”和几个核心CRD的概念，学习曲线大大降低。

6. 避坑指南与最佳实践

6.1 部署与配置中的常见陷阱

1. CRD版本兼容性 ：OpenClaw仍处于快速发展期，CRD的 apiVersion （如 v1alpha1 , v1beta1 ）和字段可能在不同版本间有变动。在升级OpenClaw Operator版本前，务必仔细阅读Release Notes和升级指南，最好在测试集群先验证。 切勿直接在生产环境进行版本升级。

2. 资源定义（Requests/Limits）不准确 ：这是导致调度问题或节点不稳定的首要原因。如果Agent容器的 resources.limits 设置得远高于其实际需求，会导致节点可调度资源计算虚低，影响装箱效率。如果 requests 设置过低，在节点资源紧张时，该Pod可能被K8s Eviction（驱逐）。 建议通过监控历史数据，设置一个贴近实际使用量（如P95分位）的 requests ，并设置一个合理的 limits （例如 requests 的1.5-2倍）。

3. 忘记配置Pod Disruption Budget (PDB) ：在进行集群维护（如节点升级）时，K8s会主动驱逐Pod。如果没有为 AgentPool 对应的Deployment设置PDB，可能导致短时间内大量Agent实例同时被终止，服务可用性骤降。务必为重要的AgentPool创建PDB，例如 minAvailable: 50% ，确保任何时候至少有一半的实例可用。

4. 镜像拉取策略 ：默认的 imagePullPolicy 是 IfNotPresent 。如果你使用了类似 :latest 的标签并频繁更新镜像，可能会因为节点缓存旧镜像而导致部署的并非最新代码。在开发环境可以设置为 Always ，生产环境则应使用明确的语义化版本标签（如 v1.2.3 ），并设置为 IfNotPresent 以提升启动速度。

6.2 针对特定场景的调优策略

1. 延迟敏感型任务 ：对于需要极低延迟的Agent，可以采取以下组合策略：

   • 节点亲和性 ：在 AgentPool.template.spec 中设置 nodeSelector 或 nodeAffinity ，将其调度到具有低延迟网络或专用硬件的节点上。
   • Pod间反亲和性 ：避免同一类型的多个高负载Agent调度到同一节点，减少资源竞争。可以使用 podAntiAffinity 。

   affinity:
     podAntiAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 100
         podAffinityTerm:
           labelSelector:
             matchExpressions:
             - key: agent-pool
               operator: In
               values:
               - summarizer-pool
           topologyKey: kubernetes.io/hostname
   

   • 提高调度优先级 ：为对应的 AgentTask 设置更高的 priorityClassName 。

2. 批量计算型任务 ：对于跑批处理、不要求实时但需要大量计算的Agent。

   • 使用Spot实例/廉价节点 ：通过 nodeSelector 将其调度到成本更低的节点池。
   • 设置合理的Job超时与重试 ：在 AgentTask 中配置较长的 timeoutSeconds 和重试策略。甚至可以结合K8s Job来运行，但OpenClaw的 AgentTask 本身已具备类似Job的特性。

3. 处理“大胖子”Agent ：指内存或GPU需求特别大的Agent。

   • 独占节点 ：使用 tolerations 和 nodeSelector 将其调度到特定的大资源节点，并通过 podAntiAffinity 确保一个节点只运行一个此类Pod，避免资源碎片。
   • 使用扩展资源（Extended Resources） ：如果使用GPU，可以定义 nvidia.com/gpu 等扩展资源，并在 resources.limits 中申请，这样K8s调度器能更精确地进行GPU绑定。

6.3 监控告警关键指标推荐

仅仅收集指标不够，必须设置有效的告警。以下是我们针对OpenClaw调度体系设置的核心告警项：

1. 调度器健康度 ：

   • openclaw_operator_up == 0 ：Operator本身宕机，需立即处理。
   • rate(openclaw_scheduler_scheduling_errors_total[5m]) > 0 ：调度器持续出错，可能是配置问题或资源不足。

2. 任务积压 ：

   • openclaw_scheduler_pending_tasks > 100 ：待调度任务队列过长，说明Agent处理能力不足或调度受阻。应触发扩容或检查Agent健康状态。

3. AgentPool异常 ：

   • kube_deployment_status_replicas_unavailable{deployment=~"openclaw-agentpool-.*"} > 0 ：某个AgentPool有不可用的副本，持续超过5分钟。需检查Pod事件日志。
   • kube_pod_container_status_restarts_total{container=~".*agent.*"}[1h] > 10 ：某个Agent容器在1小时内重启次数过多，表明应用本身不稳定。

4. 资源瓶颈预警 ：

   • sum(kube_pod_container_resource_requests{resource="cpu"}) by (node) / sum(kube_node_status_capacity_cpu_cores) by (node) > 0.9 ：某个节点上已请求的CPU资源超过总容量的90%，即将无法调度新Pod。
   • avg(rate(container_cpu_usage_seconds_total{pod=~"openclaw-agentpool-.*"}[5m])) by (pod) * 100 / on(pod) kube_pod_container_resource_limits_cpu > 80 ：某个Agent Pod的CPU使用率持续超过其限制的80%，可能需要调整 limits 或优化Agent代码。

7. 总结与展望：不止于代码行数的减少

回顾这次迁移，代码从700行缩减到72行，只是一个最表层、最直观的结果。更深层的价值在于，我们将一个脆弱、高耦合、难以理解的“黑盒”调度系统，替换成了一个标准、透明、可观测、可扩展的云原生组件。团队的认知负荷降低了，因为大家只需要关注YAML配置和业务Agent的逻辑；系统的韧性增强了，因为背靠的是K8s和OpenClaw这两个经过大规模验证的系统；未来的扩展性也更好了，无论是增加新的Agent类型，还是实现更复杂的多集群调度，都有了清晰可行的路径。

OpenClaw并非银弹，它引入了对Kubernetes的强依赖，也带来了一定的复杂度。但对于任何已经在K8s上运行服务，并且需要管理多个AI Agent或任何形式的工作负载（Worker）的团队来说，它提供了一种极其优雅的解决方案。它迫使你以声明式的、资源化的视角去思考调度问题，这本身就是一种架构上的进步。

最后分享一个小心得：在定义 AgentPool 时， 一开始不要把副本数（ replicas ）设得太高 。特别是结合HPA使用后，完全可以从1-2个副本开始，让系统根据真实负载自动调整。这既能节约资源，也能让你更直观地观察到弹性伸缩是否按预期工作。毕竟，在云原生时代，最大的成本往往不是计算资源本身，而是那些“睡大觉”的闲置实例。