企业官网建设流程全解析

前阵子我把OpenClaw接上了飞书机器人，推理后端用的是Ollama本地大模型，整套东西跑下来最大的感受是：终于可以在不把数据送出内网的前提下，让群里那个“AI助理”真的能帮我干活了。这篇文章就是把整个接入过程完整记录下来，所有步骤都是我实测过的，从创建飞书应用到OpenClaw配置Ollama，再到群里@机器人让它执行任务，一轮一轮排坑，全部写成可以直接照着操作的指南。适合给正在折腾本地大模型接入办公IM的朋友参考，不管你之前有没有玩过OpenClaw，按着这篇走一遍就能跑通。

1. 组合拳是怎么打起来的

1.1 为什么要用OpenClaw + 飞书 + Ollama这套组合

先说结论：这个组合解决的痛点是，团队日常沟通都在飞书上，但很多重复性工作（查数据、写摘要、跑脚本、整理周报）还得切到电脑前手动做。如果直接把一个AI机器人拉进群里，让它能听懂群聊里的自然语言请求，并且真的执行任务，效率提升是立竿见影的。

OpenClaw这类框架的价值在于，它不是简单的“问答机器人”，而是一个能调工具、能拆任务、能走流程的AI助理框架。搭配飞书这个触达渠道后，等于给团队开了一个“群聊即指挥台”的入口。而Ollama在这里负责提供推理能力，并且是本地的、私有的、不依赖云端API的，非常适合对数据敏感的场景。

我对比过几个方案：

这套组合对中小企业技术团队、个人开发者、以及对数据敏感的单位特别友好——Ollama让模型权重留在本地，OpenClaw让任务执行变得可控，飞书则解决了“大家都习惯用什么入口”的问题。

1.2 整体架构和数据流向

我画不出来那种漂亮的架构图，直接用文字讲清楚消息从头到尾走了一条什么路：

用户在建好的飞书群里@机器人 → 飞书开放平台捕获这条消息 → 推送到你的回调服务 → OpenClaw收到消息，解析出用户意图 → 根据任务需求决定要不要调用工具（比如读文件、执行命令、查日历）→ 把问题发给Ollama本地模型进行推理 → 得到结果后再从OpenClaw走回调接口把回复发回飞书群。

这条链路上有三个关键角色：

• 飞书开放平台：管机器人身份的注册、消息的接收和发送、回调事件的推送到你的服务。
• OpenClaw：中间的大总管，负责人机交互逻辑、任务编排、工具调用。
• Ollama：纯推理后端，负责生成文字内容。

部署位置上有两种玩法：一种是把OpenClaw和Ollama全放在公司内网机器上，回调入口走反代；另一种是我个人比较推荐的开发阶段玩法——OpenClaw和Ollama都在本地电脑跑，飞书回调地址指向一个临时公网映射，只有小范围测试群在用。生产环境再挪到内网服务器上。

1.3 适合谁用，不适合谁用

先说适合的：团队已经重度使用飞书、想快速验证AI助理能不能在真实办公场景里创造价值的技术团队；自己手里有多张显卡、不想跑云API的折腾型玩家；还有对数据合规有硬性要求的内部工具开发者。

不适合的：只想做纯聊天陪聊的（没必要搞这么重）；需要跑超大模型（比如70B以上）但硬件不够的（Ollama能跑但速度会让你崩溃）；对响应速度要求是毫秒级的（本地模型推理速度再快也有天花板，不是流式接口能解决的事）。

2. 动手前的基础准备

2.1 飞书开放平台侧：创建应用、开通机器人、拿密钥

这一步是麻烦但必须做扎实的，全程在飞书开放平台后台操作。

第一步：进入开放平台，点“创建企业自建应用”，填个名字。建议名字里带个“测试”或“内测”字样，免得大家真把它当正式机器人用。创建完成后，先停留在“应用信息”页面不要关。

第二步：在左侧菜单里找到“应用能力”，添加“机器人”能力。这个动作会让应用具备收发消息的接口权限，飞书机器人就是一次身份切换。

