大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



如果你想在 Windows 电脑上，把 OpenClaw 稳定跑起来，并最终接入飞书，这篇就是一条尽量少踩坑的完整路线。

本文只讲一条经过实践验证、适合大多数人的方案：

1. Windows 11 只负责宿主系统
2. WSL2 Ubuntu 作为唯一安装环境
3. 在 WSL2 里安装并运行 OpenClaw
4. 接入 OpenAI 兼容模型接口
5. 最后再接入飞书机器人

很多教程的问题不在于“命令错了”，而在于把所有事情一次性混在一起做。结果就是：看起来很快，出问题时完全没法排查。

如果你时间有限，只记住下面这条路线就够了：

1. 先检查 Windows 和 WSL2 是否正常
2. 不要在原生 Windows 里长期跑 OpenClaw
3. 进入 WSL2 Ubuntu，在 Linux 主目录下操作
4. 确保 WSL 里的 Node.js 版本是 22 或更高
5. 用官方安装脚本安装 OpenClaw
6. 先跑通 Gateway 和 Dashboard
7. 再接模型
8. 最后接飞书
9. 飞书先验证私聊，再考虑群聊

这条路线的核心原则只有一句话：

一次只解决一个问题。

这是很多人最容易忽略的一步。

表面上看，OpenClaw 是 Node 项目，Windows 里装个 Node 似乎就能跑。但实际部署时，原生 Windows 环境经常会遇到这些问题：

• 全局安装路径混乱
• 和 指向的不是同一个版本
• PATH 被多个工具改乱
• 某些插件、脚本、服务行为更偏向 Linux 环境
• Gateway、插件、Skills、systemd 的运行体验不一致

所以官方现在更推荐 Windows 用户通过 WSL2 来运行 OpenClaw。原因很简单：

• OpenClaw 的运行环境更接近 Linux
• 兼容性更稳定
• 排查问题时，和官方文档、社区经验更一致

不是不能装，而是不稳。

你当然可能一次装成功，但只要后面出现下面任意一种情况，排查成本就会明显上升：

• 全局命令安装了，但执行不到
• 安装脚本能跑，服务却起不来
• Dashboard 能开，插件不能用
• 模型能配，飞书接不上

如果你想的是“先用最容易复现、最接近官方推荐的方式跑通”，那 WSL2 是更稳的选择。

这篇文章适合以下几类人：

• 想在 Windows 上本地部署 OpenClaw 的用户
• 不希望被环境问题反复折腾的人
• 希望接入 OpenAI 兼容模型接口的人
• 希望把机器人接到飞书里的人
• 对 Linux 和命令行不太熟，但愿意按步骤执行的人

如果你已经是熟练 Linux 用户，也可以直接把这篇当成一份“避坑版部署清单”。

---

这一步的目的不是“形式上看一眼”，而是尽量把后面的冲突提前发现。

先在 PowerShell 里执行：

下面这些结果，说明环境基本可以继续：

• 有输出
• 有输出
• 有输出
• 找不到也没关系，说明还没装
• 返回 最干净
• 端口没有被占用
• 显示默认版本是 2

因为很多安装失败，不是 OpenClaw 本身的问题，而是旧环境残留导致的，比如：

• 老版本配置文件还在
• 端口已经被别的进程占用
• 你以为自己在用新 Node，实际命中的是旧路径
• WSL 根本没启用，后面所有步骤都会偏掉

---

在 PowerShell 中输入：

进入 Ubuntu 后，先执行：

正常应该看到类似：

然后检查 WSL 里的 Node、npm、Git：

最典型的是：

• 全局包安装成功，但命令入口没生成
• PATH 指向异常
• 、代理、权限被 Windows 环境干扰

一句话概括：

在 WSL 里干活，就尽量像在 Linux 机器上一样干活。

---

安装后验证：

如果你的目标是“先稳定跑通 OpenClaw”，用成熟仓库直接装一个足够新的 Node，往往更省事。

---

如果你在 WSL 里遇到下面这些现象：

• 一直失败
• 拉不到版本
• 明明命令没错，但网络请求就是不通

优先怀疑 DNS，而不是怀疑 OpenClaw。

如果你在 里看到：

这通常意味着 WSL 没有按默认方式帮你生成 DNS 配置。

把 调整为更简单、接近默认的配置。比如只保留：

然后删除旧的 DNS 文件：

退出 WSL 后，回到 PowerShell 执行：

重新进入 WSL，再测试：

如果返回 、 或 一类响应，说明 DNS 基本恢复。

