Win11下openclaw接入飞书：从Docker部署到彻底卸载的完整教程-嵌云网-嵌入式AI开发资源站

Win11下openclaw接入飞书：从Docker部署到彻底卸载的完整教程

REECHO大鱼总舵·2026-09-24·阅读 22 GEO检测（免费）

openclawwin11飞书机器人

|难度：普通|阅读约 34 分钟

1. 环境准备与基础认知

1.1 在动手之前先理清三个问题

把 openclaw 这套东西在 win11 上跑通，并且接到飞书里，再把它彻底卸载干净，这件事拆开看其实就三个问题：装什么、怎么配、怎么删。标题看着简单，但实际操作里每一步都藏着坑，尤其是 Windows 11 的权限机制、Docker 的虚拟化支持、飞书机器人的回调策略，这三者掺和在一起，稍不留神就会在一堆莫名其妙的报错里耗掉一整个下午。

先说 openclaw 是什么。你可以把它理解成一个本地跑的智能体网关，它负责承接各种模型能力（比如千问、Claude 这类），然后把对话能力和工具调用能力暴露成统一的服务接口。换句话说，openclaw 本身不生产“智能”，它负责把“智能”接进来、转发出去，再让下游的客户端（比如飞书机器人、命令行终端）能拿到结果。正因为它是个中间层，所以配置项特别碎，配置文件里任何一个路径、token、channel 写错，都会让你觉得“明明按照教程做了，怎么就跑不起来”。

再说为什么标题里非要带上 win11。Windows 11 跟 openclaw 的兼容性其实不算最丝滑的，原因有几个：第一，openclaw 的官方脚本很多面向 Linux 环境设计，到了 Windows 上要依赖 WSL2 或者 Git Bash 来模拟 POSIX 环境；第二，Windows 11 对 Docker 的支持依赖 Hyper-V 和 WSL2 后端，而这两个东西的安装顺序和 BIOS 虚拟化设置非常容易被忽略；第三，飞书机器人在 Windows 本地回调时，涉及端口转发、防火墙放行，这些操作在 win11 上比 Linux 上要繁琐得多。所以，在动工之前把这三个坑都摸清楚，后面会省掉大量时间。

如果你之前用过 Docker 跑过服务，那底子会好很多；如果连 Docker 都没碰过，也别慌，我在下面每一节都会把“为什么这么做”讲明白，你照着抄基本能通。

文末我会专门讲卸载环节。很多人装完 openclaw 之后发现不想要了，直接删文件夹，结果 Docker 镜像还在、自启动服务还在、环境变量还在，垃圾越积越多。彻底卸载的本质是把“文件、镜像、容器、服务、配置、环境变量”这六样东西一个一个清干净，缺一样都叫“卸载不干净”。

1.2 这套方案选用的整体结构

我在 win11 上实际跑通 openclaw 并接到飞书的方案，选的是 Docker 容器方式，而不是原生二进制方式。为什么这么选，理由很实在：openclaw 的依赖链条太长，包括 Python 版本、Node 运行时、各类 SDK 和系统库，原生安装很容易因为某个依赖版本冲突导致整个环境崩掉，而且卸载的时候很难清理干净。Docker 把这一切都隔离在镜像里，装也好、卸也好，一个命令就能搞定。

整体结构是：win11 宿主机上装 Docker Desktop，Docker 里跑 openclaw 容器，容器内部映射端口到宿主机，win11 宿主机上跑一个飞书机器人客户端（或者直接把飞书回调地址指向容器映射出的端口），飞书用户发消息，飞书服务器通过回调地址把消息推给 openclaw，openclaw 调用配置好的大模型，再返回结果给飞书。整个链路里，openclaw 是大脑和通讯中枢，飞书是入口和出口，win11 是承载一切的地基。