第三步：拿到四个关键凭证。在“凭证与基础信息”页面看App ID和App Secret。App ID是应用的唯一标识，App Secret相当于应用的密码。在“事件订阅”页面设置Encrypt Key和Verification Token，这两个值在配置回调的时候会用到，建议先复制到记事本里，省得到时候来回翻页面。

第四步：开通权限。在“权限管理”里搜机器人相关的权限，我当时开通的核心权限就这么几项：

• 获取与发送单聊、群组消息
• 读取用户发给机器人的单聊消息
• 接收机器人被@的消息事件
• 上传图片或文件（如果想让机器人发附件需要这个）

飞书后台的权限列表偶尔会调整名称，不用死背权限标识，按“中文名+用途”来搜就行。权限默认是“未开通”状态，一个个点开通，开通后要等超级管理员审核，个人开发的话通常你把自己设成管理员就能秒过。

2.2 Ollama安装与本地模型准备

Ollama的安装是真的简单，但踩坑的人都踩在了“模型选型”上，所以这块多说几句。

安装本身分三步：

Windows用户直接下载安装包，装完命令行就能用；macOS用户同理，下载安装包或走Homebrew；Linux用户一条命令搞定：

curl -fsSL https://ollama.com/install.sh | sh

装完先验证一下，在终端里执行：

ollama --version

能输出版本号就说明装好了。

然后拉模型。这里我给一张基于自己实测的选型建议表，别盲目追大参数：

我最后稳定使用的是qwen2.5:7b，原因就一个：中文理解能力和工具调用能力取得了比较好的平衡。拉模型的命令：

ollama pull qwen2.5:7b

拉完以后，Ollama的服务默认跑在11434端口。测试一下API是否可用：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}]}'

能看到内容返回就代表本地大模型已经准备好了。

2.3 OpenClaw安装与初始化

OpenClaw这个框架的定位，简单说就是“给大模型装上手脚，再挂上各种IM渠道”。它把任务解析、工具调用、渠道适配都打包好了，我只需要写配置文件告诉它模型在哪、飞书在哪。

安装方式根据你用的系统选，我测试时用的是直接下载编译产物解压到 /opt/openclaw 的方式，Windows下一样有对应版本。下载解压后先初始化工作目录：

mkdir -p ~/openclaw && cd ~/openclaw

然后准备配置文件 openclaw.yaml，这个文件是顶梁柱，后面所有联调都围绕它转。初次可以先写一个最小化配置确认能跑，我建议直接按下一章的配置走，一步到位反而少走弯路。

3. 核心联调：让OpenClaw用上本地模型并接入飞书

3.1 配置Ollama作为OpenClaw的推理后端

OpenClaw对模型后端的支持走的是OpenAI兼容接口，而Ollama本身就暴露了一个OpenAI兼容的 /v1 端点，所以这里有个非常取巧的配置方式——直接把Ollama的地址填到一个“OpenAI兼容格式”的配置块里。

我当时配置文件里这部分的写法长这样：

model: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 api_key: ollama model: qwen2.5:7b temperature: 0.7 max_tokens: 2048

几个字段逐个说明：

• base_url 指向Ollama的OpenAI兼容端点，是本地的。
• api_key 随便填一个非空字符串就行，Ollama默认不校验密钥。
• model 填入你 ollama pull 下来的模型名。
• temperature 控制回复随机性，跑正经任务建议0.2-0.4，和用户闲聊时可以调到0.7以上。
• max_tokens 控制单次回复长度，2048在多数场景够用，如果让机器人写长文，调到4096。

如果机器上有多个模型想切换，我最开始的做法是直接改model字段重启，后来发现OpenClaw支持在对话里指定模型名，只要模型已经拉下来了，直接说“用14b模型回答”也能自动切过去，具体支持程度看版本差异，但至少这句指令会被记录到上下文里。

3.2 配置飞书渠道和机器人身份

