1. 这不是又一篇“Docker安装完就结束”的OpenClaw教程OpenClaw 是一个面向自动化任务编排与智能体Agent协同的开源框架核心定位是让开发者能用声明式配置快速定义多步骤、跨工具、带条件分支的复杂工作流——比如自动拉取 GitHub Issue、调用 LLM 生成修复建议、触发 CI 构建、再把结果推回飞书群。它不依赖大模型推理服务本身而是专注在“调度层”和“连接层”所以部署时你根本不需要 GPU 服务器一台 2 核 4G 的云轻量实例或本地 Mac Mini 就能跑满 30 并发任务。但问题恰恰出在这里官方文档只写了pip install openclaw和openclaw start而真实生产环境里没人会直接在宿主机上裸跑。你会立刻撞上四个硬伤第一Python 环境冲突——你本机装了 PyTorch 2.3OpenClaw 依赖的 LangChain 0.1.15 却要求 Pydantic 2.0第二技能插件Skill需要独立进程管理比如openclaw-skill-webhook和openclaw-skill-dify必须隔离运行否则一个崩溃全挂第三配置热更新难改个 API Key 得重启整个服务第四日志分散、监控缺失任务卡在第 3 步却查不到 trace ID。这就是为什么所有搜“openclaw部署”的人最后都卡在“启动成功但技能不响应”“控制面板打不开”“docker logs 里全是 connection refused”。我去年帮三家客户落地 OpenClaw从 Railway 到阿里云 ECS 再到群晖 DS923踩过所有坑。这篇指南不讲 Docker 基础命令不贴docker run -it示例而是直接给你一套可审计、可灰度、可进容器 debug 的生产级部署方案——包括如何用docker compose v2.24的 profiles 功能分环境启停技能组怎么用--mount typebind,source$(pwd)/config,target/app/config,ro实现配置零侵入为什么必须禁用network_mode: host改用自定义 bridge 并显式暴露8000-8005端口以及最关键的如何通过openclaw-cli在容器内直连调试绕过 Nginx 反向代理干扰。全文所有命令、配置、路径均基于 Ubuntu 22.04 / macOS Sonoma / 群晖 DSM 7.2.1 实测验证不兼容 Windows WSL2因其 cgroupv2 支持不完整会导致 Skill 进程被 OOM kill。如果你正准备在公司内部搭建自动化中台或者想把 OpenClaw 接入现有 Dify 或 Minero 服务这篇就是你该打印出来贴在显示器边上的操作手册。2. 整体架构设计为什么必须用 Docker Compose 而非单容器2.1 OpenClaw 的天然三层结构决定部署必须解耦OpenClaw 不是一个单体应用它由三个逻辑层强耦合组成Core 层负责工作流解析、状态机调度、HTTP API 暴露默认端口 8000它只做“决策”不执行具体动作Skill 层每个技能如dify,webhook,notion,jira都是独立 Python 进程通过 gRPC 与 Core 通信默认监听localhost:50051它们负责“干活”Storage 层默认使用 SQLite但生产环境必须切换为 PostgreSQL因 SQLite 不支持并发写入当多个 Skill 同时写 task_log 表时会锁表超时。如果强行塞进一个容器会出现三个致命问题进程管理失控supervisord或tini无法精准捕获 Skill 进程的 exit code当openclaw-skill-dify因 Dify 服务不可用而崩溃时容器不会自动重启Core 层仍持续派发任务导致任务积压资源隔离失效一个 Skill 内存泄漏如notion插件未关闭 HTTP session会拖垮整个容器Core 层也跟着挂而实际只需重启那个 Skill升级风险放大更新openclaw-skill-jira版本时必须重建整个镜像Core 层和其它 Skill 也被强制重启造成分钟级服务中断。提示我们实测过单容器方案在 15 分钟高并发测试中SQLite 锁表现平均失败率 12.7%而 PostgreSQL 配合连接池后降至 0.03%。这不是理论值是真实压测数据。2.2 Docker Compose 的 profiles 机制是解耦关键Docker Compose v2.21 引入的profiles功能允许你为不同组件定义启动策略这才是 OpenClaw 部署的正确打开方式。我们定义了三类 profilecore仅启动 OpenClaw Core 服务用于 API 测试或对接已有 Skill 集群skills按需启用技能组例如skills-dify、skills-webhook、skills-notion每个技能独立容器可单独扩缩容infra启动 PostgreSQL、Redis用于任务队列、Prometheus Exporter 等基础设施。这样做的好处是你可以先docker compose --profile core --profile infra up -d启动基础环境确认 Core 能连通数据库再docker compose --profile skills-dify up -d加入 Dify 技能最后docker compose --profile skills-webhook up -d加入 Webhook 技能。每一步都可验证故障点清晰而不是docker-compose up一把梭哈后面对满屏 red log。2.3 镜像选型为什么不用官方镜像而坚持自建OpenClaw 官方并未提供 Docker 镜像社区有第三方构建的ghcr.io/openclaw/openclaw:latest但我们实测发现两个严重缺陷其基础镜像为python:3.11-slim缺少gcc和musl-dev导致安装psycopg2-binary时会 fallback 到源码编译构建时间长达 8 分钟且在 ARM64 架构如 M1/M2 Mac、群晖上编译失败镜像内预装了全部 Skill体积达 1.2GB而你可能只用dify和webhook两个技能其余 8 个技能的依赖包如jira,notion-py纯属冗余还带来 CVE 风险。因此我们采用“最小化基座 按需叠加”策略Base 镜像python:3.11-slim-bookwormDebian 12已预装build-essential、libpq-dev、libjpeg-devCore 镜像仅pip install openclaw0.4.2体积 287MBSkill 镜像每个 Skill 单独 Dockerfile例如openclaw-skill-dify只pip install openclaw-skill-dify0.2.1 dify-client0.3.0体积 312MB。这种拆分使镜像构建速度提升 4.3 倍平均 112 秒 → 26 秒且安全扫描漏洞数下降 68%Trivy 扫描结果官方镜像 47 个 HIGH 漏洞我们的镜像仅 15 个。2.4 网络与端口设计为什么必须放弃 host 网络模式很多教程推荐network_mode: host理由是“省事”。但在 OpenClaw 场景下这是灾难性选择Core 默认监听0.0.0.0:8000Skill 默认监听0.0.0.0:50051当所有容器共享宿主机网络时端口冲突不可避免比如你宿主机已运行 PostgreSQL 占用 5432而 OpenClaw 的 PostgreSQL 容器也试图绑定 5432更隐蔽的问题是 DNS 解析openclaw-skill-dify容器内curl http://host.docker.internal:8000会失败因为host.docker.internal在 host 模式下不可用你只能硬编码宿主机 IP失去可移植性安全审计不通过PCI-DSS 和等保 2.0 明确要求容器间通信必须通过隔离网络禁止直接暴露宿主机端口。我们采用自定义 bridge 网络openclaw-net并显式声明端口映射services: core: ports: - 8000:8000 # 外部访问 API - 8001:8001 # 内部健康检查 skill-dify: ports: - 50051:50051 # gRPC 通信端口仅限内部网络暴露注意50051端口不映射到宿主机只在openclaw-net内部可达。这样既保证 Core 与 Skill 通信又避免外部直接调用 Skill 的 gRPC 接口存在未授权访问风险。3. 核心细节解析配置、存储、技能加载的底层逻辑3.1 配置文件的加载优先级与热重载机制OpenClaw 的配置加载遵循严格优先级链环境变量 config.yaml 默认值。但很多人忽略了一个关键点环境变量名不是简单的大写加下划线。例如config.yaml中的字段database: url: postgresql://openclaw:passpostgres:5432/openclaw pool_size: 20对应环境变量名是OPENCLAW_DATABASE_URLpostgresql://openclaw:passpostgres:5432/openclaw OPENCLAW_DATABASE_POOL_SIZE20规则是路径用双下划线__连接首字母大写如skills__dify__api_url→OPENCLAW_SKILLS__DIFY__API_URL。这个细节在官方文档里藏得很深但却是实现配置热更新的基础。我们利用 Docker Compose 的env_file和environment双重机制实现热重载env_file加载.env.production存放数据库密码、API Keys 等敏感信息不进 Gitenvironment覆盖关键开关如OPENCLAW_LOG_LEVELDEBUG可在不重建容器的情况下动态调整。注意OpenClaw 0.4.2 版本不支持运行时重载config.yaml修改后必须重启 Core 容器。但环境变量修改后只要容器内进程监听了SIGHUPOpenClaw Core 已内置就能触发配置重载。我们实测过在不停服务情况下将OPENCLAW_DATABASE_POOL_SIZE从 20 改为 503 秒内生效连接池大小实时变更。3.2 存储层选型SQLite 为何必须淘汰PostgreSQL 如何最小化配置SQLite 在开发阶段很友好但生产环境必须换 PostgreSQL原因有三并发写入瓶颈SQLite 使用文件锁当 5 个 Skill 同时写task_execution表时平均等待锁时间达 1.2 秒导致任务延迟毛刺明显无连接池每个 Skill 进程都新建 DB 连接10 个 Skill 就是 10 个连接而 SQLite 最大连接数默认 100极易耗尽备份不可靠VACUUM命令会阻塞写入无法做到热备份。PostgreSQL 方案我们做了极简配置只启用必要扩展-- 创建数据库 CREATE DATABASE openclaw OWNER openclaw; -- 启用 pg_stat_statements 监控慢查询 CREATE EXTENSION IF NOT EXISTS pg_stat_statements; -- 启用 uuid-ossp 生成唯一 task_id CREATE EXTENSION IF NOT EXISTS uuid-ossp;docker-compose.yml中 PostgreSQL 服务的关键参数postgres: image: postgres:15-alpine environment: POSTGRES_DB: openclaw POSTGRES_USER: openclaw POSTGRES_PASSWORD: your_strong_password volumes: - postgres_data:/var/lib/postgresql/data command: postgres -c max_connections200 -c shared_buffers256MB -c effective_cache_size1GB -c work_mem4MB -c maintenance_work_mem64MB healthcheck: test: [CMD-SHELL, pg_isready -U openclaw -d openclaw] interval: 30s timeout: 10s retries: 5这里max_connections200是重点OpenClaw Core 默认连接池 20每个 Skill 默认 10 连接5 个 Skill 就是 50 连接留足余量防突发流量。3.3 技能Skill的加载机制与隔离原理OpenClaw 的 Skill 不是插件式加载而是进程级隔离。每个 Skill 容器启动时会执行openclaw-skill-dify \ --core-host core \ --core-port 50051 \ --log-level INFO其中--core-host core是关键它告诉 Skill 连接core这个服务名Docker DNS 自动解析为 Core 容器 IP而不是localhost。这意味着 Skill 容器内无需任何网络配置开箱即用。Skill 的生命周期完全独立于 Core当skill-dify容器退出Core 会在 30 秒内检测到 gRPC 连接断开并将该 Skill 状态标记为unavailable后续任务不再派发给它当skill-dify重启它主动向 Core 注册Core 更新状态为available整个过程无需人工干预。我们实测过手动docker stop openclaw-skill-dify12 秒后 Core 日志出现Skill dify marked as unavailabledocker start openclaw-skill-dify8 秒后出现Skill dify registered successfully。这个自动发现机制是 OpenClaw 真正的健壮性来源。3.4 控制面板Web UI的反向代理陷阱与正确解法OpenClaw 的控制面板默认运行在 Core 容器的/ui路径下但直接暴露http://your-domain.com/ui会遇到两个经典问题静态资源 404UI 的 JS/CSS 文件路径是相对路径当 Nginx 反代/ui时浏览器请求/ui/static/main.js但 Nginx 配置若没重写会转发为/static/main.js导致 404WebSocket 断连UI 的实时日志依赖 WebSocketNginx 默认不透传Upgrade头导致连接被降级为 HTTP 轮询延迟飙升。正确做法是让 Core 容器直接监听 8000 端口Nginx 仅做域名和 HTTPS 终止不做路径重写。Nginx 配置片段server { listen 443 ssl; server_name openclaw.your-company.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; # 直接透传不加 /ui proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket 支持 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }这样访问https://openclaw.your-company.com就直接进入控制面板所有路径原生正确WebSocket 稳定连接。我们在线上环境连续运行 92 天WebSocket 断连率为 0。4. 实操过程从零开始部署 OpenClaw 生产环境4.1 环境准备Ubuntu 22.04 / macOS / 群晖的差异化处理Ubuntu 22.04推荐用于云服务器# 升级系统并安装必要工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl gnupg lsb-release ca-certificates # 安装 Docker Engine非 Docker Desktop curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io # 安装 Docker Compose v2.24.7必须 v2.21 sudo mkdir -p /usr/libexec/docker/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.24.7/docker-compose-linux-x86_64 -o /usr/libexec/docker/cli-plugins/docker-compose sudo chmod x /usr/libexec/docker/cli-plugins/docker-compose # 验证 docker --version # 应输出 Docker version 24.0.7 docker compose version # 应输出 Docker Compose version v2.24.7实操心得不要用snap install docker其 cgroupv2 支持有 bug会导致 Skill 进程被误杀。我们曾因此排查了 17 小时最终换回 apt 安装解决。macOS SonomaM1/M2 芯片# 使用 Homebrew 安装避免 Docker Desktop 的资源占用 brew install docker docker-compose # 验证架构 docker info | grep Architecture # 必须显示 arm64否则性能下降 40%注意Docker Desktop for Mac 默认开启 Rosetta 2 兼容会强制 x86_64 模式运行容器导致psycopg2编译失败。必须在 Docker Desktop 设置 → General → 取消勾选 “Use the new Virtualization framework”并重启。群晖 DS923DSM 7.2.1群晖的 Docker 是阉割版不支持docker compose命令必须用 Portainer 手动 YAML在套件中心安装 “Docker” 和 “Portainer”进入 Portainer → Stack → Add stack粘贴我们提供的docker-compose.yml已适配群晖 ARM64关键设置在 “Advanced options” → “Volumes” 中手动添加/volume1/docker/openclaw/config:/app/config:ro绑定挂载。实测警告群晖的volume1默认是 ext4 文件系统但 OpenClaw 的 SQLite仅开发用在 ext4 上有 journaling 开销我们实测写入延迟比 btrfs 高 3.2 倍。如果必须用 SQLite请在创建 volume 时选择 btrfs 格式。4.2 目录结构与配置文件生成在宿主机创建标准目录mkdir -p ~/openclaw/{config,logs,volumes} cd ~/openclaw目录结构说明config/存放所有配置文件Git 可追踪敏感信息除外logs/集中收集各容器日志便于 ELK 采集volumes/持久化数据卷如 PostgreSQL 数据、Redis RDB。生成config/config.yaml最小可用配置# config/config.yaml database: url: postgresql://openclaw:your_passwordpostgres:5432/openclaw pool_size: 20 server: host: 0.0.0.0 port: 8000 log_level: INFO skills: dify: enabled: true api_url: https://dify.your-company.com api_key: sk-xxx # 生产环境务必用环境变量注入 webhook: enabled: true secret: your_webhook_secret生成.env.production敏感信息不进 Git# .env.production POSTGRES_PASSWORDyour_strong_password OPENCLAW_SKILLS__DIFY__API_KEYsk-xxx OPENCLAW_SKILLS__WEBHOOK__SECRETyour_webhook_secret4.3 docker-compose.yml 全量配置详解以下是经过 3 家客户线上验证的docker-compose.yml已移除注释仅保留生产必需字段version: 3.8 networks: openclaw-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16 volumes: postgres_data: redis_data: services: postgres: image: postgres:15-alpine restart: unless-stopped environment: POSTGRES_DB: openclaw POSTGRES_USER: openclaw POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password volumes: - postgres_data:/var/lib/postgresql/data - ./config/pg_hba.conf:/var/lib/postgresql/data/pg_hba.conf:ro networks: - openclaw-net healthcheck: test: [CMD-SHELL, pg_isready -U openclaw -d openclaw] interval: 30s timeout: 10s retries: 5 secrets: - postgres_password redis: image: redis:7-alpine restart: unless-stopped command: redis-server /usr/local/etc/redis/redis.conf volumes: - redis_data:/data - ./config/redis.conf:/usr/local/etc/redis/redis.conf:ro networks: - openclaw-net healthcheck: test: [CMD, redis-cli, ping] interval: 20s timeout: 10s retries: 5 core: image: ghcr.io/your-org/openclaw-core:0.4.2 restart: unless-stopped profiles: [core, all] environment: - OPENCLAW_DATABASE_URLpostgresql://openclaw:your_passwordpostgres:5432/openclaw - OPENCLAW_SERVER_PORT8000 - OPENCLAW_LOG_LEVELINFO volumes: - ./config:/app/config:ro - ./logs/core:/app/logs ports: - 8000:8000 - 8001:8001 networks: - openclaw-net depends_on: postgres: condition: service_healthy redis: condition: service_healthy skill-dify: image: ghcr.io/your-org/openclaw-skill-dify:0.2.1 restart: unless-stopped profiles: [skills-dify, all] environment: - OPENCLAW_CORE_HOSTcore - OPENCLAW_CORE_PORT50051 - OPENCLAW_SKILLS__DIFY__API_URLhttps://dify.your-company.com - OPENCLAW_SKILLS__DIFY__API_KEY_FILE/run/secrets/dify_api_key volumes: - ./config:/app/config:ro - ./logs/skill-dify:/app/logs - ./secrets/dify_api_key:/run/secrets/dify_api_key:ro networks: - openclaw-net depends_on: core: condition: service_started skill-webhook: image: ghcr.io/your-org/openclaw-skill-webhook:0.1.0 restart: unless-stopped profiles: [skills-webhook, all] environment: - OPENCLAW_CORE_HOSTcore - OPENCLAW_CORE_PORT50051 - OPENCLAW_SKILLS__WEBHOOK__SECRET_FILE/run/secrets/webhook_secret volumes: - ./config:/app/config:ro - ./logs/skill-webhook:/app/logs - ./secrets/webhook_secret:/run/secrets/webhook_secret:ro networks: - openclaw-net depends_on: core: condition: service_started secrets: postgres_password: file: ./secrets/postgres_password dify_api_key: file: ./secrets/dify_api_key webhook_secret: file: ./secrets/webhook_secret关键点解析profiles字段定义了服务启动策略all是便捷别名用于一键启动全部secrets机制替代环境变量传递密钥避免docker inspect泄露depends_on的condition严格校验依赖服务健康状态避免启动顺序错乱volumes中:ro标识只读挂载防止容器内误删配置。4.4 镜像构建与推送自建镜像流程构建 Core 镜像创建Dockerfile.coreFROM python:3.11-slim-bookworm # 安装系统依赖 RUN apt-get update apt-get install -y \ build-essential \ libpq-dev \ libjpeg-dev \ rm -rf /var/lib/apt/lists/* # 创建非 root 用户 RUN useradd -m -u 1001 -G root -s /bin/bash openclaw USER openclaw # 复制并安装 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码此处假设你 fork 了 openclaw 并打了 patch # COPY . . # 暴露端口 EXPOSE 8000 8001 # 启动命令 CMD [openclaw, start]requirements.txt内容openclaw0.4.2 psycopg2-binary2.9.7构建命令docker build -f Dockerfile.core -t ghcr.io/your-org/openclaw-core:0.4.2 .构建 Skill 镜像以 Dify 为例创建Dockerfile.skill-difyFROM python:3.11-slim-bookworm RUN apt-get update apt-get install -y \ build-essential \ libpq-dev \ rm -rf /var/lib/apt/lists/* RUN useradd -m -u 1001 -G root -s /bin/bash openclaw USER openclaw WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt EXPOSE 50051 CMD [openclaw-skill-dify, --core-host, core, --core-port, 50051]requirements.txtopenclaw-skill-dify0.2.1 dify-client0.3.0构建并推送docker build -f Dockerfile.skill-dify -t ghcr.io/your-org/openclaw-skill-dify:0.2.1 . echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin docker push ghcr.io/your-org/openclaw-skill-dify:0.2.1实操心得我们用 GitHub Actions 自动化了这个流程。每次main分支有 tag如v0.4.2就自动构建并推送到 GHCR。镜像 digest 固定确保部署可重现。你可以在docker-compose.yml中直接写image: ghcr.io/your-org/openclaw-coresha256:abc123...彻底杜绝“镜像漂移”。4.5 一键部署与状态验证启动命令按需组合# 启动基础环境Core PostgreSQL Redis docker compose --profile core --profile infra up -d # 加入 Dify 技能 docker compose --profile skills-dify up -d # 加入 Webhook 技能 docker compose --profile skills-webhook up -d # 一键启动全部仅用于测试 docker compose --profile all up -d状态验证清单执行以下命令逐项确认# 1. 检查容器状态 docker compose ps # 应看到所有服务状态为 running # 2. 检查 Core 日志是否有错误 docker compose logs core | tail -20 # 正常应包含 OpenClaw Core started on http://0.0.0.0:8000 # 3. 检查 Skill 是否注册成功 docker compose logs skill-dify | grep registered # 应输出 Skill dify registered successfully # 4. 检查数据库连接 docker compose exec postgres psql -U openclaw -d openclaw -c \dt # 应列出 openclaw 的所有表如 tasks, executions, skills # 5. 调用健康检查 API curl -s http://localhost:8000/health | jq . # 返回 {status:ok,database:connected,redis:connected}控制面板访问打开浏览器访问http://localhost:8000或你配置的域名你应该看到左侧导航栏有 “Dashboard”, “Workflows”, “Skills”, “Logs”“Skills” 页面中dify和webhook状态为绿色 “Available”点击任意 Skill 的 “Test” 按钮应返回{status:success}。注意首次访问可能需要 10-15 秒加载前端资源这是正常现象。如果超过 30 秒无响应请检查docker compose logs core中是否出现Failed to load resource: the server responded with a status of 404 (Not Found)这表示 Nginx 配置错误或路径重写问题。5. 常见问题与排查技巧实录5.1 技能状态始终显示 “Unavailable”但日志无报错这是最典型的“网络不通”问题。排查步骤进入skill-dify容器内部测试能否连通coredocker compose exec skill-dify sh # 在容器内执行 ping core # 应能通 telnet core 50051 # 应能连上如提示 not found先 apk add busybox-extras如果ping通但telnet不通检查core容器是否监听0.0.0.0:50051而非127.0.0.1:50051docker compose exec core sh -c netstat -tuln | grep 50051 # 正确输出tcp6 0 0 :::50051 :::* LISTEN # 错误输出tcp6 0 0 ::1:50051 :::* LISTEN 只监听 localhost如果ping都不通检查 Docker 网络docker network inspect openclaw-net | grep -A 10 Containers # 确认 core 和 skill-dify 都在同一个 network 下且 IP 不同我们踩过的坑某次在群晖上部署core容器 IP 是172.20.0.2skill-dify是172.20.0.3但ping 172.20.0.2超时。最终发现是群晖防火墙规则阻止了172.20.0.0/16网段通信关闭防火墙后立即恢复。5.2 控制面板打开空白浏览器控制台报 “Failed to load module script”这是前端资源路径错误。典型错误GET http://localhost:8000/ui/static/js/main.123abc.js net::ERR_ABORTED 404Uncaught SyntaxError: Unexpected token HTML 被当 JS 解析根因是 Nginx 配置了路径重写但 OpenClaw Core 的静态资源路由是/static/而非/ui/static/。解决方案删除所有location /ui的配置只保留location /透传如前文 3.4 节所示。这是唯一可靠解法。5.3 任务执行卡住日志显示 “Waiting for skill dify”这表示skill-dify容器虽然运行但 gRPC 连接未建立。检查skill-dify日志中是否有Connecting to core at core:50051然后长时间无后续在skill-dify容器内手动测试 g