先把话说在前面这篇文章不是项目宣传稿而是我过去两个多月把一个内部 AI 工具集合升级成一套真正能在生产环境里跑起来的“AI 智能任务调度平台”的完整记录。背景说起来很典型公司里散落着七八个 AI 辅助项目有的用 Python 脚本定时调大模型接口有的用开源 Agent 框架在本地跑私有模型互相之间没有统一入口、没有任务队列、没有监控业务方每次问“我这任务到底跑没跑、结果在哪”运维就得翻半天日志。后来我们决定用 EasyStack EKS 企业级云原生底座承载环境用 OpenClaw 做智能编排层把零散任务收敛成平台化的调度体系。今天这篇就把架构拆解、部署步骤、生产化改造和踩坑记录都摊开讲给正准备做同类平台的同学一份可以直接照着做的参考。这套组合解决的是一个很实际的问题模型本身不是瓶颈任务的组织和调度才是。EasyStack EKS 在我这儿扮演的是“企业级底座”的角色负责容器编排、资源隔离、GPU 调度、高可用这些基础设施能力OpenClaw 则是“任务大脑”负责理解任务、拆解步骤、调用工具和路由到大模型。两个东西组合在一起既能享受云原生的弹性又不用从零写一套 Agent 编排框架。适合的读者画像也很清楚手里已经有三五个 AI 应用想整合成统一平台的技术负责人或者你在用 Kubernetes 但不确定如何承载 AI Agent 工作负载这篇文章值得看完。1. 破题企业里的 AI 任务为什么缺一个“调度中枢”1.1 从“会调模型”到“会调度任务”中间隔着一条鸿沟大部分团队最早接触 AI 的方式都是写一个脚本在某个时间点或者某个事件触发后调用大模型的 API把返回结果写进数据库或者发到群里。这个模式做一两个独立工具没问题但数量上来以后问题就暴露了。我这边曾经同时维护着三套定时脚本一套每天早上抓取行业新闻并让模型生成简报一套处理销售团队提交的文本分类请求还有一套在夜间批量做历史工单的摘要归档。每套脚本都有自己的定时器、自己的重试逻辑、自己的日志格式。业务方提需求的时候说得很模糊比如“能不能把摘要结果也自动发到飞书”听起来只是加两行代码实际上要动脚本的触发链、权限和异常处理。最崩溃的是某个脚本夜里三点静默失败第二天早上业务方发现没有收到报告我们连“到底有没有跑过”都查不出来。这就是单点脚本和任务调度平台之间的差距。工业生产环境里需要一个统一的东西来承接“任务进来—排队—分配—执行—结果回写”这一整条链路。OpenClaw 恰好提供了任务拆解和技能调用的框架而 EasyStack EKS 则为整条链路提供了可靠运行的基础设施。两个配合才把“会调模型”升级成了“会调度任务”。1.2 EasyStack EKS 与 OpenClaw底座和大脑的分工很多人第一次听到 EasyStack EKS 和 OpenClaw 的组合都会困惑这两者是不是功能重叠。实际上分工非常清楚。EasyStack EKS 本质上是企业级 Kubernetes 发行版解决的是资源层的问题。任务调度平台里所有的组件包括 OpenClaw 控制器、执行 Worker、模型网关、向量数据库、监控系统最终都要跑在某个地方。EKS 能提供标准 K8s 的容器编排能力同时还带了企业级常用的东西多租户隔离、资源配额、GPU 调度、持久化存储、审计日志。这些在生产环境不是可选项是刚需。举个例子如果没有资源配额业务团队 A 提交的一个批量任务就可能把整个集群的 CPU 吃满业务团队 B 的在线服务跟着遭殃。EKS 底座可以把这种事从“事故”变成“配置项”。OpenClaw 解决的是任务本身怎么被智能处理的问题。它是一个开源的 AI 智能体编排框架核心能力包括接收任务描述、拆解执行步骤、调用一组预定义的技能Skill、把中间结果喂给大模型做推理最后汇总输出。它在架构里的角色更像“总控调度员”而各种 Skill 是它手上的工具大模型是它的大脑。你可以让 OpenClaw 同时对接本地模型和云端模型根据任务类型路由到合适的模型后端这就是多模型协作的基础。1.3 前置知识不是云原生专家也能跟得上这篇文章虽然涉及 K8s但我不会默认你已经精通整套容器生态。你只需要理解几个基础概念容器镜像是一个打包好的运行环境Docker 是构建和运行容器的工具Kubernetes 负责把容器调度到多台机器上并保证它们一直在跑。至于 EasyStack EKS你可以先把它理解成一个开箱即用的 K8s 环境该有的组件都有了不需要自己拼装。OpenClaw 部分也相对友好它本质上是 Node.js 写的服务配置项不多初始化以后把它当作一个可以对话、可以调技能的“AI 后端服务”就行。2. 整体架构拆解三个平面一条链路2.1 资源平面EasyStack EKS 底座上到底跑了什么架构拆解下来其实可以分成三个平面。第一个是资源平面也就是 EasyStack EKS 这一层。在它上面我并不只是跑一个 OpenClaw 实例而是跑了一整套支撑任务调度平台的组件组件作用部署方式OpenClaw Controller接收任务请求执行智能编排Deployment至少 2 副本Task Worker实际执行 Skill 脚本和模型调用Deployment支持 HPA 弹性扩缩容Redis任务队列、状态缓存、分布式锁StatefulSet对象存储存放模型生成的报告、归档数据使用 EKS 对接的存储后端Prometheus Grafana采集任务指标、展示监控面板Deployment DaemonSet 采集器选择 EasyStack EKS 而不是直接用裸的 K8s最重要的原因是企业级管控能力。多业务团队共用一个集群每个团队需要独立的命名空间和配额运维侧需要知道谁在什么时间提交了什么任务特殊时期还要限制某些命名空间的资源占用。这些在原生 K8s 上配置起来费时费力EKS 这类企业发行版通常已经把这些管控能力集成好了直接开配置项就能用。2.2 智能平面OpenClaw 在架构中的真实定位第二个平面是智能平面核心是 OpenClaw。我私下喜欢把它叫作“带手脚的模型路由器”因为它做的事情比纯模型调用要多一层。最简单的任务流程是这样的任务请求到达 OpenClaw 后它先分析用户给的描述比如“请把 /data/sales 目录下的 CSV 文件汇总成一份周报并按产品线拆分”。OpenClaw 会把这个大目标拆成几个子步骤列出目录下所有文件、读取每个文件的摘要、调用模型生成周报内容、按产品线拆分、写入输出目录。拆解之后它通过预先定义好的 Skill 来执行每个步骤。Skill 可以理解成一组打包好的工具里面有可执行的 Shell 命令、Python 脚本、HTTP 请求模板还有给模型看的“该在什么情况下用这个工具”的描述。这种设计最聪明的地方在于模型不需要直接操作文件系统或者调用数据库它只需要“看”到 Skill 的输入然后做出“用哪一个工具、传什么参数”的决策。这就把不可控的模型输出和真实系统操作之间加了一层缓冲区。我在实际使用中OpenClaw 的 Skill 体系确实降低了模型乱写命令带来的风险因为你只让它调用白名单里的工具而不是自由发挥。2.3 任务链路从触发到结果回写的全流程第三个平面是流程。这里我把一次完整任务的执行链路固定成了下面这个模板所有任务类型都走这条路触发源产生任务可以是定时 Cron、外部 Webhook、人工在聊天工具里发指令也可以由另一个任务链路上游产生。任务进入 Redis 队列带上任务 ID、类型、优先级、输入参数。OpenClaw Controller 消费队列解析任务描述进行意图识别。根据任务类型选择模型后端简单的文本分类走本地 qwen2.5-3b复杂的多轮推理走云端大模型。规划执行步骤Controller 把任务拆成多个 Skill 调用。Worker 执行 Skill必要时调用外部系统数据库查询、HTTP API、文件读写。中间结果回传给模型做推理生成最终输出。结果校验通过后写入对象存储并更新 Redis 中的任务状态。发通知给发起人成功发摘要失败发错误信息和重试建议。这套链路看起来复杂但好处是每一步都是可观测、可重试、可审计的。生产环境里没有“不确定跑没跑”这种状态。2.4 为什么不直接“Shell 脚本 crontab”硬扛我确实见过团队用最粗暴的方式硬扛一台 4 核 8G 的服务器上面堆了二十几个 Cron 定时任务每个任务调一次模型 API结果写进一个 shared 目录。痛点非常明显某一个任务把 Python 环境搞坏了其他任务全受影响内存不够的时候整个机器的进程都被杀掉没有并发限制两个任务同时调 API 导致限流。最麻烦的是想扩容只能纵向升级服务器成本高还不见得有效。放到 EasyStack EKS 上以后这些问题被一层一层拆开处理了容器隔离让每个任务有自己的运行环境一个脚本坏了不会污染其他任务K8s 调度让任务分布到多台节点天然就是横向扩容的Redis 队列加 Worker 并发上限解决了任务之间互相争抢资源的问题。用一个容器平台来承载 AI 任务本质上跟用容器承载 Web 服务是一样的逻辑只是很多人一开始没转过这个弯。3. 从零到一OpenClaw 部署实操纪实3.1 环境准备先让 WSL2、Node.js、Ollama 三兄弟就位严格来说 OpenClaw 不是一个“一键安装完事”的工具它需要一系列前置环境。我在 Windows 开发机上先搭好了本地方案然后再容器化搬到 EKS这样调试起来方便得多。第一步把 Windows 的 WSL2 环境理顺。OpenClaw 在 Windows 上运行时很多依赖命令执行的能力需要 WSL 的 Linux 环境支撑。这里有个最容易踩的坑安装好了 WSL 但系统里可能开了旧版 WSL1而你完全没意识到。检查方式是在 PowerShell 里执行wsl --status如果输出的版本信息不是 WSL2或者提示内核版本过旧需要执行更新wsl --update wsl --set-default-version 2我最初遇到的情况就是 OpenClaw 初始化时直接报“无法安全验证 WSL2 环境”搞得一头雾水。后来用wsl --status一看才发现默认版本还停留在 WSL1很多依赖系统调用的技能都跑不动。升级到 WSL2 以后问题迎刃而解。这一步的经验是不要在初始化失败时急着去改 OpenClaw 的配置先确认底层环境是正常的。第二步安装 Node.js。OpenClaw 是 Node.js 生态的项目我建议直接用 nvm 安装 LTS 版本目前我这边用的是 Node 20。为什么强调用 LTS因为生产环境你不想被 Node 大版本升级带来的破坏性变更折磨。装好以后用node -v确认。第三步装 Ollama 并拉取本地模型。Ollama 是本地运行大模型的工具我在本机安装后拉取了一个 Qwen2.5 3B 模型这个尺寸在 CPU 上也能跑用来做文本分类、摘要生成、意图识别这类轻量任务非常合适ollama pull qwen2.5:3b拉取完成后可以先用ollama run qwen2.5:3b随便聊两句确认模型能正常响应。这一步的意义是把“模型问题”和“编排框架问题”分开排查后面 OpenClaw 接不上模型时至少能确定模型服务本身没毛病。3.2 三步完成 OpenClaw 初始化与环境验证环境就绪后OpenClaw 的部署流程反而很快。这里记录的是我验证过的一套通用做法不同版本细节可能有差异但整体思路一致。第一步全局安装 CLI 工具并把项目初始化到一个空目录npm install -g openclaw openclaw init ai-task-hub cd ai-task-hub第二步修改配置文件主要是模型后端。OpenClaw 支持 OpenAPI 兼容接口Ollama 启动后默认监听本机 11434 端口所以模型部分的配置大概长这样models: local: provider: ollama base_url: http://localhost:11434 model: qwen2.5:3b context_size: 4096第三步启动并验证健康检查接口。启动后我用 curl 打了一次健康检查端口确认服务是真的起来了curl http://localhost:3000/health返回一个 JSON 格式的 OK 状态后我就开始尝试在 OpenClaw 里直接发一个最简单的任务指令比如“请读取当前目录下的 README 并总结三句话”。这一步是为了验证“模型调用 Skill 执行”的完整链路是否打通而不是只验证模型能聊天。3.3 接入 qwen2.5-3b给 OpenClaw 换一个本地大脑把 qwen2.5-3b 接到 OpenClaw 这件事实操比我预期顺。Ollama 本身对 OpenAI 兼容接口的支持比较完善所以 OpenClaw 不需要什么魔改只要把模型后端指向 Ollama 的地址就行。这里有一个非常关键的细节如果 OpenClaw 不是和 Ollama 跑在同一台机器的同一个环境里千万不要用localhost去指。比如 OpenClaw 跑在 Docker 容器里Ollama 跑在宿主机上那容器里的localhost指向的是容器自己连不上 Ollama。在 Docker 环境的正确做法是使用宿主机可访问的地址比如http://host.docker.internal:11434或具体的局域网地址。这个坑让我折腾了整整一个下午都是因为没分清不同环境里localhost的语义。另外3B 模型的能力边界要心里有数。做文本分类、信息抽取、指令理解这类“不复杂但需要快”的任务很够用但如果你让它做复杂的多步推理或者让它生成超长内容3B 模型要么逻辑混乱要么在上下文窗口限制处被截断。所以我在架构里定了一条简单规则简单任务走本地小模型复杂推理走云端大模型。OpenClaw 支持配置多个模型后端执行任务时按类型路由这就把成本和质量平衡住了。3.4 编写第一个 Skill把日报汇总任务落地Skill 是 OpenClaw 里让我感觉最值回票价的部分。它本质上是一个带描述的工具包包含工具本身和模型应该什么时候用它的说明。我拿第一个真正上线的任务举例把销售团队每天提交的 CSV 日报自动汇总成 Markdown 周报。这个 Skill 定义了三件事一是工具入口一个 Python 脚本负责读取公司共享目录下最近的 5 个 CSV 文件二是调用参数包括文件路径前缀、日期范围、按产品线拆分的开关三是模型使用说明告诉 OpenClaw“当用户要求汇总日报或生成周报时应该调用这个工具并把 CSV 的列名表作为上下文传给模型”。实际效果是我现在只需要在 OpenClaw 里说一句“生成销售周报”它就会自动执行拉取文件、分析表格结构、调用模型生成 Markdown、按产品线拆分、写入对象存储然后推送通知。整个过程中我需要做的只是把 Skill 文件放到指定目录然后重启服务让它加载。这个模式一旦跑通业务方提需求的速度跟不上我加 Skill 的速度。4. 从开发机到生产环境容器化与 EKS 部署实录4.1 把 OpenClaw 装进 Docker 镜像不只是做个镜像那么简单开发机上跑通以后下一步是把 OpenClaw 容器化然后部署到 EasyStack EKS 上。这个环节最考验细节因为开发环境和容器环境的差异会引出一堆幺蛾子。Dockerfile 我写得很克制只保留运行所需的最小集。基础镜像用 Node 20 的 slim 版本安装 OpenClaw 后复制 Skill 目录最后用非 root 用户启动服务。这里特别强调两点第一.env 文件绝对不要打进镜像密钥这类东西在 K8s 里走 Secret 注入第二Skill 目录里如果有依赖 Python 包的部分需要额外处理因为 slim 镜像里默认没有 Python 环境。我一开始没注意结果容器跑起来Skill 报“找不到 python3”排查半天才发现是基础镜像的问题。FROM node:20-slim WORKDIR /app RUN useradd -m openclaw COPY . . RUN npm install -g openclaw openclaw init --no-interactive USER openclaw EXPOSE 3000 HEALTHCHECK --interval30s --timeout5s --retries3 \ CMD curl -f http://localhost:3000/health || exit 1 CMD [openclaw, start]这里有个取舍把 Skill 直接 COPY 进镜像会带来一个维护问题每次改 Skill 都要重新构建镜像。我的做法是分两类处理通用的静态技能打进镜像跟业务强相关的技能放到持久化目录挂载进来。这样改业务脚本不需要走镜像构建流程发布更灵活。4.2 在 EKS 上交付Deployment、Service、ConfigMap 的搭配用法容器镜像推送到镜像仓库以后EKS 上的部署就按 K8s 的标准套路来。我用了 ConfigMap 存放非敏感的配置比如日志级别、任务超时时间用 Secret 存放模型服务的 API Key 和数据库密码。Deployment 的配置有几个关键点。副本数我设了 2OpenClaw Controller 不是完全无状态的它内部有任务状态缓存所以多副本时必须保证只有一个是“主控制器”我用 Redis 分布式锁做 leader election避免两个副本同时消费同一个任务导致重复执行。这是生产环境一个特别容易被忽略的问题你以为多副本就是高可用结果任务被重复执行了两遍下游系统收到双份数据。apiVersion: apps/v1 kind: Deployment metadata: name: openclaw-controller namespace: ai-platform spec: replicas: 2 selector: matchLabels: app: openclaw-controller template: metadata: labels: app: openclaw-controller spec: containers: - name: controller image: registry.internal/ai-platform/openclaw:2.1.0 ports: - containerPort: 3000 envFrom: - configMapRef: name: openclaw-config env: - name: REDIS_LOCK_KEY value: openclaw:leader resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 4GiDeployment 外面再包一层 Service稳定暴露内部访问地址如果外部系统需要回调 OpenClaw 的 Webhook 接口再加 Ingress。这一步就是标准的云原生操作EKS 上这些资源也都是原生支持的不需要做任何适配。4.3 有状态问题怎么处理任务状态、模型缓存和数据持久化任务调度平台天然是有状态的这一点在容器化时最容易栽跟头。容器是“用完即走”的思维但目标任务不能接受“容器重启任务状态清零”。我在设计里做了三个明确的分工。任务队列和任务状态放在 Redis这是系统的“短期记忆”最终产物报告、摘要、知识库片段放到对象存储这是“长期记忆”OpenClaw 的 Skill 脚本依赖的临时文件放在 PVC 里这是“工作台”。三块数据放在不同的存储后端生命周期不同备份策略也不同而不是一刀切全挂到一个存储卷上。模型缓存是另一个很多人忽略的点。OpenClaw 加载模型的时候会有一些缓存文件如果用同一个本地模型跑大量任务缓存能显著降低推理延迟。但因为节点可能会被重新调度缓存放在容器本地磁盘太脆弱。我的做法是把缓存目录挂到 PVCK8s 调度时通过 volumeAffinity 尽量让任务 Worker 落到固定缓存节点的策略效果还挺明显。4.4 GPU 与资源配额防止一个任务吃掉整个集群本地小模型在 CPU 上跑没问题但如果有团队想部署 13B、70B 级别的模型GPU 就是绕不开的话题。EasyStack EKS 的 GPU 调度遵循 K8s 的标准方式在 Pod 里声明 GPU 资源的请求量resources: limits: nvidia.com/gpu: 1但我更想提醒的是配额这件事。EKS 上多团队共用集群如果不在命名空间级别设置 ResourceQuota一个团队提交的大型模型推理任务就可能把 GPU 节点占满其他团队的任务原地排队。我上线第二周就吃过这个亏。后来的方案是每个业务团队独立的命名空间配额写清楚apiVersion: v1 kind: ResourceQuota metadata: name: quota-sales-team namespace: sales-team spec: hard: requests.cpu: 16 requests.memory: 64Gi limits.cpu: 32 limits.memory: 128Gi同时配置 LimitRange限制单个 Pod 的最大资源申请量防止有人申请 64 核 256G 的“巨无霸 Pod”把调度器都搞懵。5. 生产级任务调度的几个关键设计5.1 任务模型别把所有任务都当成定时任务做调度平台最忌讳的就是一上来就堆 Cron 表达式。我梳理了实际业务场景发现任务触发方式至少有三种定时触发、事件触发、人工触发。典型场景分别是夜间批量摘要、Webhook 接收外部系统消息、业务人员在聊天工具里向 AI 助手提需求。这里用一张表来梳理任务类型设计任务类型触发方式调度策略典型用例定时批处理Cron 表达式固定时间窗口错过则补跑夜间舆情摘要生成事件驱动Webhook / MQ 消息实时分发支持重试工单自动分类入库人工交互聊天 / API 调用异步执行结果回调让 AI 生成数据分析报告依赖流水线上一个任务成功后触发条件判断后入队数据抓取完成后自动生成简报这个表格看起来简单但真正落地的时候每类任务的优先级、超时策略、失败处理都不一样。人工交互类任务通常要求响应快定时批处理则更看重成功率事件驱动最怕重复消息。把这些差异体现在任务模型里调度平台才真正算“生产可用”。5.2 优先级与并发控制AI 任务也会抢资源AI 任务有个特点它不是纯计算密集也不是纯 I/O 密集而是模型调用和工具执行交替出现。这种情况下如果不做并发控制大批量任务同时提交模型服务会被打爆任务反而全部变慢。我在 Worker 层加了一个简单的并发上限机制核心思路是在 Redis 里维护一个“正在执行的任务数”计数每次消费任务前先检查是否达到上限否则把任务放回队列等待。这个做法比直接依赖 K8s HPA 更稳因为 HPA 是面向 Pod 数量做弹性但单个 Pod 内部如果不控制并发多开 Pod 只会增加资源竞争。HPA 还是得配我设置了一个不激进但有效的策略当任务队列积压超过 50 个且持续 10 分钟自动把 Worker 的副本数从 2 扩到 5。这一步让平台在偶发的高峰期能自己兜住不需要半夜爬起来手动扩容。5.3 多 AI 协作的实际实验主 Agent 管拆解子 Agent 管执行OpenClaw 最吸引我的一点是它支持多 Agent 协作的场景。我做了个实验一个主 Agent 接收任务后把任务拆分成多个子任务分别派发给不同子 Agent子 Agent 各自使用不同的 Skill 和模型后端最后把结果汇总给主 Agent。实验里踩到两个明显的坑。第一个是上下文串扰。多个子 Agent 共享了一个上下文池结果 A 任务的历史消息被 B 任务看到了输出里出现了完全无关的内容。解决方案很直接每个子 Agent 必须使用独立的上下文实例任务之间通过结构化输入输出传递数据而不是共享对话历史。第二个坑是 Token 浪费。主 Agent 把整段原始资料发给每一个子 Agent子 Agent 各自处理后又把完整结果传给主 Agent中间传输的内容大量重复。修复办法是在 Skill 层增加“摘要门”子 Agent 回传结果前先做一次压缩只返回关键字段。实验做完我对多 Agent 协作的态度变得比较务实可以用但必须严格控制任务边界不要让 Agent 之间“自由聊天”否则就是一场灾难。5.4 可观测性没有日志和指标谈不上生产级如果一个平台跑得好好的直到出了问题你才发现自己什么都看不到那它就不是生产级。我在 EKS 上部署 Prometheus Grafana给 OpenClaw 暴露了一套结构化指标。我采集的指标里最有价值的有四个任务成功率、任务平均耗时、队列积压数量、模型调用延迟。前两个反映整体健康度第三个反映调度是否卡住第四个直接暴露模型服务的问题。告警规则也简单有效# 任务成功率低于90%持续5分钟 (sum(rate(task_success_total[5m])) / sum(rate(task_total[5m]))) 0.9 # 队列积压超过100持续10分钟 openclaw_task_queue_depth 100日志方面所有组件统一输出 JSON 格式日志每个任务带一个 traceId 贯穿始终。排查问题的时候一条 traceId 能拉出触发源到模型调用的完整链路。这套体系上线以后我们再也没出现过“半夜任务失败却要等业务方发现”的情况。6. 现场排障实录那些让我熬夜的问题6.1 “OpenClaw 无法安全验证 WSL2 环境”版本不对一切白搭这个问题是我在安装初期遇到的OpenClaw 在 Windows 上初始化时提示无法安全验证 WSL2 环境。排查路径其实不复杂但第一次遇到确实会懵。记住一个原则优先检查 WSL 本身的健康状态而不是怀疑 OpenClaw。在 PowerShell 里执行wsl --status它会告诉你 WSL 的版本、内核状态、默认版本。如果发现默认版本不是 2执行wsl --set-default-version 2 wsl --update然后wsl -l -v确认所有发行版的 VERSION 列显示为 2。这个问题根因大多是系统里同时存在 WSL1 和 WSL2 的运行环境OpenClaw 检测到环境不统一就直接拒绝工作。按这个流程处理后重新初始化 OpenClaw 就正常了。6.2 Node.js 版本引发的启动失败OpenClaw 安装后启动直接报错错误信息里带ERR_REQUIRE_ESM这类字眼。这类问题的原因多半是 Node.js 版本太老有些新语法和包格式不被支持。我的处理方式是切到 Node 20 LTS清理 npm 缓存后重新安装。这里分享一个习惯任何 Node.js 项目部署到生产环境前把node -v固定写入 README最好是直接用.nvmrc文件锁定版本不然团队里每个人的开发版本都不一样迟早踩坑。6.3 Ollama 连接闪断localhost 指向了谁部署到容器里之后OpenClaw 经常报连不上 Ollama错误是ECONNREFUSED。第一反应以为是 Ollama 挂了结果它好端端跑在宿主机上。问题出在容器网络容器内的localhost是容器自己不是宿主机。改成host.docker.internal:11434就通了。如果 OpenClaw 和 Ollama 都部署在 K8s 集群里则建议用 Service 域名相互访问比如http://ollama-service:11434这样稳定性更好。这个小知识点我打赌能帮不少人少折腾两个小时。6.4 时间漂移和处理不了的长尾问题容器默认使用 UTC 时区任务日志时间和业务方的北京时间差了 8 个小时排查问题时总觉得时间线对不上。解决方式是挂载/etc/localtime并在容器启动命令里设置TZAsia/Shanghai。另一个长尾问题是日志量大的时候容器内日志文件无限增长最后撑爆磁盘。后来给所有 Worker 加了 logrotate 配置每天轮转日志并保留最近 7 天。问题现象根因快速解决WSL2 验证失败OpenClaw 拒绝启动默认 WSL1wsl --set-default-version 2Node 报 ESM 错误启动即崩Node 版本过旧nvm 切到 Node 20 LTSOllama 连接拒绝ECONNREFUSEDlocalhost 语义错误容器环境换host.docker.internal日志时间错乱排查困难容器默认 UTC挂载 localtime 并设 TZ任务重复执行下游收到双份多副本同时消费用 Redis 锁选主控制器7. 写在最后的一点真实体会这套平台从立项到第一批任务稳定跑了三周最大的体感是技术选型本身并不神奇EasyStack EKS 和 OpenClaw 都是成熟的东西真正难的是把“环境、任务、模型、工具”这四样东西的边界划清楚。我一开始犯的错误就是想得太复杂总希望 OpenClaw 能一把梭把所有任务都接管结果模型乱叫工具、任务互相干扰。后来把任务拆分、Skill 白名单、队列和资源配额这些基础功夫做扎实平台反而越来越稳。最后再分享一个很朴素的经验不管你的任务调度平台做得多智能永远给业务方留一个“人工兜底”的入口。AI 编排再怎么顺畅也挡不住某一天模型服务抽风或者上游数据格式变更。我们平台里每条任务链路都配置了失败后的通知业务方收到失败消息后可以直接转给人工处理而不是对着一个静默失败的黑盒干着急。生产级 AI 平台拼到最后拼的从来都是可靠性和可解释性。这两点做到位前面所有折腾就都值了。