接下来是飞书侧的接入。OpenClaw的渠道配置里找到飞书段，把准备阶段拿到的四个凭证填进去：

channels: feishu: app_id: cli_xxxxxxxx app_secret: xxxxxxxxxxxxxxxxxxxxx verification_token: xxxxxxxxx encrypt_key: xxxxxxxxx

这里有几个容易踩坑的细节：

• app_secret 是“凭证与基础信息”里的那个，不是“事件订阅”里的东西，别搞混。
• encrypt_key 如果暂时不想开启加密回调，飞书后台可以不填，OpenClaw里也留空，但如果你在飞书后台填了encrypt_key，OpenClaw这里就必须填，否则回调会解密失败。
• verification_token 在事件订阅页面显示，用于回调时校验消息来源，填错的话OpenClaw日志里会报“验证不通过”。

配置完之后启动OpenClaw，它会自动向飞书注册长连接。这里解释一下：飞书机器人接入有两种模式，一种是Webhook回调模式，飞书把事件POST到你的公网地址；另一种是长连接模式，机器人主动和飞书保持一个WebSocket连接。OpenClaw支持的是长连接模式，好处是不需要公网回调地址，企业内网部署也能直接用，这一点对本地模型方案特别重要。

3.3 事件订阅配置和公网回调逻辑

虽然长连接模式不需要公网地址，但飞书后台仍然会检查“事件订阅”里是否配置了请求网址。我第一次配置的时候就被卡在这里——飞书要求保存事件订阅地址时必须通过URL验证，OpenClaw如果没启动或者地址不通，后台就死活保存不了。

解决方案是先在飞书后台的事件订阅页面填一个任意的可访问地址，随便拿个公网HTTPS地址占位，让飞书完成验证。真正的事件推送其实走长连接，飞书后台那个请求地址只是用于验证合法性，不会真的推送事件内容过来。

在本地开发阶段，如果非要开启Webhook模式，那就得让OpenClaw监听的回调端口暴露到公网。我的建议是直接用一台有公网IP的云服务器做反代，把本地11435端口映射出去，或者用内网映射工具做临时通道。生产环境建议直接部署在公网服务器上，然后通过防火墙规则限制飞书回调来源IP段，安全性和稳定性都更好。

权限配置在长连接模式下有个坑：即使长连接已经建立，如果“权限管理”里没有给机器人开通“接收消息”权限，飞书端发来的消息事件也不会被推过来。我当时调了一下午，最后发现就是权限漏勾了一项。

3.4 启动OpenClaw并验证飞书消息通路

所有配置填完后启动OpenClaw：

./openclaw start

日志里看到类似“feishu channel connected”或者“long connection established”的提示，就说明飞书长连接已经建好了。

然后打开飞书，搜索应用名称找到你的机器人，先私聊发一句“你好”。正常情况下，几秒后OpenClaw会打印接收到的消息事件，然后把请求转给本地模型，并把模型回复通过机器人发回对话里。

验证这一步，我强烈建议先私聊再拉群，因为群里测试涉及@机器人、群权限等额外变量，先私聊打通基础链路，能少排查一半问题。私聊通了之后再到群里建个小测试群，确认一下群里@机器人也能触发响应。

4. 实测中常见的问题与排查

4.1 消息发到机器人，但OpenClaw毫无反应

这是接入飞书时出现频率最高的问题。先不要慌，按这个顺序排查：

第一，打开OpenClaw日志，确认有没有收到飞书事件。日志里干干净净什么都没打印，说明事件根本没推过来。这时检查飞书后台“事件订阅”里有没有配置“接收消息v2.0”事件，没配置的话飞书不会主动推消息。

第二，日志里出现了消息事件，但OpenClaw没回复。这个问题多半出在模型调用上，可能Ollama没启动，或者base_url写错了。手动curl一下Ollama的接口，通了再回来查OpenClaw配置。

第三，如果是群聊里@机器人没反应，但私聊正常，检查飞书后台权限里有没有勾选“获取群组中所有消息”和“接收机器人被@消息事件”。另外群成员必须在应用的可用范围内，飞书支持设置机器人可用范围，新机器人默认可能只有创建者能用。

