企业官网建设流程全解析

边学边做：如何用 openclaw + ollama + 飞书搭一个能跑起来的智能机器人

我得先交代一下背景。这个项目是我在折腾本地 AI 工具链的时候顺手攒出来的，起因特别朴素：我想让飞书群里的机器人在不依赖云端大模型 API 的情况下，也能回答一些日常问题——比如查资料、做简单的推理、帮忙整理通知。市面上不少机器人方案都绑定了付费接口，或者部署起来很重，对我这种只想在内部小范围用一用的人来说，不太划算。

后来我发现了 openclaw 这个调度框架，再配上 ollama 跑本地模型，最后用飞书开放平台把机器人和群聊打通。整套东西跑起来之后，效果超出我预期，所以想把这套方案的完整思路、部署步骤和踩过的坑都整理出来，给同样有需求的朋友做一个参考。

这套方案最适合谁？如果你有一台配置还行的电脑或服务器，想在飞书里有一个“自己说了算”的机器人，又不想被各家云厂商的 Token 费用绑住，那这篇文章应该能帮到你。就算你之前没接触过 openclaw 或 ollama，只要跟着步骤走，也能把机器人拉起来。

这套方案解决的核心问题与整体架构

我先说说这套架构到底解决了什么问题，这样你后面看步骤会更有方向感。

第一个痛点是成本不可控。用云端大模型 API 做机器人，每一轮对话都按 Token 计费。群聊场景里信息密集，机器人被 @ 的次数一多，账单就不好看了。而 ollama 可以把模型完全跑在本地，只要机器性能够，对话成本几乎为零。

第二个痛点是数据私密性。企业内部或者个人社群里聊的内容，很多时候不想经过第三方服务器。本地推理意味着所有消息都在自己的机器上处理，不回传任何东西，这一点对敏感场景特别重要。

第三个痛点是调度逻辑太死板。很多机器人框架只支持“收到消息 -> 调模型 -> 回复”这种简单链路。但实际使用中，我经常需要让机器人先判断消息类型，再做不同处理——比如普通闲聊走小模型，复杂问题走大模型，或者某些指令直接走本地脚本。openclaw 正好提供了灵活的工作流编排能力，可以把这些逻辑串起来。

整个架构分三层。接入层是飞书开放平台，负责接收群消息、发送回复，相当于机器人的“嘴巴和耳朵”。调度层是 openclaw，它作为常驻服务，监听飞书回调，解析消息内容，然后根据预设的工作流规则决定让谁来处理。推理层是 ollama，管理本地模型的生命周期，接收 openclaw 转发过来的提示词，生成回答再返回给 openclaw。

这三层配合起来，消息流大致是：群里有人 @ 机器人 -> 飞书服务器把事件推送到 openclaw -> openclaw 判断意图并调用 ollama -> 模型生成回答 -> openclaw 调飞书 API 发回群聊。整个过程延迟在本地网络环境下基本感觉不到。

值得说明的是，openclaw 本身并不绑定某个特定的大模型厂商。它更像是一个中间件，你可以在工作流里配置不同的后端。我在项目里选了 ollama，纯粹是因为它部署简单、模型管理方便，而且完全离线。如果你后续想接入其他推理引擎，openclaw 的适配层也能帮你省不少事。

部署前必须想清楚的三个选型问题

虽然标题看起来是“三步走”，但实际上手之前，有几个选型问题如果没想清楚，后面会反复返工。我把它们放在最前面，这是最容易踩坑的地方。

机器配置：跑得动多大模型，由内存和显存决定

很多人一上来就问“要什么配置”，其实这个问题取决于你想跑多大的模型。ollama 支持从 0.5B 到 70B 不等的参数规模，模型越大，回答质量通常越好，但资源消耗也成倍增长。

我的实际经验是：如果只是普通群聊问答、信息整理、简单推理，7B 到 8B 量级的量化模型就够用。这类模型在 CPU 上也能跑，但速度会偏慢。我有一个测试用的虚拟机，只分配了 4 核 CPU 和 8GB 内存，跑 7B 模型大约每秒只能生成几个 Token，回答一段话要等十几秒，体验比较煎熬。

后来我把主力部署放到了一台 32GB 内存的机器上，给 ollama 分配了 16GB 的上下文空间，速度明显提升。如果你有 NVIDIA 显卡，哪怕只是 8GB 显存，用 GPU 推理 7B 模型基本可以做到秒回，那体验就非常好了。

我的建议是：别在模型选择上贪大。先跑一个 7B 或 8B 的量化模型把整个链路打通，确认没问题再根据效果决定要不要换更大的模型。这样能最快看到结果，也方便排查问题。

