Windows原生部署个人AI助手：OpenClaw+DeepSeek+飞书实战

先交代一个背景：我一直在找一个能挂在本地常驻的“个人AI管家”，但市面上的方案要么绑定云平台的数据中转，要么强制要求装 Linux，要么配置复杂到让人想退货。后来倒腾了 OpenClaw 这套东西，才算是找到一个能老老实实塞进 Windows 原生环境里的智能体底座。如果你也想过“往飞书群里扔一个机器人，让它随叫随到、帮你跑通 DeepSeek 大模型”，这篇文章应该能帮你把路趟平。下面写的每一步，都是我在这台 Windows 机器上实际敲过命令、掉过坑、又填回去的总结，不是看一眼文档就能抄走的那种。

1. 选型逻辑：为什么是 OpenClaw + DeepSeek + 飞书这套组合

1.1 OpenClaw 到底是什么，它在你电脑里扮演什么角色

先说清楚一个概念：OpenClaw 本身不产生智能，它是一个本地的智能体运行时，核心作用是“消息路由 + 任务调度”。你可以把它想象成一个前台经理：用户从飞书发来一句“帮我把这周的项目周报整理成表格”，消息先进到 OpenClaw，它判断要不要理你、该用哪个模型、要不要调用工具，最后把 DeepSeek 生成的结果送回到飞书会话里。

我拆成一个三层结构就很好理解了：

• 飞书是你的对讲机：消息从这儿进来，答案从这儿出去；
• OpenClaw 是前台经理：接电话、判断需求、安排干活的人；
• DeepSeek 是后厨团队：真正负责动脑子、组织语言、生成内容的角色；
• 往后如果接上 MCP 工具，就等于给经理配了工具箱，它才能查天气、读文件、操作数据库。

所以 OpenClaw 解决的核心问题不是“给你一个聊天窗口”，而是把 IM 通道、大模型 API、外部工具这三层东西粘合起来。对国内用户来说，它对飞书、钉钉这类 IM 适配得很细，不需要你自己去抠每个平台的协议细节。如果你只想在本地跑一个“随时能在工作群里被呼叫”的通用智能体，这套路径目前是最省力的。

1.2 DeepSeek 和飞书，凭什么最搭

DeepSeek 的优势在于三点：接口兼容 OpenAI 协议，迁移成本低；服务部署在国内，直连稳定、延迟可控；价格在同类模型里属于便宜得让人想多调几次的类型。日常的总结、改写、写文档、整理待办这些活，它干得相当稳，完全撑得起一个常驻群机器人的消耗。

飞书这边，开放平台的机器人机制做得比较完整，最关键的它支持长连接接收事件。什么意思呢？传统 Webhook 模式需要你有一个公网 HTTPS 地址让飞书把消息推给你，而长连接模式是飞书主动与你本地进程之间拉一条专线，事件通过这条连接推送下来。对本地部署来说，这堪称天选模式：不用买服务器、不用配域名、不用搞内网穿透，一台 Windows 电脑跑个进程就能收消息。

OpenClaw 对长连接模式的适配做得比较成熟，配置好之后基本上是一次连接、自动重连。这套组合的价值就出来了：一个纯本地私有、随叫随到、能进团队群的 AI 助手，该有的都有了。

1.3 为什么不推荐 WSL 和 Docker

我知道很多教程上来就让你装 WSL 或者 Docker Desktop，我的建议是：如果目标是长期挂机跑一个 Agent 进程，别折腾它们。

WSL 的实际问题我在用的时候感受很深：文件 IO 性能和原生 Windows 差距明显，Windows 大版本更新后偶尔网络模式会抽风，而且开机自启一个 WSL 里的服务还得分层处理系统启动顺序和桌面环境的关系，进程管家也接不顺。Docker Desktop 更不用说了，依赖虚拟化，开机就吃掉几个 G 内存，对一个小底座来说成本太高。

原生 Windows 跑 Node.js 进程没有任何问题，这套方案的复杂度反而更低。后面我会专门讲 Windows 下的自启和守护怎么做，这几招学会了，这套方案在 Windows 上的稳定程度基本能追上 Linux 服务器。

2. 原生 Windows 下的环境准备与仓库部署

2.1 需要装哪些东西：清单与检查方法

准备的东西其实不多，三样核心工具就能开路：