第四，确认是否在群里“@机器人”而不是直接发消息。OpenClaw默认只在被@的时候响应，避免群里所有消息都触发一遍。

4.2 本地模型响应慢或者答非所问

Ollama在CPU上跑7B模型不是不能用，但生成速度可以慢到让你怀疑人生。如果你发现机器人回复一句话要等30秒以上，先去看看资源占用。用OpenClaw配置temperature略调低能减少一些“废话”，切到更小模型能提升速度，但我更推荐的是换量化版本——Ollama默认拉下来的就是量化过的，如果还嫌慢，可以拉更小参数的模型。

答非所问的问题绝大多数出在“系统提示词”上。OpenClaw会给模型一个初始system prompt，里面说明了机器人的身份、职责、可用工具。如果这个提示词写得模糊，模型就会自由发挥。我当时遇到最典型的现象是：让它查今天日程，它回复一段“好的，已为你查询今日日程”的废话，但根本没调用日程工具。后来把system prompt改成“你是一个办公助手，收到指令后必须先调用对应工具获取数据，再基于工具返回结果回复用户”，这个问题基本绝迹。

4.3 工具调用失效或模型不肯使用工具

这是OpenClaw场景下比较致命的问题。现象是模型能回答问题，但当OpenClaw给它提供了“执行命令行”或“读取文件”这类工具时，它假装没看到，或者使用了工具但结果没有正确传回模型。这类问题我从两个角度修过：

模型侧：确认你拉的模型支持function calling/tool calling。qwen2.5系列和llama3.1系列支持，但一些老的对话模型或精简模型不支持，不支持就不会按OpenClaw约定的工具格式输出。

框架侧：OpenClaw里如果配置了多个模型，要确认工具调用模式下有没有锁定模型。有些框架的默认模型是“轻量对话模型”，工具调用要单独指定“工具模型”。把两个模型都切换成同一个支持tool calling的模型，问题就没了。

还有一个容易被忽略的细节是：工具返回结果后，不能直接把结果原样丢给模型。如果工具返回了一段巨大日志或JSON，模型会“淹没”在信息里，不知道该提取什么。我当时做的一个优化是给工具加了一层“摘要管线”，让工具先返回提炼后的关键信息，再交给模型组织语言回复。

4.4 几个容易被忽略的小细节与排查速查表

说几个只有实际跑过才会注意到的小坑：

密钥别写错。App Secret这个值非常长，复制粘贴时要小心首尾空格，我当时复制的时候混进了一个换行符，排查了一个小时。

日志是最大的排障依据。OpenClaw默认日志比较详细，建议把日志级别调到debug跑一天，出问题时顺手就能看到是哪一环掉了。

机器人可用范围要提前规划。飞书后台可以限制机器人的可用部门或成员，建议测试阶段就限制在少数几个人，免得机器人被乱调。

服务守护。OpenClaw进程挂了，机器人就失联了。开发阶段无所谓，演示或者小范围使用时，建议用systemd或者进程守护工具把OpenClaw托管起来，崩溃自动拉起来，省心很多。

再给你一个排查速查表，贴在手边很实用：

5. 写在最后的一点实操体会

这次接入做完，我最大的体会是：技术链路本身不复杂，真正需要花心思的是“把机器人调教得像个助理，而不是一个聊天玩具”。本地模型的优势是隐私、可控、没有token焦虑，缺点是模型能力上限就摆在那里，所以更要靠OpenClaw这套框架去补足——用工具调用代替模型死记硬背，用任务编排降低对模型的智力要求。建议你第一周先让机器人做“查日程、发消息、跑脚本”这三件小事，顺手之后再慢慢加外部工具。这个系列我计划按模块往下写，下一篇想聊OpenClaw如何调用本地文件资源和实现定时任务，都是这次接入实际用到又踩过坑的方向，希望能帮同样在折腾的人少走点弯路。