这里有一个设计决策值得多说两句：openclaw 与飞书的对接，到底是谁主动连谁？很多第一次接触的人会默认“openclaw 主动连飞书”，其实不是。飞书开放平台的工作机制是“你提供一个公网或者局域网内可访问的回调地址，飞书服务器在有新消息时主动往这个地址推数据”。所以你的 openclaw 必须暴露一个可以被飞书服务器访问到的 HTTP 接口。在 win11 本地开发环境里，这通常意味着你要么把端口映射到公网，要么在局域网内测试，要么用内网穿透工具把本地端口暴露出去。我在后面的章节里会具体讲我用的方案。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 安装 openclaw：从零到能跑

2.1 前置条件核对清单

安装之前，先把下面这几项逐一过一遍。缺任何一项，后面都可能出现让人抓狂的诡异报错。

Windows 11 版本建议 22H2 或更高，旧版本对 WSL2 的支持不够完善
BIOS/UEFI 中必须开启虚拟化技术（Intel VT-x 或 AMD-V）
已安装并启用 WSL2 功能，且默认版本为 WSL2
已安装 Docker Desktop，并设置为使用 WSL2 后端
已注册飞书开放平台账号，并创建好企业自建应用
已准备好一个大模型 API Key（openclaw 支持千问、Claude 等，配置方式不同但原理一致）

为什么 WSL2 这么关键？因为 Docker Desktop 在 Windows 上如果不走 WSL2 后端，就走 Hyper-V 后端，而 Hyper-V 后端在 win11 家庭版上默认是缺失的（家庭版没有 Hyper-V）。WSL2 用的是一个轻量级虚拟机，家庭版和专业版都能装，所以绝大多数教程都会让你走 WSL2 这条路。

提示：如果你之前装过 WSL1，记得在 PowerShell 里用 wsl --set-default-version 2 把它切换到 WSL2，否则 Docker 容器启动时会报不兼容错误。

2.2 Docker Desktop 安装要点

Docker Desktop 的安装包可以直接从 Docker 官网下载，安装的时候要注意两个选项：一个叫 “Use WSL 2 based engine”，这个必须勾选；另一个是 “Add shortcut to desktop”，这个随意。安装完成后重启系统，然后打开 PowerShell，输入 wsl --status 确认 WSL2 已经是默认版本。

如果 wsl --status 提示你尚未安装 WSL，直接执行 wsl --install。这个命令会自动装好 WSL2 和一个默认的 Ubuntu 发行版。装完之后记得重启。

Docker Desktop 启动后，右下角托盘图标应该变成稳定的鲸鱼图标，不会一直转圈。如果一直转圈，多半是 WSL2 的问题，可以在 PowerShell 里执行 wsl --shutdown 然后重新启动 Docker Desktop。

2.3 拉取 openclaw 镜像并创建容器

Docker 环境就绪后，就开始拉镜像。openclaw 的官方镜像在 Docker Hub 上，名称一般是 openclaw/openclaw 或者类似的命名空间，具体以你实际操作时的官方文档为准。

bash复制docker pull openclaw/openclaw:latest

拉取完毕后，创建并启动容器：

bash复制docker run -d \
  --name openclaw \
  -p 8080:8080 \
  -e OPENCLAW_MODEL_PROVIDER=openai-compatible \
  -e OPENCLAW_MODEL_API_KEY=你的APIKey \
  -e OPENCLAW_MODEL_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 \
  -e OPENCLAW_MODEL_NAME=qwen-max \
  -v openclaw_data:/app/data \
  openclaw/openclaw:latest

上面这个是配置千问的例子。OPENCLAW_MODEL_BASE_URL 指向千问的 OpenAI 兼容接口，OPENCLAW_MODEL_NAME 填你要用的模型名。如果你要用 Claude，则需要换成对应的 base URL 和模型名，API Key 也要换成 Anthropic 的。

端口映射这里，-p 8080:8080 是把容器内的 8080 端口映射到宿主机的 8080 端口。飞书回调地址届时指向 http://你的宿主机IP:8080/... 即可。