工具	用途	版本要求
Node.js	运行 OpenClaw 服务	18 及以上，优先选 LTS
Git	拉取仓库代码	任意新版本
Windows Terminal	调试、看日志更舒服	建议安装，非必须

Node.js 安装时有一件事必须注意：安装向导里一定要勾选“Add to PATH”，否则装完在新终端里运行node -v会提示找不到命令。装完三样之后，新开一个终端窗口，依次跑下面三条命令验证：

node -v # v20.11.1（实际数字以你的为准） npm -v # 10.2.4 git --version # git version 2.44.0.windows.1

三条命令都有输出，就说明基本环境是通的。这里有个隐藏坑：如果你电脑之前装过老的 Node 版本，建议直接用官网 LTS 安装包覆盖升级。OpenClaw 依赖的某些模块对 Node 版本有硬性要求，版本太低会在npm install阶段报engine相关的警告，严重时直接失败。

Git 安装一路默认即可。有个可选建议：安装到“Checkout as-is, commit as-is”这一步时保持默认，避免拉代码时换行符被乱改成 CRLF 导致各种诡异问题。

2.2 拉取仓库、安装依赖，以及一个常见卡点

OpenClaw 的代码在开源仓库里，直接用 Git 克隆到本地目录。我的习惯是放在一个不带中文和空格的路径下，比如D:\dev\openclaw，避免后面某些命令行工具对路径的解析出幺蛾子：

mkdir D:\dev cd D:\dev git clone <OpenClaw仓库地址> openclaw cd openclaw

依赖安装阶段我建议直接用 npm：

npm install

这一步最容易遇到两种情况。第一种是网络问题，某些包下载超时，表现是卡在一个包上很久然后报ETIMEDOUT，这个可以通过给 npm 配置国内镜像源解决。第二种是部分涉及原生编译的模块在 Windows 上需要 build tools 才能编译，这种情况多数官方会提供预编译二进制，实际碰到的概率不大。

还有一个非常容易被忽略的点：OpenClaw 是 Monorepo 结构，一部分集成模块是独立发包的，比如飞书适配器往往在packages/integrations/feishu子目录里。如果根目录装完依赖后提示某个子项目缺失，你就要到对应子目录再跑一次安装命令。这一步别偷懒，很多飞书连接失败的问题，排查到最后其实是子目录依赖没装全。

2.3 配置文件从哪来：sample 文件与初始化命令

OpenClaw 提供了初始化命令，帮你把默认配置生成到本地：

npm run init

这个命令会在项目根目录生成一套示例配置，包含环境变量文件和 Agent 角色定义文件。如果你不喜欢跑命令，也可以自己复制项目根目录的.env.example为.env，效果差不多。

第一次看到配置文件，字段确实多，很多人就是在这时候懵的。我的建议是不要着急全看懂，先只关注三块：

1. 平台接入：飞书的 App ID、App Secret、事件加密 Key；
2. 模型接入：DeepSeek 的 API Key、接口地址、模型名；
3. Agent 定义：给它起名字、写清楚它的职责和回复风格。

第 3 章和第 4 章我会分别讲 DeepSeek 和飞书这两块的配置细节。把这三大块弄明白，你就能跑起来，剩下的高级配置项是后面慢慢摸的事。

3. DeepSeek 模型接入：密钥、模型名与请求路径的细节

3.1 注册、创建 API Key，最容易翻车的是保存环节

先去 DeepSeek 开放平台注册账号，登录后进入控制台，左侧能找到“API Keys”入口。点创建，给你填一个自己认识的名字，比如“openclaw-local”，生成之后系统只会完整显示一次，复制保存到你的环境变量文件里。

这个环节我见过太多人翻车：Key 没保存，刷新页面后发现自己永远看不见了，只能重新创建。建议准备一个专门记配置的本地文件，或者直接往.env里填，填完再复制一份备份到密码管理器。DeepSeek 的 API Key 是sk-开头的一长串字符，配置里我习惯用双引号包起来，防止后续被命令行工具解析时吞掉字符。

3.2 核心配置：兼容 OpenAI 协议的三个关键字段

OpenClaw 内核对大模型的调用走的是 OpenAI 兼容协议，所以接 DeepSeek 的本质就是告诉内核三件事：接口地址、密钥、模型名。在.env里找到 LLM 相关配置段，大致填写如下（具体字段名可能随版本有出入，以项目自带 sample 文件注释为准）：