因为安装脚本、npm 拉包、插件安装、模型调用、飞书连接，本质上都依赖网络。

如果 DNS 本身就坏了，你后面看到的一切报错都可能只是“表面现象”：

• 安装脚本下载失败
• npm 拉不到包
• 插件装不全
• 模型接口不可达
• 飞书长连接异常

先把网络打通，是为了避免后面在错误方向上浪费时间。

---

确认 WSL 和 Node 环境正常后，再执行官方推荐安装命令：

这条命令会按官方推荐方式安装 CLI，并进入初始化流程。

原因很实际：

• 路径标准
• 初始化流程更完整
• 后续和官方文档更一致
• 出问题时更容易对照排查

实际部署里，安装变慢最常见的原因不是命令错了，而是：

• npm 拉包慢
• 某些大依赖下载慢
• 网络抖动
• 镜像源响应速度不稳定

你可以先检查当前 npm 源和连通性：

如果你所在网络环境下官方源明显更慢，可以临时切换：

正确做法不是迷信某个源，而是：

1. 先测
2. 再切
3. 观察是否真的改善

---

安装完成后，通常会进入首次交互式配置。

如果你是第一次部署，推荐这样选：

这是整篇文章里最关键的思路之一。

因为一旦失败，你根本不知道问题出在哪一层：

• 安装没完成？
• Gateway 没起来？
• 配置文件有问题？
• 模型没通？
• 飞书权限没开？

先把 OpenClaw 本体跑起来，再逐层叠加能力，才是最省时间的办法。

因为初次部署的目标不是“功能全开”，而是“拿到一个明确可验证的成功状态”。

对 OpenClaw 来说，这个成功状态应该是：

• CLI 可用
• Gateway 可用
• Dashboard 可打开
• TUI 可进入

只要这几项成立，说明底座已经稳了。

---

在 WSL 里，QuickStart 有时会在启用 Gateway 服务时出现 相关报错。

这类报错常见，但不一定意味着安装失败。

先看 OpenClaw 是否已经安装成功：

再看用户级 systemd 是否正常：

如果 systemd 本身是正常的，再执行：

然后继续：

你希望看到类似：

先确认“程序装没装好”，再确认“服务有没有起来”，这是两层不同的问题。

---

当 Gateway 正常运行后，可以执行：

或者直接访问：

这通常不是服务坏了，而是浏览器访问 Dashboard 时没有带上 Gateway Token。

你可以这样取出 token：

然后用带参数的地址访问：

因为 Dashboard 是一个很好的中间检查点。

如果这一步成功，通常说明：

• OpenClaw 主程序已安装
• Gateway 已运行
• 本地服务已监听
• 浏览器能访问服务

这时你还没有引入模型、渠道、插件这些额外变量，所以诊断范围非常清晰。

---

如果你的模型平台提供的是这几个东西：

• 兼容
• 明确的模型名

那最稳的做法，通常不是去找某篇旧教程里的特定模板，而是直接按 OpenAI 兼容 provider 的思路来接。

这会带来两个好处：

• 配置更通用
• 换模型平台时迁移成本更低

这是另一个很容易踩的坑。

问题不是命令错，而是配置还没填完整，校验就先触发了。

直接编辑配置文件，一次性写完整，再统一校验：

这样做的好处是：

• 一次改完一组关联字段
• 减少半成品状态下的校验报错
• 更容易整体检查 JSON 结构

---

编辑配置文件：

按下面思路补齐。

如果你当前目标只是：

• 模型能回复
• Dashboard 能聊天
• 飞书能收发消息

那先关掉它，能少很多无关警告。

等主链路稳定后，再决定要不要补上检索能力，会更合理。

---

进入 Chat 页面，发送一句最简单的话：

也可以直接在终端里执行：

然后发送：

只要能收到正常回复，通常说明：

• OpenClaw 本体正常
• Gateway 正常
• 模型 provider 配置有效
• API 联通正常
• 默认模型切换成功

---

模型跑通后，再装飞书插件：

安装完成后重启 Gateway：

例如：

• 插件是否已安装
• Gateway 是否正常
• 飞书配置是否完整
• 事件是否真的进来了

因为渠道接入本身又多了一层变量：

• 插件安装
• 应用配置
• 事件订阅
• 长连接
• 飞书权限
• 测试人员范围

如果你连模型都还没跑通，就直接接飞书，后面一旦机器人不回消息，你很难判断问题到底在模型层还是渠道层。

---

打开飞书开放平台：

