企业官网建设流程全解析

最近一直在折腾一套东西，目的很单纯：把 OpenClaw 跑起来，通过飞书机器人当入口，再接上 Ollama 本地大模型，让 AI 助手真真切切地帮我办事，而不是只能在网页上陪聊。折腾了几天，总算把这条路完全打通了。这篇就当 OpenClaw 实战系列的第一篇，把飞书接入、Ollama 本地模型配置、联通验证、以及我踩过的坑全部写清楚。如果你已经在跑 OpenClaw，想知道怎么接飞书机器人；或者你想把自己的私有数据、内部工具全部交给机器人打理，又不想把聊天记录传到云上，那这篇应该能帮你省下至少一个晚上的试错时间。

1. 前期认知：这套组合到底在做什么

1.1 一句话看懂三层架构

先说清楚整条链路是怎么走的。

飞书机器人是所有消息的入口，相当于公司门口的前台。你在飞书里跟机器人发一句话，飞书服务器会把这条消息通过事件订阅推给 OpenClaw。OpenClaw 收到消息后，负责理解这句话、决定要做什么，然后把请求交给 Ollama 里运行的本地大模型，模型给出回复内容或工具调用指令，OpenClaw 再执行对应操作。最终把结果通过飞书消息 API 回复到你的聊天窗口。

用更直白的话说：OpenClaw 是那个真正干活的“手和脚”，飞书机器人是“耳朵和嘴巴”，Ollama 里跑的本地大模型是“脑子”。三者缺一不可。OpenClaw 本身不产生智能，它只负责把消息流转起来、调用工具、执行命令；Ollama 提供模型推理能力；飞书则是你随时随地都能触达的交互界面。

为什么要用三层而不直接把飞书事件转发给模型？因为 OpenClaw 在中间充当了代理层，它能做工具调用、上下文管理、多会话隔离。没有这一层，你接个大模型 API 只能做纯问答，没法让它去读取文件、跑命令、调内部 API。这也是 OpenClaw 这类 AI Agent 运行时存在的意义——把模型能力和真实世界操作接起来。

我在本地实测的完整数据流大概是这样：飞书私聊发消息 → 飞书长连接通道推到 OpenClaw → OpenClaw 把带系统提示词的 Prompt 发给 Ollama → Ollama 返回文本（或函数调用） → OpenClaw 执行工具 → 结果回传给飞书。整个过程只依赖本机服务和飞书服务器，没有经过任何第三方 AI 网关，数据不出内网，这对企业内部工具来说非常重要。

1.2 为什么选飞书机器人和 Ollama 而不是其他方案

选择飞书作为消息入口，首先是因为飞书开放平台的机器人生态足够成熟。企业自建应用可以申请机器人能力，支持长连接事件订阅，不需要公网回调地址，个人开发者在没有公网服务器的情况下也能跑通。相比之下，钉钉的机器人权限划分更严格，很多消息会话场景需要复杂的权限申请；Slack 虽然 API 设计好，但国内团队使用率低，协作上下文不在一起。飞书还有一个优势是手机端体验好，机器人消息可以像普通聊天一样推送，随时随地下达指令。

选 Ollama 则完全是冲着本地推理和 OpenAI 兼容接口去的。Ollama 安装简单、模型管理方便，一条命令就能拉下来 Qwen、Llama 等主流开源模型，而且它从较新版本开始原生暴露了/v1的 OpenAI 兼容 API，这意味着 OpenClaw 可以用标准 OpenAI 接口的方式直接调用 Ollama，不需要写适配代码。更关键的是，数据完全留在本机。很多时候我不想把内部文档、日志片段、脚本内容发给云端模型，本地部署正好解决这个顾虑。

关于成本也得说一句。云端大模型按 token 计费，如果机器人每天被频繁调用，跑一个月也是一笔不小的开销。本地大模型一次投入硬件成本，之后就没有边际费用了。唯一需要接受的是模型智商天花板——7B 参数的模型当然没法和云端千亿参数模型比复杂推理，但用在我的日常操作场景里已经绰绰有余。

2. 环境准备与组件部署

2.1 Ollama 本地模型部署三步走

Ollama 的部署非常简单，无论哪个系统都有对应的安装方式。macOS 用户直接执行brew install ollama，Windows 用户去官网下载安装包，Linux 用户可以用官方脚本curl -fsSL https://ollama.com/install.sh | sh。装完以后，打开终端验证一下：ollama --version，能输出版本号就说明装好了。