数据卷 openclaw_data 很重要，它用来持久化 openclaw 的配置、会话记录和日志。如果不用数据卷，容器一删，整个配置全没了，后续升级和迁移都非常痛苦。

2.4 为什么用环境变量而不是配置文件

openclaw 支持环境变量和配置文件两种配置方式。我建议在容器化场景下优先使用环境变量，原因是环境变量的覆盖优先级高、不占用容器内文件系统、方便在 docker-compose 里统一管理。但工作目录下通常还是需要一份 openclaw.config.json 或类似的配置文件，用来定义渠道（channel）、技能（skill）、知识库（knowledge）这些复杂结构体。你可以在宿主机上先写好配置文件，然后通过挂载的方式让容器读取：

bash复制docker run -d \
  --name openclaw \
  -p 8080:8080 \
  -v /c/Users/你的用户名/openclaw/config:/app/config \
  -v openclaw_data:/app/data \
  openclaw/openclaw:latest

配置文件的具体字段要看 openclaw 版本，不同版本差异不小。如果你用的版本比较新，配置结构通常是“模型 + 渠道 + 技能”三大块。模型负责定义接入哪个大模型，渠道负责定义有哪些入口（飞书、网页、命令行等），技能负责定义 openclaw 能调用哪些工具。这个设计思路很清晰，你只要按着这个脑图去填配置，逻辑上就不会乱。

3. 配置飞书机器人：把消息接进来

3.1 飞书开放平台创建应用

要接飞书，先得在飞书开放平台（open.feishu.cn）上创建一个企业自建应用。这个过程是免费的，但需要你有飞书账号。创建好应用后，你会拿到一个 App ID 和 App Secret，这两个东西就是飞书识别你应用的凭证，相当于你应用的身份证和密码。后面所有 API 请求都要带上它们。

创建应用后，还需要做三件事：

开启“机器人”能力：在应用的功能配置里找到“机器人”，启用它。这样你的应用才拥有收发消息的能力。
配置事件订阅：飞书服务器通过 Webhook 把用户消息推送到你的服务端，所以你需要配置一个“请求地址”。这个地址必须是你 openclaw 容器暴露出来的 HTTP 接口。
添加权限：在权限管理里，至少需要开通 im:message:send_as_bot（以机器人身份发消息）、im:message:read（读取消息）这两个权限。权限不开通，飞书会拒绝你的 API 调用。

3.2 回调地址配置与内网穿透

回调地址这一节是很多人卡住的地方。你的 openclaw 容器跑在 win11 上，监听的是 0.0.0.0:8080，在局域网内其他设备可以访问到你宿主机 IP 的 8080 端口。但飞书服务器在公网，它没法直接访问你的局域网 IP。所以需要做一层“桥接”，把你本地的 8080 端口暴露到公网。

解决方案有三种，我按推荐度排序：

购买一台轻量云服务器，在上面部署内网穿透工具（比如 frp 或者 Tailscale），把本地端口映射到公网服务器上，再由公网服务器转发到飞书。这个方案最稳定，适合长期使用。
使用现成的内网穿透服务，比如花生壳或者 ngrok，免费额度一般够测试用。缺点是稳定性受服务商影响，且免费域名会变化。
如果你和飞书服务器在同一个局域网内（比如企业内部部署），可以直接用局域网 IP 配回调地址，飞书服务器如果也在内网，自然可以访问。

我当时测试阶段用的是 ngrok，命令很简单：

bash复制ngrok http 8080

启动后 ngrok 会给你一个公网域名，比如 https://abc123.ngrok.io。在飞书后台的“事件订阅”里填 https://abc123.ngrok.io/webhook/feishu 就可以。注意 openclaw 的 webhook 路径要以你实际版本文档为准，不同版本路由不同。

注意：ngrok 免费版每次启动域名都会变，所以每次重启 ngrok 后都要回飞书后台改回调地址，非常麻烦。如果你只是测试，忍一忍；如果打算长期用，建议直接用云服务器 + frp。