模型选型：通用对话与中文能力的平衡

ollama 的模型库里有不少选择，但并不是每个都适合飞书群聊这个场景。我试过几个，简单说下体感。

• qwen2.5:7b：中文能力很扎实，日常问答和指令理解都还不错，资源消耗适中，是我的主力选项。
• llama3.1:8b：英文表现更强，中文稍逊。如果你的群聊以中文为主，可以当作备选，但不作为首选。
• gemma2:9b：整体质量不错，但显存占用偏高，CPU 环境下速度不太理想。
• phi3:mini：模型小、速度快，适合做意图判断或分类任务，但不适合复杂对话。

我的建议是：如果你的使用场景是中文为主，直接选 qwen2.5:7b 起步。如果你想做意图分类这类轻任务，可以用 phi3 专门跑分类，把 qwen 留给真正的对话生成，两不耽误。

飞书应用类型：自建应用与商店应用的区别

在飞书开放平台创建应用时，会面临“自建应用”和“商店应用”的选择。这里必须提醒你：个人或内部使用，一定选自建应用。

商店应用需要发布审核，而且面向的是多租户市场，权限和流程都更复杂。自建应用只需要在你的企业或组织内部可见，创建之后自己就能用，不需要过审，配置也简单得多。后文我会按自建应用的方式带你走完整个配置流程。

第一步：ollama 安装与本地模型准备

说完了选型，现在开始动手。先从最底层——推理引擎——开始。

安装 ollama 并验证服务

ollama 的安装在不同操作系统上略有差别。我在 Linux 服务器上用的是官方脚本，Windows 和 macOS 也有对应的安装包。这里以 Linux 为例：

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

安装完成后，ollama 会自动注册为系统服务，监听默认端口 11434。你可以用下面的命令确认服务状态：

systemctl status ollama

如果看到active (running)，说明服务已经起来了。接下来用一条命令验证 API 是否可访问：

curl http://localhost:11434/api/tags

正常会返回一个 JSON 数组，即使里面还没有模型。这一步很关键，因为后面 openclaw 连接 ollama 时，走的就是这个 HTTP 接口。

下载并运行 qwen2.5:7b 模型

ollama 拉取模型非常简单，一条命令就能搞定：

ollama pull qwen2.5:7b

首次拉取会从模型仓库下载几个 GB 的文件，具体大小取决于模型版本。下载完成后，你可以直接跑一个测试对话：

ollama run qwen2.5:7b "请用一句话介绍你自己"

正常情况下模型会在几秒内给出回答。这个测试不仅能确认模型可用，还能顺便观察一下生成速度。如果这一关就慢得离谱，建议先别往下走，考虑换小一点的模型，或者看看机器的资源占用情况。

设置环境变量允许外部访问

默认情况下，ollama 只监听127.0.0.1，也就是只允许本机访问。如果 openclaw 和 ollama 在同一台机器上，这个配置没问题。但如果 openclaw 部署在其他机器上，就需要让 ollama 监听所有网卡。

方法是在 systemd 服务配置中增加环境变量：

sudo systemctl edit ollama

在编辑器中加入以下内容：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重启服务：

sudo systemctl restart ollama

这里有一个安全提示：如果机器有公网 IP，监听0.0.0.0意味着任何人都能访问你的推理接口，容易被滥用。建议要么通过防火墙限制来源 IP，要么用内网部署，不要让这个端口暴露到公网。

第二步：飞书开放平台应用创建与机器人配置

ollama 就绪之后，接下来把飞书这边的“入口”打开。

自建应用的创建流程

登录飞书开放平台后台，进入“开发者后台”，点击“创建企业自建应用”。填写应用名称和描述，提交后就会生成一个 App ID 和 App Secret，这两个凭证后面 openclaw 要用。

进入应用后，需要开通“机器人”能力。在应用功能里找到“机器人”，开启后飞书会自动为该应用创建一个机器人账号。这个机器人就是将来进群陪你聊天的那个身份。

接着需要配置权限。在“权限管理”页面，搜索并开通以下权限：

• im:message：读取和发送单聊、群聊消息
• im:message.group_at_msg：接收群聊中 @ 机器人的消息
• im:message.p2p_msg：接收与机器人的单聊消息

权限开通后，在“事件与回调”页面配置请求地址。这个地址必须是 openclaw 暴露出来的公网或内网可访问的 URL。具体值取决于你的 openclaw 部署方式，我一般把 URL 路径设为http://<服务器IP>:<端口>/feishu/event。

