趁着周末把 OpenClaw前身 Clawdbot部署到了本地接着用扣子编程配通了飞书机器人全程没有写一行代码。OpenClaw 负责在本地执行 Agent 任务扣子负责无代码编排对话流程飞书机器人负责当日常聊天入口。最后的效果是我在飞书里发一句“把当前任务整理成表格发我”机器人真能把一张 Markdown 表格推回群里。这篇把整个部署过程、配置逻辑和踩过的坑完整复盘一遍想不写代码就搞一个飞书 AI 助理的朋友照着走基本能复现。1. 这个组合到底怎么分工OpenClaw、扣子、飞书的三角关系1.1 先搞清楚三样东西各自是干嘛的OpenClaw 是一个本地优先的 Agent 管理框架基于 Node.js 开发社区里习惯叫它“智能体管家”。它的特点是能理解自然语言指令并且能连接本地工具和资源——比如读本地笔记、调用脚本、操作各种服务。部署到自己的电脑上之后相当于给机器配了一个常驻的 AI 执行员你说一句话它就尝试帮你把活干了。扣子是字节跳动的无代码 AI 应用搭建平台核心是“工作流”和“插件”。它的设计理念是把编程逻辑图形化不需要写 if、for、函数调用而是把功能节点拖到画布上连线、配参数、填提示词一个完整的对话应用就组装出来了。所以在标题里说的“扣子编程”本质上是“编排”不是“编码”。飞书机器人是整个系统的前台。把应用加进飞书会话之后用户的每一条消息都会经过飞书的事件订阅机制送到后端处理处理结果再以消息形式返回。你不需要额外装 App也不用学任何指令就是在聊天框里正常说话。我做了一个比较直观的类比飞书机器人是前台接待扣子是总调度室OpenClaw 是真正干活的员工。前台把你的话传给调度室调度室分析意图、规划流程员工去执行最后结果再沿原路返回给你。三层各管一段谁都不过于复杂。1.2 一次完整请求是怎么流转的用“发送表格”这个场景来拆解一次完整请求消息链路大致是这样用户在飞书里发消息“把本周任务整理成表格发我”飞书机器人把消息事件推送到扣子 Bot扣子工作流让大模型判断用户意图要的是“任务整理 表格输出”工作流调用 OpenClaw 插件把指令转发到本地 OpenClaw 服务OpenClaw 读取本地的任务数据按指令整理结果返回结构化文本扣子工作流再用一个大模型节点把结果整理成 Markdown 表格扣子把最终结果通过飞书机器人发回会话这 7 步里真正需要 OpenClaw 干重活的只有第 5 步其余步骤全是扣子工作流里配置出来的。这也是无代码方案的核心思路把复杂的 Agent 能力藏在本地把流程控制交给可视化编排两边各干最擅长的事。1.3 为什么选这个组合直接代码开发和纯扣子 Bot 差在哪如果不用扣子直接在飞书开放平台自建应用开发路径大概是申请 App ID、配置事件订阅、写消息处理逻辑、处理回调验签、再用 API 发消息。这一套下来全是代码活对不想写代码的人来说基本等于劝退。光是验签和回调地址的坑就能耗掉一整天。如果只用扣子 Bot 但不接 OpenClaw扣子本身只能调用云端的插件和服务本地文件、私有数据、自己电脑上的工具全部碰不到。扣子确实自带不少插件但涉及个人本地数据的时候能力天花板非常明显。把三者串起来正好互相补短板我用一个表格说明方案实现门槛能干什么主要短板纯飞书机器人开发高需写服务端代码收发消息、完全自定义逻辑开发维护成本大验签和部署麻烦纯扣子 Bot低拖拽配置对话、知识库、云插件碰不到本地资源私有数据无法使用扣子 OpenClaw 飞书低无代码编排对话编排 本地 Agent 执行需要维护本地服务和端口映射这套组合的核心价值是把“AI 能力”和“本地执行力”合并到一个聊天窗口里。对个人用户来说最直接的好处就是日常办公里那些整理、汇总、查询的小事不用再手动切换工具直接在飞书里说一句话就能拿到结果。2. 部署前的准备环境、账号、依赖一个都不能少2.1 先列一份物资清单动手之前先把东西备齐不然装到一半发现缺账号缺环境会非常被动。我当时的完整清单是一台常开的电脑Windows / Linux / macOS 都行我用的是 Windows 配 WSL2Node.js 20 及以上版本从官网下载 LTS 包Git用来拉取 OpenClaw 项目扣子账号直接在扣子官网注册飞书账号最好有飞书开发者后台的权限一个端口映射工具用于把本地端口暴露到公网供扣子和飞书调用这里解释一下为什么 Node.js 是硬性依赖OpenClaw 整个项目跑在 Node.js 运行时上依赖管理和项目启动都靠 npm 完成版本太老或者没装后面npm install和npm start都跑不起来。建议直接装 LTS 版本没必要追新。2.2 Windows 用户先把 WSL2 环境弄干净Windows 上部署 OpenClaw 最容易出问题的环节就是 WSL2。OpenClaw 的脚本和依赖有很多面向 Linux 环境的逻辑在 WSL2 里跑比在原生 PowerShell 里跑顺得多。WSL2 不是一个完整虚拟机它相当于 Windows 内嵌的轻量 Linux 环境资源占用低启动速度快对 Node.js 项目非常友好。配置步骤不复杂以管理员身份打开 PowerShell依次执行wsl --install装完之后重启电脑。重启后再开一个管理员 PowerShell执行wsl --status确认输出的默认版本是 2。如果版本不对或者提示需要更新内核继续执行wsl --update wsl --set-default-version 2这里有一个经常被忽略的细节wsl --install装完系统默认发行版后还要进到发行版里完成账号初始化。我第一次就是只装了 WSL 框架没初始化 Ubuntu结果 OpenClaw 的所有命令都提示找不到环境绕了很大一圈才排查清楚。所以装完 WSL2 之后第一时间打开 Ubuntu 终端设置一个 Linux 用户名和密码把基础环境“激活”。2.3 安装 Node.js 并确认环境变量去 Node.js 官网下载 LTS 安装包装完在 WSL 终端里验证node -v npm -v能正常打印版本号就说明 Node.js 环境没问题。有一点要提醒在 Windows 下直接安装 Node.js 和在 WSL2 内安装 Node.js 是两套完全隔离的环境OpenClaw 跑在 WSL2 里就必须在 WSL2 内能执行node -v。如果发现 WSL 里找不到 node那就是要进 WSL 终端重新安装而不是在 Windows 侧安装。关于版本管理我的建议是用 nvmNode Version Manager来管理 Node.js而不是直接装系统级版本。早期我图省事直接装了系统级 Node后来项目要求升级版本差点把机器上其他依赖搞崩。换 nvm 之后切换版本就一条命令的事代价是前期要多装一个工具但后面非常省心。3. OpenClaw 本地部署实操把 Agent 引擎跑起来3.1 拉取项目代码并安装依赖进入 WSL 终端在工作目录执行git clone https://github.com/OpenClaw/clawdbot.git cd clawdbot npm install npm run setupgit clone是拉取官方仓库的最新代码用这种方式比下载压缩包好在以后升级方便一句git pull就能同步更新。npm install会安装全部依赖这一步输出的日志特别长是正常现象耐心等它跑完就行。npm run setup是用来初始化项目配置的第一次执行会生成默认配置文件和目录结构。这一步最容易出的问题是 Node 版本太低导致npm install中途报错。遇到报错不要急着去网上搜答案先执行node -v看版本如果低于 20直接升级 Node 再重来。如果遇到权限类报错大概率是之前用系统级 sudo 装了全局依赖建议把环境切换到 nvm 管理后再试不要跟权限问题硬刚。3.2 启动 OpenClaw 并完成首次对话依赖装好后启动命令是npm start首次启动会进入配置引导需要完成三件事设置 Agent 名称和身份、选择要接入的大模型、选择默认启用的工具集。重点说大模型这块。OpenClaw 自身不带推理能力天然需要接一个 LLM 才有“脑子”。最快的方案是接入云端大模型 API填一个 Key 就能用也可以接本地模型服务比如 Ollama 里跑的 qwen2.5-3b 这类小参数模型。本地模型的好处是数据和请求不出本机请求的隐私性好一些坏处是推理速度比云端大模型慢效果也受硬件性能影响。如果你只是想把个人助理跑通先用云端 API 最省事后续再折腾本地化也不迟。配置完成之后在终端里发一句“你好介绍一下你自己”OpenClaw 能正常回复就说明本地 Agent 已经活了。我当时的第一个回复内容不是重点重点是循环跑通之后整个系统的心情立刻不一样了因为后面所有工作都建立在“OpenClaw 本身是一个可对话的 Agent”这个基础上。3.3 把本地服务端口映射到公网OpenClaw 启动后会在本地监听一个 HTTP 端口常见的是 4000 端口具体以项目文档为准。问题是扣子是云端服务它访问不到你电脑的 localhost所以这里必须做一步端口映射。操作思路是用一个端口映射工具把本地 4000 端口映射成一个公网可访问的 HTTPS 地址。工具会给你返回一个公网 URL之后在扣子插件里填这个 URL扣子就能调通 OpenClaw。这一步的次序建议是先测通再配置。映射完成之后用 curl 或者浏览器访问一下公网 URL确认能收到 OpenClaw 的响应再去做扣子侧的配置。千万不要反过来两边全部配完才发现网络不通到时候排查链路长了不止一倍。我吃过这个亏第一次直接跳过连通性测试结果扣子插件一直报 502排查了半天才发现映射工具的免费域名过期了。4. 扣子侧无代码编程工作流搭建与 OpenClaw 接入4.1 创建一个 Bot 并搭出基础工作流登录扣子控制台新建 Bot选择“工作流”模式。画布上默认有一个开始节点和一个结束节点接下来要在这条最小链条上补节点开始节点接收用户发来的文本消息作为整个工作流的输入大模型节点让模型判断用户意图并为后续节点生成指令插件节点调用 OpenClaw执行本地任务大模型节点可选把 OpenClaw 返回的结果重新整理为指定格式结束节点把最终内容输出给飞书扣子工作流的用法在官方教程里有很多但有一个经验值得单独说画布上每个节点都有限定的输入输出别想着把逻辑全塞进一个节点里。意图判断、任务执行、结果格式化尽量拆成独立节点每个节点只干一件事。这样调试时看节点日志非常清晰哪一步出问题直接定位。我见过有人把提示词写成一个超长的大模型节点结果日志里完全看不出是哪步拦截了消息浪费时间还容易心态崩。4.2 通过自定义插件把 OpenClaw 接入工作流在扣子的“插件”入口创建一个自定义插件把 OpenClaw 的 HTTP 接口描述交给扣子。操作上把接口的 Base URL、请求路径、请求方式和参数说明按 OpenAPI 格式填好扣子会自动生成一个可拖拽的插件节点。之后在工作流里直接拖出这个节点输入参数是“给 OpenClaw 的自然语言指令”输出参数是“OpenClaw 返回的结果”。到这里扣子已经可以“指挥”本地的 OpenClaw 干活了。有一个细节OpenClaw 返回的原始结果里经常混着很多技术字段比如工具调用的状态、中间日志等不能直接发给用户看。不需要着急写代码去解析往下游加一个大模型节点让模型“从返回内容里提取用户需要的部分按指定格式输出”就行。这是无代码组合里非常实用的一招相当于把格式化工作外包给大模型而不是自己写正则和解析逻辑。4.3 把扣子 Bot 发布到飞书扣子官方提供了和飞书的集成。发布 Bot 时选择飞书渠道扣子会自动创建对应的飞书机器人应用并配置事件订阅发布完成后直接在飞书里搜索这个机器人就能开始对话。这个方式最简单不用手动配置回调地址适合绝大多数个人用户。如果企业要求用自己名下的飞书应用也可以手动去飞书开放平台创建应用再把事件订阅回调地址指向扣子的 Webhook。这里有一个硬性要求飞书要求回调地址必须 HTTPS所以第 3 章做的端口映射必须能输出一个 HTTPS 公网地址这一步卡住了非常多的人甚至包括一些写代码很熟练的朋友。5. 飞书机器人配置与“发送表格”实战5.1 飞书开放平台创建应用并开启机器人手动创建飞书应用的流程大致是进入飞书开放平台创建一个“企业自建应用”然后在“机器人”能力里打开机器人开关。创建完成后后台会给你 App ID 和 App Secret 两个关键凭证后面配置权限、发送消息都要用到。紧接着配置“事件订阅”订阅“接收消息”事件。回调地址填扣子提供的 Webhook 地址。这一步做完之后建议立刻做一次连通性测试在飞书里给机器人发一条消息然后去扣子工作流日志里看有没有新请求进来。有日志就说明事件链路通了没有日志就回到回调地址和权限配置上找问题。5.2 权限申请与版本发布飞书机器人要收发消息必须申请消息相关的权限常见的两个是im:message和im:message:send_as_bot。申请完权限并不等于立刻生效还要在“版本管理与发布”里创建一个新版本并发布权限才会真正挂到应用上。这里是我踩过的第三个坑权限申请了审核过了但忘了发布新版本结果机器人能收到消息却发不出回复。后来在飞书后台把应用版本一发布一切恢复正常。权限申请、审核、发布这三个动作缺一不可很多“机器人不回复”的问题根子就在这里。5.3 实测让机器人把结果整理成表格推回来全链路跑通之后我在飞书私聊里直接发了一句“把当前任务列表整理成表格发我”。机器人返回的是一张带表头、内容分列清晰的 Markdown 表格而不是一坨没有结构的文字。这一步的实现思路是在扣子的结果格式化节点里让大模型按固定格式输出表格并在提示词里明确指定列名比如“任务名称、状态、截止时间”模型就会根据 OpenClaw 返回的数据填充表格内容。如果你想要更正式的样式在飞书里可以用消息卡片模板。下面是一个示意 JSON展示了卡片的基本结构{ msg_type: interactive, card: { header: { title: { tag: plain_text, content: 待办任务清单 } }, elements: [ { tag: markdown, content: | 任务 | 状态 | 截止 |\n| --- | --- | --- |\n| 写周报 | 未开始 | 周五 | } ] } }实测下来的经验是纯文本 Markdown 表格最稳消息卡片在字段少的时候很好看但复杂任务里内容一多卡片反而容易被折叠或截断。所以日常使用我一般优先走文本表格只有给领导汇报那种场景才用卡片。6. 常见问题与排查实录报错逐个击破6.1 Windows 下提示“无法安全验证 WSL2 环境”怎么办这是 Windows 用户最容易撞到的报错。我第一次看到“无法安全验证 WSL2 环境。请参考 wsl --status”这种提示时第一反应是重新安装 WSL后来发现完全不用。按提示执行wsl --status先看输出里的“默认版本”是不是 2“内核版本”有没有异常。如果默认版本是 1 或者没有内核信息继续执行wsl --update wsl --set-default-version 2如果更新完还是报错去 Windows“启用或关闭 Windows 功能”里检查“适用于 Linux 的 Windows 子系统”和“虚拟机平台”这两项有没有勾选。大部分这个报错都是 WSL2 没真正启用成功而不是 OpenClaw 本身的问题。6.2 Node.js 和 npm 安装阶段的高频报错安装阶段的问题相对集中我整理了几个高频场景提示 Node.js 版本过低去官网下载 LTS 版本确认当前终端执行的node -v是新版本。注意 WSL 里和 Windows 里的 Node 是两套环境别装错位置。npm install 跑一半失败先把 node_modules 目录删掉清理 npm 缓存再重新执行安装。一直卡在依赖解析或下载这种情况多数是网络波动多试几次通常能过不建议反复清缓存越清越乱。提示 EACCES 权限拒绝卸掉系统级 Node改用 nvm 管理版本再重装依赖。跟权限硬刚只会浪费时间。6.3 飞书侧消息收发异常遇到“机器人不回复”的时候排查顺序非常关键。我建议按下面的顺序来不要跳步机器人有没有成功发布到飞书飞书应用里的“机器人”能力有没有开启事件订阅的回调地址是否是 HTTPS并且公网可访问权限有没有申请并发布新版本扣子工作流日志里有没有报错按照这个顺序排查大概率能在前五步内找到问题。我遇到最多的情况是回调地址不通或者权限未发布真正需要去改工作流逻辑的情况反而很少。6.4 避坑经验速查表最后整理一张速查表把前面提到的坑集中起来现象主要原因解决办法OpenClaw 启动后自动退出端口被占用换一个监听端口或关闭占用进程扣子插件测试报 400HTTP 接口路径或参数名不对回 OpenClaw 文档核对路径和参数飞书收不到表格内容权限未发布新版本在飞书开放平台发布应用新版本机器人回复内容乱码编码格式不统一在扣子大模型节点里指定 UTF-8 输出本地模型回复很慢模型参数太小或机器性能不足换云端大模型 API或升级硬件配置最后说一点真实体会。整套系统折腾下来最大的感受是把 OpenClaw、扣子、飞书串起来本质上是在搭一条“需求—执行—反馈”的链路每一环都不难难在把前置环境弄干净。部署前把 WSL2、Node.js、端口映射这三件事搞定后面的工作流配置基本都是一次过。我现在还常用这套组合在飞书里让机器人汇总周报、提醒待办甚至让它去翻本地笔记日常生活里用得最多的一句话反而是“发送表格”。如果你希望数据完全留在本地可以给 OpenClaw 接 Ollama 里的 qwen2.5-3b 这类小模型飞书机器人照常工作只是响应会慢一些。又或者你想换更强的模型OpenClaw 这类框架一般也支持接入其他大模型服务自由度高很多。这篇记录不追求炫技只希望让没写过一行代码的朋友也能照着把系统跑起来。希望你能少踩几个我踩过的坑一次成功。