LLM_PROVIDER=deepseek_openai LLM_BASE_URL=https://api.deepseek.com LLM_API_KEY=sk-你的密钥 LLM_MODEL=deepseek-chat

拆开解释一下为什么这样填：

• LLM_PROVIDER：有些版本叫OPENAI_COMPATIBLE或CUSTOM_OPENAI。看到OPENAI别误会成非要接 OpenAI 官方，它只是声明“我要用 OpenAI 格式的协议去访问一个第三方服务”。
• LLM_BASE_URL：DeepSeek 的接口根地址，注意这里不要加/v1尾巴。不少文档会写成https://api.deepseek.com/v1，实测兼容层会自动补路径，加了反而可能拼出重复路径导致 404。
• LLM_MODEL=deepseek-chat：这是 DeepSeek 对外对话模型名，对应 V3 系列。如果你需要深度思考那一档（对应 R1），可以改成deepseek-reasoner。
• TEMPERATURE=0.6：采样温度，控制回复随机性。日常助手 0.6 比较稳，创意生成可以调到 0.9，事实问答放到 0.3。

配置里通常还有MAX_TOKENS、CONTEXT_LIMIT之类参数，刚开始全部保持默认，等跑通后再按需优化。

3.3 接入后先做一次四步验证

配置完 DeepSeek 这边，我强烈建议先用一行命令独立验证密钥本身没问题，免得后面 OpenClaw 出问题时误伤排查方向。在终端执行：

curl https://api.deepseek.com/chat/completions ^ -H "Content-Type: application/json" ^ -H "Authorization: Bearer sk-你的密钥" ^ -d "{\"model\":\"deepseek-chat\",\"messages\":[{\"role\":\"user\",\"content\":\"你好\"}],\"stream\":false}"

注意^是 Windows cmd 的续行符，如果你习惯用 PowerShell，换成反引号。正常返回的 JSON 里会有content字段，里面有正经的回复文本，说明 Key、模型名、地址三者全对。

返回401 Authentication Fails，说明 Key 错了；返回Model Not Exist，说明模型名填得不对；返回 404，多半是基地址多加了路径。这些前置问题尽量在命令行阶段解决，后面进 OpenClaw 会省掉一大半的排查时间。

3.4 多 Agent 下怎么分配模型

OpenClaw 支持在一个实例里跑多个 Agent 角色，每个角色可以指定不同的模型。我平时会在 Agent 定义文件里给“客服助手”指定deepseek-chat，给“深度分析助手”指定deepseek-reasoner，这样花销看得明白，效果也分得清。

这里有个经验：想让 Agent 话多、回复快，选deepseek-chat；涉及步骤推理的任务，比如“帮我分析这段代码为什么报错”，R1 的思维链能力明显更强，但响应时间会拉长。群里用的时候等待太久体验反而差，所以我的默认角色一直坚持放deepseek-chat。

4. 飞书自建应用与消息通道的打通

4.1 一步步创建飞书自建应用

飞书机器人不是“开通就有”，得在开放平台创建一个“企业自建应用”。详细流程我拆成六步：

1. 打开飞书开放平台，进入开发者后台，选择“创建应用”，类型选“企业自建应用”。
2. 给它起个名字，比如“本地小助手”，图标随便选一个。创建完成后进入应用详情页。
3. 在左侧“应用能力”里添加“机器人”能力。这一步决定了飞书会话里能不能 @ 到它。
4. 在“凭证与基础信息”页面找到App ID和App Secret。App Secret 默认隐藏，点刷新后只显示一次，立刻复制保存。
5. 进入“权限管理”，搜索并开通这几个权限：
   • im:message.receive_v1（接收单聊/群聊消息）
   • im:message:send_as_bot（以机器人身份发送消息）
   • im:chat:readonly（读取群信息，用于判断上下文） 权限名称可能因平台版本略有差异，但逻辑就三类：收消息、发消息、看群信息。
6. 进入“版本管理与发布”，创建一个新版本并发布。自建应用不发布版本，配置是不生效的，发布后如果企业有审批流程还得等管理员通过。

注意：创建应用前你至少要是该企业成员并且有开发者权限。如果测试企业只有你一个人，流程更简单，发布会直接通过。