3.3 飞书与 openclaw 的 channel 配置

openclaw 里把飞书这种接入方式叫做 channel（渠道）。配置渠道的目的，是告诉 openclaw “飞书来的消息往哪个模型送，回答完之后怎么发回飞书”。在配置文件里，你需要在 channels 节点下加一个飞书渠道的配置。

核心字段一般包括：

json复制{
  "channels": {
    "feishu": {
      "type": "feishu",
      "appId": "你的AppID",
      "appSecret": "你的AppSecret",
      "webhookPath": "/webhook/feishu"
    }
  }
}

appId 和 appSecret 从飞书开放平台复制，webhookPath 必须与你在飞书后台填写的路径一致。配好后重启容器，再在飞书里给你的机器人发一条消息，openclaw 的日志里应该会出现新的会话记录，那就说明链路通了。

3.4 飞书机器人发送表格的几个额外配置

热搜词里有一条“飞书机器人发送表格”，这个场景在很多团队协作里经常用到。openclaw 本身并不直接内置“发表格”这个动作，但你可以在技能（skill）里配置一个工具，让 openclaw 生成 CSV 或 Excel 文件，然后通过飞书 API 上传到聊天里。

关键在于飞书机器人发文件需要额外的上传接口权限，一般是 im:resource 相关权限。你在飞书后台把相关权限开了之后，openclaw 的技能模块里就可以调用文件上传接口。具体技能代码因版本而异，但你只要理解原理就不难：openclaw 生成文件 → 调用飞书 API 上传 → 返回 file_key → 用消息接口发送 file 类型消息。整个过程跟你在飞书里手动发文件是一样的逻辑。

3.5 消息被截断问题的预防

另一个热搜词是“openclaw在飞书输出容易被截断”，这个我实测确实会遇到。原因是飞书单条消息的文本长度限制比较严格（一般为 15000 字节以内），而大模型生成的回复很容易超出这个长度。openclaw 在发送消息时如果没有做分片处理，超出长度的部分会被飞书直接丢弃，或者整个消息发送失败。

解决方案有两个层面。第一，在 openclaw 的模型配置里设置 max_tokens 上限，比如 2000 到 4000 之间，让单次回复不会太长。第二，在飞书渠道配置里开启“消息分段”或者“自动分片”的功能（如果版本支持的话）。如果这两个都不行，最后的兜底方案是让 openclaw 把长文本先写入飞书云文档，然后把文档链接发给用户——飞书文档对长度几乎没有限制，而且阅读体验更好。

4. 常见问题与排查实录

4.1 容器启动失败：端口被占用

用 docker run 启动 openclaw 时，如果提示 port is already allocated，说明 8080 端口已经被其他程序占用了。这个问题的典型原因是之前已经跑过一个同名容器，或者系统里有其他开发服务器占用了 8080 端口。

排查思路：

bash复制netstat -ano | findstr :8080

如果输出的最后一列 PID 对应进程不是你熟悉的程序，可以在任务管理器中结束掉它。更安全的做法是直接用另一个端口，比如 -p 8081:8080，然后用 8081 去配回调地址。我个人倾向于换端口，因为结束系统进程有风险，容易误杀重要服务。

4.2 session file locked 报错

热搜词里有一条很典型的报错：agent failed before reply: session file locked (timeout 60000ms)。这个报错我遇到过不止一次，言简意赅地说：openclaw 的会话文件被锁住了，等到 60 秒超时都没拿到锁。

什么情况下会锁文件？通常是两个 openclaw 进程同时操作同一个会话文件。比如你开了两个终端窗口，同时往同一个容器里发消息；或者容器异常重启，但旧进程的锁还没释放。解决办法就是把容器停掉，等几秒，再启动：

bash复制docker restart openclaw