接下来是拉取模型。我在这个实战系列里默认推荐 Qwen2.5 系列，原因是中文理解能力在同参数量级别里属于第一梯队，而且对工具调用的支持比很多老模型好。如果你的机器是 CPU 为主、内存 16G 左右，建议拉qwen2.5:7b，这是性能和速度平衡得最好的选择；如果有独立显卡且显存在 8G 以上，直接上qwen2.5:14b，推理质量会有肉眼可见的提升。拉取命令就一行：

ollama pull qwen2.5:7b

这里要注意，Ollama 的模型名是全名。ollama list里显示什么，OpenClaw 配置里就写什么，不要自作主张简写。比如你拉的是qwen2.5:7b-instruct，配置里就不能只写qwen2.5，否则模型侧会报找不到模型。

部署过程中有个经常被忽略的环节：环境变量。默认情况下 Ollama 只监听127.0.0.1:11434，如果 OpenClaw 和 Ollama 跑在同一台机器上，这个默认值就够了。但如果你想把 Ollama 跑在另一台机器上，或者局域网内多台机器共享同一个模型服务，就必须在启动前设置监听地址：

export OLLAMA_HOST=0.0.0.0:11434 export OLLAMA_ORIGINS=* ollama serve

OLLAMA_ORIGINS=*是防止浏览器跨域拦截用的，OpenClaw 这类服务端程序一般不会触发，但设上能省掉很多奇怪的异常。另外可以设置并发参数OLLAMA_NUM_PARALLEL=2，让模型同时处理两个请求，代价是显存和内存占用翻倍。这一步不是必须的，个人使用默认串行就够。

2.2 飞书开放平台后台创建机器人

飞书机器人的创建要在飞书开放平台后台完成。进入平台后选择“创建企业自建应用”，名字随意，比如“我的本地助手”。创建成功后，第一件事是进入“凭证与基础信息”页面，把App ID和App Secret记录下来，这两个凭证后面要用，相当于机器人的身份证和密钥。

接下来在“添加应用能力”里启用“机器人”。启用后，飞书会为应用自动生成一个机器人身份。然后是权限管理，这一步很多新手会漏。机器人要接收消息并回复，至少需要开通以下几类权限：im:message（获取消息内容）、im:message.group_at_msg:readonly（在群聊中被 @ 时读取消息）、im:message.group_msg（读取群内所有消息，可选）、im:chat:readonly（读取会话信息）。我建议一开始先只开前三个，足够完成基础的私聊回复和群里被 @ 回复。

关键配置在“事件订阅”里。飞书支持两种事件接收方式：将事件发送至开发者服务器（Webhook）和使用长连接接收事件。很多人在这一步被卡住，因为 Webhook 模式要求你提供一个公网 HTTPS 回调地址，没有公网服务器的开发者直接绝望。解决办法就是选长连接模式。长连接模式下，飞书服务器会主动跟 OpenClaw 建立一条 WebSocket 通道，OpenClaw 只需运行在本地，不需要任何公网入口。在事件订阅页面添加事件im.message.receive_v1，这个事件对应“接收消息”的实时推送。

飞书后台还有一个“加密策略”选项，可以给事件推送加encrypt_key，也可以留空。个人使用建议不开加密，少一个参数少一份配置错误的风险；团队内部使用建议开启，防止消息内容在网络传输中被截获。开了加密的话，encrypt_key和verification_token都要记下来，后面要填进 OpenClaw 配置。

最后也是最容易忘记的一步：在“版本管理与发布”里创建一个版本并提交发布，由企业管理员审核通过。我之前配置完后台一切看起来都正常，但机器人就是不回消息，查了半天才发现应用根本没有发布线上版本，消息事件自然不会推送。这一步完成，飞书侧准备工作才算真正结束。

2.3 OpenClaw 安装与全局配置

OpenClaw 是一个开源 AI Agent 运行时，安装方式比较灵活，最简单的是用 npm 执行npx openclaw-cli install，它会自动安装可执行文件并创建默认配置目录。装好后，执行openclaw serve首次启动，程序会生成默认配置文件，通常位于~/.openclaw/agent.yaml或~/.openclaw/openclaw.yaml，不同版本文件名可能略有差异，不过不影响整体思路。

配置文件里主要分两大块：通道配置（channels）和模型配置（model）。通道配置用来声明接入哪些消息平台，比如飞书，需要填入上一步拿到的凭证；模型配置用来声明使用哪个大模型后端，这里就指向本机的 Ollama。后面两个章节我会分别给出可以直接抄的配置示例。

OpenClaw 启动后默认监听127.0.0.1:3000（或类似端口），这个是给它自己页面的，不用管。真正起作用的是后台进程里建立的飞书长连接。启动日志里如果能看到飞书通道连接成功，说明前半段已经通了。