配置回调时还需要选择事件类型。至少勾选以下两个：

• im.message.receive_v1：接收消息事件
• message相关的事件订阅

验证回调地址的核心细节

飞书在保存回调地址时，会向该地址发送一个 URL 验证请求，要求返回特定的加密校验信息。openclaw 已经内置了这套处理逻辑，所以只要地址配置正确、服务在运行，保存时应该能直接通过验证。

如果你发现自己点了保存但验证不通过，最常见的两个原因是：

• 服务器端口没开放，飞书无法访问到你的 URL
• openclaw 服务没启动，或路径配错了

建议先用浏览器或curl手动访问一下这个地址，确认服务确实可达，再来排查配置问题。

第三步：openclaw 环境准备与连接飞书

现在到了整个方案的调度中枢环节。openclaw 在这里扮演的角色是：接收飞书推送的消息事件，解析出文本内容，构造提示词，调用 ollama 拿到回复，再封装成飞书要求的消息格式返回。

安装与初始化 openclaw

openclaw 的安装方式在不同版本下略有差异。我用的方式是通过 Git 拉取源码，再按照仓库里的说明初始化。大致步骤如下：

git clone <openclaw 仓库地址> openclaw cd openclaw # 安装依赖，具体命令以仓库 README 为准

初始化完成后，openclaw 会生成一个配置目录，里面包含主配置文件和渠道配置文件。需要重点修改的是渠道配置——在这里填入飞书应用的 App ID 和 App Secret。

配置示例大致如下：

channels: feishu: app_id: "你的 App ID" app_secret: "你的 App Secret" encrypt_key: "你的加密 KEY" verification_token: "你的校验 Token"

这几个值都能在飞书开发者后台的“事件与回调”页面找到。加密 KEY 和校验 Token 不是必填项，但建议填上，这样回调数据的传输会更安全。如果留空，openclaw 会默认按不加密模式处理，飞书那边也要对应关闭加密选项。

配置模型连接与提示词模板

openclaw 里关于模型调用的配置通常在另一个配置段中，需要指定 ollama 的服务地址和模型名称。核心配置项如下：

llm: provider: ollama base_url: "http://localhost:11434" model: "qwen2.5:7b"

如果你的 openclaw 和 ollama 在同一台机器，用localhost就行；如果不在同一台机器，改成 ollama 那台机器的实际 IP，并确保端口可达。

除了模型，openclaw 还支持自定义提示词模板。你可以给机器人设定一个“人设”，比如“你是一位耐心的助理，回答要简洁清晰”。这个模板会在每次调用模型时作为系统提示词注入，直接影响回答风格。

启动 openclaw 并验证飞书连接

配置完成之后，启动 openclaw 服务：

# 具体启动命令以仓库说明为准，通常是一个可执行文件 ./openclaw start

启动日志如果没有任何报错，说明服务已经正常运行。这时可以去飞书群里把机器人拉进来，然后 @ 它发一条消息试试。

如果一切顺利，机器人会在几秒内回复你。如果没反应，优先查看 openclaw 的运行日志，飞书回调是否到达、模型调用是否成功、返回结果是否正常，这三个环节中的任何一个出错都会导致静默失败。

让机器人更聪明的几种实用性调优

把机器人跑起来只是第一步，真正好用的机器人还需要针对实际场景做调优。我根据自己的使用习惯，整理了几类比较实用的优化方向。

用意图分流减轻模型负担

群聊里的消息质量参差不齐，不是每一条都需要大模型来处理。比如“你好”“在吗”这类打招呼的消息，完全可以走一个简单的关键词判断逻辑，直接返回固定回复，不用调用模型。这样既省资源，响应也更快。

openclaw 的工作流可以设置前置规则层，在消息进入模型之前先做一层“过滤”。你可以定义一些关键词规则，让特定类型的消息走特定分支。比如包含“提醒”的消息进入提醒处理流程，包含“翻译”的消息走翻译模板。这比把所有消息一股脑丢给模型要聪明得多，也更容易控制。

调整生成长度与温度参数

如果你发现机器人的回答啰嗦，或者有时答非所问，可以调整模型生成参数。ollama 在执行时暴露了温度（temperature）和最大生成长度（max_tokens）等参数，openclaw 是否支持透传取决于版本实现。

我个人的经验是，在群聊场景里把温度设低一点（比如 0.7），回答会更稳定；把最大生成长度控制在 500 以内，避免机器人长篇大论刷屏。太长的回复在群聊里观感并不好，反而显得像在灌水。

为敏感话题设置兜底回复

