先说一个我观察到的现象大多数人玩 AI 助手还停留在“打开网页、输入问题、等回复”的阶段。真正把 AI 用进工作流的人早就换了思路——不是你去问它而是它主动来找你。把 OpenClaw 接进飞书之后团队群里躺着一个机器人你说一句“把昨天报表整理成多维表格发群里”它自己就干完了。这篇就是我从零开始在云服务器上部署 OpenClaw 并接入飞书的完整记录涉及选型、安装、飞书应用配置、skill 扩展、以及几个让人头大的报错排查给同样想折腾这套东西的人一个可以直接抄的作业。先说结论OpenClaw 不是又一个聊天机器人框架它更像一个“AI 能力调度网关”。模型只负责思考和生成真正干活靠的是围绕它转的各类 skill。飞书则是目前把 AI 塞进办公场景最顺手的入口有现成的机器人 API、多维表格、消息卡片一套组合下来相当于给团队配了个 24 小时在线的数字员工。下面按我实际操作的顺序把这套体系的每个环节拆开讲。1. OpenClaw 是什么一个把 AI 拽进消息流的开放智能体网关1.1 它到底解决了什么问题和 codex 等工具的本质区别很多人第一次搜 OpenClaw是因为看到了“openclaw 与 codex”这个对比词。这俩东西表面看都是命令行工具但定位完全不同。Codex 这类工具解决的是“在代码场景里帮你写代码”核心是代码生成与执行它的活动范围基本限定在仓库、终端、沙箱环境里。OpenClaw 则是一个泛化的智能体运行框架它不关心你用的是哪个模型也不限定任务类型它做的是把“模型能力”和“外部动作”连接起来。打个比方Codex 像一个只会修车的老师傅技术很好但你得把他带到车前OpenClaw 像一家 24 小时调度中心接到电话后派哪个师傅、开哪辆车、带什么工具都由调度中心统一安排。外部世界每接入一个 channel飞书、微信、Telegram、网页就等于给调度中心多装了一部电话每装一个 skill就等于给师傅的工具箱里多塞了一套工具。我最初被 OpenClaw 吸引就是因为它的可插拔结构。模型层可以用 OpenAI、Claude也可以用本地 Ollama 跑的量化模型消息层支持飞书、微信、Discord 等动作层靠 skill 无限扩展。这三层互不绑定意味着你可以用免费本地模型跑一个只服务内部群的机器人也可以接最强商业模型处理复杂任务模型升级或切换对飞书机器人侧完全无感。1.2 为什么先用飞书而不是微信网上很多人问“openclaw 微信”我也试过但客观说微信对机器人的限制非常多。个人微信没有官方机器人接口网页版协议不稳定风控严格一不小心就封号。飞书则完全是另一套逻辑它官方支持自建应用、机器人、事件订阅、消息卡片、多维表格 API是开放平台级的 IM天生适合做自动化办公。从团队协作角度看飞书的“群聊 机器人点名”模式特别好用。你在群里 机器人它就能收到消息并把结果回传到群里想把结构化数据展示出来飞书有多维表格和消息卡片比在微信里发一段纯文本体验好太多。如果你只是个人玩接微信也并非不行但不是官方通道稳定性全看第三方方案的维护力度。我刚上手时直接从飞书开始少走了很多弯路。1.3 和 ClawHub 的关系引擎与技能市场热词里有一组“openclaw跟clawhub的区别”这俩名字太像确实容易混。OpenClaw 是运行引擎本体负责加载配置、调度模型、分发消息、执行 skill。ClawHub 则是围绕 OpenClaw 建立的技能分发社区你可以把它理解成 VS Code 和它的插件市场的关系。OpenClaw 装了 ClawHub 插件或者在配置里指向 ClawHub 源之后就能用skill install这类命令一键安装社区里发布的技能包比如飞书表格处理、网页抓取、定时任务。我一直觉得OpenClaw 的精髓就在于 skill 生态脱离 ClawHub 它只是一个空壳引擎接上 ClawHub它才变成可以自由组装能力的平台。后面我会专门讲 skill 怎么装、怎么写。2. 云主机选型与运行环境准备这一步决定你后面少踩多少坑2.1 系统与配置建议Ubuntu 22.04 为主标题里的 HoRain云 是我这次用的云服务器实际体验下来它只是个普通的云主机。你完全可以用任何一家云服务商配置思路是一样的。我的选型标准系统 Ubuntu 22.04 LTS2 核 4G 起步硬盘 40G 以上。如果只是跑一个飞书机器人加上各种普通 skill2C4G 够用如果你想用本地 Ollama 跑 7B 级别模型内存建议直接上 16G不然模型加载就会把内存吃满。为什么优先选 Ubuntu因为 OpenClaw 在 Linux 环境下的依赖安装最省事很多运行时组件比如浏览器控制、容器管理对 Linux 的支持也最完整。不建议一上来就在 Windows 服务器上搞后面遇到权限、路径、依赖冲突的问题会多不少。如果你已经在用云主机建议装好之后先做两件事更新系统包配置好 swap 分区。模型推理和依赖编译都比较吃内存swap 至少给 4G能有效避免 OOM 把进程杀掉。2.2 开放端口与域名/回调之前的预判飞书接入有两种事件接收方式后面会细说。这里先说端口规划默认情况下 OpenClaw 会监听一个本地管理端口具体端口看版本配置你不需要把它直接暴露到公网管理界面通常本机访问或通过 SSH 隧道访问就够了。真正涉及公网的是飞书机器人回调如果走 Webhook 回调模式飞书服务器要能访问到你服务器上的 HTTPS 地址。这意味着你需要提前准备一个公网可达的域名和有效证书或者用长连接模式来绕开这一步。我在第一次部署时就因为没预判到这一点在回调地址上卡了很久。教训是搭环境之前先想清楚走哪种事件接收模式再决定要不要提前配域名。如果只是内部测试强烈建议直接用飞书的长连接模式省掉公网回调配置后面讲飞书配置时会具体说。2.3 一台 Windows 电脑也能当开发环境热词里有“win11 openclaw 安装”和“powershell安装openclaw 能指定目录吗”说明很多人在 Windows 本地折腾。实话说Windows 上跑 OpenClaw 不是不可以尤其是你本地已经有 WSL2 的情况下体验会好很多。如果坚持在 Windows PowerShell 里直接装要注意安装目录可以通过OPENCLAW_HOME之类的环境变量指定不同版本环境变量名可能会有差异安装文档里会写默认目录一般在用户目录下路径里有空格或中文容易出问题。我个人的建议是Windows 本机只做开发调试生产环境还是放 Linux 服务器。Windows 上装完之后要跑服务会遇到防火墙弹窗、路径分隔符、权限不足等一系列小问题调试成本不低。把服务器当“生产环境”把本机当“临时调试台”这个分工能让你心态平和很多。3. OpenClaw 安装、升级与卸载的完整操作3.1 Ubuntu 上的安装与目录规划OpenClaw 的安装方式在不同版本之间变化挺快我装的时候是直接通过官方提供的安装脚本装的本质是把运行文件放到指定目录并生成初始配置。安装之前先把目录规划好比如我习惯把所有数据放在/opt/openclaw配置目录和工作目录分开方便后面备份和升级。安装步骤大致是这样# 更新系统基础包 sudo apt update sudo apt upgrade -y # 根据官方 README 执行安装不同版本命令有差异以官方文档为准 curl -fsSL https://get.openclaw.example/install.sh | bash装完以后建议立刻做三件事。第一确认命令能正常执行比如openclaw --version第二初始化配置目录生成默认配置文件第三启动一次服务并看日志是否正常。第一次启动会创建基础目录结构和默认配置如果这里就报错优先检查依赖版本和系统架构大多数安装失败都是这两个原因。目录权限也要注意不要用 root 跑常驻服务单独建一个系统用户跑更安全。3.2 Windows PowerShell 安装与指定目录Windows 上的安装同样可以通过官方脚本完成但 PowerShell 执行策略默认可能会拦截脚本需要先放开# 临时放开执行策略仅当前用户 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser # 执行官方安装脚本 irm https://get.openclaw.example/install.ps1 | iex关于“能不能指定目录”这个问题我实测是可以的。安装脚本一般会接受一个安装路径参数或者读取环境变量来改变默认位置。如果脚本没显式支持你还可以先设置用户级环境变量再执行安装。我强烈建议不要把 OpenClaw 装到C:\Program Files这类带空格的路径下运行时解析路径很容易出问题。装完之后把安装目录下的bin路径加到 PATH 里不然每次都要输全路径才能启动。Windows 上最容易踩的坑是防火墙。第一次启动监听端口时Windows 会弹出防火墙授权弹窗一定要点允许否则后面飞书回调或本地 Web 服务会莫名超时。另外一个坑是杀毒软件某些实时防护会把 OpenClaw 生成的临时脚本当风险文件隔离。我遇到过一次排查了半天最后在隔离区里找到了缺失文件加白名单才解决。3.3 升级和卸载保持干净“如何升级openclaw版本”这个问题频繁出现是有原因的。OpenClaw 迭代速度比较快新版本通常带来新能力但也会调整配置文件格式。我的升级习惯是三步走先备份配置目录再看官方 changelog 确认有没有破坏性变更最后执行升级命令。升级后如果服务起不来八成是配置文件里的旧字段不再兼容错误日志里一般会明确提示哪个字段有问题逐条改就行。卸载反而简单。如果当初是脚本安装的官方一般提供卸载脚本如果找不到就手动删除安装目录、配置目录再清理环境变量和开机自启项。Windows 上还要检查计划任务里有没有残留的启动项。把卸载做干净的好处是重装时不会被旧配置干扰尤其是你已经改了很多 skill 和通道配置的情况下旧配置残留容易和新版本产生诡异冲突。3.4 容器化部署与 NAS 场景的补充如果你在“飞牛安装openclaw 能干什么”这类词里看到了 NAS 部署我多说一句。NAS 上跑 OpenClaw 是可行的飞牛这类系统都支持 Docker官方或社区一般也会维护容器镜像。Docker 部署的本质是把服务、配置目录和数据卷映射出来端口映射规则和 Linux 裸装类似。NAS 的优势是 7x24 小时低功耗常驻劣势是 CPU 性能一般跑重一点的本地模型会吃力建议模型还是调用远程 APINAS 只负责跑调度逻辑。4. 飞书应用创建与消息链路打通4.1 创建企业内部自建应用并开启机器人飞书接入的第一步是在飞书开放平台创建应用。登录飞书开放平台后选择“企业自建应用”填个名字和描述提交后你会拿到App ID和App Secret这两个凭证后面配置 OpenClaw 时要用到务必保存好。创建完应用后第一件事是开通“机器人”能力。在应用的“添加应用能力”里找到机器人启用它。此时你的应用已经具备了收发消息的资格但还不能直接工作因为缺少权限。权限配置是很多人第一次接入时最容易忽略的环节。你需要至少申请这几个权限读取和发送单聊/群聊消息、以机器人身份发送消息、上传图片或文件如果后续要让机器人发附件、读写多维表格如果要用表格能力。权限申请后在企业管理后台里需要管理员审核审核通过才真正生效。接下来是事件订阅。飞书通过事件订阅把“用户 了机器人”这件事通知给你的服务你的服务收到事件后处理并调用 API 回复。没有事件订阅机器人就是聋子——你 它它根本收不到。在事件订阅里添加im.message.receive_v1事件然后选择接收方式这就是我前面提到的关键岔路口。4.2 事件订阅两种方式Webhook 回调与长连接飞书事件订阅有两种接收方式Webhook 回调和长连接。Webhook 回调模式要求你提供一个公网 HTTPS 地址飞书服务器会把事件 POST 到该地址。这个模式适合生产环境但对个人开发者不太友好因为你必须有公网域名和可信证书否则飞书会拒绝推送。我见过太多人卡在这一步报错信息里那句“network unavailable, please go to feishu network diagnosis to find the problem”让无数人抓狂后面我会专门讲这个报错。长连接模式就好办得多。飞书官方提供了长连接接收事件的能力你的服务主动连上飞书服务器事件通过这个常驻连接推给你。优点是不需要公网 IP、不需要域名、不需要配证书服务器只要能出网就行企业内部测试或家里服务器部署直接无脑选这个模式。我第一次部署时还不知道这个模式折腾半天证书和回调后来切成长连接几分钟就通了。4.3 配置 OpenClaw 的飞书通道参数飞书应用准备好之后回到 OpenClaw。在配置文件的channels或messengers区域不同版本命名不一样注意看版本文档添加飞书配置核心参数就几个app_id、app_secret、事件接收模式长连接或 Webhook、以及机器人名字。填完之后重启 OpenClaw如果日志里出现类似“feishu channel connected”或“长连接已建立”的提示恭喜你链路已经通了。我在这一步的经验是先不要急着验证复杂功能先在飞书里把自己的应用拉进一个测试群然后 机器人发条消息。如果它能回复说明事件订阅、权限、消息发送三个环节全通了如果不回复按顺序排查先看 OpenClaw 日志里有没有收到事件再看权限是否生效最后看回复调用是否报错。日志比什么调试工具都靠谱绝大多数问题都能在日志里找到线索。5. 让飞书机器人学会发表格消息与多维表格实战5.1 先分清“富文本表格”和“多维表格”“飞书机器人发送表格”是个高频需求但很多人其实没搞清楚自己要的是哪种表格。飞书里有两种“表格”实现方式完全不同。第一种是消息里的富文本表格本质是消息正文的一部分。通过飞书消息 API 的post类型发送富文本里面可以包含多行多列的表格结构适合在聊天窗口里直接展示少量数据比如“本周任务跟进表”这种三五行的内容。优点是实现简单不用额外建数据表缺点是没法交互、不能筛选排序数据量大了阅读体验很差。第二种是多维表格 Bitable它是飞书文档体系里的一个独立数据表。你需要先创建一张多维表格拿到app_token和table_id然后通过 API 逐行写入数据。写入完成后机器人把多维表格的链接发给用户用户点开就能看、能筛选、能协作编辑。这种方式适合真正的业务数据比如几十上百行的订单记录、任务清单。5.2 多维表格的写入链路与最小落地姿势多维表格的写入链路理解起来不难拿到凭证、找到数据表、逐行写入、返回链接。飞书开放平台提供多维表格的 API你需要在应用权限里加上多维表格相关的读写权限在权限管理里搜“多维表格”就能看到。一条最小可用的数据写入流程是这样用App ID / App Secret获取tenant_access_token这个 token 有有效期要注意刷新。调用创建多维表格或读取已有多维表格的接口拿到app_token。根据表名或表 ID 拿到table_id。构造记录数组每条记录是一个 JSON 对象字段名对应表头字段。批量写入接口一次可以提交多条记录写入成功后会返回记录 ID。把多维表格的 URL 拼出来发给用户。在 OpenClaw 里这个流程通常会被封装成一个飞书相关的 skill。你只需要在群里说“把下面这些数据整理成多维表格发我”它会自动完成创建表格、写数据、回传链接的动作。我第一次搭通这个链路时挺感慨的整套动作背后是五次 API 调用但对用户来说就是一句话的事。这就是 skill 封装的价值——把高频操作的复杂度藏起来让 AI 用自然语言直接驱动。这里要提醒一句多维表格的字段类型是严格匹配的数字字段写字符串会报错日期字段格式不认也会报错。如果你的数据源来自爬虫或手工整理的表格最好在写入前做一次字段类型校验。调试阶段多用飞书开放平台的 API 调试器它能看到完整的请求响应比在黑盒里猜报错原因高效太多。5.3 Lark CLI 在调试阶段到底怎么用热词里有“openclaw 飞书 lark cli 安装”说明不少人搜过。Lark CLI 是飞书开放平台提供的命令行工具可以在终端里直接调试应用凭证、发消息、查事件订阅状态。我个人的使用经验它最大的价值不在“生产”而在“调试”。举个例子飞书回调地址配好了却收不到事件推送你可以先用 Lark CLI 手动触发一个测试事件看 CLI 输出什么。如果 CLI 能收到说明飞书到你们服务的链路通了问题在 OpenClaw 的事件处理逻辑如果 CLI 也收不到说明链路压根没通要回飞书后台检查订阅配置。用排除法把“平台侧”和“应用侧”分开是排查接入问题最有效的方式。Lark CLI 的安装方式以飞书官方文档为准通常是 npm 或二进制包。装好之后建议把凭证配置到环境变量里这样不用每次敲命令都带参数。另外CLI 还能帮你验证tenant_access_token的生成和有效期这在调试权限问题时很实用。如果你搜到“vue 飞书h5免登录授权”这类词注意别混淆。那是飞书 H5 网页应用的免登场景用在 Web 前端要拿用户身份的场景跟机器人收发消息是两套体系。如果你后续想把 OpenClaw 的能力做成一个 Web 页面给团队用免登才有意义目前只是群聊机器人用不到。6. Skill 与本地模型OpenClaw 的能力扩展机制6.1 skill 的安装与目录结构前面多次提到 skill这章展开讲。OpenClaw 的 skill 本质上是一个包含配置清单、说明文档和可执行脚本的目录告诉模型“我有这个能力什么情况下调用我怎么调用”。安装 skill 的常见方式是通过 ClawHub 源命令大概是openclaw skill install skill-name。装完之后skill 会出现在本地技能目录里一般按名字分目录存放。一个典型 skill 目录里至少有这几个东西SKILL.md说明文件描述技能用途、触发条件、输入输出格式、manifest配置定义工具名称、参数 schema、以及实现逻辑的脚本Python、Shell 或 Node 都行。模型在决策时会先扫描这些说明判断当前任务是否需要调用这个工具再按 schema 生成调用参数。网上那些“妙想skill安装openclaw教程”之类的关键词本质就是在教大家安装第三方 skill 包。安装社区 skill 前我建议先看一眼它的 manifest 和脚本内容确认它只会做它声称的事不会偷偷读取敏感文件或外发数据。毕竟 skill 是以你的服务身份运行的权限控制要自己把关。6.2 让 OpenClaw 用本地 Ollama 干活不想为每个小任务付 API 费用又想要数据留在本地那就上 Ollama。OpenClaw 配置模型提供商时选 Ollama 类型把接口地址指向http://127.0.0.1:11434再填上模型名我用的是 qwen2.5:7b本地跑起来性能和效果均衡。配置好之后OpenClaw 发送给模型的请求会走本地推理消息链路完全不变飞书机器人照常工作。有一点要注意本地 7B 模型的理解和指令遵循能力和顶级商业模型还是有差距复杂任务容易理解偏。我的习惯是“轻活本地、重活远程”——群聊里简单的信息查询、格式整理走本地模型重要的数据分析、长文档总结走商业模型 API。在 OpenClaw 配置里按 skill 或按会话维度切换模型就能实现这种分流策略。6.3 自定义中转站的配置逻辑热词“openclaw 自定义中转站”也挺常见。所谓中转站本质上是一个兼容某类模型 API 规范的中间服务。你可以在 OpenClaw 的模型配置里把 base_url 改成中转站地址这样所有模型请求都会先经过中转站再由它转发到真正的模型服务商。配置逻辑不复杂核心参数就三样base_url、api_key、model。但选中转站要谨慎因为你的对话数据都会经过它用不知名的小站有数据泄露风险。我个人的建议是能用官方 API 就用官方实在要中转比如访问不便或成本优化选有口碑、运营时间长的服务而且不要把敏感数据喂给接中转站的模型链路。7. 踩坑实录从“network unavailable”到 CAU 与 Chrome 控制7.1 飞书 network unavailable 的完整排查链路这句报错“network unavailable, please go to feishu network diagnosis to find the problem”堪称飞书接入第一劝退神句。它表面上是在说网络问题但它实际覆盖的场景非常多。我经历过的原因就有三种按出现频率排序回调地址公网不可达、应用权限不足导致 API 调用被拒、事件订阅未正确加密验证。完整的排查链路我是这样走的。第一步先判断你的接入模式。如果是长连接模式报这个错大概率不是公网问题而是飞书后台的事件订阅配置和实际接入模式不匹配检查订阅里的事件是否已启用。第二步如果是 Webhook 回调模式去飞书后台的“事件订阅”页面里面提供“网络诊断”功能让飞书主动探测一次你的回调地址。如果诊断显示不通检查服务器安全组有没有放行对应端口、域名解析是否正确、证书是否有效。第三步看 OpenClaw 日志里到底卡在哪一步——是没收到事件还是收到事件但调用 API 时被拒。被拒多半是权限或 token 问题重新检查授权范围和 token 获取逻辑。这个报错的坑就在于它把所有问题都归成一句“network unavailable”实际上网络只是最后一环。所以我的建议是永远以“链路分断”的思路去拆——平台到服务、服务到 API两端各查各的问题范围立刻缩小一半。7.2 CAUComputer Agent Use与容器控制 Chrome 的设置热词里“openclaw的cau computer如何设置”和“openclaw 容器 控制chrome”是同一类需求。CAU 可以理解成 OpenClaw 给智能体开放的一双“手”让它可以操作浏览器完成点击、填表、截图等动作。最常见的落地方式是控制 Chrome 浏览器而 Chrome 的控制通道就是 CDPChrome DevTools Protocol。要让 OpenClaw 能控制 Chrome我踩过坑之后总结出的配置思路是起一个带远程调试端口的 Chrome 实例然后在 OpenClaw 的 CAU 配置里填上调试端口地址。如果你担心本机环境被污染可以用 Docker 跑一个带 Chrome 的容器只把调试端口映射出来这样智能体再怎么折腾浏览器影响范围都被限制在容器内。容器方式的隔离性明显更好我最后改用容器方式之后再没担心过它把宿主机搞乱。这里的配置细节不同 OpenClaw 版本差异较大升级版本后配置项改名的情况很常见。不要照抄网上的旧教程要以你当前版本的配置模板为准不确定的参数宁可不填也不要瞎填。一个错误参数导致的失败往往比缺参数更难排查。7.3 其他高频问题速查我把这段时间遇到的、以及网上高频出现的问题整理成一张表方便你直接照着排查。现象根因处理建议飞书 机器人无响应事件订阅未启用或权限未生效检查im.message.receive_v1事件是否添加权限是否审核通过重启服务回调地址收不到事件推送公网不可达或证书无效用飞书后台网络诊断测试回调地址确认安全组、DNS、证书机器人能收消息但发不出去缺少发消息权限或用错 token 类型申请im:message:send_as_bot权限用tenant_access_token调用发送接口多维表格写入报字段类型错字段类型和写入数据类型不匹配在 API 调试器里确认表结构写入前做类型转换升级后服务起不来配置文件字段不兼容旧版备份后对照新版本配置模板逐项迁移字段本地模型响应特别慢内存不足或模型过大加内存、换小参数模型或改用 GPU 推理OpenClaw 2.0 升级后很多人反映 skill 命令和配置格式有变化这在高速迭代的开源项目里很正常。升级前一定先看官方迁移文档不要用旧思维去套新版本配置项改了名字、命令参数换了位置都可能导致服务异常。另外还有人问“openclaw 容器 控制chrome到底怎么用”如果你只需要让智能体读网页做摘要建议先用现成的网页抓取 skill不要一上来就上浏览器控制。浏览器控制是重武器启动慢、消耗资源、还要重视觉模型的配合很多场景其实是杀鸡用牛刀。先想清楚你到底需要它做什么再决定要不要上这套方案。我在实际配置中的最后一条心得是不要追求一步到位。先跑通“飞书能收到消息、能回复”再逐步加 skill、加多维表格、加浏览器控制。每加一层验证一层出问题能马上定位。这套系统最大的风险不是装不上而是你一次塞了太多能力出了问题根本不知道是哪一环在捣乱。先把主链路稳定跑起来后面再加什么都来得及。