3. 核心接入配置：把三块拼起来

3.1 飞书通道配置项逐一对照

在 OpenClaw 配置文件里，飞书通道的配置区块大概长这样：

channels: feishu: enable: true app_id: "cli_xxxxxxxxxxxx" app_secret: "你的AppSecret" encrypt_key: "" verification_token: "" mode: websocket events: - im.message.receive_v1

逐项解释一下：

• app_id：飞书后台“凭证与基础信息”页面的 App ID，格式类似cli_开头的一串字符。
• app_secret：对应的 App Secret，这个值只显示一次，如果忘了就在后台重置。
• encrypt_key：事件订阅里的加密密钥。如果你在飞书后台没有开启加密，这里留空即可；开了就一定要填，否则飞书推送过来的消息 OpenClaw 解不开，日志里会报解密失败。
• verification_token：事件订阅里的验证令牌，同样是开了才填。
• mode：固定写websocket，对应飞书后台选的长连接模式。
• events：需要监听的事件类型数组。目前只订阅im.message.receive_v1就够了。

很多人在这个环节踩坑是因为填空了但没填对。比如encrypt_key和verification_token都是从后台复制过来的，复制的时候容易多带一个空格，或者把“仅展示一次”的提示文字也复制进去了。我的建议是每次改完配置就校验一遍，确保字段后没有多余空格。还有一点，配置修改后需要重启openclaw serve才会生效，不要改完就干等。

配置完成后启动 OpenClaw，观察日志。如果飞书长连接建立成功，日志里会看到类似 “websocket connected” 或者飞书通道 ready 之类的输出。这时去飞书后台的事件订阅页面，也会看到长连接状态显示为已连接。

3.2 Ollama 模型接入 OpenClaw 的配置确认

模型侧配置是文件里的 model 区块。我实际跑通的配置如下：

model: provider: ollama base_url: "http://127.0.0.1:11434/v1" model_name: "qwen2.5:7b" temperature: 0.7 max_tokens: 2048 context_window: 8192

重点讲base_url为什么是http://127.0.0.1:11434/v1。Ollama 从 0.16 版本左右开始在原生 HTTP 服务上提供 OpenAI 兼容的/v1接口，也就是说直接用http://IP:11434/v1就能当做一个 OpenAI 服务的替身。OpenClaw 内部实现的模型客户端就是按 OpenAI 接口格式调用的，所以 base_url 必须包含/v1这个路径前缀。如果漏掉，请求会打到 Ollama 的根路径/，结果就是 404 或者找不到模型接口。

如果你把 Ollama 跑在别的机器上，或者局域网共享，base_url要改成那台机器的实际地址，比如http://192.168.1.100:11434/v1，千万不能继续写127.0.0.1。这里的127.0.0.1指的是运行 OpenClaw 的本机回环地址，而不是 Ollama 所在机器的地址。

temperature这个参数对效果影响很大。日常问答、闲聊、写作润色，用0.7比较合适，生成的句子自然且有变化。但如果主要用途是工具调用、代码生成、提取结构化数据，建议把temperature调到0.2到0.4之间，因为这些场景需要的是确定性和准确度，温度太高模型容易一本正经地编参数。

max_tokens控制生成文本的最大长度。日常问答 2048 够用，需要让模型写长文、总结长文档时再调到 4096。注意max_tokens设太大并不会让模型一次性塞出那么多字，它只是允许的上限，反而会拖慢首次生成速度，不建议盲目调大。

context_window决定模型能看到的上下文长度。Ollama 默认模型的上下文参看窗口是 4K 或 8K 左右，如果你希望机器人在对话中记住更多历史，可以把这里调大，但要考虑显存占用。8K 对日常使用已经够了，我用下来还没碰到明显记忆不足的情况。

3.3 连接自检三连

配置写完，别急着发消息，按下面三步自检，能省掉大量排查时间。

第一步，验证 Ollama 在线且暴露了/v1接口。在终端执行：

curl http://127.0.0.1:11434/v1/models

如果返回一段 JSON，里面带data数组和模型列表，说明 Ollama 服务正常，而且 OpenAI 兼容接口可用。如果返回 404 或 connection refused，去检查 Ollama 有没有启动、监听地址对不对。这个 curl 测试是最快的判据。

第二步，验证飞书通道连接。启动openclaw serve，看启动日志里有没有异常输出。正常情况下日志会显示配置文件加载成功，飞书通道完成注册，进入等待事件状态。如果日志中出现feishu connect failed，大概率是凭证填错，或者应用没发布，需要回飞书后台核对。