本地模型在回答某些特定领域问题时，可能给不出准确答案。与其让它胡编，不如设定一个兜底策略：当模型的回答包含不确定词汇，或者置信度过低时，返回“这个问题我还不太确定，建议人工确认一下”。这种兜底机制在群聊场景里很实用，能避免机器人给错误信息。

具体实现上，openclaw 的规则层可以检查回答内容中是否包含“我不确定”“我猜测”等特征词，命中则替换为兜底文案。虽然有点笨，但有效。

部署过程中最常见的五个坑及排查思路

这部分是实战经验的结晶。我跨过的坑不少，挑五个最典型的写下来，基本覆盖了大多数新手会遇到的问题。

回调地址验证失败

前面提到过，飞书配置回调地址时，会发一个验证请求。如果验证失败，通常原因集中在端口不通、路径不对、服务未启动。排查顺序：先用curl访问地址确认可达，再看 openclaw 日志里有没有收到请求，最后核对应用凭证是否正确。

机器人收不到群消息

回调验证通过了，但 @ 机器人没反应，绝大多数情况是事件订阅没配全。飞书要求应用必须订阅im.message.receive_v1才能收到消息事件，这个事件在“事件与回调”页面添加时，要确保已发布版本。注意，配置修改后需要重新“创建版本并发布”，否则改动不会生效。

发布应用版本这一步非常容易漏。很多人改完权限和事件配置，直接就在群里测试，结果机器人毫无反应，查了半天才发现没发布新版本。

模型响应速度太慢

如果模型本身没问题，但回复速度就是上不去，先确认是否走了 GPU。ollama ps命令可以查看当前模型运行使用的设备，如果显示 CPU，说明没有加载 GPU 版本。可能需要重新安装带 CUDA 支持的 ollama 版本，并确保显卡驱动正常。

如果确认已经用了 GPU 但仍慢，大概率是模型太大，显存装不下，发生了内存交换。观察显存占用，如果接近上限，就换小一档的模型，或者减少上下文长度。

openclaw 日志大量报错但服务还在跑

openclaw 是单体服务，它对外暴露了多个接口和回调入口。如果日志里报错但服务开着，通常是某个信道的凭证配错了，或某个依赖服务超时。此时不要慌，先看报错内容里是否提到了外部服务地址，跟着提示去检查对应服务即可。

网络隔离导致回调不达

飞书服务器在国内，向你的服务器发回调时，如果你的机器放在家里宽带后面，没有公网 IP，或者路由器没做端口映射，飞书根本找不到你。解决思路有两种：一是用内网穿透工具把本地端口暴露到公网，二是直接把服务部署到有公网 IP 的云服务器上。

我个人的建议是：如果机器已经在内网跑了其他服务，尽量别用穿透工具暴露 80 或 443 端口到公网，安全风险偏高。给 openclaw 单独开一个端口，并限制来源 IP，会稳妥得多。

从跑通到好用：真实使用体验与资源建议

整套系统部署完成之后，我实际用了一个多月，基本满足了我最初的需求。现在飞书群里每天会有人 @ 机器人查资料、做汇总、问一些流程问题，它都能应付。特别是本地部署这一点，让我不用担心消息内容被第三方平台留存，心理负担小了很多。

如果你已经照着上面的步骤跑通了，我个人还有几个建议：

• 给机器人一个明确的“人设”：在提示词里写清楚它的职责边界、语气风格和回答长度偏好，效果会好非常多。不要指望一个裸模型天然就适合你的业务场景。
• 定期更新模型：ollama 的模型仓库更新频率不低，新版本通常在能力和稳定性上有提升。隔一两个月关注一下对应模型是否有新版本，值得升级就拉一下。
• 保留一份干净的备份配置：openclaw 的配置改多了之后，容易出一些难以察觉的问题。我在调优过程中经常把配置改坏，后来习惯在每次大改前备份一份正常配置，出问题了直接还原，效率高很多。

资源方面，如果你的机器只有 8GB 内存，跑 7B 模型会比较吃力，建议先从 phi3:mini 或者 qwen2.5:3b 开始；16GB 内存可以比较流畅地跑 7B 模型；想要跑 13B 以上的模型，最好有 32GB 内存，或者直接上显卡。这个阶梯式建议是我实测下来的经验，能帮你少走弯路。

最后再分享一个技巧：ollama 支持同时加载多个模型，但默认会按需卸载不活跃的模型以释放内存。如果希望机器人响应稳定，避免模型反复加载卸载，可以设置OLLAMA_KEEP_ALIVE环境变量，把模型保持时间拉长。这个参数不复杂，但很实用，值得一试。