建议按这个顺序操作：

1. 创建企业自建应用
2. 添加机器人能力
3. 在“测试企业和人员”里把自己加入测试范围
4. 创建版本并发布

通常不是 OpenClaw 的问题，而是飞书后台这两件事没做：

• 没加机器人能力
• 没把自己加到测试人员，或者没发布版本

如果这两步没完成，你在飞书客户端里往往根本找不到这个机器人。

这一步没做完，前面所有接入都像“看起来差一点”，但永远不真正生效。

---

在 WSL 中执行：

然后重启：

因为群聊会引入更多变量：

• 是否被 @
• 群权限是否正确
• 机器人是否进群
• 群策略是否允许
• 是否进入白名单

如果你连私聊都还没验证通过，就先开群聊，问题会指数级复杂。

正确顺序应该是：

1. 私聊跑通
2. 配对成功
3. 稳定回复
4. 再考虑群聊策略

---

仅仅写完 OpenClaw 侧配置还不够，飞书后台还要继续完成这些设置。

路径：

路径：

选择：

至少添加：

至少保证消息接收相关权限已经启用。

这一步必须完成，否则测试人员通常无法真正使用。

因为飞书机器人是否“存在”和是否“能收消息、能回消息”是两件不同的事。

很多人会出现这种情况：

• 后台看起来都配了
• 应用也建了
• 机器人似乎也有了
• 但就是不回消息

本质上常常是事件订阅、权限、发布状态没有完整闭环。

---

如果你配置的是：

那么第一次给机器人发消息时，通常会看到类似：

这不是失败，而是首次授权机制在工作。

回到 WSL 中执行：

批准成功后，建议再重启一次 Gateway：

然后回到飞书私聊窗口，再发一句：

如果机器人能回复，就说明飞书接入已经成功。

这比“任何人都能直接私聊调用”更安全，也更适合测试和内部使用。

---

如果你配置了：

但没有继续设置允许的群，OpenClaw 往往会提示类似：

这句话的意思不是“机器人坏了”，而是：

• 私聊通常不受影响
• 群消息会被静默丢弃

因为它更安全。

因为只要私聊已经跑通，你就已经证明了三件事：

• 飞书插件工作正常
• 飞书长连接基本正常
• OpenClaw 能收到并处理消息

这时群聊只是策略问题，不再是“系统是否能工作”的问题。

---

这里不讲大而空的“可能原因很多”，只给你最实用的排查顺序。

先执行：

重点看是否出现：

如果没有，优先处理 Gateway 本身，不要先去改模型或飞书。

先检查：

如果 Gateway 没跑起来，Dashboard 打不开是结果，不是原因。

如果 Gateway 正常，但提示 token 缺失，就按前文方法补 token 访问。

按这个顺序查：

然后回到 Dashboard 或 TUI 做最简单测试。

最有效的命令通常是：

这能帮你判断：

• 长连接是否建立
• 飞书事件是否进来了
• 是否卡在权限
• 是否卡在 pairing
• 是否到达模型调用阶段

先看：

必要时再切源，不要先入为主。

优先执行：

很多时候不是“配置没写进去”，而是服务没重载到新配置。

---

---

如果你准备实际动手，建议严格按下面顺序来：

1. 检查 Windows 与 WSL2 环境
2. 进入 WSL，确认在 目录操作
3. 升级 Node 到 22+
4. 修复 DNS 或网络问题
5. 安装 OpenClaw
6. 跑通 Gateway
7. 打开 Dashboard
8. 配置并打通模型
9. 安装飞书插件
10. 配置飞书后台
11. 完成 pairing
12. 验证飞书私聊
13. 最后再考虑群聊

这个顺序的价值，不在于“看起来规范”，而在于：

• 每一步都有明确成功标准
• 每一步都能隔离错误范围
• 任何一步失败，都知道该往哪里查

---

OpenClaw 在 Windows 上最稳的姿势，不是“尽量少步骤”，而是“尽量少混乱”。

如果把整件事拆开看，本质上只有四层：

1. 系统环境
2. OpenClaw 本体
3. 模型接入
4. 飞书渠道

所以这篇文章最想帮你解决的，不只是“怎么装”，而是：

出问题时，你知道先看哪里，为什么看这里，以及为什么现在不该去动别的地方。

如果你照着本文的路线走，先跑通 WSL2 里的 OpenClaw，再接模型，最后接飞书，成功率通常会高很多，排错成本也会低很多。

彩蛋：获取限免大模型无限token：atomgit.com/