4.2 选长连接还是 Webhook：本地部署的唯一合理答案

飞书给事件订阅提供了两个模式，这里必须讲清楚，因为这一步直接决定你后续能不能跑起来。

Webhook 回调模式：飞书服务器把消息事件通过 HTTP POST 推到你指定的 HTTPS 地址。这意味着你必须有公网可达的服务器或内网穿透隧道，还要配域名和 SSL 证书。本地 Windows 裸机几乎不适合，直接放弃。

长连接模式：飞书开放平台支持客户端与服务端建立长连接，事件通过这个连接推送下来。客户端不需要公网 IP、不需要入站端口，只要你的 Windows 能正常访问飞书服务器即可。OpenClaw 的飞书适配器干的正是这件事。

所以走到“事件订阅”时，请求方式选项一定要选“使用长连接接收事件”，然后添加事件接收消息 im.message.receive_v1。添加完，飞书页面会提供加密密钥配置项，按需开启事件加密，开启后把 Encrypt Key 也复制保存，等下填进 OpenClaw 配置。

4.3 OpenClaw 侧的飞书字段与白名单

回到 OpenClaw 配置，找到飞书相关字段。我填过的最小集合是这个样子（字段名因版本会有出入，以 sample 注释为准）：

FEISHU_APP_ID=cli_xxxxxxxx FEISHU_APP_SECRET=你的AppSecret FEISHU_ENCRYPT_KEY=可选，事件加密密钥 FEISHU_MODE=long_connection FEISHU_ALLOWED_USERS=ou_xxxx,ou_yyyy FEISHU_ALLOWED_GROUPS=oc_xxx

最后两项是安全控制：只允许指定的用户 open_id 或群 ID 跟机器人对话，其他人发消息一律忽略。这个白名单务必加上，否则只要 App Secret 泄露，任何人都能拿你这个机器人消耗模型额度。

用户 open_id 怎么找？在飞书群里随便发一句话，到飞书后台的“事件接收”开发调试日志里，能看到每条消息的sender_id.open_id，复制出来填进去即可。如果赶时间，也可以先用通配符*跳过限制，联调成功后再收紧。

5. 端到端联调：从飞书消息到 DeepSeek 回复的完整链路

5.1 用前台模式启动，观察两条关键日志

配置都填好之后，首次建议直接前台启动：

npm start

正常启动后日志分两条线索，你要学会从里面读信息：

1. 飞书适配器初始化：会打印connect success或long connection established之类，说明长连接已经拉起来了；
2. Agent 初始化：会打印agent loaded和模型就绪信息，说明 DeepSeek 连接验证通过。

如果只看到飞书连接成功但 Agent 报错，大概率是模型配置有问题，回到第 3 章的命令行验证；如果 Agent 正常但飞书连接失败，检查 App Secret 和长连接参数是否填对。

5.2 第一个对话，以及链路中每一跳在做什么

在飞书里拉一个群，把机器人拉进群，然后@机器人 你好。从发送到收到回复，消息实际经过五跳：

1. 飞书服务器通过长连接把消息事件推给 OpenClaw，事件体包含消息文本、发送者 ID、群 ID；
2. OpenClaw 做权限校验：发送者是否在白名单、群聊里是否 @ 了机器人（单聊默认不用 @）；
3. 校验通过后，消息进入 Agent 上下文管理，OpenClaw 把历史消息拼接起来，构造请求体；
4. OpenClaw 调用 DeepSeek 的/chat/completions接口，带上用户消息和 Agent 的 system prompt；
5. DeepSeek 返回文本，OpenClaw 通过飞书机器人接口把回复写回原会话。

第一次回复慢几秒很正常，模型推理要时间，首轮还有上下文初始化开销。如果回复里带了 @ 你的群聊提醒，说明整条链路是通的。

5.3 多轮对话的记忆边界

接着问一句“我刚刚说了什么”，如果机器人能接上，说明多轮上下文没问题。这里要打破一个常见误解：多轮对话不是“开着就有记忆”，而是 OpenClaw 把最近 N 轮消息缓存起来，每次请求时拼接发送。

