老读者应该知道Openclaw这个开源AI智能体项目我从第一版就开始跟了。前面两章分别聊了基础概念和首次部署跑通今天把第3章补上专门讲进阶部署。这一章的核心内容都是实际部署和长期使用中绕不开的环节环境方案怎么选、模型后端怎么接、技能怎么扩展、IM和工作流怎么打通、权限审批和一票报错怎么处理。目标读者是已经在本地跑过基础版、准备把Openclaw当日常生产力工具来用的朋友。如果你只是刚接触也能从这里把部署的底层逻辑看明白少走很多弯路。先说清楚这一篇默认你已经有能力完成基础安装也就是拉代码、装依赖、跑起一个能对话的Openclaw实例。这一章要解决的是从“能跑”到“跑得稳、接得广、用得好”的中间地带。1. 部署方式怎么选Windows、WSL还是纯Linux服务器1.1 三种环境的取舍逻辑Openclaw本身是个Node.js项目理论上跨平台但实际部署时环境差异非常大。我三种环境都试过一段时间结论很明确如果只是个人电脑上用优先WSL2如果是团队或者长期对外服务直接上Linux服务器Windows原生只适合快速体验不适合长期跑。为什么Windows原生不推荐核心问题出在工具链和文件权限上。Openclaw会频繁操作工作目录、调用外部进程、执行脚本审批Windows的路径分隔符和权限模型跟Linux差异太大很多场景会卡在莫名其妙的地方。典型的就是PowerShell里执行openclaw命令提示“无法将‘openclaw’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这个报错在Windows环境里极其常见特别容易劝退新手。WSL2方案则聪明很多。它在Windows上开了一个完整的Linux内核Node.js、Python、Docker这些工具链跟生产环境完全一致性能损耗很小文件访问也比第一代WSL强得多。我现在的做法是Windows负责日常办公WSL2里面跑Openclaw两边互不干扰文件通过\\wsl$\路径互通体验很顺。纯Linux服务器则是另一个逻辑。它解决的是“7x24小时稳定运行”的问题不依赖个人电脑是否开机、是否休眠。适合把Openclaw接成团队服务、做了IM机器人、或者跑自动化任务队列的场景。成本无非是一台云主机部署方式跟WSL2里几乎一样迁移成本很低。1.2 目录规划与版本管理环境定下来之后下一步是目录和版本。Openclaw默认把工作数据放在~/.openclaw/里面至少有几类东西配置文件、workspace工作区、exec-approvals.json审批记录、日志、skill目录。这个目录结构在Windows下对应的是C:\Users\Administrator\.openclaw\在Linux和WSL下则是/root/.openclaw/或/home/用户名/.openclaw/。很多人忽略了一点这个目录就是整个Openclaw的“家”备份、迁移、多实例部署都围绕它展开。我建议从第一天起就把~/.openclaw/纳入Git管理起码把配置文件和skill目录管起来。workspace和日志可以忽略但配置和技能代码必须版本化。openclaw本身迭代很快热词里已经能看到openclaw 2.0的讨论。升级前先看一眼官方更新日志确认breaking changes然后备份整个.openclaw目录。这个操作30秒搞定但能救回一整个下午。2. 模型后端接入云端API、本地Ollama和NVIDIA NIM三条路2.1 NVIDIA NIM的配置过程热词里有“openclaw配置nvidia nim”这确实是进阶部署里很有价值的一环。NIM是NVIDIA推出的推理微服务架构它不是单一模型而是一套把模型封装成API服务的方式底层跑的通常是Llama、Qwen这类开源模型的NVIDIA优化版本GPU推理效率比裸跑模型要稳不少。配置NIM前得先说明白两个东西。第一NIM需要NVIDIA的API Key如果你是在英伟达的云服务上跑直接在NGC官网申请即可如果是在自己的GPU服务器上部署NIM容器那还要先拉镜像、起容器Openclaw这边只负责对接API地址。第二NIM对GPU有要求普通CPU机器跑不起来别在这上面浪费时间。Openclaw配置NIM的常见做法是改环境变量。基本逻辑是设置模型服务的地址、模型名、API Key这三要素export OPENCLAW_MODEL_BASE_URLhttps://integrate.api.nvidia.com/v1 export OPENCLAW_MODEL_NAMEnvidia/llama-3.1-nemotron-70b-instruct export OPENCLAW_API_KEY你的NVIDIA API Key设置完之后重启Openclaw让它重新加载配置。跑起来之后可以在对话里问它“你当前使用的是什么模型”如果正常返回模型名说明NIM路由已生效。这个配置思路和接OpenAI的API几乎一致因为NIM对外暴露的是OpenAI兼容接口Openclaw这类工具对接成本很低。实际体验下来NIM路线适合对推理质量有要求、本身又有NVIDIA GPU环境的用户。如果手里只有普通电脑或者纯CPU服务器更实际的路线是下面这个。2.2 本地Ollama的模型选择与Skill安装要点热词里“openclaw使用本地ollama如何安装skill”是很多人搜的点。Ollama解决的是“不想把对话数据发到云端”的诉求模型跑在本地隐私性拉满不花钱但代价是模型能力受限于硬件。Openclaw接Ollama的配置相当简单export OPENCLAW_MODEL_BASE_URLhttp://localhost:11434/v1 export OPENCLAW_MODEL_NAMEqwen2.5:14bOllama默认端口是11434同时也暴露了OpenAI兼容的/v1接口所以Openclaw这边不需要额外插件。模型名看你本地Ollama拉了什么模型想稳一点就qwen2.5系列显存大可以考虑更大参数的。真正容易出问题的是Skill的安装位置。Ollama本身不是技能系统Openclaw的Skill指的是它的技能插件默认放在~/.openclaw/skills/下。安装skill有几种方式从Openclaw的技能市场直接安装配置里通过指令触发手动下载skill压缩包解压到~/.openclaw/skills/目录重启生效自己在skills目录下手写一个skill的SKILL.md定义文件用Ollama本地模型时skill不宜装太多。本地模型的指令跟随能力比云端大模型弱一截skills一多它反而容易不知所措。我的经验是最多保留五六个核心的比如网页抓取、文件整理、定时任务这种其他的用到再临时装。2.3 自定义API服务网关的编排逻辑热词里“openclaw自定义中转站”这个话题我必须专门拎出来说。很多人理解的中转站是解决“网络不通”的问题这个我不展开讨论也不建议碰。但“自定义API服务网关”本身是个正当需求尤其在企业内部和团队协作场景下特别实用。真实场景是这样的团队里多个人用Openclaw每个人都要配各自的API Key模型渠道还不一样有人用A厂商的有人用B厂商的月底对账很痛苦。这时候你把Openclaw的请求统一指向一个内部API网关由网关做三家模型服务的路由、密钥管理和用量统计Openclaw这边只认网关的地址。这是很典型的工程化做法。Openclaw端只需改环境变量指定网关的base URL和key网关负责把请求分发到真正的模型服务去。这种方式的价值在于把“模型供应商切换”从“改每一台机器的配置”变成了“改网关一处配置”。以后换模型、加渠道、调整价格策略都跟终端用户无关运维成本肉眼可见地降。3. 技能扩展与工具调用Skill和CAU Computer的正确姿势3.1 Skill安装与开发的完整流程Skill是Openclaw能力扩展的核心机制相当于给智能体装“新技能”。一次完整的skill安装流程应该是先确认skill的依赖环境是否已安装再放进skills目录最后重启并测试。比如你要装一个PDF解析的skill看起来只是搬运几个文件实际上它可能依赖Python的pdfplumber库。不装好依赖skill加载时报错你都不知道去哪排查。我的建议是每个skill都要有一套自己的依赖说明装之前先看README装完立刻用测试样本跑一遍。开发自定义skill也没那么玄乎。一个最简单的skill其实就是SKILL.md里写清楚这个技能的名称、触发条件、执行步骤再配一个可执行的脚本。Openclaw的调度器会在大模型生成回复时根据用户意图匹配skill把控制权交给skill脚本执行。本质上是“大模型负责理解意图脚本负责精确动作”的分工。3.2 CAU Computer怎么设置才不翻车热词里有“openclaw的cau computer如何设置”CAU Computer指的是让Openclaw直接操控电脑的能力配置项比如模拟键鼠操作、读取屏幕、操作应用程序。这是Openclaw进阶能力里风险最高的模块因为一旦放开权限AI就能在你的电脑上“动手”了。怎么设置才安全我总结了三层控制。第一层设备权限。CAU Computer默认读取当前机器上可用的显示设备和输入设备你可以通过配置限定它只能操作某个虚拟显示器或特定窗口而不是整台机器。第二层审批控制。涉及实际操作的命令必须经过exec-approvals机制确认这一层绝不能跳过。第三层白名单目录。Openclaw的工作区默认限制在workspace目录内CAU功能的文件读写也要遵循这个边界防止它跑到系统目录里乱动。实操上第一次启用CAU Computer建议先在测试环境虚拟机或备用机里跑通确认它不会乱点鼠标键盘之后再放到主力机上。我自己第一次测试时它就出现过误操作——本来只想让它打开记事本结果它连着打开了计算器和画图板。问题不大但放在生产环境就是事故。3.3 组合Skill实现一个工作流示例单个skill能做的事有限真正的价值在组合。我举一个自己日常在用的例子每天早上9点Openclaw自动抓取几个行业新闻源去除重复内容筛选与我关注的技术栈相关的条目生成一份摘要通过飞书机器人推送到团队群里。这个流程拆下来涉及新闻抓取skill、文本处理skill、飞书通知skill再加上一个定时触发器。单看每个环节都很简单但组合在一起就是一个能省半小时的自动化流程。设置这类工作流时建议先手动触发一次跑通全流程再配置定时执行。不要一上来就全自动否则某个环节出错你还要花时间去翻日志找原因。4. 外部生态接入微信、飞书与内部工作流集成4.1 微信接入的配置路径把Openclaw接进微信是很多人的刚需毕竟微信是日常沟通的主阵地。Openclaw做微信接入的思路不是做一个开挂机器人去轰炸群聊而是做一个“私人助理”在私聊或特定场景下呼应你的指令。热词里专门有“openclaw微信”可见需求量大。微信接入的典型做法是借用个人微信的自动化能力通过HOOK或者模拟客户端方式让Openclaw能收发消息。但这里必须提醒一句个人微信的自动化操作有账号风控风险轻则限制功能重则封号。如果只是自己小范围测试问题不大如果要长期使用我更建议用企业微信的API或者公众号后台接入合规且稳定。配置过程大体几步先确认你的Openclaw实例能通过公网地址被访问到再在Openclaw的配置里开启微信通道绑定要监听的微信消息格式和响应策略。测试时发一条“开场白”消息确认机器人能回复然后逐步增加指令类型。4.2 飞书接入与Openclaw和Codex的定位差异热词里同时出现“openclaw接入飞书”和“openclaw与codex”我先说接入再说定位差异。飞书接入比微信更顺滑因为飞书开放平台本身就是为企业协作设计的机器人API完善官方支持Webhook机器人。把Openclaw接入飞书的步骤是在飞书开放平台创建一个应用拿到App ID和App Secret配置事件订阅地址为Openclaw的webhook端点然后把消息权限配上让机器人能接收和发送群消息。配置完记得做权限申请飞书的权限粒度很细收消息、发消息、上传文件都是不同的权限点。漏掉任何一个都会导致功能异常。至于Openclaw和Codex的对比它们其实不在一个赛道上。Codex更像一个编码助手专注在代码生成和仓库交互上Openclaw是一个通用智能体框架强调跟环境交互、调用外部工具、执行多步骤任务。你可以把Codex看作Openclaw的“技能之一”——Openclaw完全可以调用Codex API做代码生成但Openclaw的定位是更大的“数字管家”。4.3 通过Webhook和API集成内部工作流IM接入只是外部生态的入口真正让Openclaw发挥价值的是把它接进内部工作流。比如给它一个webhook地址让它收到特定消息后自动创建工单或者通过API让Openclaw读取内部数据库定时生成报表。实现这类集成时我建议优先用Webhook收口让Openclaw像一个通用消息中枢。业务系统只管往webhook推送事件Openclaw负责理解事件并触发后续动作。这种方式耦合度低业务系统不需要依赖Openclaw的SDK出问题也好排查。5. 权限、审批与故障排查实录5.1 exec-approvals.json的读法与审批流热词里有一串报错关键字“legacy exec approvals exist at /root/.openclaw/exec-approvals.json. runope”。这个提示通常在Openclaw启动时出现意思是检测到了旧版本的审批记录文件官方建议你跑一条命令来处理。exec-approvals.json这个文件记录的是“哪些命令被允许在机器上执行”的审批列表。Openclaw出于安全考虑凡是执行可能产生副作用的命令都会先写进这个审批文件等用户确认。这不是bug是安全机制。当启动时提示legacy exec approvals时正确的处理方式是查看文件内容cat /root/.openclaw/exec-approvals.json然后根据提示执行官方给出的迁移命令通常是把旧文件的格式升级成新版本或者备份后重置。千万不要图省事直接删掉这个文件。因为里面可能记录了关键的审批项贸然删除会导致很多之前放行的操作重新要求审批打断正在运行的自动化流程。我在生产环境踩过一次坑升级Openclaw版本后启动时报这个提示我没细看文件内容就直接备份覆盖结果第二天好几个定时任务跑不动全是权限审批被卡住。后来花了半个下午逐个重新审批。血的教训。5.2 干净卸载与重装的正确姿势热词里有人搜“openclaw卸载”看着冷门其实是每个用过的人都会遇到的问题。Openclaw卸载的坑点在于它不是单一的软件包而是由程序本体、依赖环境、配置文件、skill、工作区数据共同组成。只删掉程序残留文件还是会占用空间甚至导致重装后配置冲突。我的建议卸载顺序是先把配置文件备份一份然后停掉所有Openclaw进程再删除程序安装目录和~/.openclaw目录最后清理npm全局链接或pip包。装回时要确保之前的关联组件也一并清干净避免新旧版本混在一起。如果你是在Docker里部署的卸载就简单多了删容器、删镜像、删挂载卷。Docker部署本来就在隔离性上有天然优势这也是为什么我建议生产环境优先考虑容器化。5.3 常见报错与解决思路速查把这段时间遇到的高频报错整理成一张表方便对照排查报错特征可能原因解决思路无法将“openclaw”项识别为cmdletWindows下npm全局路径未加入PATH找到npm全局目录手动加入系统环境变量exec-approvals.json legacy提示版本升级导致审批文件格式过旧查看文件内容执行官方迁移命令切勿直接删CUDA相关报错模型后端依赖GPU环境异常确认NVIDIA驱动和CUDA版本匹配尝试CPU模式兜底Ollama连接失败本地模型服务未启动或端口不通检查11434端口curl localhost:11434测试连通性skill加载失败技能依赖的组件缺失查看skill的README补齐依赖后重启Docker容器启动后无日志输出挂载卷权限不足给挂载目录加写权限或用--user指定用户这张表不是全量排查手册但覆盖了新手和进阶用户最常撞上的墙。核心思路是先确认环境再查配置文件最后看日志。不要一上来就无脑重装。5.4 openclaw部署到Ubuntu时CUDA环境的坑热词里有一条“ubuntu2204 cuda openclaw”指向Ubuntu 22.04上同时装CUDA和Openclaw的场景。这类环境坑点一般不在Openclaw本身而是CUDA和驱动不匹配。Ubuntu 22.04默认源里的NVIDIA驱动版本一般比较保守而你手头的CUDA工具包可能需要更新的驱动。装完之后nvidia-smi显示正常但跑模型时照样报CUDA初始化失败。这类问题我的排查思路是分三层第一层是驱动本身能否被系统识别第二层是CUDA版本跟驱动是否兼容第三层是Openclaw调用的是CUDA还是ROCm。如果第三层都没问题但前后端就是连不上极有可能是权限问题——Openclaw进程没有访问GPU设备的权限。在容器里部署的尤其常见启动容器时忘了加--gpus all参数GPU资源根本没映射进去。最后一件事长期维护的几条建议文章写到最后不做什么宏大总结了就分享三点掏心窝的经验。第一配置文件的版本管理一定要做。Openclaw这类工具迭代快、可配置项多你永远不知道哪个配置项会在下一次升级中改变语义。把.openclaw目录里的配置和skill纳入Git管理后升级出问题可以秒回滚新机器部署也只需要拉代码。第二日志要养成定期查看的习惯。Openclaw跑得越是顺手越容易忘记它背后在那一堆进程里执行什么。定时翻翻日志能提前发现异常避免某天突然发现定时任务已经三天没跑了。第三生产环境务必用Docker或者systemd托管。不要用nohup挂着就以为万事大吉进程挂了没人知道机器重启了服务起不来也没人知道。用systemd加个自动重启策略设置日志轮转这套东西花不了多少时间但能让你真正睡个安稳觉。Openclaw是个值得长期跟的工具但工具始终是工具能不能稳定地融入工作流靠的还是部署时的工程化程度。希望这篇进阶部署的经验对你有用后续如果官方出了大的架构调整我们下一篇再聊。