第三步，端到端测试。在飞书里给机器人发一条私聊消息，比如“你好”。如果链路全通，OpenClaw 日志会显示收到来自open_id的消息，随后模型接口被调用。第一次回复可能比较慢，因为 Ollama 要把模型文件加载进内存，十几秒甚至几十秒都是正常的。等到模型常驻后，回复速度会明显变快。可以用ollama ps看当前内存里加载了哪些模型，如果显示qwen2.5:7b而且标注了100%，说明模型已经预热完成。

4. 实操过程：从第一句“你好”到多轮任务

4.1 基础问答实测

链路打通后，我在飞书里做的第一件事很简单，发了一个“你好”。

机器人那边返回的内容大致是“你好，我是运行在本地模型上的 AI 助手，底层使用 Qwen2.5 模型，通过 OpenClaw 接入飞书。”回复速度大约在 3 到 5 秒。考虑到 7B 模型跑在纯 CPU 上，这个响应速度完全可以接受。

这个阶段建议把日志级别调到调试模式，比如openclaw serve -v debug。日志里能看到 OpenClaw 给模型拼接的完整 Prompt，包括系统提示词、用户消息、历史对话摘要。这对理解模型行为非常重要。你可以看到 OpenClaw 默认的系统提示词是什么风格，如果你觉得它太过啰嗦或者预设角色不满意，可以在配置里自定义system_prompt。比如我为了让机器人适合企业内部使用，把系统提示词改成了“你是公司的内部助手，要简洁、准确、友好地回答员工问题，涉及敏感信息时不要输出”。

基础问答只是验证，真正有价值的还是让机器人干活。

4.2 让机器人真正动手干活

OpenClaw 和普通聊天机器人的最大区别，就是它内置了工具调用能力。模型在生成回答时，不仅能输出纯文本，还能输出一个结构化的“工具调用”指令，OpenClaw 收到后就会执行对应的本地操作或 API 请求，再把执行结果反馈给模型继续生成最终回复。

我实测的第一个真实任务是在飞书里发了一句：“帮我列出当前目录下的文件和文件夹”。OpenClaw 收到消息后，把请求交给本地模型，模型判断需要调用list_directory这个工具，OpenClaw 执行命令并拿到了当前目录文件列表，最后把列表整理成一段话回复到飞书。

这里有个很重要的实测感受：工具调用能力在不同参数量的模型上差距非常明显。7B 模型在“单个工具、参数简单”的场景下表现稳定，比如列目录、读文件、请求一个固定 API。但一旦涉及“多步推理”，比如先分析文件内容再决定要不要调另一个工具，7B 模型就容易漏参数或者选错工具。如果你对这类复杂流程有刚需，建议把模型换成qwen2.5:14b，工具调用可靠性能上一个台阶。这是我在反复测试中感受到的最明显差异。

另外要注意，OpenClaw 的工具体系支持自定义。默认内置了一批常见工具，比如执行命令、读文件、发 HTTP 请求，你也可以在配置里声明自己的工具。那个才是这个系统真正发挥威力的地方，后续系列可以单开一篇专门讲工具开发。

4.3 多用户与多群会话隔离

接入飞书后，机器人往往不是只有你一个人在用。企业里可能一个小团队都来跟这个机器人交互，这时候就涉及会话隔离问题。

OpenClaw 的默认行为是按照消息来源为每个用户或每个群创建独立的会话上下文。同一个用户的不同消息会共享一份对话历史，不同用户之间互相不影响。在配置里你可以调整 session 的划分策略：按open_id隔离就是每个人都有自己的私聊上下文；群聊场景可以按chat_id加user_id双重维度隔离，保证群里每个人在群里被 @ 时都有自己的记忆线。

实际使用中有一个不算问题但需要留意的地方：本地模型只有一个，所有会话共享 Ollama 的推理资源。如果你开的是 7B 模型且没有设置并发，多个用户同时发消息时，后面的请求会排队，响应时间会明显变长。内部小团队 10 人以下使用，7B 模型默认串行基本够用；人多了建议设置OLLAMA_NUM_PARALLEL=2，或者直接上 14B 并开启显卡加速。

会话历史也不能无限制累积。每轮对话都会占用上下文窗口，历史太长会把 context_window 撑爆，新消息反而看不到关键信息。在 OpenClaw 配置里可以限制每个会话保留的最大历史轮数，我通常设成 10 到 20 轮。JSON 日志里会有上下文占用率的提示，如果你发现模型开始重复早期的回答内容，多半就是历史把窗口挤占完了。

5. 常见翻车现场与排查清单

5.1 机器人完全不回复