如果还不行，就该检查挂载的 data 目录权限。Windows 的 NTFS 文件系统映射到容器内时，权限模型跟 Linux 不一样，偶尔会出现文件被占用的情况。此时可以进入容器，手动删除会话锁文件：

bash复制docker exec -it openclaw rm -f /app/data/sessions/*.lock

然后重启容器。这个操作不会删除你的历史会话数据，只会清掉残留的锁。

4.3 容器运行正常但飞书没有响应

这是最让人头疼的：容器日志干净、端口映射正常、飞书后台也显示回调成功，但发消息石沉大海。我给你一个排查顺序：

第一，先看飞书后台的“事件订阅”页面有没有显示“请求成功”。飞书后台会记录每次推送事件的 HTTP 状态码，如果你看到 200 就说明飞书服务器确实把消息送到了你的回调地址。

第二，如果回调地址返回 200，但 openclaw 没反应，多半是渠道配置里的校验令牌（Encrypt Key）与后台不一致。飞书支持对回调内容做 AES 加密，如果你在后台配置了加密密钥，那 openclaw 的渠道配置里也必须填写同样的密钥，否则消息虽然收到了，但解不开。

第三，如果以上都对，就查模型 API Key 是否有效。openclaw 收到消息后要先调大模型 API，如果 Key 余额不足或者 IP 白名单限制，它会在日志里打印认证错误，但飞书那边什么也不知道。

这类问题的核心思路就是“逐层验证”：飞书 → 回调 → openclaw → 模型 API。每一层都有日志，顺着日志查，一定找得到断点。

4.4 Windows 11 特有的坑

Windows 11 上跑 Docker 容器，有一个非常经典的坑：防火墙默认阻止了宿主机对外部请求的 8080 端口响应。你本机访问 http://localhost:8080 没问题，但局域网内其他设备访问 http://你的IP:8080 超时。解决方法是在 Windows 防火墙里放行 8080 端口入站规则：

powershell复制New-NetFirewallRule -DisplayName "OpenClaw 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

另外，如果你用的是 WSL2 后端，Docker 容器的端口映射实际上发生在 WSL2 虚拟机和 Windows 宿主之间，偶尔会出现映射丢失的情况。重启 Docker Desktop 基本能解决。

4.5 常见问题快速排查表

症状	可能原因	解决动作
Docker Desktop 无法启动	未启用 WSL2 / BIOS 虚拟化关闭	执行 `wsl --install`，重启进 BIOS 开启 VT
容器启动报 name 冲突	已存在同名容器	先 `docker rm openclaw` 再运行
飞书回调返回 401	App Secret 错误	核对飞书后台密钥
回调返回 404	Webhook 路径不匹配	统一 openclaw 配置和飞书后台路径
容器日志显示认证失败	模型 Key 错误或无权限	检查 Key 与模型名、base URL
飞书消息被截断	消息长度超限	调低 max_tokens，开启分片
局域网访问不了端口	防火墙拦截	PowerShell 添加入站规则
session file locked	多线程/异常退出	删除 `.lock` 文件并重启容器

5. 彻底卸载 openclaw：不留任何痕迹

5.1 为什么卸载这么难

openclaw 这类“容器化 + 配置项散落”的应用，卸载难点不在“删文件”，而在“你不知道它还占了什么”。很多人以为把 Docker 容器删掉就完事了，实际上镜像文件、数据卷、Docker 网络、环境变量、开机自启项、配置文件，这些都不会因为你删了一个目录而自动消失。更麻烦的是，如果你升级过几次版本、换过配置路径，旧版本遗留下来的文件可能散落在好几个目录里。

所以我建议卸载前先做一个清单，这个清单就是我在开头说的六样东西：文件、镜像、容器、服务、配置、环境变量。接下来我一个个讲怎么清。

5.2 第一步：停止并删除容器

这是最直观的一步。在 PowerShell 里执行：

bash复制docker stop openclaw
docker rm openclaw

如果你之前用 docker-compose 启动的，则需要在对应目录里执行：

bash复制docker compose down

docker compose down 会同时停止并删除 compose 文件中定义的所有容器。这一步是安全的，不会删除镜像和数据卷，只是把运行环境清掉。

5.3 第二步：删除镜像与数据卷

容器删除后，镜像还是在磁盘上的，占空间几个 GB 很正常。删除镜像：

bash复制docker rmi openclaw/openclaw:latest

如果镜像名不对，可以先 docker images 查看一下。数据卷的删除有点隐蔽，很多人会漏掉。查看现有数据卷：

bash复制docker volume ls

找到 openclaw 相关的数据卷（比如 openclaw_data），然后：

bash复制docker volume rm openclaw_data

数据卷里保存的是所有会话记录、配置、日志。不删它，你的聊天记录和个人信息就一直留在硬盘里。从隐私角度讲，这一步不能省。

5.4 第三步：清理宿主机上的配置文件

如果你在宿主机上创建过配置文件目录（比如 /c/Users/你的用户名/openclaw/config），直接整个目录删掉。要注意的是，openclaw 在运行过程中可能还会在用户目录下创建一些隐藏配置，比如 .openclaw 文件夹，或者在环境变量里写入指向配置的路径。检查两个位置：

C:\Users\你的用户名\.openclaw\
C:\Users\你的用户名\openclaw\

有就删，没有就跳过。

5.5 第四步：清理环境变量与 PATH

安装 openclaw 时，某些安装脚本会向系统环境变量里写入 OPENCLAW_HOME 或把 openclaw 的 bin 路径加进 PATH。打开“系统属性 → 环境变量”，在用户变量和系统变量里挨个检查。找到 openclaw 相关的变量，删掉对应的 PATH 条目。这一步比较繁琐，但为了彻底卸载不能省。不清理的话，以后你在命令行里输入 openclaw 可能还会莫名其妙地出来一个命令。

5.6 第五步：检查开机自启动项

如果你之前配置过开机自启，还需要清理注册表里的 Run 键或者计划任务。在 PowerShell 里执行：

bash复制Get-ScheduledTask | Where-Object {$_.TaskName -like "*openclaw*"} | Unregister-ScheduledTask -Confirm:$false

如果注册表里有自启项，可以用系统自带的“任务管理器 → 启动应用”页面来排查和禁用。注册表不建议新手手动修改，优先用工具界面操作。但实际上，如果你是通过 Docker 跑的 openclaw，Docker Desktop 的自启动决定了容器是否跟着开机启动，所以这一步在很多情况下可以简化——你只需要在 Docker Desktop 的设置里取消“开机启动 Docker Desktop”，并且确定没有把 openclaw 容器设为 restart: always 策略即可。如果在 docker run 时没写 --restart always，那容器本身不会跟着开机自启。

5.7 第六步：验证卸载是否彻底

卸载完成后，做一个验证。重启你的 win11 系统，打开 PowerShell，依次执行下面几个命令，看是否还有 openclaw 的痕迹：

bash复制docker ps -a
docker images
docker volume ls
where.exe openclaw

前三项应该没有任何 openclaw 相关结果，最后一项应该提示“找不到文件”。如果全部清空，恭喜你，这台机器已经没有 openclaw 了。

5.8 卸载与重装的关系

如果你卸载 openclaw 的目的是“装的时候坏了，想重装一遍”，那其实不用把环境变量和数据卷全清掉——这些正好是重装时节省配置时间的东西。但如果目的是“彻底告别”，那请务必按上面的步骤一个一个走。

我个人在实际操作中的体会是：80% 的人卸载不干净，问题都出在数据卷和 PATH 环境变量这两项。因为它们在系统里是没有显眼入口的，不像你在桌面上删个快捷方式那么直观。所以我把它们单独拎出来重点强调。最后再分享一个小技巧，卸载前可以先在 .env 或配置目录里备份一份你当时用的 API Key 格式和 base URL，这样万一以后要重装，能少走不少弯路。