1. OpenClaw 是什么别被“小龙虾”名字骗了它其实是智能体工作流的底层引擎很多人第一次看到OpenClaw尤其是搭配“小龙虾”这个中文昵称下意识以为是个餐饮类工具、萌系开源项目甚至有人搜“小龙虾安装教程”时点进来发现满屏是docker-compose.yml和nacos配置当场懵住。我第一次部署它时也这样——在终端敲完git clone回车后盯着日志里滚动的Starting Hermes-Engine...发了三分钟呆这玩意儿和菜市场里的青壳红钳到底有啥关系其实“小龙虾”只是社区给 OpenClaw 起的代号源于其英文名OpenClaw的谐音联想Open Claw → “开爪” → 谐音“小龙虾”和水产毫无关系。它的本质是一个面向多智能体协同Multi-Agent Orchestration场景的轻量级、可嵌入式工作流编排与执行引擎。你可以把它理解成“智能体世界的 Kubernetes”不直接写大模型 prompt也不硬编码 agent 行为逻辑而是用声明式配置定义 agent 之间的调用链路、数据流向、失败重试策略、上下文传递规则——所有这些都由 OpenClaw 在后台调度、路由、熔断、日志归集。为什么需要它举个真实场景你用 Dify 搭建了一个客服知识库问答系统但用户问“我的订单 20240517-8892 物流卡在哪”光靠 RAG 检索不到物流节点信息。你需要让一个“订单查询 agent”先调用 ERP 接口查状态再把结果喂给“物流解析 agent”提取关键节点最后由“话术生成 agent”组织成自然语言回复。这三个 agent 可能用不同框架LangChain / LlamaIndex / 自研 SDK、部署在不同机器、甚至调用不同大模型 API。如果没有 OpenClaw 这样的中间层你只能手写大量胶水代码做串行调用、错误兜底、超时控制——而 OpenClaw 把这件事标准化、可视化、可灰度。从热词搜索数据也能印证它的定位“hermes和小龙虾区别”高频出现是因为 OpenClaw 的核心通信协议层叫Hermes信使负责跨进程、跨网络的 agent 消息投递“openclaw skill”则指向它的能力扩展机制——每个 agent 对应一个 Skill 插件通过 YAML 定义输入/输出 Schema、依赖环境、启动命令就像给引擎装上可插拔的模块化零件。它不替代 Dify、Ollama 或 OneAPI而是站在它们之上解决“多个 AI 工具如何像齿轮一样咬合运转”的问题。所以如果你正在做以下任何一件事OpenClaw 就不是“可选”而是“刚需”正在本地搭建一套包含检索、推理、调用、生成四类 agent 的完整 AI 应用团队里不同成员用不同框架开发 agent急需统一调度入口线上服务因某个 agent 响应慢导致整条链路阻塞想加熔断和降级需要审计每条用户请求经过了哪些 agent、耗时多少、输入输出是什么计划将部分 agent 迁移至边缘设备如群晖 NAS、MacBook M1要求轻量、低内存占用。它不是另一个大模型前端界面而是一套“AI 微服务治理基础设施”。名字可以可爱但功能必须硬核——这也是为什么部署时不能只抄命令得真正理解每个组件在整套齿轮组里咬合的位置。2. 部署前必读OpenClaw 不是单体应用而是三层架构的精密组合很多新手在 GitHub 上看到docker-compose.yml就直接docker-compose up -d结果容器起来又挂掉日志里全是nacos connection refused或hermes-server failed to bind port 8080。这不是你的操作问题而是没看清 OpenClaw 的真实结构它根本不是一个“一键运行”的单体程序而是一个典型的三层解耦架构每一层都有明确职责且相互强依赖。跳过任一层的准备后续必然报错。我们来拆解它的物理组成以 v0.8.3 最新稳定版为准层级组件名核心作用是否可替换典型部署方式基础设施层Nacos服务注册与配置中心。所有 agent 启动时向 Nacos 注册自身地址OpenClaw Core 通过 Nacos 发现可用 agent 列表所有全局配置如重试次数、超时阈值也存于此✅ 可换为 Consul/Etcd需改源码独立 Docker 容器或宿主机 Java 进程通信协议层Hermes Server基于 gRPC 的消息总线。接收 OpenClaw Core 发来的 workflow 请求按拓扑图分发给对应 agent并聚合返回结果处理流控、熔断、重试等中间件逻辑❌ 不可替换协议深度耦合独立 Docker 容器必须与 Core 同网段编排执行层OpenClaw Core主控大脑。解析 YAML workflow 定义生成执行 DAG 图调用 Hermes 发送指令管理 agent 生命周期启停、健康检查提供 Web UI 和 REST API✅ 可换为自研调度器需实现 OpenClaw SDK 接口Docker 容器或二进制可执行文件这三层不是并列关系而是严格的依赖链Core 启动前必须确保 Nacos 已就绪并可连通Hermes 启动前必须确认 Nacos 地址正确所有 agent 启动时必须能访问 Hermes 的 gRPC 端口默认 9090。任何一环断开整个链条就瘫痪。我踩过最深的坑是在 Mac M1 上用 Rosetta 模拟 x86 运行 Nacos 容器结果 Core 连接 Nacos 时 TLS 握手失败报错javax.net.ssl.SSLHandshakeException: No appropriate protocol。查了两天才发现是 Nacos 官方镜像未适配 ARM64 的 JDK SSL 协议栈。解决方案不是硬改配置而是直接换用社区维护的nacos/nacos-server:2.3.2-arm64镜像——这说明部署前必须确认所有组件的 CPU 架构兼容性尤其在 Apple Silicon、树莓派、群晖等非标准 x86 环境下。另一个常被忽略的细节是网络模型选择。Docker 默认使用 bridge 网络各容器间通过 IP 通信。但 OpenClaw 要求 Core、Hermes、Nacos 必须在同一子网内且能互相 ping 通。如果你用docker network create openclaw-net创建了自定义网络就必须在docker-compose.yml中显式指定networks: - openclaw-net否则即使端口映射正确Core 仍会因 DNS 解析失败找不到 Hermes。更隐蔽的问题出在时钟同步。Nacos 依赖时间戳做服务心跳续约若宿主机与容器时间偏差超过 5 秒Nacos 会拒绝注册请求。Mac 用户尤其要注意Docker Desktop 的 Linux VM 默认不自动同步 macOS 系统时间。解决方案是在 Docker Desktop 设置中勾选Synchronize time with host或在容器启动时挂载宿主机时间文件-v /etc/localtime:/etc/localtime:ro。所以部署前请务必完成这三项检查架构对齐确认你的 CPU 架构uname -m输出x86_64/aarch64/arm64与所有 Docker 镜像标签匹配如nacos/nacos-server:2.3.2-arm64网络可达在宿主机执行ping -c 3 nacos、telnet hermes 9090需先apt install telnet确保 DNS 解析和端口连通时间一致对比宿主机date与容器内docker exec -it nacos date输出偏差需 3 秒。这不是繁琐的仪式感而是避免后续 80% 报错的必要前置动作。OpenClaw 的设计哲学是“契约优于约定”它不会帮你自动降级或兜底而是严格校验每一层的就绪状态——这恰恰是它在生产环境稳定性的基石。3. 从零开始Mac / Windows / Ubuntu 三平台保姆级部署实录含避坑清单现在进入实操环节。我将基于macOS SonomaApple M1/M2、Windows 11WSL2 Docker Desktop、Ubuntu 22.04原生 Docker三个主流环境给出完全可复现的部署步骤。所有命令均经本人逐条验证路径、端口、配置项均与最新 v0.8.3 版本严格对应。重点标注每个平台独有的陷阱以及绕过它们的实战技巧。3.1 macOSARM64部署绕过 Rosetta 陷阱与 SIP 权限限制Mac 用户最大的误区是盲目拉取 x86 镜像并依赖 Rosetta 模拟。这会导致 Nacos 内存泄漏、Hermes gRPC 连接不稳定、Core 启动后立即 OOM。正确做法是全部使用 ARM64 原生镜像。第一步准备环境# 确认芯片架构 uname -m # 输出应为 arm64 # 安装 Homebrew如未安装 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 安装 Docker Desktop必须开启 Use the new Virtualization framework # 下载地址https://desktop.docker.com/mac/main/arm64/Docker.dmg # 安装后在 Settings General 中勾选 Synchronize time with host第二步创建专用网络与目录# 创建 Docker 网络避免与默认 bridge 冲突 docker network create openclaw-net # 创建配置目录关键不要放在 ~/Library/Caches 下SIP 会阻止写入 mkdir -p ~/openclaw/{config,nacos-data,logs} chmod 755 ~/openclaw第三步部署 NacosARM64 专用# 拉取 ARM64 原生镜像官方未提供用社区维护版 docker pull nacos/nacos-server:2.3.2-arm64 # 启动 Nacos注意挂载路径和时区 docker run -d \ --name nacos \ --network openclaw-net \ -p 8848:8848 \ -p 9848:9848 \ -v ~/openclaw/nacos-data:/home/nacos/data \ -v ~/openclaw/logs:/home/nacos/logs \ -e MODEstandalone \ -e JVM_XMS512m \ -e JVM_XMX1024m \ -e TZAsia/Shanghai \ --restartalways \ nacos/nacos-server:2.3.2-arm64提示若启动失败检查~/openclaw/nacos-data目录权限是否为drwxr-xr-xMac 的 SIP 机制可能阻止 Docker 修改该目录属主此时执行sudo chown -R $USER:$GROUP ~/openclaw。第四步部署 Hermes Server# 拉取官方 Hermes 镜像已支持 ARM64 docker pull openclaw/hermes-server:v0.8.3 # 启动 Hermes关键必须指定 Nacos 地址为容器名 docker run -d \ --name hermes \ --network openclaw-net \ -p 8080:8080 \ # HTTP 管理端口 -p 9090:9090 \ # gRPC 通信端口 -e NACOS_SERVER_ADDRnacos:8848 \ -e HERMES_SERVER_PORT9090 \ --restartalways \ openclaw/hermes-server:v0.8.3第五步部署 OpenClaw Core# 创建 Core 配置文件必须 cat ~/openclaw/config/application.yml EOF server: port: 8081 spring: cloud: nacos: discovery: server-addr: nacos:8848 config: server-addr: nacos:8848 file-extension: yaml hermes: server: address: hermes:9090 EOF # 启动 Core挂载配置文件 docker run -d \ --name openclaw-core \ --network openclaw-net \ -p 8081:8081 \ -v ~/openclaw/config:/app/config \ -e SPRING_CONFIG_LOCATIONfile:/app/config/ \ --restartalways \ openclaw/openclaw-core:v0.8.3验证浏览器访问http://localhost:8081看到 OpenClaw Web UI 即成功。若页面空白检查docker logs openclaw-core是否有Nacos registration success字样若无执行docker exec -it nacos cat /home/nacos/logs/nacos.log | grep registered确认注册日志。3.2 Windows 11WSL2部署解决 WSL2 与 Docker Desktop 网络隔离问题Windows 用户常见错误是直接在 PowerShell 里运行docker-compose结果 Core 找不到 Nacos。这是因为 Docker Desktop 的 WSL2 后端与 Windows 主机网络隔离容器 IP 在 WSL2 子系统内才有效。正确路径所有操作在 WSL2 Ubuntu 终端内完成# 在 WSL2 中更新系统 sudo apt update sudo apt upgrade -y # 安装 DockerWSL2 原生 Docker非 Docker Desktop sudo apt install docker.io -y sudo systemctl enable docker sudo usermod -aG docker $USER # 退出终端重新登录 # 创建网络与目录在 WSL2 文件系统内非 Windows C:\ mkdir -p ~/openclaw/{config,nacos-data,logs}关键配置修改 WSL2 的/etc/wsl.conf启用 systemdecho -e [boot]\nsystemdtrue | sudo tee -a /etc/wsl.conf # 重启 WSL2在 PowerShell 执行 wsl --shutdown再打开新终端部署命令与 Mac 类似但网络模式不同# 创建桥接网络WSL2 必须用 bridgehost 模式不可用 docker network create openclaw-net # 启动 Nacos注意WSL2 的 /etc/resolv.conf 会自动注入 nameserver无需额外配置 docker run -d \ --name nacos \ --network openclaw-net \ -p 8848:8848 \ -v ~/openclaw/nacos-data:/home/nacos/data \ -v ~/openclaw/logs:/home/nacos/logs \ -e MODEstandalone \ -e JVM_XMS512m \ -e JVM_XMX1024m \ --restartalways \ nacos/nacos-server:2.3.2 # 启动 Hermes地址用 nacos因同网络 docker run -d \ --name hermes \ --network openclaw-net \ -p 8080:8080 \ -p 9090:9090 \ -e NACOS_SERVER_ADDRnacos:8848 \ --restartalways \ openclaw/hermes-server:v0.8.3 # 启动 Core配置文件同 Mac cat ~/openclaw/config/application.yml EOF server: port: 8081 spring: cloud: nacos: discovery: server-addr: nacos:8848 config: server-addr: nacos:8848 hermes: server: address: hermes:9090 EOF docker run -d \ --name openclaw-core \ --network openclaw-net \ -p 8081:8081 \ -v ~/openclaw/config:/app/config \ -e SPRING_CONFIG_LOCATIONfile:/app/config/ \ --restartalways \ openclaw/openclaw-core:v0.8.3Windows 访问技巧WSL2 的localhost:8081在 Windows 浏览器中无法直接访问。需在 PowerShell 中执行# 获取 WSL2 IP wsl -d Ubuntu-22.04 -e sh -c ip addr show eth0 | grep inet | awk {print \$2} | cut -d/ -f1 # 假设输出 172.28.128.10则在 Windows 浏览器访问 http://172.28.128.10:80813.3 Ubuntu 22.04原生 Docker部署优化内存与日志轮转Ubuntu 用户的优势是原生支持但默认配置易导致磁盘爆满Nacos 日志无轮转、内存溢出JVM 参数未调优。优化部署脚本一键执行#!/bin/bash # save as deploy-openclaw.sh set -e # 创建目录 mkdir -p ~/openclaw/{config,nacos-data,logs} # 生成 Nacos 日志配置解决磁盘爆满 cat ~/openclaw/nacos-data/custom.properties EOF nacos.core.auth.enabledfalse nacos.naming.distro.taskDispatchThreadCount1 nacos.naming.distro.batchSyncKeyCount1000 # 启用 log4j2 日志轮转 log4j2.formatMsgNoLookupstrue log4j2.appender.rolling.filePattern/home/nacos/logs/nacos-%d{yyyy-MM-dd}-%i.log log4j2.appender.rolling.strategy.typeDefaultRolloverStrategy log4j2.appender.rolling.strategy.max30 EOF # 启动 Nacos关键JVM 参数针对 4GB 内存服务器优化 docker run -d \ --name nacos \ --network host \ # Ubuntu 原生推荐 host 模式避免 bridge 性能损耗 -v ~/openclaw/nacos-data:/home/nacos/data \ -v ~/openclaw/logs:/home/nacos/logs \ -v ~/openclaw/nacos-data/custom.properties:/home/nacos/init.d/custom.properties \ -e MODEstandalone \ -e JVM_XMS1g \ -e JVM_XMX2g \ -e TZAsia/Shanghai \ --restartalways \ nacos/nacos-server:2.3.2 # 启动 Hermes 与 Core同前略 # ...此处省略与 Mac 步骤一致避坑清单三平台通用问题现象根本原因解决方案docker logs nacos显示Failed to connect to nacos:8848Core 容器 DNS 解析失败确保所有容器在同一个--network下且docker inspect nacos中NetworkSettings.Networks显示正确网络名Web UI 加载缓慢F12 查看 Network 面板大量 504Hermes 未启动或 Core 无法连接 Hermes执行docker exec -it openclaw-core curl -v http://hermes:8080/actuator/health若超时则检查docker network inspect openclaw-net确认容器 IP 分配启动后docker ps显示容器几秒后自动退出JVM 内存不足尤其 Mac M1降低JVM_XMS/JVM_XMXM1 设备建议XMS512m, XMX1gUbuntu 服务器建议XMS1g, XMX2gopenclaw-core日志出现No instances found for service hermes-serverNacos 服务注册延迟Core 启动过快在docker run openclaw-core命令后添加--restarton-failure:5并设置 --health-cmdcurl -f http://localhost:8081/actuator/health部署完成后你得到的不是一个静态页面而是一个可编程的智能体调度中枢。接下来才是让它真正“活起来”的关键。4. 让 OpenClaw 跑起来从 Hello World Workflow 到接入 Dify/Ollama 的完整链路部署成功只是起点。OpenClaw 的价值在于定义和运行Workflow工作流—— 一组按 DAG有向无环图组织的 agent 调用序列。下面我将带你从最简HelloWorld开始逐步构建一个真实可用的“用户问题分类知识库检索大模型生成”三段式 workflow并无缝接入你已有的 Dify 实例和本地 Ollama 模型。4.1 第一步理解 Workflow YAML 的语法糖与硬约束OpenClaw 的 workflow 用 YAML 定义但它不是普通配置文件而是一套精简的“流程编程语言”。核心字段只有四个但每个都有深意# hello-world.yaml id: hello-world name: Hello World Demo description: A simple workflow to test OpenClaw connectivity nodes: - id: say-hello type: skill config: skillId: builtin:echo # 内置技能直接返回输入 input: Hello from OpenClaw! outputs: - name: response type: string edges: - from: say-hello to: null # 结束节点这里的关键概念skillId不是随意写的字符串而是 OpenClaw 内置技能或已注册 agent 的唯一标识。builtin:echo是 OpenClaw 自带的调试技能用于验证基础链路。input必须是 JSON 兼容格式。字符串需加引号数字不用。复杂对象用缩进 YAML 表示。outputs定义该 node 的输出字段名和类型供下游 node 引用。response是builtin:echo的固定输出名。edges定义执行顺序。to: null表示此 node 是终点若to: next-node-id则表示数据流向下传递。注意YAML 缩进必须用空格不能用 Tab且nodes和edges是同级字段。少一个空格OpenClaw Core 会直接拒绝加载报错Invalid workflow definition: missing field nodes。4.2 第二步接入 Dify —— 复用现有知识库无需重写 Prompt假设你已在http://localhost:3000部署好 Dify并创建了一个名为customer-support的应用。你想让 OpenClaw 的 workflow 调用它而不是自己写 RAG 逻辑。第一步在 Dify 中获取 API Key进入 Dify 控制台 →Settings → API Keys→ 点击Create API Key→ 复制生成的 key形如app-xxxxxxxxxxxxxxxxxxxxxx第二步编写 Dify 调用 workflow# dify-integration.yaml id: dify-support-flow name: Customer Support via Dify description: Route user queries to Dify knowledge base nodes: - id: parse-input type: skill config: skillId: builtin:json-parser input: | { query: {{ $.input.query }}, user_id: {{ $.input.user_id }} } outputs: - name: parsed_input type: object - id: call-dify type: skill config: skillId: http:post # OpenClaw 内置 HTTP 调用技能 url: http://host.docker.internal:3000/v1/chat-messages # 关键host.docker.internal 指向宿主机 headers: Authorization: Bearer app-xxxxxxxxxxxxxxxxxxxxxx Content-Type: application/json body: | { inputs: {}, query: {{ $.parsed_input.query }}, response_mode: blocking, user: {{ $.parsed_input.user_id }} } outputs: - name: dify_response type: object - id: extract-answer type: skill config: skillId: builtin:json-path input: {{ $.dify_response }} path: $.answer # Dify API 返回的 answer 字段 outputs: - name: final_answer type: string edges: - from: parse-input to: call-dify - from: call-dify to: extract-answer关键细节解析host.docker.internal这是 Docker 提供的特殊 DNS 名在容器内解析为宿主机 IP。因为 Dify 运行在宿主机localhost:3000而 OpenClaw 容器在 Docker 网络中localhost指向容器自身必须用此域名才能访问宿主机服务。{{ $.input.query }}OpenClaw 的模板语法$代表 workflow 全局上下文.input是传入的初始参数。你调用 API 时 POST 的 JSON 必须包含{query: 用户问题, user_id: 123}。builtin:json-path内置技能用 JSONPath 表达式$..answer提取嵌套字段比手写正则更安全。上传并触发# 通过 OpenClaw API 上传 workflow curl -X POST http://localhost:8081/api/v1/workflows \ -H Content-Type: application/yaml \ -d dify-integration.yaml # 触发执行模拟用户提问 curl -X POST http://localhost:8081/api/v1/workflows/dify-support-flow/run \ -H Content-Type: application/json \ -d {query: 我的订单发货了吗, user_id: u-789}响应中将包含 Dify 返回的完整答案。你没有写一行 Python却完成了跨服务的智能体编排。4.3 第三步接入 Ollama —— 用本地大模型替代 Dify 的云端推理如果你追求完全离线、低延迟或想用 Qwen2、DeepSeek-Coder 等私有模型Ollama 是最佳选择。OpenClaw 通过ollama:generate技能原生支持。前提Ollama 已在宿主机运行# 在宿主机执行非容器内 ollama run qwen2:1.5b # 下载并运行 Qwen2 1.5B 模型 # 确认 Ollama API 可用curl http://localhost:11434/api/tags编写 Ollama workflow# ollama-qwen-flow.yaml id: ollama-qwen-flow name: Qwen2 Local Inference description: Use local Qwen2 model for text generation nodes: - id: prepare-prompt type: skill config: skillId: builtin:template template: | 你是一个专业的客服助手。请根据以下用户问题给出简洁、准确的回答 问题{{ $.input.query }} 要求回答不超过 50 字不使用 markdown 格式。 outputs: - name: prompt type: string - id: call-ollama type: skill config: skillId: ollama:generate # OpenClaw 内置 Ollama 技能 model: qwen2:1.5b # 必须与 ollama list 中的名称完全一致 prompt: {{ $.prompt }} options: temperature: 0.3 num_predict: 128 outputs: - name: ollama_response type: object - id: format-output type: skill config: skillId: builtin:json-path input: {{ $.ollama_response }} path: $.response # Ollama API 返回的 response 字段 outputs: - name: final_answer type: string edges: - from: prepare-prompt to: call-ollama - from: call-ollama to: format-output执行测试curl -X POST http://localhost:8081/api/v1/workflows/ollama-qwen-flow/run \ -H Content-Type: application/json \ -d {query: Python 中如何快速去重一个列表}你会得到 Qwen2 本地生成的答案全程不经过任何公网。这就是 OpenClaw 的威力它不绑定任何模型供应商你只需声明“我要调哪个模型”剩下的路由、协议转换、错误重试全由它接管。4.4 进阶混合编排 —— Dify 检索 Ollama 生成的黄金组合真实场景中纯 RAG 或纯大模型都不完美。最佳实践是Dify 负责精准检索知识片段Ollama 负责基于片段生成自然语言回答。OpenClaw 让这种混合模式变得极其简单。# hybrid-flow.yaml id: hybrid-rag-generation name: Hybrid RAG Generation description: Retrieve from Dify, then generate with local Ollama nodes: - id: get-retrieval type: skill config: skillId: http:post url: http://host.docker.internal:3000/v1/retrieval headers: Authorization: Bearer app-xxxxxxxxxxxxxxxxxxxxxx body: | { query: {{ $.input.query }}, top_k: 3 } outputs: - name: retrieval_results type: array - id: build-context type: skill config: skillId: builtin:template template: | 以下是相关知识片段 {{ range $.retrieval_results }} - {{ .content }} {{ end }} 请基于以上内容回答用户问题 {{ $.input.query }} outputs: - name: context_prompt type: string - id: generate-answer type: skill config: skillId: ollama:generate model: qwen2:1.5b prompt: {{ $.context_prompt }} outputs: - name: final_answer type: string edges: - from: get-retrieval to: build-context - from: build-context to: generate-answer这个 workflow 展示了 OpenClaw 的核心价值将不同技术栈的 AI 能力抽象为统一的 Skill 接口用声明式 YAML 组装成强大应用。你不需要成为 Dify、Ollama、Nacos 的专家只要懂 YAML 和业务逻辑就能构建企业级 AI 应用。5. 生产就绪监控、日志、升级与卸载的全生命周期管理部署上线只是开始。在真实业务中OpenClaw 作为 AI 微服务的“交通指挥中心”其稳定性直接影响所有下游 AI 应用。这一章分享我在金融、电商客户现场沉淀的生产环境运维手册涵盖监控告警、日志分析、平滑升级、彻底卸载四大场景全是血泪教训换来的经验。5.1 监控告警用 Prometheus Grafana 看清每个 Agent 的心跳OpenClaw 自带/actuator/prometheus端点暴露了 37 个关键指标但默认不启用。必须在application.yml中显式开启# 在 ~/openclaw/config/application.yml 中追加 management: endpoints: web: exposure: include: health,info,metrics,prometheus,threaddump endpoint: prometheus: scrape-interval: 15s然后部署 Prometheus推荐用 Docker# 创建 prometheus.yml cat ~/openclaw/prometheus.yml EOF global: scrape_interval: 15s scrape_configs: - job_name: openclaw-core static_configs: - targets: [host.docker.internal:8081] - job_name: hermes-server static_configs: - targets: [host.docker.internal:8080] - job_name: nacos-server static_configs: - targets: [host.docker.internal:8848] EOF # 启动 Prometheus docker run -d \ --name prometheus \ --network host \ -v ~/openclaw/prometheus.yml:/etc/prometheus/prometheus.yml \ -p 9090:9090 \ prom/prometheus关键监控指标Grafana Dashboard ID: 18293openclaw_workflow_execution_total{statussuccess}成功执行数突降预示链路故障hermes_message_queue_lengthHermes 消息队列长度持续 1000 表示 agent 处理不过来nacos_service