“养虾”这事我琢磨了大概两周才彻底玩明白。所谓OpenClaw本地“养虾”说白了就是在一台自己的电脑上把开源个人AI助手OpenClaw跑起来接入本地大模型做推理再通过飞书机器人作为统一入口收发消息、执行任务整个过程所有计算和存储都发生在本地聊天记录、文件解析、自动化指令全部不出电脑。这名字里的“虾”其实就是OpenClaw那只爪子的谐音养虾就是部署、配置、长期调教它。这套方案最适合两类人一类是手里有16GB以上内存电脑、想认真搞一个真正属于自己的AI助手的技术爱好者另一类是对数据隐私敏感、不想把对话记录和个人文件交给任何云端服务的上班族。文章后面我会从架构选型、模型配置、飞书接入、问题排查一步步拆完。1. 项目概述与需求拆解1.1 “养虾”到底养的是什么OpenClaw这个项目核心定位是一个运行在本地的AI智能体网关。它本身不是一个问答机器人更像是一个“调度中枢”接收来自不同渠道的消息调用本地大模型做理解再根据你的指令去执行具体动作。你可以把它接上飞书、接入定时任务、接上脚本、接上浏览器工具甚至让它读本地文件、整理资料、生成日报。也就是说OpenClaw负责“听懂你要干什么”本地大模型负责“思考怎么干”而飞书只是你跟前台对话的窗口。“养”这个字也很有意思。它不像云端AI那样装好就用OpenClaw需要你喂模型、调参数、配权限、写提示词、观察日志、处理异常。今天它回答慢了明天它理解错了后天它突然连不上飞书了都得你来伺候。养熟了之后它会变成你电脑里的一个常驻服务随时响应数据也不出门。我在实际部署中最大的感受是养虾的第一步不是装软件而是先想清楚你想让它承担什么角色。是当私人知识库问答助手还是当定时任务管家还是当智能搜索代理不同角色的模型选择、提示词设计和工具权限完全不一样。我这边最终定位是“本地文件管理 飞书待办提醒 每周日报自动生成”三个核心场景。1.2 这套方案解决了什么问题先说痛点。用云端AI最大的问题是隐私和成本。你把个人笔记、聊天记录、工作文档一股脑传上去等于把家里的钥匙复制给了别人。订阅费用不低而且大模型厂商的接口偶尔不稳定消息发出去半天等不到回复。本地大模型飞书的组合把这些痛点挨个解决了数据隐私所有对话内容、文件内容都在本地大模型里处理不经过任何第三方AI接口飞书在整个链路里只做消息中转相当于一条加密管道。成本可控本地推理走的是自己的硬件资源除了电费几乎没有边际成本可以无限对话不心疼。离线可用断网之后只要局域网内飞书还能通——或者说你直接用本地方案调试模型照样能跑哪怕外网全断本地的AI服务也不受影响。权限可控OpenClaw能访问哪些目录、执行哪些命令完全由你定义不存在云端AI“过度调用工具”的失控风险。当然这套方案也有它的代价最直接的就是你得有一台性能过得去的电脑还要花时间折腾配置。但它带来的自主感和安全感是云端方案给不了的。1.3 适合谁来折腾先说硬件门槛。我自己用的是32GB内存的普通桌面电脑没有独立显卡靠CPU跑一个7B参数的量化模型日常问答在可接受范围内。如果手头有支持量化的显卡体验会明显上一个台阶。再说技术水平。如果你接触过命令行、看过JSON配置文件、能理解“环境变量”这个概念那这套攻略你基本就能跟着走完。完全不懂技术的用户我不建议碰因为养虾过程会涉及大量细节排查没有基础很容易劝退。适合折腾OpenClaw飞书的人我总结有三种画像一是注重隐私的技术爱好者喜欢把数据牢牢攥在自己手里二是需要随手能用的AI助手但不想订阅云服务的效率工具控三是想深入研究智能体工作原理、拿本地部署练手的开发者。如果你符合其中任何一类这篇攻略你值得完整看一遍。2. 整体架构设计与技术选型2.1 架构总览一句话讲清楚数据流整套系统的数据流其实非常简洁我拆成了四个环节飞书客户端 → 飞书服务器 → 本地OpenClaw服务 → 本地大模型Ollama → 执行结果原路返回用户在飞书里给机器人发消息消息经过飞书服务器加密转发到本地OpenClaw的监听端口。OpenClaw解析这条消息判断是普通对话还是需要调用工具的任务然后把处理后的请求发给本地大模型。模型推理完成后结果由OpenClaw整理成飞书消息格式再通过飞书API发回用户的会话窗口。关键点在于整个链路中大模型推理这一步完全发生在本地不存在把消息内容发送到任何第三方AI平台的环节。飞书服务器在整个过程中承担的角色只是一个加密信道的中转站把用户的消息从手机端传到你的电脑上再把电脑生成的结果传回手机端。这也顺便解释了标题里“数据真·不出电脑”的含义——准确说是“AI推理链路上的数据不出电脑”飞书作为即时通讯工具它的服务器只转发密文我们在本地配置的是飞书自建应用并开启长连接模式接收事件根本不需要暴露公网入口。2.2 本地大模型选型思路为什么是Ollama本地运行大模型的方案其实有不少比如直接部署Python版的transformers、用llama.cpp跑GGUF量化模型或者用Ollama做统一管理。我最终选择Ollama核心原因有四个第一它把模型下载、版本管理、API服务化打包成了一个命令行工具一条命令就能拉模型、跑服务新手友好度极高。第二Ollama底层用的就是llama.cpp那套高性能推理实现CPU的AVX指令集、GPU的CUDA加速都能充分利用推理速度在同级别方案里算第一梯队。第三它对模型量化格式的支持非常好可以在占用资源不变的前提下把模型文件压缩到二分之一甚至三分之一这对普通电脑的显存和内存压力相当关键。第四OpenClaw内置了对Ollama的原生支持配置文件里指定一下API地址就能对接不需要自己写一堆胶水代码。选型的时候还要考虑嵌入模型。OpenClaw如果要处理“本地文件语义搜索”这类功能需要一个文本嵌入模型把文档切成向量存起来。我在Ollama里额外拉了一个嵌入模型几GB的内存占用效果够用匹配度还不错。2.3 飞书机器人接入方案长连接优先公网回调谨慎飞书开放平台提供两种接收消息事件的方式一种是传统的公网回调地址需要在你的服务器或者电脑上暴露一个HTTPS接口给飞书服务器访问另一种是长连接模式客户端主动和飞书服务器建立WebSocket通道飞书有新消息时直接通过已建立的连接推下来。我强烈建议普通用户直接采用长连接模式原因很现实公网回调需要你有一台能被公网访问的服务器或者在家里路由器上做端口映射而普通家庭宽带的公网IP情况复杂DDNS、端口映射、HTTPS证书这一套折腾下来光一个回调接入就能卡你三天对新手非常不友好。长连接模式完全不需要这些只要本地电脑能访问互联网飞书服务器就能把事件推送到你这边的OpenClaw进程里。而且长连接在安全上天然更有优势。公网回调意味着你的电脑暴露了一个对外接口任何嗅探到地址的人都可能往这个接口塞伪造请求一旦验证逻辑写得不够严谨整个系统就有被攻破的风险。长连接模式下本地没有任何对外监听端口攻击面大幅缩小。2.4 “数据真不出电脑”的边界与实现原理这句话我要说透避免有人理解成“飞书服务器完全不经过”。飞书是云端协作工具你和机器人的聊天记录、消息内容在传输过程中一定会经过飞书服务器中转加密传输。这和“AI推理数据不出电脑”是两个层面的事。真正的关注点是你的提问内容、文档内容、模型上下文里的一切信息在AI处理这个环节是否离开过你的电脑。在OpenClawOllama这套方案里答案是完全没离开。OpenClaw调用的是本地Ollama服务的API默认监听127.0.0.1:11434这个地址只有本机自己能访问外部网络根本连不上所以模型看到的所有内容都停留在内存和本地磁盘上。还有一层容易被忽略的是日志。我一开始没注意后来发现OpenClaw会把完整的对话记录写到本地日志文件里还包括一些调试信息。这意味着即使AI推理不出电脑日志文件本身就在本地留着大堆敏感数据所以一定要做日志脱敏和访问权限管理后面我会专门讲。3. 核心细节解析与实操要点3.1 OpenClaw安装与初始化OpenClaw的安装前提是电脑上有Node.js运行时。建议装最新的LTS版本Node版本太老会导致依赖装不上。装好之后通过包管理器全局安装OpenClaw命令行工具安装完成后先跑一下版本命令确认安装成功。然后做初始化。初始化会在用户目录下创建OpenClaw的配置目录里面包含主配置文件、日志目录、技能目录和存储目录。我建议在初始化完成之后立刻把配置目录用Git管起来这样每次改配置之前都先提交一个版本改崩了随时回滚。我调试期间至少回滚了十几次这个习惯救了我很多次。初始化之后先别急着连模型第一步是让OpenClaw能正常启动、有一个基础的健康检查。跑一下启动命令看到服务起来、控制台打印出监听端口之后再继续后面的配置。3.2 本地模型配置参数选择与上下文窗口设置模型这一步的核心是“选对参数量”和“配置好上下文窗口”。先说选模型。普通16GB内存、无独显的电脑我建议选7B到8B级别的量化模型如qwen2.5系列和llama3.1系列。以qwen2.5:7b为例它大约需要5GB内存存储权重加上推理时的KV缓存给Ollama预留8GB内存就够了剩余内存还能让OpenClaw和飞书连接吃得消。32GB内存的电脑可以把窗口拉长建议把模型上下文设置为4096到8192个token这样模型能一次性读入比较长的文档。如果你的任务经常涉及长文档摘要可以考虑把上下文拉到16K左右但推理速度和内存占用会同步上升需要自己权衡。还有两个参数要单独说温度和top_p。我实测下来OpenClaw作为智能体执行任务时温度设为0.3到0.7之间比较合适太低了输出呆板任务描述稍复杂就会答非所问太高了容易“跑偏”或者自作主张特别是自动操作文件系统的场景一个幻觉指令可能把你的文件目录弄乱所以宁可用低一点的温度也不要让它太“有创意”。3.3 飞书应用创建与权限配置飞书机器人接入的第一步是在飞书开放平台创建一个企业自建应用。创建之后进入“添加应用能力”启用机器人能力这一步会给你的应用生成一个机器人后面所有消息收发都通过这个机器人身份进行。然后去“权限管理”页面把机器人需要的权限逐个添加上。我这边用到的核心权限包括读取用户发给机器人的单聊消息、读取群聊中机器人的消息、以机器人身份发送消息、上传图片或文件。这里有一个常见误区很多人只加了发送消息权限结果接收消息时发现回调事件根本没触发其实就是漏了接收类权限。权限配好后要给应用开放“事件订阅”选择长连接模式订阅“接收消息”事件。长连接模式下不需要填回调地址整个配置简单很多。最后把App ID、App Secret、加密密钥这几样信息保存下来后面配置OpenClaw时要用到。3.4 秘钥管理与环境变量飞书应用的App Secret、加解密密钥属于高敏感信息直接写进OpenClaw的主配置文件里风险很大一旦配置文件被同步到Git仓库或者分享给别人等于把机器人的控制权交出去了。我建议的做法是采用环境变量方式注入敏感字段。OpenClaw本身支持环境变量覆盖配置项你在启动它的终端里先导出环境变量或者在配置目录下建一个环境变量文件填入FEISHU_APP_IDcli_xxxxxxxx FEISHU_APP_SECRETxxxxxxxx FEISHU_ENCRYPT_KEYxxxxxxxx FEISHU_VERIFY_TOKENxxxxxxxx然后OpenClaw在读取配置时会用环境变量里的值覆盖默认值这样主配置文件里不需要出现任何真实密钥。同时把环境变量文件加入Git忽略名单防止误提交。硬件好的机器推荐用Linux或macOS做宿主Windows上跑Ollama和OpenClaw也不是不行但内存管理和长连接稳定性实测不如前两者。4. 实操过程与核心环节实现4.1 第一步跑通本地模型在接触OpenClaw之前先把Ollama单独跑通这一步能帮你把“模型问题”和“业务问题”隔离出来。安装Ollama后在终端里执行一条拉取命令把你选定的模型下载到本地。下载完成后用一条对话命令测试模型是否正常工作ollama run qwen2.5:7b 你好请用一句话介绍你自己看到模型正常回复说明推理链路没问题。这里有个细节Ollama默认的服务端口是11434OpenClaw后续会通过这个端口调用模型所以Ollama进程需要一直保持运行。建议把Ollama注册成系统服务让它开机自启省得每次手动拉起来。我在实测中还发现Ollama默认加载模型时会把权重全部读入内存多个模型反复切换时会发生模型卸载再加载的情况导致第一次访问特别慢。解决方法是配置Ollama常驻模型数量让常用模型一直保留在内存里响应速度会稳定很多。4.2 第二步OpenClaw连接本地模型模型跑通后开始配置OpenClaw的主配置文件把默认的云端模型供应商改成本地Ollama。配置文件的核心片段大致如下{ llm: { provider: ollama, baseUrl: http://127.0.0.1:11434, model: qwen2.5:7b, temperature: 0.5, contextWindow: 8192 } }我踩过的第一个坑就是忘了加baseUrlOpenClaw默认连的是它内置的云端模型地址结果启动后一直报连接超时当时我还以为是网络问题排查了半小时才发现是默认配置没改。所以配置文件里的每一项都要有意识地去检查不要想当然。改完配置重启OpenClaw然后在日志里看到“LLM provider connected”之类的输出再用OpenClaw自带的调试命令发一条消息测试确认从OpenClaw到模型这条链路是通的。4.3 第三步飞书机器人接入飞书接入的核心是把前面申请到的App凭证填入配置并启动长连接事件监听。OpenClaw的飞书通道配置参考以下结构{ channels: { feishu: { appId: cli_xxxxxxxx, appSecret: env:FEISHU_APP_SECRET, encryptKey: env:FEISHU_ENCRYPT_KEY, verificationToken: env:FEISHU_VERIFY_TOKEN, eventMode: websocket, autoReconnect: true } } }配置完成后启动OpenClaw确认日志里出现“Feishu websocket connected”之类字样就说明长连接已经建立。这时用一个飞书账号给机器人发一条“你好”正常情况会在几秒内收到机器人的回复。这一步我卡得最久的问题是消息重复接收。同样的消息机器人回复了两遍。排查后发现是我在飞书后台既订阅了长连接事件又在OpenClaw里额外配置了回调地址两路通道同时把消息推进来造成了重复。解决方法是只保留长连接一路回调地址那里直接留空。4.4 第四步联调与自动化任务基础对话通了之后就可以开始养真正的自动化能力了。我建议从三个场景练手由易到难第一个场景是“关键词提醒”。在OpenClaw里配置一个规则当用户消息里包含“提醒我”时调用内置的定时器技能在指定时间往飞书会话里推送提醒消息。这个场景涉及消息解析、技能调用、定时任务三个基础能力练完能跑通智能体的完整闭环。第二个场景是“本地文件摘要”。让OpenClaw读取本地某个目录下的文档调用本地模型生成摘要再把摘要发到飞书群。这个场景会考验上下文窗口和本地文件权限配置也是“数据不出电脑”最有说服力的一个例子。第三个场景是“日报自动生成”。通过OpenClaw的定时触发机制每天傍晚自动读取当天的环境数据或日志文件调用模型整理成结构化日报定时推送到指定飞书群。这个场景练完之后你的“虾”已经从玩具变成了生产力工具。我实际运行中最常用的是第三个场景。每天下午6点飞书群自动收到一份整理好的日报全程不经过任何第三方AI服务这个体验确实有一种“数据在自己手里”的踏实感。4.5 性能调优响应速度优化本地模型的响应速度目标不是和云端大模型比而是“够用”单轮消息响应控制在10秒以内这就已经达到了可用的标准。我实测的优化手段有四个一是模型量化等级。相同参数量下Q4量化比Q8量化推理速度快20%到30%内存占用也低得多。对日常对话而言Q4和Q8的输出质量差距体感不大所以我会优先选Q4。二是上下文窗口控制。上下文越长每次推理需要计算的KV缓存就越多速度会指数级下降。建议即使模型支持32K上下文日常配置也控制在8K以内只在处理长文档的临时任务里临时拉长。三是用GPU或更好的CPU。即使是集成显卡只要Ollama能调用到推理速度也比纯CPU快不少。小显存机器可以给Ollama配置模型层数卸载到GPU剩余层留在CPU效果依然可观。四是避免模型热切换。尽量保持只用一个主力对话模型不要频繁在多个模型之间切来切去否则每次切换都会触发重新加载权重动辄几十秒的等待会让人崩溃。5. 常见问题与排查技巧实录5.1 高频问题速查表我把自己在养虾过程中遇到的高频问题整理成了一个速查表按“现象-原因-解法”的格式列出方便你直接照方抓药现象常见原因排查方法飞书消息发出去没回复OpenClaw服务没启动或模型加载慢看OpenClaw日志有无收到事件记录先测模型响应消息重复回复同时开了长连接和公网回调只保留一种事件接收方式机器人回复内容答非所问温度参数过高或提示词混乱温度降到0.5以下检查技能描述是否歧义首次消息特别慢模型未常驻内存正在重新加载打开Ollama常驻配置日志全是错误模型无输出模型文件损坏或版本不兼容重新拉取模型或在Ollama换一个量化版本重启后配置丢失修改了配置文件但没重启服务确认改动已保存并重启OpenClaw5.2 内存与性能瓶颈分析“养虾”过程中最让人头疼的就是内存不够用。Ollama吃内存、OpenClaw吃内存、飞书长连接也吃内存三者叠加16GB内存的机器在加载8B模型加长上下文时很容易出现系统级卡顿甚至OOM。我的解决思路是给每个组件设置内存上限。Ollama可以通过环境变量限制KV缓存占用的内存OpenClaw可以限制日志缓冲和并发任务数飞书侧主要是控制不开启过多会话。32GB内存的机器按上面的配置正常使用内存占比大概在70%左右开几十个浏览器标签页也不至于卡死。还有一个容易被忽视的坑OpenClaw在处理多任务时会往内存里堆上下文如果有人一次性在飞书里发来一大段几万字的长文模型可能会直接把内存打满。我的做法是在OpenClaw里配置一个消息长度上限超长消息自动截断到模型上下文窗口的区间内避免极端情况把机器拖垮。5.3 飞书消息收发失败排查飞书消息只能发不能收是排查起来最绕的一类问题。我的排查顺序是先看飞书后台有没有事件投递记录再看本地OpenClaw日志有没有收到事件的打印最后看消息处理代码是否报错。通过这三步定位能区分问题出在飞书侧、OpenClaw侧还是模型侧。有一个典型场景飞书后台显示事件已经成功推送到长连接但机器人就是不回复。这种情况多半是OpenClaw收到了事件但没匹配到对应的处理函数。我遇到过因为机器人账号在群聊里没被所以事件里不包含消息内容的坑也有因为会话ID类型不对导致发送失败的问题。解决方法是把日志级别调到最详细一条条看OpenClaw对事件的完整解析过程。5.4 权限与日志坑权限问题主要集中在飞书应用的“可用范围”上。自建应用默认只对企业内特定成员可用如果你用个人微信同款账号测试时发现机器人完全不存在大概率是可用范围没把你所在的群或者人加进去。日志坑主要是敏感信息泄露。OpenClaw的日志会把飞书事件原文、用户消息内容、模型完整回复全部记录下来有些日志级别下连AccessToken都会被打印出来。我在排查完问题之后会把日志级别调回默认等级并配置日志定期轮转清理防止日志文件无限膨胀。另外如果配置了文件访问权限OpenClaw能读取本地目录日志里也会出现文件路径和片段内容。建议在配置里把不必要的高敏感目录排除在可访问范围之外。6. 安全与隐私加固6.1 日志脱敏“数据不出电脑”不等于“数据不出日志文件”。OpenClaw默认日志会把用户消息原文和模型回复完整记录下来长时间运行后日志文件里积累的敏感信息量相当可观。我建议在部署完成后立即做三件事开启日志脱敏功能把消息原文替换成脱敏后的摘要对日志目录设置权限只有当前用户能读写配置日志自动轮转超过一定大小后自动压缩归档。有一次我排查一个半夜报错的问题第二天打开日志文件发现里面躺着完整的工作文档内容虽然没有传出去但任何人只要拿到这台电脑的登录权限就能直接翻阅。这让我意识到本地化部署不等于自动安全本地部署只是把数据边界从“云端”收回到“本地”边界内的防护依然要自己负责。6.2 最小权限原则给OpenClaw配置文件访问权限和技能权限时请严格遵守最小权限原则。我见过有些教程直接给OpenClaw配置了整个用户目录的读写权限这种做法非常危险一旦某个技能被恶意触发攻击者就有机会遍历你的所有个人文件。我的建议是只给OpenClaw建一个独立的数据目录限定它只能在这个目录下读写文件。技能方面凡是涉及执行命令、修改文件、网络请求的能力都要在配置里明确列出允许的路径和域名白名单。可以不用的技能尽量关闭减少被误触发或恶意调用的面。另外本地模型本身也是攻击面之一。我建议不要轻易从第三方来源下载未经验证的模型权重尽量只使用知名模型仓库里的官方发布版本下载前比对哈希值防止模型被篡改植入恶意指令。6.3 备份与恢复养虾养到最后最值钱的是配置和经验而不是模型权重。模型随时可以重新拉取真正需要备份的是OpenClaw的技能配置、提示词文件、定时任务规则和飞书应用的凭证信息。我自己的备份策略是每天用Git自动提交一次配置目录保留最近30天的历史版本每周手动导出一份完整的配置文件发到加密压缩包里存到移动硬盘。恢复的时候只要把配置目录拉回来Ollama里重新拉一次模型权重飞书长连接重新建立整个系统半小时左右就能恢复到备份时的状态。还有一个心得是每次改配置之前先手动提交一次Git快照改坏了就回滚完全不慌。这套备份习惯我用了很久在OpenClaw的版本升级场景里尤其好用升级前打个标签升级后发现新版本行为异常弹指间就能回到旧版可用状态。我个人实际操作下来的感受是OpenClaw这套“养虾”方案最打动人的地方不是它有多智能而是它把所有环节都摆在你面前模型是你选的权限是你配的日志是你管的数据是你自己的。相比之下云端AI更像是一个黑盒你只能猜它拿你的数据做了什么。折腾过程中会有一些曲折尤其是飞书权限配置和模型参数调优那几天但当你看到自己的电脑跑着一个能实时响应消息、能读文件、能发日报的AI助手而且是完全属于你一个人的那种满足感很难形容。最后再分享一个小技巧别急着追求复杂技能先把“飞书对话-本地模型-简单技能”这条链路跑稳再一步步加功能养虾这件事慢就是快。
