OpenClaw本地部署实战：从WSL2到飞书微信接入

前阵子同事让我帮忙找一个能自动整理消息、平时还能写周报摘要的机器人但重点是不想把聊天记录传到别人的服务器上。我想了一圈最后把目光落在 OpenClaw 上。这个项目在开发者圈子里热度涨得很快定位很直白跑在你自己设备上的开源个人 AI 助手。模型可以接本地部署的 Ollama也可以接各类兼容 OpenAI 接口的模型服务消息入口支持命令行、微信、飞书、Telegram 等常用渠道。核心逻辑不复杂所有消息先汇到一个中心AI 根据上下文和规则生成回复或者执行定时任务、调用本机工具。我花了一个晚上在 Windows 的 WSL2 环境里把它跑通之后又陆续折腾了微信接入、飞书机器人和本地大模型对接中间踩了不少坑。这篇指南不打算只罗列命令我会把每个关键选择背后的原因也讲清楚比如为什么推荐用 WSL2、为什么建议先把命令行跑通再碰消息渠道。适合三类人看准备自己部署 AI 助手的开发者、对数据隐私敏感的效率工具爱好者、以及想用开源模型驱动自动化流程但还不知道从哪入手的人。1. 为什么要把 AI 助手放在自己电脑上1.1 云端助手做不到的三件事现在很多人习惯用手机上的智能助手或者网页版 AI这类服务确实方便但有几个问题很难绕过去。第一是数据不透明你发出去的消息、上传的文件最终会流向哪里、会不会被拿去训练普通用户根本没法验证。第二是能力边界固定云端助手能做什么取决于平台开放了多少功能你想让它读一个特定文件夹、调用某个内部脚本基本做不到。第三是长期成本按 token 计费的服务用起来心里总有个疙瘩高频使用一个月下来不是小数目。OpenClaw 换了一种思路把助手本体做成开源程序跑在你自己的电脑或服务器上模型、数据、工具调用全都在你的控制范围内。它不是“又一个聊天机器人外壳”而是一个可以编程的智能体框架。举个我实际用的例子我让它每个工作日早上 9 点读取指定目录下的日报文件用本地模型生成摘要再通过飞书机器人发到部门群。这个流程在云端助手那边几乎没法实现但在 OpenClaw 里只是一个定时任务加一个脚本的事。1.2 OpenClaw 和 WorkBuddy 这类工具定位有什么不同很多人在选型时会拿 OpenClaw 和 WorkBuddy 这类助手类工具放在一起比。我自己的理解是WorkBuddy 这类产品更偏向企业协作场景强调的是开箱即用的团队助手能力界面、权限、审批流程都做得比较完整适合不太想动手、直接给团队用的场景。OpenClaw 不太一样它更像一个“助手的开发框架”核心价值在可编程、可扩展模型可以插拔渠道可以自定义你甚至可以改它的核心逻辑。这也意味着项目还比较年轻文档和社区生态都在快速变化中遇到问题常常要自己翻 issue。但反过来它的可玩性非常高技术能力强的用户能折腾出非常个性化的效果。如果你喜欢掌控感不介意偶尔自己动手排错OpenClaw 会更适合如果你只是想要一个开箱即用的工具那不妨先看看企业级的产品。1.3 本地部署就绝对安全吗必须泼一盆冷水本地部署不等于绝对安全。程序本身有漏洞的话暴露在公网的接口照样可能被攻击如果你给助手开放了读写文件、执行命令的权限那它本质上就是一个可以操作你电脑的程序。我给自己定的原则是最小权限。OpenClaw 能跑任务的账号用普通用户权限不直接给 root接入的渠道只开放必要的消息收发权限敏感目录不让它碰。安全这件事部署方式只是第一步后续的权限管理才是大头。2. 动手前准备环境WSL2、Docker 与系统要求2.1 硬件配置怎么定先说结论如果只是运行 OpenClaw 本体、模型走云端 API一台 4 核 8G 内存的小主机就够用。但如果你打算跑本地大模型硬件配置直接决定体验。使用场景CPU 要求内存要求说明仅运行 OpenClaw 本体 云端模型2 核4G 以上满足日常消息处理跑 7B 量化模型如 Qwen2.5 7B Q44 核16G基本可用回复稍慢跑 14B 以上模型8 核以上32G 以上体验较流畅建议加 GPU纯 CPU 推理 大上下文高频多核32G 以上速度仍然有限慎用“量化”这个词新手可能陌生通俗说就是把模型里的小数精度降低一点把体积压下来、推理速度提上去代价是输出质量轻微下降。Q4 量化是社区里很常见的实践7B 量化模型在 CPU 上也能跑只是速度看机器脸色。2.2 Windows 下把 WSL2 环境准备好在 Windows 上部署 OpenClaw最顺的路线是 WSL2 Ubuntu。WSL2 本质是一个轻量虚拟机和 Windows 系统集成得很好文件互通、命令互通比装双系统省事太多。安装命令在管理员 PowerShell 里执行wsl --install -d Ubuntu-22.04 wsl --set-default-version 2装完以后进入 Ubuntu 子系统先确认 systemd 有没有启用。这一步很关键OpenClaw 在 WSL2 里做环境校验时如果发现 systemd 没开会直接报出could not safely verify the WSL2 environment之类的错误。检查命令systemctl --version如果提示找不到 systemd需要手动开启。编辑/etc/wsl.conf加上下面两行[boot] systemdtrue保存后回到 Windows PowerShell 执行wsl --shutdown再重新进入 Ubuntu再看systemctl --version就能正常输出了。2.3 Linux 和 macOS 的部署差异如果你本来就用 Linux那最舒服裸机安装或者 Docker 安装都可以OpenClaw 对主流 Linux 发行版支持比较完整。macOS 用户也能跑Apple Silicon 芯片跑小模型有不错的性能但内存统一架构下大模型还是会吃紧建议先跑 7B 以下的量化模型。说实话我自己最推荐的运行环境还是 Linux 服务器或者 WSL2因为后续要跑长时间任务、定时调度Linux 的稳定性优势很明显。3. 部署 OpenClaw从安装到接入本地模型3.1 Docker Compose 方式和手工方式怎么选OpenClaw 的安装方式有几种最简单的是一键脚本但对环境假设多出问题了不好排查。我推荐 Docker Compose 方式原因很朴素所有依赖都在容器里配置写进一个 YAML 文件备份、迁移、回滚都很干净。一个典型的 Compose 配置长这样services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped volumes: - ./data:/data environment: - MODEL_PROVIDERollama - OLLAMA_BASE_URLhttp://host.docker.internal:11434 ports: - 3000:3000注意host.docker.internal是容器访问宿主机服务的专用地址因为我要让 OpenClaw 容器去连宿主机上跑的 Ollama。如果你用 Docker 里再套 Ollama 的方式要自己维护两个容器复杂度反而上去了。我用下来最省心的是Ollama 跑在宿主机OpenClaw 跑在容器里两边通过host.docker.internal通信互相不干扰。3.2 给 OpenClaw 接一个本地大模型以 Ollama 加千问为例本地模型选择很多我最早用的是 Qwen2.5 系列。原因是中文场景下它的表现扎实社区活跃权重在官方仓库和 ModelScope魔搭社区都有下载方便。部署 Ollama 和拉模型的命令curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b ollama run qwen2.5:7bollama run qwen2.5:7b如果能在终端直接对话说明模型服务正常。然后在 OpenClaw 的配置文件里指定模型来源类似这样model: provider: ollama base_url: http://localhost:11434/v1 model_name: qwen2.5:7b temperature: 0.7这里base_url之所以是http://localhost:11434/v1是因为 Ollama 提供了 OpenAI 兼容的接口OpenClaw 按 OpenAI 协议访问就能通。如果不想用 Ollama任何兼容 OpenAI 接口的服务都可以把provider改成对应的名字、填上 key 和接口地址就行。3.3 先把命令行模式跑通再说我见过很多人一上来就想让助手在微信里回复结果折腾三天还在原地。我的建议永远是把命令行模式先跑通。OpenClaw 启动后直接开一个终端聊天测试openclaw --headless openclaw chat 你好介绍一下你自己如果它正常回复说明整套链路——程序本体、模型服务、配置——都通了。这时候再接渠道如果出问题至少知道不是模型层的锅。这个先后顺序能帮你省下大量排查时间。4. 渠道接入实操让 AI 在微信、飞书里值班4.1 Channel 是什么以及 agent 怎么选择 ChannelOpenClaw 里把每个消息入口叫做 channel。简单理解就是“前台接线员”微信 channel 负责收微信消息飞书 channel 负责收飞书消息但背后的智能体逻辑是同一套。你可以在配置里同时启用多个 channel消息进来以后OpenClaw 会把信息来源、会话 ID、消息内容一起打包给 agentagent 根据规则决定怎么回复。有人问 agent 怎么选择 channel其实不是 agent 在选择而是你配置了哪些 channelagent 就能从哪些 channel 收消息、往哪些 channel 发消息。比如你只想让它在飞书里跟同事互动那就只启用飞书 channel微信那边配置不加上就行。4.2 飞书接入机器人配置和输出截断问题飞书接入算是几个渠道里比较顺的。到飞书开放平台创建一个企业自建应用开启机器人能力拿 App ID 和 App Secret再把事件订阅地址填到 OpenClaw 提供的回调地址上。配置项大致是这样channels: feishu: enabled: true app_id: your_app_id app_secret: your_app_secret这里有一个高频坑飞书单条消息长度有限制而大模型的输出经常超长结果就是“OpenClaw 在飞书输出容易被截断”。我实际测下来解决方案有三条路可以走。第一限制模型输出的max_tokens控制在平台允许范围内第二在 OpenClaw 侧开启长文本自动拆分让它把一次回复拆成多条普通消息发出第三如果内容确实很长可以让 agent 把内容生成到文档里再往聊天窗口发一个文档链接。我最常用的是第二种方式体验最接近正常对话。4.3 微信接入能发不能收的排查思路微信是大家问得最多的渠道但也是限制最多的渠道。先提醒一句个人微信的自动化协议存在封号风险我不建议在常用微信号上折腾。如果你是企业用户优先考虑企业微信或者小程序 webhook 的方式合规性更好。实际遇到“OpenClaw 能发消息到微信但微信发消息没回复”问题基本出在收消息这条链路。常见原因有三个一是消息回调地址没配对平台推送不到 OpenClaw二是同样的会话被另一个进程锁住了也就是后面要讲的 session 锁问题三是模型回复太慢平台等不到响应直接超时。排查顺序建议先看 OpenClaw 日志确认有没有收到平台的推送再看模型侧到底花了多久才生成回复。5. 高频报错排查实录5.1 核心报错速查表我把部署和日常使用中常遇到的几个报错整理成了一张表先对号入座再往下看详细处理方式。报错信息含义解决思路could not safely verify the WSL2 environment环境校验不通过开启 WSL2 的 systemd 支持重启 WSLagent failed before reply: session file locked (timeout 60000ms)会话文件被锁停掉多余进程删除 session 锁文件agent failed before reply模型侧调用失败检查模型服务状态、接口地址、API key飞书输出被截断消息长度超限调整 max_tokens、开启自动拆分微信能发不能收回调链路异常检查回调配置、session 锁、模型响应时间5.2 session file locked 是怎么来的怎么解除这个报错我踩得最深。OpenClaw 为了维护对话上下文会把每个会话的状态写到本地文件里同时用一个锁机制保证同一时刻只有一个 agent 进程能写这个文件避免上下文错乱。如果你开了一个交互式进程又同时让后台服务去跑同一个会话就会发生互抢后到的那个直接超时失败。解决办法分三步。第一步查当前有哪些 OpenClaw 进程ps aux | grep openclaw第二步把多余的进程停掉只保留你想用的那个。第三步如果确定没有别的进程在占用但报错还在可以手动清理锁文件rm -f ~/.openclaw/sessions/*.lock清理完重新启动基本就恢复了。我的个人经验是平时用后台服务模式跑不要频繁开交互式终端去操作同一个会话能避开一大半这类问题。5.3 WSL2 环境校验失败的三种修正方式could not safely verify the WSL2 environment看着吓人其实就是环境检测没过。按优先级试三个办法。第一检查前面说的/etc/wsl.conf里有没有systemdtrue没有就补上然后wsl --shutdown再重进。第二检查 WSL 内核版本是不是太老在 Windows PowerShell 里执行wsl --update这是官方命令把内核更新到最新。第三如果你用的是精简版 WSL 镜像缺了很多基础组件建议直接重新装一个 Ubuntu 22.04 发行版一了百了。5.4 消息延迟和丢失怎么从日志里定位渠道层的消息问题不要靠猜打开日志看链路。OpenClaw 的日志会记录三个阶段是否收到了渠道推送的消息、agent 是否成功生成了回复、回复是否成功发送回渠道。你可以调高日志级别把细节打出来openclaw logs --level debug然后从飞书或微信里发一条测试消息看日志停在哪一步。如果第一步就没输出问题在平台回调配置如果第二步卡住问题在模型如果第三步失败问题在渠道凭证或者发送接口。分阶段排查效率最高。6. 进阶玩法把 OpenClaw 变成自动化中枢6.1 定时任务让助手每天主动汇报OpenClaw 不只是被动等人发消息它支持配置定时任务。我自己最常用的场景是每天早上 9 点让它扫描固定的日报目录、汇总关键信息、生成摘要发到飞书群里。配置起来就是一个 cron 表达式加一个任务描述类似这样schedules: - cron: 0 9 * * * prompt: 读取 /home/user/reports 目录下最近的日报生成一份简洁的摘要并发到默认飞书群这里比较关键的是 prompt 要写得具体。模糊的任务描述模型发挥空间太大结果常常不是你想要的。我一开始只写了“汇总日报”结果它把目录下所有文件读了一遍摘要比原文还长。后来改成“提取核心进展、阻塞问题、明日计划三项总计不超过 300 字”输出一下就正常了。6.2 长期记忆让 AI 记住你的偏好智能体和普通聊天机器人的一大区别就是能不能跨对话记住东西。OpenClaw 本身有记忆机制可以把对话中的关键信息抽出来存成记忆下次相关话题直接引用。开启方法就是在配置里允许记忆功能然后用对话告诉它“记住我的偏好周报用中文语气正式”。但这里要特别提醒记忆是把双刃剑。既然它记住了你的偏好也可能记住你不希望被记住的东西。我个人建议在记忆功能里加一个过滤规则包含“密码”“token”“合同”等关键词的内容不入库。别嫌麻烦等出了问题再后悔就晚了。6.3 多模型配合小模型跑高频、大模型攻难点很多部署了本地模型的人会陷入一个误区要么一个大模型走天下要么全用云端 API。OpenClaw 支持多模型配置我现在的方案是分级调用用最小的模型做关键词分拣和意图判断日常聊天和简单任务用 7B 模型遇到复杂推理需求再动态切换到更大的模型或云端 API。这么做的原因很实在小模型跑得快、省资源高频简单任务用它最划算复杂任务交给大模型能保证质量。代价是配置复杂了一些需要提前想好判定规则比如当用户消息里包含“分析”“总结”“对比”这些词时调用大模型。实际用下来这个“大小模型协同”的思路能把整个系统的响应速度和成本控制在一个很舒服的区间。6.4 扩展能力插件和脚本OpenClaw 最有想象力的部分是你可以给它写插件让它调用本机工具。比如我写过一个简单的 Python 插件用来读取本地的网络设备监控接口把状态异常的设备列表返回给模型模型再组织成自然语言回复。这类插件本质上是给智能体装上了一双“手”。写一个插件的门槛不高核心就是注册一个可以执行的动作并定义输入输出。OpenClaw 负责把消息和参数传给插件插件执行完以后把结果回传给模型。这种模式下AI 不再只是“动嘴”它能真正操作你电脑上的软件、脚本、命令行自动化上限一下子拉高了很多。如果你对编程还不太熟也可以先从调用现成命令行工具开始把curl、date、awk这些命令封装成插件效果同样可观。最后说一点这段时间折腾下来的感受。OpenClaw 真正让我满意的不是某一个功能而是它把“助手”做成了开源、可拆、能编程的积木组合。我踩过最大的坑就是一开始太心急跳过命令行直接去接微信结果渠道和模型的问题搅在一起前前后后花了好几天。后来老老实实把命令行跑通再从飞书到微信逐步接入整个流程反而异常顺利。这篇文章里的顺序就是按“先模型、再渠道、后进阶”这条线安排的照着走能帮你省掉很多弯路。后续我还打算接着折腾多用户权限隔离和更细粒度的插件管理到时候有新经验再回来补一篇。