这是接入过程中最常见的问题，现象是你在飞书里发了消息，机器人像没看见一样。我整理了一个排查顺序，按这个顺序查基本能定位。

先查飞书后台的事件订阅状态。如果长连接没建立，说明 OpenClaw 根本拿不到消息。再查应用版本有没有发布，没发布的消息事件不会被推送。接着核对权限，im.message.receive_v1事件依赖对应的消息权限，权限没开或者没生效，事件推不过来。最后看配置里的app_id、app_secret与后台是否一致，以及加密相关参数填没填对。

我把常见情况整理成了表格，方便对照排查：

5.2 OpenClaw 连接 Ollama 失败

这种问题最好复现，直接在终端模拟请求就能判断。我先用curl http://127.0.0.1:11434/v1/models，如果连接被拒，检查 Ollama 的进程是否存活、监听地址是不是 127.0.0.1。

如果接口能访问但 OpenClaw 报错model not found，九成是模型名不一致。Ollama 的模型名带:tag，比如qwen2.5:7b，不要只写qwen2.5。还有一种情况是ollama list里显示的名字跟我配置里的完全一样，但 OpenClaw 依然报错，这时候看日志里的完整 URL。有时候base_url末尾被多拼了字符，比如多了一个/，最后形成http://127.0.0.1:11434/v1/，虽然大部分情况下 Ollama 能兼容，但个别版本会解析失败。

首次请求超时也是高发问题。大模型加载到内存需要时间，尤其纯 CPU 环境下，可能几十秒。如果你在 OpenClaw 配置文件里把请求超时设得很短，模型还没加载完就报超时了。我的做法是首次调用之前，先在终端跑一次ollama run qwen2.5:7b "hi"，让模型预热加载，之后再接通 OpenClaw 就不会有首启超时的问题。

5.3 回答质量差、中文味太淡、一本正经胡说八道

本地模型的智商天花板是现实，但很多质量问题并不是模型本身造成的，而是参数设置问题。

如果模型回复中文夹着大量英文，或者语气非常“翻译腔”，往往不是模型不行，而是系统提示词没有声明语言要求。在system_prompt里明确加上一句“请始终使用简体中文回答”，效果立竿见影。如果回答逻辑混乱、数字算错，这是参数量不够的标志，换 14B 或更高参数模型才是根本解决路径。

关于温度，我再强调一遍。同一段文字用 0.2 和 0.8 生成出来的差异非常大。低温度适合事实性问题，高温度适合创意发散。我在配置里默认 0.7，但从实际体验看，OpenClaw 场景下 0.5 是更好的默认值，兼顾稳定性和可读性。如果发现模型开始刷车轱辘话，把 temperature 再往下调。

5.4 群聊场景只回复 @ 消息

飞书群聊里机器人接收消息分两种：被 @ 时接收，以及接收群内所有消息。默认情况下，OpenClaw 的事件订阅只推送 @ 消息，这是合理的，避免机器人在群里看到所有闲聊而被频繁唤醒。如果确实需要群内所有消息都进入模型，要在飞书后台申请读取群内所有消息的权限，并且事件订阅里选择对应的消息接收方式。

我的建议是企业场景默认用 @ 触发。这样做有两个好处：一是减少无关噪声对模型上下文的污染，二是避免机器人无意间读取到群里的敏感讨论。被 @ 触发已经能覆盖绝大多数使用场景，等你有明确需求再申请“接收所有群消息”也不迟。

在群里使用时还有一个体验细节：把机器人的会话按“群聊 ID + 用户 ID”隔离，这样每个人在同一个群里 @ 机器人，机器人能记得各自对话的上下文，不会把不同用户的问题混在一起。

6. 一点个人体会

把这套链路真正跑通之后，我最大的感受是：AI 助理的体验和“网页对话框里问问题”完全不是一回事。在飞书里发消息给机器人，就像在跟一个随叫随到的同事发条微信，它能直接读取本地文件、执行命令、请求内网接口，再把结果整理成消息回给你。所有数据都留在自己的机器上，不经过任何第三方模型服务，用起来非常安心。

这几个小时配置过程里也踩了不少坑，尤其是飞书后台“应用已创建但没发布导致消息事件完全不推送”、以及“模型配置忘了/v1路径导致接口 404”这两个，每一个都是几十分钟起步的弯路。这篇把这些坑都写透了，希望能帮后来的人少浪费点时间。

下一期我打算分享怎么给 OpenClaw 写自定义工具，以及怎么结合定时任务让它在每天固定时间主动给飞书群推送日报，而不是只能被动等人来问。到时候再接上更多内部系统的 HTTP API，这个助手就真正变成团队内部的数字员工了。