简介这是一份面向开发者与运维人员的Docker安装OpenClaw代码指南帮助在容器化环境中快速部署、配置和迭代AI系统OpenClaw。压缩包共8个文件涵盖Shell安装脚本、Dockerfile、docker-compose配置、JSON配置文件、Markdown说明文档等覆盖手动安装与Dockerfile构建两种安装方式适合测试开发与分享部署两类场景。全套资源仅12KB、轻量实用目前已有1340人学习。内容围绕基础镜像启动、OpenClaw安装、网关配置、插件冲突与网络排错展开同时提供了修改默认配置、模板化简化设置等镜像优化技巧读者可直接修改其中配置用于生产部署也可借此理解容器化部署的完整流程。借助Docker分层镜像与容器隔离特性还能轻松在不同OpenClaw版本间切换、快速回滚是进行版本管理和环境隔离的高效工具。适合需要快速搭建AI系统并掌握容器化部署实践的初中级开发者。 刚拿到这个部署需求的时候我第一反应是又要在宿主机上裝一堆Python依赖和Node环境了吧。OpenClaw这种个人AI助理项目裸机部署虽然可行但升级麻烦、环境容易互相污染换台机器更是噩梦。用Docker跑起来之后整个部署过程变成了拉镜像、起容器、开控制台三步前后不到十分钟比脚本安装干净得多。这篇就围绕Docker安装OpenClaw的完整链路来写从环境准备到镜像配置再到启动踩坑适合想在本地快速跑起一个AI Agent实例、又不想把系统搞得一团糟的人参考。1. 先搞清楚一件事为什么用Docker而不是直接跑官方脚本如果你去看OpenClaw的官方文档它默认推荐的安装方式其实是PowerShell一键脚本。脚本会把Python、Node、相关依赖全部装进系统目录然后启动一个常驻服务。这种方式对新手最友好但对长期使用的人来说有几个问题很难受。第一是环境隔离差。OpenClaw依赖的Python版本、Node版本和系统里其他项目经常打架今天升级一个包明天另一个项目就跑不起来了。第二是升级麻烦脚本升级往往要重新拉依赖装一半失败的话回滚会让你崩溃。第三是卸载不干净散落在各个目录里的配置文件和缓存手动清不仅费劲还容易漏。Docker方案把这些问题全包了。镜像里已经固化好了一整套运行时环境宿主机只需要有Docker Engine其他什么都不用装。升级就是替换镜像回滚就是切回旧镜像标签卸载就是删容器删镜像干干净净。我自己的服务器上同时跑着MySQL、Redis、Nginx和OpenClaw互相完全无感这就是容器化的价值。当然也不是所有场景都适合Docker。如果你打算对OpenClaw做深度二次开发需要在源码里加断点调试、频繁改Python包依赖那还是建议用源码方式跑因为容器里的文件系统是隔离的改起来不如宿主机顺手。我自己用Docker部署时遇到过一次需要给Python库打补丁的场景当时就后悔没直接源码跑。所以部署前先想清楚自己的需求边界。那我为什么最终推荐Docker因为对绝大多数人来说OpenClaw是一个要长期稳定运行的服务而不是一个开发中的项目。既然是服务就要用服务的方式去管理容器化恰恰是当前最成熟、最省心的服务化方式。你不需要理解OpenClaw内部怎么组织项目结构只需要知道这个容器会在18000端口提供一个管理界面、在8000端口提供API入口就够了剩下的交给Docker去管。2. 部署前的环境准备与两个容易翻车的细节在开始部署之前先把基础环境盘一遍。我的宿主机是一台8核16G的Ubuntu 22.04服务器这个配置跑OpenClaw非常宽裕。Windows用户如果是用Docker Desktop流程稍微不同但原理一样。2.1 Windows下Docker Desktop虚拟化检测失败热词里有一条docker desktop failed to start because virtualisation support wasnt detected我周围至少有三个朋友第一次安装时就撞上这个报错。Docker Desktop依赖Windows自带的虚拟化能力也就是Hyper-V或WSL2后端如果BIOS里没开启虚拟化或者Windows的虚拟机监控程序没启动它就会直接罢工。检查方法很简单。任务管理器切到性能标签页看底部有没有虚拟化已启用字样。如果是已禁用就进BIOS把Intel VT-x或AMD-V打开。如果BIOS已经开了但Docker还报错那就去启用或关闭Windows功能里确认Hyper-V和适用于Linux的Windows子系统这两个选项有没有勾上勾完后必须重启一次系统。顺带提醒一下Windows上装Docker Desktop属于Docker的GUI方案而Linux服务器上装的是Docker Engine这是两套东西。如果你的OpenClaw打算长期挂在服务器上跑最好直接用一台Linux机器性能更好也稳定得多。Windows的Docker Desktop适合本地跑着玩、开发调试真当生产环境用内存和资源的管理效率差点意思。2.2 镜像拉取慢的应急方案部署OpenClaw之前还有一个隐藏关卡镜像拉取。如果你在国内网络环境下直接docker pull大概率会看到进度条像蜗牛一样爬几百兆的镜像能拉半小时。这不是OpenClaw镜像独有的问题所有Docker Hub的官方镜像都这样。我的做法是配置镜像加速器。在/etc/docker/daemon.json里填上registry-mirrors地址然后重启Docker服务。注意不同服务商提供的加速地址时效性不一样有的过一段时间就失效了所以我会定期检查docker info里Registry Mirrors那一栏是否还在生效。还有一种更取巧的办法用代理环境变量给Docker守护进程走网络但这种方案我现在不推荐了一是配置麻烦二是稳定性看运气。老老实实配加速器才是正道。2.3 宿主机目录规划OpenClaw跑起来之后会产生不少持久化数据包括会话记录、日志、用户配置、模型API Key缓存等。如果容器删除时数据也一起消失那真的会让人崩溃。所以部署之前我先规划好数据目录~/docker/openclaw/config存放OpenClaw的配置文件~/docker/openclaw/data存放会话信息和状态数据~/docker/openclaw/logs存放运行日志这三个目录通过docker-compose的volumes卷映射挂载到容器内部这样无论容器怎么重建数据都在宿主机上稳稳躺着随时可以备份和迁移。这个习惯我建议所有用Docker跑服务的人都养成不要图省事用匿名卷否则某天docker-compose down -v一执行哭都来不及。3. 完整部署过程从空目录到控制台弹窗3.1 Docker Compose编排文件OpenClaw的部署推荐用docker-compose方式管理因为单条docker run命令参数太长尤其端口映射和数据卷一多记录、修改都不方便。所以我先建一个工作目录再写入docker-compose.yml。version: 3.8 services: openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - 18000:18000 - 8000:8000 environment: - TZAsia/Shanghai - OPENCLAW_API_KEYyour_secure_api_key_here - OPENCLAW_DATA_DIR/openclaw/data volumes: - ~/docker/openclaw/config:/openclaw/config - ~/docker/openclaw/data:/openclaw/data - ~/docker/openclaw/logs:/openclaw/logs extra_hosts: - host.docker.internal:host-gateway这个配置文件有几个关键点要解释一下。首先是镜像地址我用的是GitHub Container Registry的ghcr.io地址相比Docker Hub上的镜像这里跟踪官方发布节奏更及时。如果你所在网络环境访问ghcr.io也慢那就需要先把镜像拉到本地再导入前面说的加速器方案同样适用。其次是端口映射。OpenClaw的管理控制台默认监听18000端口API服务监听8000端口。如果宿主机上这两个端口已被占用冒号左侧的端口改成别的就行比如18001:18000浏览器访问时就用18001。注意右侧端口是容器内部端口不要乱改。extra_hosts那行很多人不理解它的作用是让容器内部可以通过host.docker.internal这个域名访问宿主机上的服务。当你要让OpenClaw本地的Ollama模型或其他宿主机服务的时候这个配置能省掉很多麻烦。3.2 启动与验证mkdir -p ~/docker/openclaw/{config,data,logs} cd ~/docker/openclaw docker compose up -d上面命令执行后docker compose会先去拉取镜像这步的耗时取决于网络状况。镜像就绪后容器会自动启动通过docker ps可以看到openclaw这个容器处于Up状态。docker logs -f openclaw日志里如果出现类似Control UI is running at http://0.0.0.0:18000的提示说明控制台已经起来了。浏览器访问http://宿主机IP:18000就能看到OpenClaw的管理界面。第一次打开会要求做初始化配置主要是填写模型供应商的API Key、选择默认模型这些事。填完之后一个OpenClaw实例就算跑起来了。这一步看似简单实际上我第一次部署的时候在控制台初始化就卡住了因为默认配置里填的模型供应商跟我实际用的不一样一直报鉴权失败。所以这里提醒一下初始化时先把能配的都看完再保存别急着点确定。4. 第一次启动必踩的三个坑4.1 Control UI没有自动拉起热词里有个非常高频的报错叫openclaw control ui did not start我在多个版本上都遇到过。症状是容器已经启动成功了、日志输出也正常但访问18000端口就是连不上。排查思路要按顺序来。先看容器端口映射是否生效docker port openclaw如果端口映射正常再检查容器内部服务状态docker exec -it openclaw ps aux我遇到的一种情况是容器内的Control UI进程因为初始化检查未通过而退出但主进程没有跟着退出所以容器看起来还活着实际上管理界面已经死了。这种时候查看完整日志最有用docker logs --tail 100 openclaw如果是初始化检查未通过日志里会明确写出是哪一步卡住比如模型配置不完整、API Key格式不对等。按日志提示修好配置再重启容器就好。如果日志里没有任何异常但界面就是打不开可以试着把docker-compose.yml里端口映射改成宿主机其他端口比如18001:18000排除宿主机端口被防火墙拦截的可能。4.2 Agent启动时报unknown model热词里agent failed before reply: unknown model: deepseek这条我印象深刻因为我有一个朋友第一次部署就用这个模型做默认配置结果OpenClaw的Agent启动时直接拒绝响应。OpenClaw默认情况下并不把所有模型都视为已知如果环境变量里指定的模型名不在它的模型注册表里它就认不出来。解决办法分两步。第一步先去模型供应商的后台确认你要用的模型的准确标识符不同平台的命名规则不一样不能照着别人的配置抄。第二步在OpenClaw的环境变量或管理界面的Settings里把默认模型的标识符改成准确的那个。如果你用的是OpenRouter这种聚合网关模型名通常是vendor/model格式比如anthropic/claude-3.5-sonnet如果你用的是OpenAI官方API模型名一般是gpt-4o或gpt-4o-mini这类短名称。用错格式就会出现unknown model。还有一个小技巧是每次改完模型配置都重启一次容器再测试因为有些配置项的加载时机在启动阶段运行中改不会立即生效。4.3 容器反复重启另一个常见坑是docker ps显示容器状态为Restarting或者刚启动几秒就退出。这通常不是OpenClaw自己的问题而是启动时依赖的某个条件没满足。我的排查套路是先用docker logs openclaw看最近的错误信息再根据错误类型对症下药。比如我遇到过一种情况是容器的数据目录没有写权限导致启动时无法创建必要的子目录。修复方法很简单给卷映射的宿主机目录加写权限chmod -R 775 ~/docker/openclaw还有一次是配置文件格式写错了YAML的缩进出问题容器启动时直接解析失败。docker logs里会明确提示哪一行语法错误按提示修掉就行。如果日志里啥信息都没有就闪退试试前台运行模式docker compose 去掉-d参数让日志直接打到终端往往能捕捉到后台模式看不到的启动提示。5. 进阶配置让OpenClaw真正为你干活5.1 接入微信OpenClaw能接入微信这个特性是很多人选择它的核心原因。部署好之后要做的不是去代码里改什么而是通过环境变量把消息渠道切换到微信通道。通常做法是在docker-compose.yml的environment段里增加渠道相关配置。接入前的准备工作包括一个用于登录的微信号、确保网络能正常连接微信服务器。首次扫码登录后会出现二维码用微信扫一下OpenClaw就会以你的微信身份运行这样你在微信里收到AI回复时消息发送方看起来就是你自己。这里要说一个经验微信登录状态是存在持久化卷里的容器重启后大概率不用重新扫码但如果宿主机时间不对或者数据卷权限变了可能导致登录态失效。遇到这种情况删掉数据卷里的会话缓存文件再重启重新扫码就行。没有捷径老老实实扫码。5.2 配置本地模型跑推理热词里openclaw配置nvidia nim说明有不少人在探索用本地模型跑OpenClaw。NVIDIA NIM是NVIDIA推出的推理微服务可以把大模型封装成标准API。如果你有支持大显存的显卡用本地模型的好处是数据不出机器隐私性好而且没有API调用费用。做法也不复杂。先在你宿主机上部署好NVIDIA NIM的容器并确认API地址然后在OpenClaw的模型配置里把供应商指向这个本地API地址模型名填NIM里注册的模型标识符。由于OpenClaw跑在Docker里它访问宿主机上NIM的API时就需要用到我之前配置的host.docker.internal这个特殊域名。否则你填localhost的地址容器会去解析容器自身的localhost永远连不上宿主机。如果你的机器没有显卡只想用CPU跑一个体量较小的本地模型也能跑起来只是速度和效果会打折扣。我自己测过一个小参数量模型回复质量远不如云端大模型但胜在完全离线、完全私密。如果你对隐私不是那么敏感日常使用还是推荐云API省心又聪明。5.3 数据备份与迁移OpenClaw用久了会话历史、配置偏好、知识库这些数据会越来越值钱。这也就意味着数据备份必须提上日程。因为我把所有数据都映射到了宿主机目录备份就变得非常直接tar -czf openclaw_backup_$(date %F).tar.gz ~/docker/openclaw恢复的时候只要把数据目录解压回去再docker compose up -d启动容器一切都回来了。我有过几次迁移服务器的经历只要带着这份打包目录新机器上部署好Docker解压数据改一下配置里的域名和API KeyOpenClaw就原封不动地在新机器上复活了。最后再分享一个小技巧。如果容器日志显示一切正常但OpenClaw的响应速度越来越慢不用急着怀疑配置先看看是不是日志文件撑大了或者宿主机磁盘满了。docker system df这个命令能一眼看到各个容器的资源占用定期清理不用的镜像和日志文件是Docker长期稳定运行的基本功。OpenClaw这个项目迭代很快镜像版本更新也频繁每次更新前先看一下官方更新日志再决定要不要升级比盲目latest要好得多。本文还有配套的精品资源点击获取 Docker部署OpenClaw：环境准备、启动踩坑与本地模型配置
简介这是一份面向开发者与运维人员的Docker安装OpenClaw代码指南帮助在容器化环境中快速部署、配置和迭代AI系统OpenClaw。压缩包共8个文件涵盖Shell安装脚本、Dockerfile、docker-compose配置、JSON配置文件、Markdown说明文档等覆盖手动安装与Dockerfile构建两种安装方式适合测试开发与分享部署两类场景。全套资源仅12KB、轻量实用目前已有1340人学习。内容围绕基础镜像启动、OpenClaw安装、网关配置、插件冲突与网络排错展开同时提供了修改默认配置、模板化简化设置等镜像优化技巧读者可直接修改其中配置用于生产部署也可借此理解容器化部署的完整流程。借助Docker分层镜像与容器隔离特性还能轻松在不同OpenClaw版本间切换、快速回滚是进行版本管理和环境隔离的高效工具。适合需要快速搭建AI系统并掌握容器化部署实践的初中级开发者。 刚拿到这个部署需求的时候我第一反应是又要在宿主机上裝一堆Python依赖和Node环境了吧。OpenClaw这种个人AI助理项目裸机部署虽然可行但升级麻烦、环境容易互相污染换台机器更是噩梦。用Docker跑起来之后整个部署过程变成了拉镜像、起容器、开控制台三步前后不到十分钟比脚本安装干净得多。这篇就围绕Docker安装OpenClaw的完整链路来写从环境准备到镜像配置再到启动踩坑适合想在本地快速跑起一个AI Agent实例、又不想把系统搞得一团糟的人参考。1. 先搞清楚一件事为什么用Docker而不是直接跑官方脚本如果你去看OpenClaw的官方文档它默认推荐的安装方式其实是PowerShell一键脚本。脚本会把Python、Node、相关依赖全部装进系统目录然后启动一个常驻服务。这种方式对新手最友好但对长期使用的人来说有几个问题很难受。第一是环境隔离差。OpenClaw依赖的Python版本、Node版本和系统里其他项目经常打架今天升级一个包明天另一个项目就跑不起来了。第二是升级麻烦脚本升级往往要重新拉依赖装一半失败的话回滚会让你崩溃。第三是卸载不干净散落在各个目录里的配置文件和缓存手动清不仅费劲还容易漏。Docker方案把这些问题全包了。镜像里已经固化好了一整套运行时环境宿主机只需要有Docker Engine其他什么都不用装。升级就是替换镜像回滚就是切回旧镜像标签卸载就是删容器删镜像干干净净。我自己的服务器上同时跑着MySQL、Redis、Nginx和OpenClaw互相完全无感这就是容器化的价值。当然也不是所有场景都适合Docker。如果你打算对OpenClaw做深度二次开发需要在源码里加断点调试、频繁改Python包依赖那还是建议用源码方式跑因为容器里的文件系统是隔离的改起来不如宿主机顺手。我自己用Docker部署时遇到过一次需要给Python库打补丁的场景当时就后悔没直接源码跑。所以部署前先想清楚自己的需求边界。那我为什么最终推荐Docker因为对绝大多数人来说OpenClaw是一个要长期稳定运行的服务而不是一个开发中的项目。既然是服务就要用服务的方式去管理容器化恰恰是当前最成熟、最省心的服务化方式。你不需要理解OpenClaw内部怎么组织项目结构只需要知道这个容器会在18000端口提供一个管理界面、在8000端口提供API入口就够了剩下的交给Docker去管。2. 部署前的环境准备与两个容易翻车的细节在开始部署之前先把基础环境盘一遍。我的宿主机是一台8核16G的Ubuntu 22.04服务器这个配置跑OpenClaw非常宽裕。Windows用户如果是用Docker Desktop流程稍微不同但原理一样。2.1 Windows下Docker Desktop虚拟化检测失败热词里有一条docker desktop failed to start because virtualisation support wasnt detected我周围至少有三个朋友第一次安装时就撞上这个报错。Docker Desktop依赖Windows自带的虚拟化能力也就是Hyper-V或WSL2后端如果BIOS里没开启虚拟化或者Windows的虚拟机监控程序没启动它就会直接罢工。检查方法很简单。任务管理器切到性能标签页看底部有没有虚拟化已启用字样。如果是已禁用就进BIOS把Intel VT-x或AMD-V打开。如果BIOS已经开了但Docker还报错那就去启用或关闭Windows功能里确认Hyper-V和适用于Linux的Windows子系统这两个选项有没有勾上勾完后必须重启一次系统。顺带提醒一下Windows上装Docker Desktop属于Docker的GUI方案而Linux服务器上装的是Docker Engine这是两套东西。如果你的OpenClaw打算长期挂在服务器上跑最好直接用一台Linux机器性能更好也稳定得多。Windows的Docker Desktop适合本地跑着玩、开发调试真当生产环境用内存和资源的管理效率差点意思。2.2 镜像拉取慢的应急方案部署OpenClaw之前还有一个隐藏关卡镜像拉取。如果你在国内网络环境下直接docker pull大概率会看到进度条像蜗牛一样爬几百兆的镜像能拉半小时。这不是OpenClaw镜像独有的问题所有Docker Hub的官方镜像都这样。我的做法是配置镜像加速器。在/etc/docker/daemon.json里填上registry-mirrors地址然后重启Docker服务。注意不同服务商提供的加速地址时效性不一样有的过一段时间就失效了所以我会定期检查docker info里Registry Mirrors那一栏是否还在生效。还有一种更取巧的办法用代理环境变量给Docker守护进程走网络但这种方案我现在不推荐了一是配置麻烦二是稳定性看运气。老老实实配加速器才是正道。2.3 宿主机目录规划OpenClaw跑起来之后会产生不少持久化数据包括会话记录、日志、用户配置、模型API Key缓存等。如果容器删除时数据也一起消失那真的会让人崩溃。所以部署之前我先规划好数据目录~/docker/openclaw/config存放OpenClaw的配置文件~/docker/openclaw/data存放会话信息和状态数据~/docker/openclaw/logs存放运行日志这三个目录通过docker-compose的volumes卷映射挂载到容器内部这样无论容器怎么重建数据都在宿主机上稳稳躺着随时可以备份和迁移。这个习惯我建议所有用Docker跑服务的人都养成不要图省事用匿名卷否则某天docker-compose down -v一执行哭都来不及。3. 完整部署过程从空目录到控制台弹窗3.1 Docker Compose编排文件OpenClaw的部署推荐用docker-compose方式管理因为单条docker run命令参数太长尤其端口映射和数据卷一多记录、修改都不方便。所以我先建一个工作目录再写入docker-compose.yml。version: 3.8 services: openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - 18000:18000 - 8000:8000 environment: - TZAsia/Shanghai - OPENCLAW_API_KEYyour_secure_api_key_here - OPENCLAW_DATA_DIR/openclaw/data volumes: - ~/docker/openclaw/config:/openclaw/config - ~/docker/openclaw/data:/openclaw/data - ~/docker/openclaw/logs:/openclaw/logs extra_hosts: - host.docker.internal:host-gateway这个配置文件有几个关键点要解释一下。首先是镜像地址我用的是GitHub Container Registry的ghcr.io地址相比Docker Hub上的镜像这里跟踪官方发布节奏更及时。如果你所在网络环境访问ghcr.io也慢那就需要先把镜像拉到本地再导入前面说的加速器方案同样适用。其次是端口映射。OpenClaw的管理控制台默认监听18000端口API服务监听8000端口。如果宿主机上这两个端口已被占用冒号左侧的端口改成别的就行比如18001:18000浏览器访问时就用18001。注意右侧端口是容器内部端口不要乱改。extra_hosts那行很多人不理解它的作用是让容器内部可以通过host.docker.internal这个域名访问宿主机上的服务。当你要让OpenClaw本地的Ollama模型或其他宿主机服务的时候这个配置能省掉很多麻烦。3.2 启动与验证mkdir -p ~/docker/openclaw/{config,data,logs} cd ~/docker/openclaw docker compose up -d上面命令执行后docker compose会先去拉取镜像这步的耗时取决于网络状况。镜像就绪后容器会自动启动通过docker ps可以看到openclaw这个容器处于Up状态。docker logs -f openclaw日志里如果出现类似Control UI is running at http://0.0.0.0:18000的提示说明控制台已经起来了。浏览器访问http://宿主机IP:18000就能看到OpenClaw的管理界面。第一次打开会要求做初始化配置主要是填写模型供应商的API Key、选择默认模型这些事。填完之后一个OpenClaw实例就算跑起来了。这一步看似简单实际上我第一次部署的时候在控制台初始化就卡住了因为默认配置里填的模型供应商跟我实际用的不一样一直报鉴权失败。所以这里提醒一下初始化时先把能配的都看完再保存别急着点确定。4. 第一次启动必踩的三个坑4.1 Control UI没有自动拉起热词里有个非常高频的报错叫openclaw control ui did not start我在多个版本上都遇到过。症状是容器已经启动成功了、日志输出也正常但访问18000端口就是连不上。排查思路要按顺序来。先看容器端口映射是否生效docker port openclaw如果端口映射正常再检查容器内部服务状态docker exec -it openclaw ps aux我遇到的一种情况是容器内的Control UI进程因为初始化检查未通过而退出但主进程没有跟着退出所以容器看起来还活着实际上管理界面已经死了。这种时候查看完整日志最有用docker logs --tail 100 openclaw如果是初始化检查未通过日志里会明确写出是哪一步卡住比如模型配置不完整、API Key格式不对等。按日志提示修好配置再重启容器就好。如果日志里没有任何异常但界面就是打不开可以试着把docker-compose.yml里端口映射改成宿主机其他端口比如18001:18000排除宿主机端口被防火墙拦截的可能。4.2 Agent启动时报unknown model热词里agent failed before reply: unknown model: deepseek这条我印象深刻因为我有一个朋友第一次部署就用这个模型做默认配置结果OpenClaw的Agent启动时直接拒绝响应。OpenClaw默认情况下并不把所有模型都视为已知如果环境变量里指定的模型名不在它的模型注册表里它就认不出来。解决办法分两步。第一步先去模型供应商的后台确认你要用的模型的准确标识符不同平台的命名规则不一样不能照着别人的配置抄。第二步在OpenClaw的环境变量或管理界面的Settings里把默认模型的标识符改成准确的那个。如果你用的是OpenRouter这种聚合网关模型名通常是vendor/model格式比如anthropic/claude-3.5-sonnet如果你用的是OpenAI官方API模型名一般是gpt-4o或gpt-4o-mini这类短名称。用错格式就会出现unknown model。还有一个小技巧是每次改完模型配置都重启一次容器再测试因为有些配置项的加载时机在启动阶段运行中改不会立即生效。4.3 容器反复重启另一个常见坑是docker ps显示容器状态为Restarting或者刚启动几秒就退出。这通常不是OpenClaw自己的问题而是启动时依赖的某个条件没满足。我的排查套路是先用docker logs openclaw看最近的错误信息再根据错误类型对症下药。比如我遇到过一种情况是容器的数据目录没有写权限导致启动时无法创建必要的子目录。修复方法很简单给卷映射的宿主机目录加写权限chmod -R 775 ~/docker/openclaw还有一次是配置文件格式写错了YAML的缩进出问题容器启动时直接解析失败。docker logs里会明确提示哪一行语法错误按提示修掉就行。如果日志里啥信息都没有就闪退试试前台运行模式docker compose 去掉-d参数让日志直接打到终端往往能捕捉到后台模式看不到的启动提示。5. 进阶配置让OpenClaw真正为你干活5.1 接入微信OpenClaw能接入微信这个特性是很多人选择它的核心原因。部署好之后要做的不是去代码里改什么而是通过环境变量把消息渠道切换到微信通道。通常做法是在docker-compose.yml的environment段里增加渠道相关配置。接入前的准备工作包括一个用于登录的微信号、确保网络能正常连接微信服务器。首次扫码登录后会出现二维码用微信扫一下OpenClaw就会以你的微信身份运行这样你在微信里收到AI回复时消息发送方看起来就是你自己。这里要说一个经验微信登录状态是存在持久化卷里的容器重启后大概率不用重新扫码但如果宿主机时间不对或者数据卷权限变了可能导致登录态失效。遇到这种情况删掉数据卷里的会话缓存文件再重启重新扫码就行。没有捷径老老实实扫码。5.2 配置本地模型跑推理热词里openclaw配置nvidia nim说明有不少人在探索用本地模型跑OpenClaw。NVIDIA NIM是NVIDIA推出的推理微服务可以把大模型封装成标准API。如果你有支持大显存的显卡用本地模型的好处是数据不出机器隐私性好而且没有API调用费用。做法也不复杂。先在你宿主机上部署好NVIDIA NIM的容器并确认API地址然后在OpenClaw的模型配置里把供应商指向这个本地API地址模型名填NIM里注册的模型标识符。由于OpenClaw跑在Docker里它访问宿主机上NIM的API时就需要用到我之前配置的host.docker.internal这个特殊域名。否则你填localhost的地址容器会去解析容器自身的localhost永远连不上宿主机。如果你的机器没有显卡只想用CPU跑一个体量较小的本地模型也能跑起来只是速度和效果会打折扣。我自己测过一个小参数量模型回复质量远不如云端大模型但胜在完全离线、完全私密。如果你对隐私不是那么敏感日常使用还是推荐云API省心又聪明。5.3 数据备份与迁移OpenClaw用久了会话历史、配置偏好、知识库这些数据会越来越值钱。这也就意味着数据备份必须提上日程。因为我把所有数据都映射到了宿主机目录备份就变得非常直接tar -czf openclaw_backup_$(date %F).tar.gz ~/docker/openclaw恢复的时候只要把数据目录解压回去再docker compose up -d启动容器一切都回来了。我有过几次迁移服务器的经历只要带着这份打包目录新机器上部署好Docker解压数据改一下配置里的域名和API KeyOpenClaw就原封不动地在新机器上复活了。最后再分享一个小技巧。如果容器日志显示一切正常但OpenClaw的响应速度越来越慢不用急着怀疑配置先看看是不是日志文件撑大了或者宿主机磁盘满了。docker system df这个命令能一眼看到各个容器的资源占用定期清理不用的镜像和日志文件是Docker长期稳定运行的基本功。OpenClaw这个项目迭代很快镜像版本更新也频繁每次更新前先看一下官方更新日志再决定要不要升级比盲目latest要好得多。本文还有配套的精品资源点击获取