前阵子有个朋友跟我吐槽说他们团队每天要在飞书群里手工处理各种重复请求查数据、填报表、发通知、回工单忙得跟客服一样。我问了一句“这些活能不能交给机器人”他反问“能倒是能但数据都在内网业务规则又老变一般机器人接不住”。后来我给他搭了一套基于OpenClaw的飞书AI办公机器人用的正是本地Ollama模型支持按需自动安装skills还顺手把数据可视化做进去了。这套组合落地之后群里80%的重复问答和报表类请求都自动化了他这才意识到原来办公机器人不一定要绑云端大模型也不一定要改动一次需求就改一次代码。这篇文章就围绕“OpenClaw 飞书 本地Ollama 自动安装skills 数据可视化”这条主线展开。OpenClaw在这里扮演智能体框架层的角色负责飞书消息的收发、意图调度和技能管理Ollama提供完全本地化的推理能力数据不出内网skills机制让机器人的能力可以像装App一样按需扩展可视化部分让机器人不只“会聊天”还能直接产出图表和报表。适合正在做企业内部工具、飞书机器人或对本地模型应用感兴趣的同学参考。我下面讲的配置和步骤是基于一套常见且可复现的落地做法不一定是最新版本的最优解但链路是完整且经过验证的。1. 这套组合解决的核心问题OpenClaw、飞书与Ollama各自的角色1.1 为什么一定要选“本地模型”很多团队做AI办公机器人第一反应就是接云端大模型API因为省事、效果好。但真放到企业办公场景里云端API往往不是最优解内部经营数据、客户名单、合同信息不能随便出内网合规这一关就卡死了一大半方案其次是成本如果群里有几百号人高频调用token费用累积起来非常可观再有就是稳定性办公高峰期如果云端服务限流机器人直接变“人工智障”。Ollama这类本地推理工具解决的正是这三个痛点。它把模型跑在自己的服务器上数据全程不出内网没有按token计费的压力模型文件一旦下载完离线也能用。对我这次的项目来说选Ollama还有一个额外的好处部署足够简单。它就是一个本地服务默认监听11434端口OpenClaw把对话请求转发过去拿到返回结果再组织回复整体链路清爽。1.2 OpenClaw在整条链路里的位置OpenClaw在这个项目里不是“模型”也不是“某个具体功能”而是一个承上启下的智能体框架。简单理解它干四件事第一连接飞书开放平台接收群里的消息事件也能主动向飞书发消息第二根据消息内容做意图理解判断是闲聊、查数据还是执行某个操作第三把需要推理的请求转给Ollama本地模型把需要特定逻辑的任务分发给对应的skills执行第四维护技能包的生命周期支持按需安装、卸载和更新。打个比方如果把机器人比作一家公司Ollama是“大脑”负责思考skills是“员工”负责干具体的事飞书是“前台”负责和用户打交道而OpenClaw是“管理层”把所有环节串起来、排优先级、做决策。没有Ollama机器人没有推理能力没有skills机器人只会聊天不会干活没有OpenClaw前面两样东西根本接不进飞书。三者的关系是互补的不是竞争关系。2. 飞书侧的前置工作应用创建、权限与事件订阅2.1 创建自建应用并开启机器人能力飞书机器人本质上是开放平台上的一个“应用”。要做这件事第一步是到飞书开放后台创建一个“企业自建应用”。创建完成后会拿到两个关键凭证App ID和App Secret。这两个东西后面OpenClaw配置里要用相当于机器人的身份证和密码。创建完应用需要在“应用能力”里开启“机器人”能力。这一步以后飞书才会生成一个机器人账号你才能在群里它。接下来是权限配置常见办公机器人都需要至少这么几项权限im:message读取群聊消息im:message:send_as_bot以机器人身份发消息im:chat获取群信息im:resource上传、读取图片等资源权限申请后需要发布应用版本并且要经过企业管理员审核。如果你是在自己的测试企业里搭建这一步很简单如果是在客户环境里交付记得把这一步的时间预留出来因为审核经常要等。2.2 事件订阅与长连接模式的选择飞书机器人接收消息有两种方式一种是“事件订阅回调”需要提供一个公网可达的HTTPS地址飞书把用户的消息事件POST到这个地址上另一种是“长连接模式”客户端主动跟飞书服务器维持一个WebSocket消息来了通过这个连接推给你。我强烈建议本地开发阶段用长连接。原因很现实回调模式下你的本机服务没有公网IP要么做内网穿透要么部署到公网服务器上调试链路长、问题多而长连接模式下OpenClaw直接连飞书的WebSocket网关本地起了服务就能收到消息断线后框架还会自动重连省去了一堆网络配置的麻烦。在飞书后台配置时只需要在“事件订阅”里选择“使用长连接接收事件”然后添加事件im.message.receive_v1接收消息。OpenClaw的飞书适配器启动后会自动完成长连接握手。需要注意应用发布版本时勾选的事件权限范围必须覆盖这些事件否则服务能启动但收不到任何消息。3. OpenClaw的项目形态与skills自动安装机制3.1 核心目录结构与配置文件示意OpenClaw本身是一个服务进程一般通过配置文件描述它要连接哪个平台、使用什么模型、加载哪些技能。我项目里的目录结构大致是这样的openclaw/ ├── config/ │ └── openclaw.yaml # 主配置 ├── skills/ # 已安装的技能包 │ ├── weather/ │ ├── sales_report/ │ └── approval_query/ ├── data/ # 用于可视化的数据文件 ├── logs/ # 运行日志 └── main.py # 启动入口主配置文件openclaw.yaml里飞书和Ollama的接入参数通常在同一个文件里管理。一个常见的片段如下adapter: platform: feishu app_id: cli_xxxxxxxxxxxx app_secret: xxxxxxxxxxxxxxxx event_mode: websocket llm: provider: ollama base_url: http://127.0.0.1:11434 model: qwen2.5:7b temperature: 0.7 max_tokens: 2048 skills: dir: ./skills remote_repo: https://your-git-lab.example.com/openclaw-skills auto_install: true allowed_users: [admin, ops]这里有个容易踩坑的点event_mode如果设成回调模式就需要额外配置回调地址和token验证对于纯内网部署老老实实用websocket最省心。auto_install: true表示允许机器人按指令自动安装技能但一般我会限制只有allowed_users里的用户能触发安装避免群里任何人都能往内部环境装东西。3.2 自动安装Skills的完整流程“自动安装skills”是OpenClaw最有价值的能力之一。普通机器人加功能要靠开发者改代码、重启服务OpenClaw把技能做成可分发的软件包用户通常是管理员在群里发一条指令机器人就能把技能装好、加载好立刻投入使用。一次完整的自动安装流程大概分六步用户在群里发送指令比如/skills install sales_report。OpenClaw先校验发送者的身份是否在allowed_users白名单里这一步不能省否则安全性没法保证。框架从配置的remote_repo技能仓库读取sales_report的清单文件里面描述了这个技能的版本、入口文件、依赖项。下载技能压缩包同时校验哈希值或签名确认包没有被篡改。解压到skills/目录扫描入口文件动态注册新的意图路由。回复安装结果并把新技能加载情况写进日志。整个过程不需要人工登录服务器也不需要重启主进程。用的时候用户直接发“查询本月销售报表”OpenClaw会把这条消息匹配到刚装好的sales_report技能上技能再从数据源取数并生成报表。依赖问题是我实际部署中经常遇到的坑。技能包如果依赖了第三方Python库安装时需要在隔离环境里处理依赖而不是直接往主进程里塞。我的做法是让每个技能自带一个requirements.txtOpenClaw在安装时自动创建一个虚拟环境、安装依赖并记录环境路径。这样既能热加载又不会把主环境搞乱。4. 接入本地Ollama模型的完整链路4.1 模型选型与启动Ollama服务Ollama接入的第一步不是写配置而是选模型和准备硬件。办公场景里我并不建议一上来就追求最大参数量的模型。显存有限、并发要求也有限最合适的通常是7B到14B之间、中文支持比较好的开源模型。我自己用的配置是7B级别的模型量化后大约需要6GB到8GB显存如果只有纯CPU环境也能跑但每轮回复可能要等半分钟以上体验会明显下降。启动Ollama服务本身很简单装好之后先用命令行拉取模型ollama pull qwen2.5:7b ollama serveollama serve会默认监听127.0.0.1:11434。如果你的OpenClaw和Ollama不在同一台机器上需要把Ollama服务绑定到可访问的内网IP并设置环境变量OLLAMA_HOST0.0.0.0然后重启服务。这时可以在服务器上用curl验证一下curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话介绍你自己, stream: false }能正常返回内容说明模型服务没问题。这一步做完再回到OpenClaw侧配置。4.2 OpenClaw侧模型配置与调用逻辑配置文件里的llm段就是给OpenClaw指路用的。写了provider: ollama之后框架内部会把对话历史、工具调用请求封装成Ollama兼容的请求格式POST到/api/chat接口。这里要注意Ollama的接口格式和OpenAI不完全一样但OpenClaw的适配层会做转换你只需要确保model名称和ollama list里显示的名字完全一致。ollama list # 输出中第一列就是你要填到配置里的模型名比如 qwen2.5:7b我遇到过最频繁的问题是模型名写错。有些人用qwen2.5不带:7b有些人写成了其他版本号结果OpenClaw启动时连接正常但一发送请求就报model not found。排查方式很简单启动前先执行ollama list把完全一致的名称复制进配置。调通之后可以做个快速验证在飞书群里机器人说“帮我总结一下这段话”机器人会把消息转发给Ollama拿到返回值后再以飞书消息的形式回复。到了这一步说明“飞书→OpenClaw→Ollama”的推理链路已经闭合。接下来就可以做真正的办公自动化了。5. 数据可视化从“收到问题”到“输出图表”5.1 一个典型的图表生成请求处理链数据可视化是这个项目里最出彩的部分。机器人不只能回答“某产品上季度销量是多少”还能量出“把过去30天的销量趋势画给我看”。本质上这需要把自然语言请求转换成一次数据查询、一次图表渲染、一次图片上传。我实现的处理链路是用户在群里发“画一下本周工单趋势”OpenClaw识别到这是一个可视化请求把它交给report技能技能读取data/目录下的CSV数据文件用Python的Pandas做聚合统计然后调用Matplotlib绘制折线图生成PNG之后通过飞书API上传图片再把图片消息发送到会话里。核心代码思路很简单import pandas as pd import matplotlib.pyplot as plt def render_trend(data_path: str, output_path: str) - str: df pd.read_csv(data_path, parse_dates[date]) daily df.groupby(date).size().reset_index(namecount) plt.figure(figsize(10, 4)) plt.plot(daily[date], daily[count], markero) plt.title(工单趋势) plt.xlabel(日期) plt.ylabel(数量) plt.savefig(output_path, dpi150) return output_path这里有个中文字体的大坑服务器上如果没有安装中文字体Matplotlib生成的图片里所有中文都会变成方块。解决办法是下载并注册一个中文字体比如思源黑体然后在绘图前设置from matplotlib import font_manager font_manager.fontManager.addfont(/usr/share/fonts/source-han-sans-regular.otf) plt.rcParams[font.family] Source Han Sans CN这一步不做前面的图表逻辑再好输出也是废的。5.2 让输出适配飞书图片消息、卡片与定时推送图表生成之后怎么发给用户最直接的方式是上传到飞书并发送图片消息。飞书开放平台的图片消息API要求先把本地图片上传到飞书拿到image_key再通过im/v1/messages接口发送。OpenClaw的飞书适配器一般已经封装好了这个流程但底层逻辑就是三步上传图片、拿image_key、发消息。除了图片消息飞书的交互卡片也很有用。卡片能承载按钮、链接和结构化数据适合做“点击查看详情”这种场景。比如机器人回复一张趋势图的同时卡片上可以带一个“导出CSV”按钮用户点了就能在对话里拿到原始数据文件。这种交互体验比单纯发一段文字强得多。定时推送是另一个高频需求。办公机器人不能只等人来问还要主动汇报。我在report技能里加了一个简单的定时任务配置每天早上9点自动读取昨天的数据、生成图表、发到指定的飞书群里。这样团队领导一进办公室就能看到数据日报不用任何人手动操作。数据可视化到此就不是一个炫技功能而成了真正日常使用的业务闭环。6. 实际部署中的踩坑记录与执行体会6.1 五个高频问题的定位路径这套系统整体链路不算复杂但从零部署到稳定运行我确实踩了不少坑。挑五个出现频率最高的问题按排查路径记录下来。第一个是“消息收不到”。OpenClaw进程启动了飞书后台也配置了但群里发消息机器人没反应。先查事件订阅是否添加了im.message.receive_v1再看应用权限里有没有开通“获取单聊、群组中用户发送的消息”的权限。很多时候后台能添加事件但权限没开后台也不会有明显报错只有测试消息时才暴露。第二个是“连上了但发不出消息”。这种情况常见于App Secret填错或者没有正确获取tenant_access_token。OpenClaw会在启动日志里打印token获取结果先看一眼有没有提示invalid app_secret之类的内容。第三个是“模型请求超时”。本地模型推理本来就比云API慢如果用的是CPU推理或者模型参数过大OpenClaw默认的超时时间可能不够。解决方法是把配置里的请求超时拉长到120秒甚至更久同时给Ollama服务设置合理的并发上限避免多个请求同时过来把显存打爆。第四个是“技能安装后没有生效”。OpenClaw加载技能时通常按目录结构识别入口文件。如果技能包解压后多了两层嵌套目录或者入口文件的文件名和清单不一致框架会静默跳过。排查时先看logs/下的加载日志再确认技能目录是否在skills/下直接可见。第五个是“卡片消息显示异常”。飞书交互卡片的JSON结构非常死板一个字段写错整张卡片就显示不出来。建议先在飞书后台的“卡片调试工具”里把JSON跑通再填到skill里。别直接用AI生成一段复杂卡片JSON就丢进去调试成本会很高。6.2 上线前值得做的小事基于这次的实践我总结了四件小而重要的事强烈建议在做类似项目时提前安排。第一给所有技能包加上版本号。自动安装技能是方便但如果没有版本管理哪天更新了一个技能导致行为变了查回滚会非常痛苦。技能仓库里保留历史版本必要时一键回退比在服务器上手动改文件安全得多。第二控制allowed_users白名单。自动安装Skills能力很强但也容易被滥用。只让管理员和运维账号触发安装指令普通用户使用技能不受限制这样既灵活又安全。第三日志一定要结构化。OpenClaw本身会打日志但你在技能里也要打印自己的关键日志请求参数、数据源查询结果、图表渲染耗时、发送结果。出了问题能顺着日志一层层找不然就只能靠猜。第四先小范围试点再全量接入。我最初只是在一个人数不到20的测试群里跑验证稳定性后才放到核心业务群里。核心业务群的流量和消息复杂度远高于测试群如果Ollama服务部署在共享服务器上建议先压测一下并发能力。我在这个项目里最深的体会是办公机器人能不能被团队真正用起来关键不在于模型多聪明而在于它能不能稳定地完成那些具体、重复、琐碎的事务。OpenClaw加飞书只是把入口打通了Ollama只是把推理能力带回了内网真正让机器人生存下来的是那一套不断补充、可自动安装的skills和数据可视化这种一眼就能看到价值的功能。你先从一个最痛的场景开始比如“每天手动汇总数据报表”把它完整跑通再慢慢往里面加技能。相信我一旦团队尝到了甜头后面的事情就不再是你要不要扩展而是他们追着你问“能不能再做一个”。