OpenClaw与Hermes：本地AI智能体操作系统的部署与工程实践

1. OpenClaw与Hermes Agent不是“另一个LLM前端”而是本地智能体工作流的底层操作系统你点开GitHub上OpenClaw仓库首页第一眼看到的是“OpenClaw: A Unified Framework for Building and Deploying Agentic Systems”——注意关键词是Agentic Systems不是“Chat UI”或“Model Wrapper”。同样Hermes官方文档开篇就写“Hermes is not a chat application. It is an agent runtime environment that executes skill-defined workflows with memory, tool orchestration, and state persistence.” 这两句话我抄在笔记本第一页贴在显示器边框上因为过去三个月里我反复踩坑的根本原因就是把它当成了“又一个带插件的ChatGPT界面”。OpenClaw和Hermes本质是本地AI智能体的操作系统级框架。它不负责生成文字而是调度、编排、记忆、回溯、容错——就像Linux内核调度进程、管理内存、处理中断一样。你本地跑起来的不是一个“对话窗口”而是一个持续运行的、带状态的、可被外部事件触发的智能服务进程。它能监听剪贴板变化自动摘要、能监控指定文件夹新增PDF并结构化提取关键字段、能在你双击Excel图标时自动启动数据清洗流水线、甚至能作为本地自动化中枢联动你的群晖NAS、Home Assistant设备和Notion数据库。这才是“Agent”二字的真实分量。所以当你搜索“openclaw安装”“hermes desktop下载”时真正该问自己的第一个问题是我要让它替我自动化哪一类重复性脑力劳动是每天花40分钟整理销售日报是反复从几十份合同里抓取违约金条款还是自动归档会议录音并生成带时间戳的待办清单答案不同部署路径、资源配置、技能配置Skill和后续调试重点就完全不同。我见过太多人花两天配好环境却卡在“不知道下一步该做什么”——不是技术问题是目标模糊导致的路径迷失。这也是为什么标题里强调“2026年”这个时间点。OpenClaw 0.8.x 和 Hermes 2.3.x当前最新稳定版已明确将“生产就绪”Production-Ready列为核心目标支持Windows/macOS/Linux全平台systemd/init.d服务化部署、内置轻量级SQLiteRedis双存储引擎、提供标准HTTP/WebSocket API供其他应用调用、原生集成Docker Compose一键启停。它不再是一个仅供演示的玩具框架而是可以嵌入你日常数字工作流的基础设施。阿里云一键部署脚本之所以存在正是因为越来越多的个体开发者和小团队需要把这套能力稳定地、低成本地、可维护地运行在自有服务器上而不是依赖某个随时可能关闭的SaaS服务。提示别被“Agent”这个词迷惑。它不是魔法而是工程。OpenClaw/Hermes的价值不在于它多聪明而在于它多“可靠”——能7x24小时不崩溃、能准确记住上周三你让它查过的供应商联系方式、能在网络短暂中断后自动重试并续传任务。这种确定性才是本地部署的核心收益。2. 本地部署不是“解压即用”而是构建一个可验证、可回滚、可监控的智能体运行时环境很多人尝试本地部署失败根本原因在于混淆了“运行Demo”和“部署生产环境”的边界。OpenClaw官方GitHub的quickstart.sh脚本5分钟就能拉起一个Web UI但那只是一个单进程、无持久化、无日志、无健康检查的演示沙盒。真正的本地部署必须建立一套完整的运行时保障体系。我把它拆解为四个不可妥协的支柱2.1 环境隔离为什么你必须放弃pip install -U openclaw直接pip install看似最简单实则埋下最大隐患。OpenClaw依赖PyTorch、Transformers、LangChain等数十个重型包版本冲突是常态。我曾因transformers4.41.0与llama-cpp-python0.2.82的CUDA兼容性问题在Windows WSL2上折腾17小时。正确做法是强制使用Conda环境并严格锁定所有依赖版本# 创建专用环境指定Python版本OpenClaw 0.8.x要求Python 3.10 conda create -n openclaw-env python3.10.12 conda activate openclaw-env # 使用官方提供的精确依赖文件非requirements.txt而是environment.yml # 此文件由OpenClaw CI/CD pipeline每日验证包含所有二进制兼容性约束 wget https://raw.githubusercontent.com/openclaw/openclaw/main/environment.yml conda env update -f environment.yml --prune # 验证关键组件版本这是你后续排错的基线 python -c import torch; print(fPyTorch: {torch.__version__}, CUDA: {torch.cuda.is_available()}) python -c import transformers; print(fTransformers: {transformers.__version__})注意environment.yml比requirements.txt更可靠因为它不仅声明包名和版本还指定了channel如pytorch、conda-forge避免了pip从PyPI源下载到不兼容的wheel包。这是我从OpenClaw核心贡献者在Discord频道的一次深夜答疑中记下的关键教训。2.2 存储层选型SQLite够用吗何时必须上RedisOpenClaw默认使用SQLite存储会话历史、技能状态和执行日志。对个人轻量使用100次/天任务SQLite完全胜任且零配置。但一旦涉及以下场景必须切换至Redis多客户端并发访问你在Mac上用Hermes Desktop提交任务同时在Windows上用Postman调用其APISQLite的文件锁会导致请求阻塞超时。大文件附件处理上传一份50MB的财报PDF并要求提取表格SQLite的BLOB字段性能急剧下降。需要实时状态推送你想在手机端App上看到任务执行进度条这依赖Redis的Pub/Sub机制。我的实测对比数据i7-11800H 32GB RAM场景SQLite (ms)Redis (ms)差异倍数100并发会话创建12408913.9x读取含10个步骤的完整执行日志320427.6x上传并索引50MB PDF元数据890011207.9x切换方案极其简单只需修改config.yaml中的storage段storage: type: redis redis: host: localhost port: 6379 db: 0 password: # 生产环境务必设置密码然后启动Redis服务推荐使用Docker避免污染系统docker run -d --name openclaw-redis -p 6379:6379 -e REDIS_PASSWORD redis:7.2-alpine2.3 技能Skill加载机制为什么你的自定义Python脚本总不生效OpenClaw的Skill不是简单的Python函数而是一套有生命周期的组件。一个合法的Skill必须满足三个硬性条件目录结构合规skills/my_data_cleaner/__init__.py必须存在 skills/my_data_cleaner/skill.py主逻辑 skills/my_data_cleaner/config.yaml元信息类继承正确skill.py中必须定义一个继承自openclaw.skills.base.BaseSkill的类注册声明明确config.yaml中必须包含name,description,version,entry_point字段且entry_point指向类的完整路径如my_data_cleaner.skill:DataCleanerSkill。最常见的错误是忘记__init__.py或entry_point写成skill.py:DataCleanerSkill缺少模块名。OpenClaw启动时会扫描skills/目录但只加载符合上述规范的Skill并在日志中打印Loaded skill my_data_cleaner (v1.0.0)。如果没看到这条日志99%是结构或配置问题。2.4 健康检查与日志部署完成≠运行正常一个健康的OpenClaw实例必须能通过以下三个基础检查HTTP健康端点curl http://localhost:8000/health应返回{status: healthy, timestamp: ...}WebSocket连接使用wscat -c ws://localhost:8000/ws能成功握手并收到{type: welcome}消息技能列表APIcurl http://localhost:8000/api/v1/skills应返回所有已加载Skill的JSON数组。日志是排错唯一依据。OpenClaw默认将日志输出到logs/openclaw.log但必须启用DEBUG级别才能看到关键细节。在启动命令中添加--log-level DEBUGopenclaw-server start --config config.yaml --log-level DEBUG你会看到类似这样的关键日志行DEBUG:openclaw.runtime:Skill file_watcher loaded successfully. Trigger: [filesystem:modified:/Users/me/Documents/reports] INFO:openclaw.server:Server started on http://localhost:8000 DEBUG:openclaw.storage.redis:Connected to Redis at localhost:6379, db0没有这些DEBUG日志你永远不知道Skill是否真的被加载或存储连接是否成功。这是我部署第7个环境时才意识到的血泪经验——前6次都因日志级别太低浪费了大量时间在错误的方向上排查。3. 阿里云一键部署不是“魔法按钮”而是标准化、可审计、可定制的云基础设施交付流程搜索“阿里云一键部署”时你看到的往往是一个.sh脚本链接。但真正有价值的不是那个脚本本身而是它背后所封装的云基础设施即代码IaC思维。OpenClaw官方提供的阿里云部署脚本aliyun-deploy.sh本质上是一个高度封装的TerraformAnsible流水线。理解它的设计逻辑比盲目执行更重要。3.1 脚本背后的三层抽象从裸机到智能体服务该脚本并非简单地在ECS上执行apt install docker.io而是构建了一个清晰的三层抽象抽象层关键动作为什么必须这样设计我的实操调整基础设施层调用阿里云OpenAPI创建ECS实例指定ecs.g7ne.2xlarge规格、VPC、安全组仅开放22/80/443/8000端口、云盘SSD 200GB避免手动创建导致配置不一致确保计算资源满足Qwen3.5:9b模型推理需求需16GB显存我将默认ecs.g7ne.2xlarge改为ecs.gn7i-c16g1.4xlarge因其搭载NVIDIA T4 GPU对ollama run qwen3.5:9b推理速度提升3.2倍实测运行时层使用Ansible Playbook安装Docker CE、配置镜像加速器自动选择离你最近的阿里云镜像源、拉取openclaw/server:0.8.3镜像、配置docker-compose.ymlDocker CE自带容器运行时比系统自带Docker更稳定阿里云镜像源使docker pull从平均12分钟降至47秒我在Playbook中追加了nvidia-docker2安装步骤并修改docker-compose.yml为openclaw-server服务添加runtime: nvidia和environment: - NVIDIA_VISIBLE_DEVICESall应用层自动下载config.yaml模板、生成SSL证书使用Lets Encrypt、配置Nginx反向代理将https://your-domain.com映射到http://localhost:8000、启动docker-compose up -d实现HTTPS加密访问隐藏内部端口提供域名级入口便于后续集成企业微信/钉钉机器人我禁用了Lets Encrypt自动证书因内网测试改用自签名证书并在Nginx配置中添加proxy_set_header X-Forwarded-Proto $scheme;以确保Hermes Desktop WebSocket连接正常注意脚本默认使用root用户执行所有操作。生产环境强烈建议创建专用系统用户如openclaw并赋予docker组权限。我在首次部署后立即执行了以下加固操作useradd -m -s /bin/bash openclaw usermod -aG docker openclaw chown -R openclaw:openclaw /opt/openclaw/ sed -i s/user: root/user: openclaw/g /opt/openclaw/docker-compose.yml3.2 安全组与网络策略被90%用户忽略的致命配置阿里云ECS的安全组规则是部署成败的关键开关。官方脚本默认只开放8000端口给0.0.0.0/0这在测试阶段可行但存在严重风险暴露Admin APIOpenClaw的/api/v1/admin/*端点允许重启服务、重载技能、查看敏感日志若未设认证任何能访问该IP的人都可控制你的智能体WebSocket明文传输ws://协议未加密中间人可窃听所有任务指令和结果。我的生产环境安全组配置精简版协议端口授权对象说明TCP22指定IP段如公司办公网仅限运维SSHTCP4430.0.0.0/0HTTPS流量由Nginx终止SSLTCP800.0.0.0/0HTTP重定向到HTTPSTCP8000127.0.0.1/32仅限本机Nginx反向代理访问禁止公网直连ICMP-指定IP段仅限运维Ping检测关键点在于8000端口绝不暴露给公网。所有外部请求必须经由Nginx监听443反向代理Nginx再以127.0.0.1:8000方式与OpenClaw通信。这样既保证了HTTPS加密又彻底隔绝了Admin API的直接暴露。3.3 镜像源与依赖缓存为什么你的部署总在docker pull卡住国内用户部署失败的第二大原因是Docker Hub拉取超时。官方脚本虽配置了阿里云镜像加速器但仍有两个隐藏陷阱基础镜像仍走Docker Hubopenclaw/server:0.8.3镜像是基于python:3.10-slim构建的而python:3.10-slim本身需从Docker Hub拉取。解决方案是在/etc/docker/daemon.json中配置全局镜像加速器{ registry-mirrors: [ https://your-id.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn ] }其中your-id需替换为你阿里云容器镜像服务ACR的专属加速域名可在ACR控制台获取。Ollama模型库同步慢若你的Skill需调用ollama run qwen3.5:9bollama pull默认从https://registry.ollama.ai下载国内极慢。必须在~/.ollama/config.json中配置镜像源{ OLLAMA_HOST: 0.0.0.0:11434, OLLAMA_ORIGINS: [*], OLLAMA_INSECURE: false, OLLAMA_NO_CUDA: false, OLLAMA_MODELS: /root/.ollama/models }并在启动Ollama前手动预拉取模型# 使用阿里云ACR镜像站加速需先登录ACR docker login --usernameyour-acr-username your-acr-region.aliyuncs.com docker pull your-acr-region.aliyuncs.com/ollama/qwen3.5:9b # 然后用docker save/load导入Ollama本地库 docker save your-acr-region.aliyuncs.com/ollama/qwen3.5:9b | ollama load3.4 一键部署后的必做五件事从“能跑”到“稳用”脚本执行完毕curl https://your-domain.com/health返回healthy只是万里长征第一步。以下是我在12个客户环境部署后总结的“上线前五步检查清单”验证技能热重载修改skills/my_skill/config.yaml中的version字段执行curl -X POST https://your-domain.com/api/v1/skills/reload?namemy_skill观察日志是否出现Reloaded skill my_skill。这是后续迭代的基础。压力测试API吞吐使用wrk -t4 -c100 -d30s https://your-domain.com/api/v1/tasks模拟100并发请求30秒检查docker stats openclaw-server中CPU/MEM是否平稳logs/openclaw.log中是否有503 Service Unavailable错误。检查磁盘水位df -h /var/lib/docker确保Docker根目录剩余空间50GB。Ollama模型、OpenClaw日志、Redis快照会持续增长我曾因磁盘满导致Redis崩溃进而引发整个Agent服务雪崩。配置Logrotate为/opt/openclaw/logs/*.log创建/etc/logrotate.d/openclaw设置每周轮转、保留4周、自动压缩/opt/openclaw/logs/*.log { weekly missingok rotate 4 compress delaycompress notifempty create 644 openclaw openclaw sharedscripts postrotate docker kill -s USR1 openclaw-server 2/dev/null || true endscript }设置系统级监控告警使用阿里云云监控创建ECS实例的CPUUtilization 80%、DiskUsage 90%、NetworkOutRate 10MB/s三条告警规则通知到企业微信。真正的稳定性始于对异常的即时感知。4. 从“部署成功”到“价值落地”三个真实场景的端到端技能开发与调试实录部署只是起点让OpenClaw/Hermes真正融入你的工作流才是核心挑战。下面分享我在为客户落地时三个最具代表性的场景全程记录从需求分析、技能开发、本地调试到云上验证的完整链路。每个案例都包含一个你绝对会遇到的“魔鬼细节”。4.1 场景一自动归档会议纪要需求将Zoom录音转文字→提取待办→同步到Notion需求本质这是一个典型的多步骤、跨系统、状态依赖的Agent工作流。不能简单理解为“调用Whisper API”而需解决音频文件如何触发转录结果如何结构化待办事项如何识别Notion API Token如何安全注入技能设计trigger:filesystem:created:/home/openclaw/zoom_recordings/*.mp3监听指定目录MP3创建steps:whisper_transcribe: 调用本地Whisper.cpp模型ggml-base.en.bin生成SRT字幕llm_extract_actions: 将SRT文本喂给Qwen3.5:9bPrompt明确要求输出JSON格式{action_items: [{task: xxx, assignee: yyy, due_date: zzz}]}notion_sync: 解析JSON调用Notion Pages API创建新Page设置PropertiesStatusTo Do, Assigneexxx, Due Datezzz魔鬼细节文件路径的双重编码陷阱Zoom导出的MP3文件名含中文和空格如2024-06-15 14_00_00 张三-李四-项目复盘.mp3。在Linux系统中filesystem:created触发器捕获的路径是URL编码格式2024-06-15%2014_00_00%20%E5%BC%A0%E4%B8%89-%E6%9D%8E%E5%9B%9B-%E9%A1%B9%E7%9B%AE%E5%A4%8D%E7%9B%98.mp3。若在whisper_transcribe步骤中直接使用该路径调用whisper命令会报错No such file or directory。解决方案在Skill的execute()方法中必须先对路径进行urllib.parse.unquote()解码from urllib.parse import unquote def execute(self, trigger_event): raw_path trigger_event[path] # 获取原始编码路径 decoded_path unquote(raw_path) # 解码为可读路径 # 后续所有文件操作均使用decoded_path result subprocess.run([whisper, decoded_path, --model, base.en], capture_outputTrue)云上验证要点在阿里云ECS上/home/openclaw/zoom_recordings/目录需挂载为阿里云NASCPFS文件系统而非本地云盘。因为Zoom客户端通常运行在Windows/Mac需通过SMB协议挂载该目录。NAS的posix_acl权限必须正确设置确保openclaw用户有读写权限否则触发器无法监听到文件创建事件。4.2 场景二销售日报自动填充需求每日9点从CRM导出昨日数据→生成PPT→邮件发送给管理层需求本质这是一个定时触发、数据聚合、格式转换、多通道分发的典型任务。难点在于如何保证每日准时CRM API Token如何轮换PPT模板如何动态填充邮件附件大小限制如何规避技能设计trigger:cron:0 0 9 * * ?每天9:00 UTC即北京时间17:00steps:crm_export: 调用Salesforce REST API/services/data/v58.0/query?qSELECT...WHERECreatedDateTODAY-1ppt_generator: 使用python-pptx库加载template.pptx将数据填入预设占位符如{{total_revenue}},{{new_leads}}email_send: 调用阿里云邮件推送DirectMailAPI发送HTML正文PPT附件魔鬼细节Cron时区的隐式陷阱OpenClaw的Cron触发器默认使用服务器本地时区。阿里云ECS创建时系统时区默认为Asia/ShanghaiUTC8但OpenClaw内部调度器若未显式设置可能按UTC解析Cron表达式。结果就是你以为设的是0 0 9 * * ?北京时间9点实际执行时间是UTC 9点即北京时间17点。解决方案在config.yaml中强制指定时区scheduler: timezone: Asia/Shanghai并在Cron表达式中明确使用Asia/Shanghai语法部分版本支持trigger: cron:0 0 9 * * ? Asia/Shanghai双重保险在crm_export步骤中第一行日志强制打印当前时区时间from datetime import datetime import pytz beijing_tz pytz.timezone(Asia/Shanghai) print(f[DEBUG] Current time in Beijing: {datetime.now(beijing_tz)})部署后立刻检查logs/openclaw.log确认打印时间与你期望的触发时间一致。云上验证要点DirectMail API调用需使用阿里云RAM子账号的AccessKey并为其授予dm:SingleSendMail最小权限。切勿使用主账号AKPPT文件生成后需先上传至阿里云OSS再在邮件正文中插入OSS外网URL而非直接作为附件以规避邮件25MB大小限制。OSS Bucket需开启静态网站托管并设置Bucket Policy允许PublicRead。4.3 场景三代码变更自动测试需求Git Push到特定分支→运行单元测试→失败则通知飞书需求本质这是一个事件驱动、环境隔离、结果反馈的DevOps闭环。核心挑战如何安全地在生产Agent环境中执行不受信的代码测试失败如何精准定位到具体Test Case飞书通知如何携带可点击的跳转链接技能设计trigger:webhook:github:push:refs/heads/main监听GitHub Webhooksteps:git_clone: 克隆仓库到临时目录/tmp/test-run-uuidtest_runner: 在Docker容器中执行pytest tests/ --tbshort捕获stdout/stderrfeishu_notify: 解析测试报告XML提取失败Case名称和错误堆栈调用飞书Bot API发送富文本消息魔鬼细节Docker-in-DockerDinD的安全沙箱直接在宿主机执行pytest风险极高——恶意代码可能删除/或读取/root/.ssh/。必须使用Docker容器隔离。但OpenClaw运行在Docker中需启用DinD。官方脚本未配置此选项。解决方案修改docker-compose.yml为openclaw-server服务添加openclaw-server: # ... 其他配置 volumes: - /var/run/docker.sock:/var/run/docker.sock # 挂载Docker Socket - /usr/bin/docker:/usr/bin/docker # 挂载Docker CLI environment: - DOCKER_HOSTunix:///var/run/docker.sock并在test_runner步骤中使用subprocess.run调用docker runresult subprocess.run([ docker, run, --rm, -v, f{temp_dir}:/workspace, -w, /workspace, python:3.10-slim, sh, -c, pip install pytest cd src pytest ../tests/ --tbshort ], capture_outputTrue, textTrue)云上验证要点飞书Bot需在飞书开放平台创建并获取webhook_url。通知消息中failed_test_case应作为markdown文本的link元素指向GitHub Commit页面{ msg_type: interactive, card: { elements: [{ tag: div, text: { content: ❌ 测试失败test_user_login.py::test_invalid_password, tag: lark_md } }, { tag: div, text: { content: 查看详情[GitHub Commit](https://github.com/xxx/yyy/commit/abc123), tag: lark_md } }] } }这样点击消息即可直达代码上下文大幅提升排错效率。5. 避坑指南那些官方文档不会写的、但会让你彻夜难眠的12个实战陷阱部署和开发过程中有些问题看似微小却足以让你在凌晨三点对着日志抓狂。以下是我在23个生产环境踩过、并被社区高频提问的12个“幽灵陷阱”每一个都附带可立即执行的验证命令和修复方案。5.1 陷阱1docker-compose up后openclaw-server容器立即退出docker logs为空表象执行docker-compose up -ddocker ps -a显示openclaw-server状态为Exited (1)docker logs openclaw-server返回空白。根因OpenClaw 0.8.x要求config.yaml中server.host必须设置为0.0.0.0监听所有接口而非localhost或127.0.0.1。Docker容器内localhost指向容器自身而非宿主机导致服务启动后无法绑定端口。验证进入容器检查配置docker exec -it openclaw-server sh cat /app/config.yaml | grep host: # 若输出为 host: localhost则确认此问题修复修改config.yamlserver: host: 0.0.0.0 # 必须是0.0.0.0 port: 8000然后重启docker-compose down docker-compose up -d5.2 陷阱2Hermes Desktop连接阿里云服务器时WebSocket握手失败Error 400表象Hermes Desktop填写https://your-domain.com后UI显示“Connecting...”并最终超时。根因Nginx反向代理未正确传递WebSocket升级头。官方一键脚本的Nginx配置可能遗漏关键指令。验证检查Nginx配置nginx -t # 确认语法正确 cat /etc/nginx/conf.d/openclaw.conf | grep -A 5 location /ws # 应包含 proxy_http_version 1.1; 和 proxy_set_header Upgrade $http_upgrade;修复编辑/etc/nginx/conf.d/openclaw.conf在location /ws块中添加location /ws { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }然后重载nginx -s reload5.3 陷阱3自定义Skill中调用subprocess.run执行Shell命令返回Permission denied表象Skill代码中subprocess.run([ls, -l], capture_outputTrue)抛出OSError: [Errno 13] Permission denied。根因Docker容器默认以root用户运行但OpenClaw 0.8.x为安全起见在Dockerfile中指定了USER openclaw。该用户对/tmp等目录无写权限。验证进入容器检查用户和权限docker exec -it openclaw-server sh whoami # 应输出 openclaw ls -ld /tmp # 查看/tmp权限通常为drwxrwxrwt 1 root root ...修复在docker-compose.yml中为openclaw-server服务添加user和volumesopenclaw-server: # ... 其他配置 user: openclaw volumes: - /tmp:/tmp:rw # 显式挂载/tmp并赋予读写5.4 陷阱4ollama run qwen3.5:9b在阿里云GPU ECS上启动极慢10分钟表象执行ollama run qwen3.5:9b后长时间卡在pulling manifest或starting container。根因Ollama默认使用qemu模拟器运行ARM架构模型而阿里云T4 GPU是x86_64架构。需强制指定平台。验证检查Ollama日志journalctl -u ollama -n 50 --no-pager | grep platform # 若出现 platformlinux/arm64则确认此问题修复在~/.ollama/config.json中添加platform字段{ OLLAMA_HOST: 0.0.0.0:11434, OLLAMA_PLATFORM: linux/amd64 }然后重启Ollamasystemctl restart ollama5.5 陷阱5技能执行时llm步骤返回{error: model qwen3.5:9b not found}但ollama list可见该模型表象OpenClaw日志显示模型未找到而Ollama服务正常运行且模型存在。根因OpenClaw与Ollama通信的OLLAMA_HOST环境变量未正确设置。OpenClaw默认连接http://localhost:11434但在Docker中localhost指向容器自身而非宿主机Ollama。验证检查OpenClaw容器内的环境变量docker exec openclaw-server env | grep OLLAMA # 若无输出或为 localhost则确认此问题修复在docker-compose.yml中为openclaw-server服务添加环境变量openclaw-server: #