OpenClaw+飞书+WSL2:Windows本地AI数字员工搭建指南 1. 项目概述为什么是 OpenClaw 飞书 WSL2 这个组合OpenClaw 不是又一个玩具级 AI Bot它是一个真正能跑通“感知-决策-执行”闭环的轻量级 AI Agent 框架。我第一次在本地跑通它的hello world示例时就意识到它和市面上那些靠预设规则硬凑的“智能助手”有本质区别——它能理解你发来的飞书消息里“把上周销售数据导出成 Excel 发给王经理”这句话背后的意图能自动调用本地 Python 脚本查数据库、生成文件、再调用飞书 API 发送整个过程不需要你写一行业务逻辑代码。而飞书作为国内企业协同效率最高的平台之一其开放平台提供的机器人能力稳定、权限粒度细、消息样式丰富且与企业微信相比对自建服务的网络策略更友好调试期几乎不碰壁。至于 WSL2它不是为了“假装用 Linux”而是解决了一个 Windows 用户长期被忽视的痛点Node.js 生态里大量依赖原生模块比如node-gyp编译的sqlite3、sharp图像处理库在 Windows 原生 CMD/PowerShell 下编译失败率极高报错信息全是MSBUILD和VC的天书而 WSL2 提供的是一个完整的、内核级隔离的 Linux 用户空间所有 npm install、yarn build、甚至后续模型推理的 Python 环境都能在 Ubuntu 的标准 POSIX 环境下丝滑运行错误日志清清楚楚排查路径明明白白。这个组合的核心价值不是“技术炫技”而是为中小团队和个人开发者提供了一条可落地、可维护、低成本的数字员工建设路径。它绕开了动辄数万的 SaaS 订阅费也避开了需要专业 DevOps 维护的 Kubernetes 集群。一台 16G 内存的 Windows 笔记本装好 WSL2配好 OpenClaw就能让一个飞书机器人 7×24 小时帮你自动归档会议纪要、同步 CRM 数据、甚至根据日报内容生成周报初稿。我上个月帮一家做跨境电商的客户部署他们原来每天花 2 小时人工整理各平台订单数据现在 OpenClaw 每小时自动拉取、去重、格式化、生成汇总表并推送到飞书群人力成本直接归零。所以当你看到标题里“手把手”“配置代码全给”这些字眼请别把它当成一个简单的安装教程——这是一份从 Windows 用户真实工作流出发为你量身定制的、能立刻产生业务价值的生产力工具包。关键词里的openclaw、飞书助手、Node.js、WSL2每一个都不是孤立存在它们共同构成了一个完整、健壮、可调试的端到端链路。2. 整体设计思路与方案选型解析2.1 为什么必须用 WSL2而不是 Docker Desktop 或原生 Windows这个问题我被问过不下二十次。答案很直接环境一致性与调试友好性。先说 Docker Desktop WSL2 这个看似“更现代”的方案。它确实能打包环境但代价是调试地狱。当你在容器里运行 OpenClaw发现飞书消息收不到、或者模型调用超时你需要一层层进入容器、检查网络、看日志、甚至挂载源码进容器调试——这个过程比在 WSL2 里直接nano config.js修改一行配置再npm run dev重启慢三倍。更重要的是Docker Desktop 在 Windows 上本身就是一个资源黑洞它会常驻一个 Hyper-V 虚拟机吃掉 2G 以上内存对于一台主力办公的 Win11 笔记本这已经占了 1/8 的总内存。而 WSL2 是微软官方深度集成的子系统它共享宿主机的内存管理空闲时自动释放启动速度以毫秒计wsl -d Ubuntu-22.04命令敲下去0.3 秒内就进入终端这种响应速度是任何容器方案无法比拟的。再看原生 Windows 方案。网上很多教程教你在 PowerShell 里npm install -g openclaw-cli然后openclaw init。听起来很美但实测下来90% 的失败都卡在node-gyp rebuild这一步。原因在于 Windows 的 Node.js 安装包默认不带 Python 和 Visual Studio Build Tools而node-gyp需要它们来编译 C 扩展。你得手动下载 2GB 的 VS Build Tools再配置环境变量最后还可能因为 Python 版本不匹配node-gyp要求 Python 3.10而你电脑里可能是 3.12导致编译失败。我在公司内部做过一次统计新入职的 5 位前端同事有 4 位在第一步就放弃了。WSL2 则彻底规避了这个问题Ubuntu 仓库里python3、build-essential、curl这些基础工具开箱即用apt install nodejs npm装上的就是为 Debian/Ubuntu 精心编译过的二进制包所有依赖的.so动态库路径都正确npm install命令跑起来就像呼吸一样自然。所以方案选型不是追求“最新”而是选择“最省心、最可靠、最符合 Windows 用户实际工作习惯”的那一个。2.2 为什么推荐 Ollama DeepSeek 作为默认模型后端OpenClaw 支持多种大模型接入包括 OpenAI、Anthropic、以及各种开源模型。但如果你的目标是“完全离线、零 API 调用费用、数据不出本地”那么 Ollama 就是目前 Windows WSL2 环境下最成熟的选择。Ollama 的核心优势在于它把模型的下载、加载、推理、API 服务全部封装成了一个极简的命令行工具。你只需要ollama run deepseek-coder:6.7b它就会自动从官方仓库拉取模型约 4.2GB解压到~/.ollama/models然后启动一个本地的http://localhost:11434API 服务。这个服务完全兼容 OpenAI 的 RESTful 接口规范意味着 OpenClaw 的配置文件里你只需要把OPENAI_API_BASE_URL指向http://localhost:11434/v1其他参数model,api_key保持不变就能无缝切换。DeepSeek-Coder 6.7B 这个模型是我经过一周压力测试后选定的“甜点型号”。它在 16GB 内存的 WSL2 环境下能稳定运行推理速度token/s比同尺寸的 CodeLlama 高 15%而且对中文编程指令的理解准确率极高。我用它测试过“把这段 Python 代码改成异步版本并添加 Redis 缓存逻辑”它给出的修改建议 90% 可直接合并。相比之下更大的 32B 模型虽然效果更好但在 WSL2 里会频繁触发内存交换swap导致响应延迟飙升到 10 秒以上完全失去“助手”的实时性。所以这个选型背后是性能、内存、效果、稳定性四者之间反复权衡的结果不是随便挑一个热门模型就往上套。2.3 飞书应用配置的关键逻辑为什么必须用“自建应用”而非“机器人”飞书开放平台提供了两种接入方式“机器人”和“自建应用”。很多新手会直接创建一个“群机器人”因为它看起来最简单。但这是个巨大的陷阱。群机器人本质上是一个单向的“消息推送器”它只能被动接收飞书服务器发来的事件比如用户了它然后回复一条消息。它没有权限去主动读取群聊历史、没有权限去获取用户个人信息、更没有权限去调用飞书的其他 API比如日历、文档、审批。而 OpenClaw 的核心能力恰恰在于它的“主动性”。比如一个典型场景是“当飞书日历里新增一个‘项目启动会’的日程时自动创建一个对应的飞书多维表格并把会议链接、参会人名单填进去。” 这个动作需要 OpenClaw 主动监听日历事件Webhook然后调用多维表格 API 创建记录。这只有“自建应用”才能做到。自建应用在飞书后台创建后会获得一个App ID和App Secret你可以用它们换取长期有效的tenant_access_token这个 token 拥有你授权范围内的所有 API 权限。配置时最关键的一步是“应用权限”设置。你必须勾选im:message:send发送消息、contact:user:read读取用户信息、calendar:read读取日历等具体权限然后点击“提交审核”——注意这里不需要真的等飞书审核个人开发者的自建应用提交后立即生效。这个细节是绝大多数网上教程遗漏的也是导致“配置完了却没反应”的最常见原因。3. 核心细节解析与实操要点3.1 WSL2 的精准安装与 Ubuntu 22.04 环境初始化WSL2 的安装网上很多教程让你在 PowerShell 里敲wsl --install这确实能一键搞定但它有个致命缺陷它会默认安装最新版的 Ubuntu目前是 24.04而 Ubuntu 24.04 的内核默认启用了cgroup v2这与 Ollama 的某些底层容器运行时存在兼容性问题会导致ollama run命令卡死。所以我们必须手动指定安装 Ubuntu 22.04。第一步在管理员权限的 PowerShell 中执行# 启用 WSL 功能如果尚未启用 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启电脑重启后去微软商店搜索 “Ubuntu 22.04 LTS”点击“获取”安装完成后首次启动会要求你创建一个 Linux 用户名和密码记住这个用户名后面所有操作都基于它。安装完毕后打开 Windows 设置 - 系统 - 电源和睡眠 - 其他电源设置 - 选择电源按钮的功能 - 更改当前不可用的设置 - 取消勾选“启用快速启动”。这一步极其重要因为“快速启动”会阻止 WSL2 正确关机导致下次启动时文件系统损坏出现Invalid argument错误。做完这个回到 PowerShell执行wsl -l -v你应该看到类似这样的输出NAME STATE VERSION * Ubuntu-22.04 Running 2接下来是环境初始化。不要急着装 Node.js先升级系统并安装基础工具# 进入 WSL2 wsl -d Ubuntu-22.04 # 更新软件源换成清华源国内访问更快 sudo sed -i s/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list sudo sed -i s/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list # 更新并升级 sudo apt update sudo apt upgrade -y # 安装必备工具 sudo apt install -y curl wget git vim build-essential python3-pip python3-venv提示build-essential包含了gcc,g,make等编译工具这是后续npm install能成功的关键。python3-pip和python3-venv是为后续可能需要的 Python 工具如 Ollama 的某些插件做准备。3.2 Node.js 的安全安装与版本管理避开 v24.16.0 陷阱网络热词里反复出现error installing 24.16.0: node.js v24.16.0 is not yet released这暴露了一个普遍误区盲目追求最新版。Node.js 的偶数版本如 18.x, 20.x是长期支持版LTS稳定、bug 少、生态兼容性好而奇数版本如 21.x, 23.x是“当前版”主要用于尝鲜和测试生命周期短很多 npm 包还没适配。OpenClaw 的官方文档明确要求 Node.js 18.0.0所以我们的目标是安装Node.js 20.18.0 LTS。最安全的方式是使用nvmNode Version Manager它可以让你在同一台机器上轻松切换多个 Node.js 版本避免全局污染。在 WSL2 终端中执行# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载 shell 配置 source ~/.bashrc # 使用 nvm 安装 Node.js 20.18.0 nvm install 20.18.0 # 设为默认版本 nvm alias default 20.18.0 # 验证 node -v # 应该输出 v20.18.0 npm -v # 应该输出 10.5.0注意千万不要用sudo apt install nodejs来安装Ubuntu 仓库里的 Node.js 版本通常严重滞后比如还是 18.19而且apt安装的node命令在某些系统里会被映射为nodejs导致npm找不到node报错command not found。nvm安装的路径是~/.nvm/versions/node/v20.18.0/bin/它会自动添加到你的PATH环境变量绝对可靠。3.3 OpenClaw 的克隆、安装与核心配置文件详解现在环境干净了我们开始部署 OpenClaw。官方 GitHub 仓库是https://github.com/open-claw/openclaw但直接git clone下来会得到一个包含所有示例和文档的庞然大物。对于只想快速跑通飞书助手的用户我们采用更轻量的方式使用 OpenClaw 官方提供的 CLI 工具来初始化一个最小化的项目。# 全局安装 OpenClaw CLI npm install -g openclaw/cli # 创建一个新项目目录 mkdir my-openclaw-bot cd my-openclaw-bot # 初始化项目选择 Custom 模式这样可以手动配置所有选项 openclaw init在交互式提问中你会遇到几个关键选项Project name: 输入feishu-botSelect a template: 选择blank空白模板最干净Install dependencies?: 选择Yes初始化完成后项目结构如下my-openclaw-bot/ ├── package.json ├── src/ │ ├── index.ts # 主入口文件 │ └── skills/ # 技能定义目录 ├── config/ │ └── default.ts # 核心配置文件 └── .env # 环境变量文件需手动创建核心配置文件config/default.ts是整个项目的“大脑”。它定义了模型、飞书、存储等所有后端服务的连接参数。我们来逐行解析并修改它import { Config } from openclaw/core; export const config: Config { // 模型配置指向本地 Ollama 服务 model: { provider: openai, // OpenClaw 将 Ollama 视为 OpenAI 兼容接口 apiKey: ollama, // 这个值可以是任意字符串Ollama 不校验 key baseUrl: http://host.docker.internal:11434/v1, // 关键WSL2 内部访问宿主机的地址 model: deepseek-coder:6.7b, }, // 飞书配置从飞书开放平台获取 feishu: { appId: cli_xxxxxx, // 替换为你的 App ID appSecret: xxxxxxxx, // 替换为你的 App Secret encryptKey: xxxxxxxx, // 替换为你的 Encrypt Key在飞书后台“安全设置”里 verificationToken: xxxxxxxx, // 替换为你的 Verification Token同上 }, // 存储配置使用 SQLite轻量且无需额外服务 storage: { type: sqlite, database: ./data/storage.db, // 数据库存储路径 }, };注意baseUrl的值http://host.docker.internal:11434/v1。这是一个 WSL2 的特殊 DNS 名称它会自动解析为宿主机Windows的 IP 地址。因为 Ollama 是运行在 Windows 宿主机上的我们稍后会安装而 OpenClaw 运行在 WSL2 里所以 WSL2 必须通过这个地址才能访问到宿主机的 11434 端口。如果你写成http://localhost:11434/v1OpenClaw 会尝试连接 WSL2 自己的 localhost那当然是失败的。3.4 飞书开放平台的完整配置流程附截图逻辑说明飞书的配置是整个项目里最容易出错的一环因为它的后台界面更新频繁且关键配置项藏得比较深。我将按顺序用文字描述每一步的操作和目的让你即使看不到截图也能精准定位。第一步创建自建应用登录 飞书开放平台 。点击右上角头像 - “开发者后台” - “创建应用” - “自建应用”。应用名称填OpenClaw 数字员工应用描述写基于 OpenClaw 框架的自动化助手点击“创建”。第二步配置应用权限创建后进入应用详情页左侧菜单栏找到“权限管理”。点击“添加权限”在弹出的窗口中搜索并勾选以下权限im:message:send发送消息im:message:read读取消息用于上下文理解contact:user:read读取用户信息用于个性化回复calendar:read读取日历用于事件监听勾选完点击“提交审核”。再次强调个人开发者提交后立即生效无需等待。第三步配置事件订阅Webhook左侧菜单栏找到“事件订阅”。开关打开“启用事件订阅”。“请求 URL” 填写https://your-domain.com/webhook。等等你还没有域名别慌这里先填一个占位符比如https://example.com/webhook。因为我们后续会用ngrok做内网穿透这个 URL 会在ngrok启动后动态生成到时候再回来修改。“加密密钥Encrypt Key”和“验证令牌Verification Token”这两个字段点击旁边的“生成”按钮系统会为你生成一长串随机字符务必复制并保存到一个安全的地方因为它们会用于校验飞书发来的所有事件的真实性防止恶意伪造。第四步获取凭证左侧菜单栏找到“凭证管理”。这里你能看到App ID和App Secret同样复制并保存。这三个东西App ID,App Secret,Encrypt Key,Verification Token就是你后续配置.env文件的全部钥匙。提示飞书的 Webhook 有一个严格的校验机制。每次它向你的 URL 发送事件时都会在 HTTP Header 里带上X-Feishu-Signature和X-Feishu-Timestamp。OpenClaw 的 SDK 会自动用你提供的Encrypt Key和Verification Token去验证这个签名。如果验证失败飞书会认为你的服务不可信后续事件将不再推送。所以这四个字符串一个都不能错。4. 实操过程与核心环节实现4.1 在 Windows 宿主机上安装并运行 OllamaOllama 是整个链路的“模型引擎”它必须运行在 Windows 宿主机上因为 WSL2 本身是一个轻量级虚拟机它没有自己的 GPU而 Ollama 的模型推理需要调用宿主机的 CPU 和内存。安装步骤非常简单访问 Ollama 官网 。下载OllamaSetup.exeWindows 版本。双击安装一路“下一步”安装路径默认即可。安装完成后它会自动在后台运行一个服务并在系统托盘显示一个鲸鱼图标。安装完毕后按Win R输入cmd在命令提示符里执行ollama list如果看到NAME ID SIZE的表头说明服务已启动。接着我们下载 DeepSeek-Coder 模型ollama run deepseek-coder:6.7b第一次运行会自动下载模型约 4.2GB根据你的网络速度可能需要 5-15 分钟。下载完成后你会看到一个提示符这意味着模型已经加载到内存可以进行对话了。输入why is the sky blue?它会用英文给你一个科学解释。此时Ollama 的本地 API 服务http://localhost:11434已经就绪。你可以用浏览器访问http://localhost:11434/health如果返回{status:ok}就证明一切正常。注意Ollama 默认只监听localhost这意味着只有本机Windows能访问。但我们的 OpenClaw 运行在 WSL2 里它需要访问这个服务。所以我们必须修改 Ollama 的监听地址。在 Windows 的 PowerShell管理员中执行# 停止 Ollama 服务 Stop-Service Ollama # 修改配置让 Ollama 监听所有网络接口 Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Ollama -Name ImagePath -Value C:\Users\YourName\AppData\Local\Programs\Ollama\ollama.exe serve --host 0.0.0.0:11434 # 启动服务 Start-Service Ollama这样WSL2 就可以通过http://host.docker.internal:11434访问到它了。4.2 使用 ngrok 实现内网穿透打通飞书 Webhook飞书的 Webhook 要求你的服务必须有一个公网可访问的 HTTPS URL。而你的 OpenClaw 服务运行在 WSL2 里IP 是172.x.x.x对外不可见。解决方案是使用ngrok它能将你本地的http://localhost:3000映射成一个全球唯一的https://xxxx-xx.ngrok-free.app域名。访问 ngrok 官网 下载 Windows 版本。解压后打开命令提示符进入解压目录执行ngrok config add-authtoken your-token。your-token需要你先在官网注册一个免费账号然后在 Dashboard 里找到。启动 ngrok将 WSL2 的 3000 端口OpenClaw 默认端口映射出去ngrok http http://localhost:3000你会看到类似这样的输出Session Status online Account youremail.com Version 3.4.0 Region United States (us) Web Interface http://127.0.0.1:4040 Forwarding https://a1b2c3d4-ef56.ngrok-free.app - http://localhost:3000这个https://a1b2c3d4-ef56.ngrok-free.app就是你的公网地址。现在回到飞书开放平台的“事件订阅”页面把之前填的占位符https://example.com/webhook替换成https://a1b2c3d4-ef56.ngrok-free.app/webhook然后点击“保存并验证”。飞书会立刻向这个地址发送一个验证请求如果 OpenClaw 服务正在运行它会自动响应状态会变成“已验证”。提示ngrok的免费版有连接时长限制约 2 小时到期后会断开。但没关系你只需要在断开后重新在命令行里按↑键调出上一条命令回车重跑即可。它的 URL 每次都是新的所以你必须养成习惯每次重启ngrok后第一时间去飞书后台更新 Webhook URL。4.3 OpenClaw 项目的完整构建、启动与飞书机器人激活现在所有外部依赖Ollama、ngrok、飞书都已就绪我们回到 WSL2 终端完成最后的拼图。首先确保你位于项目根目录my-openclaw-bot下。我们需要创建.env文件把飞书的凭证注入进去# 创建 .env 文件 cat .env EOF FEISHU_APP_IDcli_xxxxxx FEISHU_APP_SECRETxxxxxxxx FEISHU_ENCRYPT_KEYxxxxxxxx FEISHU_VERIFICATION_TOKENxxxxxxxx NODE_ENVdevelopment EOF然后安装项目依赖npm install这一步会根据package.json里的dependencies下载所有 Node.js 包。由于我们是在 WSL2 的纯净 Ubuntu 环境下npm install几乎不会失败整个过程大约 2-3 分钟。接下来启动 OpenClaw 服务npm run dev你会看到控制台输出一大段日志最终停在 OpenClaw is running on http://localhost:3000 ✅ Feishu webhook verified successfully. Ready to receive messages from Feishu!这表示服务已启动并且成功通过了飞书的 Webhook 验证。此时打开你的飞书客户端找到一个测试群点击右上角“” - “添加机器人” - “从应用市场添加” - 搜索你创建的应用名OpenClaw 数字员工点击“添加”。添加成功后你就可以在群里 这个机器人发送你好它应该会立刻回复你好我是 OpenClaw 数字员工有什么可以帮您。实操心得第一次测试时如果机器人没有回复不要慌。先检查 WSL2 终端里的日志看是否有Received event from Feishu这样的日志。如果没有说明飞书的事件根本没有到达你的服务问题一定出在ngrok或飞书 Webhook 配置上。如果有日志但回复失败则问题在 OpenClaw 的技能逻辑或模型调用上。这种分层排查法能帮你 80% 的时间都定位到根源。4.4 一个实用技能的完整开发自动归档会议纪要光让机器人“说话”没用它的价值在于“做事”。我们来开发一个真实场景的技能当用户在飞书群里发送一条包含“会议纪要”字样的消息时自动将其内容保存为 Markdown 文件并上传到飞书云文档。在src/skills/目录下创建一个新文件meeting-notes.tsimport { Skill, Context, Message } from openclaw/core; export const MeetingNotesSkill: Skill { name: meeting-notes, description: 自动归档会议纪要到飞书云文档, trigger: (ctx: Context) { const text ctx.message.text?.toLowerCase() || ; return text.includes(会议纪要) || text.includes(meeting notes); }, execute: async (ctx: Context) { const { message, feishu } ctx; const content message.text || ; // 1. 生成 Markdown 内容 const markdownContent # 会议纪要\n\n## 时间\n${new Date().toLocaleString()}\n\n## 内容\n${content}; // 2. 调用飞书 API 创建云文档 try { const docRes await feishu.client.docx.create({ folder_token: fld_xxxxxx, // 替换为你的飞书云文档文件夹 ID title: 会议纪要-${new Date().toISOString().slice(0, 10)}, }); // 3. 将 Markdown 内容写入文档 await feishu.client.docx.batchUpdate({ document_id: docRes.data.document_id, requests: [ { insert_block: { index: 0, block: { paragraph: { elements: [ { text_run: { content: markdownContent, }, }, ], }, }, }, }, ], }); return ✅ 会议纪要已成功归档文档链接${docRes.data.url}; } catch (error) { console.error(Failed to create doc:, error); return ❌ 归档失败${error instanceof Error ? error.message : 未知错误}; } }, }; // 导出技能让主程序识别 export default MeetingNotesSkill;然后在src/index.ts的skills数组里导入并注册这个技能import { OpenClaw } from openclaw/core; import { MeetingNotesSkill } from ./skills/meeting-notes; const claw new OpenClaw(); // 注册技能 claw.use(MeetingNotesSkill); claw.start();保存后在 WSL2 终端里按CtrlC停止当前服务再执行npm run dev重启。现在回到飞书群发送请帮我把今天的会议纪要归档一下1. 项目进度同步2. 下周上线计划3. 风险点讨论。机器人会立刻创建一个云文档并把你的文本格式化后放进去。这个技能的代码展示了 OpenClaw 的核心范式trigger定义何时执行execute定义如何执行所有飞书 API 的调用都封装在ctx.feishu.client里你不需要关心鉴权、重试、错误处理等底层细节专注业务逻辑即可。5. 常见问题与排查技巧实录5.1 WSL2 启动失败“WslRegisterDistribution failed: 0x800701bc”这是 WSL2 最经典的错误通常出现在 Windows 10 2004 之前的旧版本或者 BIOS 里关闭了虚拟化VT-x/AMD-V。解决方法分三步确认 Windows 版本按Win R输入winver确保是 Windows 10 版本 2004 或更高或 Windows 11。如果不是请先升级系统。开启 BIOS 虚拟化重启电脑狂按F2/Del/F10进入 BIOS 设置找到Advanced-CPU Configuration-Intel Virtualization Technology或SVM Mode将其设为Enabled保存退出。重置 WSL在管理员 PowerShell 中执行wsl --unregister Ubuntu-22.04 wsl --install这会彻底清除旧的 WSL2 实例重新安装。5.2npm install卡在node-gyp rebuild报错gyp ERR! find Python这说明node-gyp找不到 Python 解释器。根本原因是你在 WSL2 里没有安装 Python或者安装的版本不对。解决方案是在 WSL2 终端里执行python3 --version确认输出是3.10.x或3.11.x。如果没有执行sudo apt install python3.10。然后告诉node-gyp使用哪个 Pythonnpm config set python python3.10 npm config set msvs_version 2019最后清理缓存并重试npm cache clean --force npm install。5.3 OpenClaw 启动后飞书消息收不到日志里也没有Received event这 99% 是ngrok的问题。请按以下顺序逐一检查确认ngrok进程是否在运行在 Windows 的任务管理器里搜索ngrok.exe看它是否在“后台进程”里。确认ngrok的转发地址是否正确打开http://127.0.0.1:4040ngrok的 Web UI看Forwarding行显示的 URL 是否和飞书后台配置的 URL 完全一致包括https://和/webhook后缀。确认飞书 Webhook 是否已“验证”回到飞书开放平台看“事件订阅”页面的状态是不是绿色的“已验证”。如果不是点击“重新验证”。临时关闭防火墙在 Windows 设置里暂时关闭“Windows Defender 防火墙”排除防火墙拦截ngrok流量的可能性。5.4 Ollama 模型加载后OpenClaw 调用超时报错fetch failed这通常是网络超时或模型未完全加载导致的。Ollama 的deepseek-coder:6.7b模型首次加载需要 1-2 分钟期间它会返回 503 错误。解决方案是