记忆长度取决于CONTEXT_LIMIT这类参数。我日常按场景调：普通问答上下文不超 10000 token，塞太多杂音会拉低答复质量；做长文分析时放宽到 30000 以上。另外 OpenClaw 按会话维度隔离上下文，不同群之间对话不串味，这也是我敢把它放团队群的原因。

6. 常见故障排查与稳定性优化

6.1 三种 404 的区分：模型、接口与事件

调试阶段我踩过三个方向完全不同的 404，症状看起来差不多，根因完全不同，整理成一张表：

现象	报错特征	根因	解决办法
模型不存在	model not found	模型名填错，比如把deepseek-chat写成deepseek-v3	改成官方文档里的deepseek-chat
接口路径重复	404 Not Found	base_url末尾多了/v1	去掉尾巴，只留https://api.deepseek.com
飞书事件收不到	日志里完全没有消息事件	没添加im.message.receive_v1或应用没发布版本	回后台补事件、发版本
消息发出但机器人不理	日志显示请求成功但用户无感知	白名单没放行，或群聊没 @ 机器人	加白名单，群聊务必 @

排查顺序永远是：先看飞书事件有没有进来，再看有没有构造 DeepSeek 请求，最后看回复有没有发出去。日志把链路切成三截，每一截正常与否一目了然。

6.2 长连接为什么会自动断开

长连接模式免了公网回调，但连接偶尔会自动断开重启。如果日志里一会儿disconnect一会儿reconnect，别慌，多数是正常重连，OpenClaw 内置了自动重连逻辑。真正要警惕的是断了之后长时间重连不成功。

我碰到的原因主要有三类：电脑休眠把网络栈拉垮了；中途切换 Wi-Fi 导致出站连接被重置；偶尔是管理员在飞书后台重置过应用凭证，导致 Secret 失效。对应的解法分别是：在电源设置里关掉“允许计算机关闭此设备以节约电源”，网卡属性里把节能相关的勾选去掉；或者设置 Windows 电源计划为“始终接通电源”；凭证失效就回到开发者后台重新复制并更新配置。

6.3 进程守护方案：pm2 在 Windows 的用法

Node 进程崩了没人管，机器人就无声下线了。Windows 下保活的核心思路就两条：开机自启 + 崩溃拉起，最省心的方案是pm2：

npm install -g pm2 cd D:\dev\openclaw pm2 start npm --name openclaw -- start pm2 save

pm2 save会保留当前进程列表。Windows 重启后要让 pm2 自动恢复，还需要装一个开机启动插件：

pm2 install pm2-windows-startup pm2-startup install

这样 Windows 登录用户后，pm2 会按保存列表自动把 openclaw 拉起来。如果追求更轻量的系统级服务注册，也可以用 NSSM 把 Node 入口注册成 Windows Service，做到开机无需登录就运行。二选一即可，我个人选 pm2，因为它自带日志查看和重启策略，对排错更友好。

6.4 日志、调试开关与 API 错误码速查

排错时把日志级别调到 debug 是最快的方法：

LOG_LEVEL=debug npm start

打开之后你能看到每个 HTTP 请求的时序和结果。我再给一个极简速查表：

• 飞书 API 返回19001或235开头错误码：权限没配齐，复查 4.1 节的权限步骤；
• 返回401：App Secret 错误或已过期，重新复制并更新环境变量；
• DeepSeek 返回401：API Key 错误；
• DeepSeek 返回429：触发限流或余额不足，去控制台查余额；
• 整体无响应但 CPU 占用高：检查是不是两个机器人互相 @ 形成了死循环。

结语：这套方案跑起来之后的一点个人体会

这套东西已经在我的 Windows 电脑上稳定跑了一个多月，最深刻的体会就是“本地私有、随叫随到”八个字。所有对话记录都存在自己机器上，没有第三方中转，日志说翻就翻，模型额度花多花少一目了然。日常工作里我把它拉进项目群，让它做会议记录、整理待办、给新同学讲背景资料，它从不缺席。最关键的是，配置好之后你就真的不用再管它，偶尔想起来看一眼日志，确认它还在正常值班就够了。

如果接下来想继续折腾，我建议优先研究 MCP 工具链，让机器人从“只能聊天”升级到“能动手干活”，比如执行定时任务、查询内部数据、读写本地文件。Windows 原生这条路选定了，就别再纠结什么 WSL 不 WSL，先跑起来再说，坑都是一步步踩平的。