把养虾这件事做成一个“会自己说话的智能系统”是我鼓捣了三个多月的一个项目内部代号就叫“人人养虾”。我把一套小型循环水养殖设备接到 OpenClaw 这个自动化调度框架上让温度、溶氧、pH、氨氮这些传感器数据每天自动汇入再由它统一驱动水泵、增氧机、自动喂食器。刚开始一切都靠硬编码的告警规则看着是自动化实际上是个“哑巴系统”它能告诉你哪个指标超了但说不出为什么超、接下来应该先动哪个设备。后来我把 Ollama 接进来在本地服务器上跑了大语言模型才算是把“告警”升级成了“参谋”——模型能读数据、能给解释、能出操作建议。这篇文章想把整个落地过程里我觉得最值得说的部分写出来包括为什么要坚持用本地模型、怎么搭环境、怎么把 Ollama 接进 OpenClaw、以及上线之后踩过的那些真坑。这篇文章适合正在做类似自动化养殖、家庭鱼房改造、或者任何想给 OpenClaw 这类调度系统加一个“本地大脑”的读者参考。不需要你有多深的机器学习背景但最好对 Linux 基础命令和 Python 有一点概念。我会把每一步为什么这么做、参数怎么定、效果如何都讲清楚可以直接照着抄。1. 人人养虾到底是个什么项目系统里每天都在跑什么1.1 从传感器到执行器原来缺的是中间那层语义可以先看一下这套系统的整体分层我在设计的时候给它拆成了四层采集层、调度层、模型层、控制层。层级承担的工作典型组件采集层定时读取水质参数、设备状态溶氧传感器、温度探头、pH电极、氨氮检测模块调度层汇聚数据、触发规则、编排动作OpenClaw 自动化流程模型层解释数据、生成报告、抽取意图Ollama 运行的本地大语言模型控制层执行具体硬件动作增氧机继电器、水泵变频器、投喂电机采集层每五分钟上报一轮数据MQTT 消息进 OpenClaw调度层先把数值和阈值做一次比较超限就进告警队列。在没有模型之前告警队列只做一件事往手机推一条消息内容是“溶氧低于5mg/L请注意”。多了没有。问题在于溶氧低可能因为增氧机故障、水太肥导致微生物大量耗氧、温度升高导致氧气溶解度下降也可能是探头脏了读数不准。四种原因对应完全不同的处理动作只推一条“请注意”等于没推。模型层要补的正是这个“解释”环节。OpenClaw 收到告警之后会先把近几天的指标变化和设备运行日志聚合成一段文本然后调用 Ollama 上的模型让它输出一段“可能是哪里出了问题、建议先检查哪个环节、是否建议操作某个设备”的说明。动作还是由人点确认后让 OpenClaw 去执行模型不直接碰继电器中间永远插着一个“人确认”的环节这是安全底线。1.2 为什么我不愿意只用阈值规则非要上模型纯粹靠规则来诊断也不是不行但规则是脆弱的。今天我写了“溶氧低于5且温度高于28则怀疑增氧不足”明天出现溶氧正常但虾进食减少的情况这条规则就失效了要重新手写。而养虾这个场景里指标之间的关联非常复杂氨氮高了会影响虾的活力虾活力低了又会进一步加剧排泄物积累形成正反馈恶化。这种互相咬合的关系用 if-else 去穷举几乎不现实。大模型在这里的价值恰恰是把“指标之间的关联”作为先验知识带进来。它不见得比养殖专家更准但它能在几秒内把水温、溶氧、氨氮、pH 几条线放到一起看给出一个“不完美但决策可参考”的假设。这对个人养虾来说已经够了。我平时最多同时看二十个池子每一池出问题的时候模型给的第一轮判断基本能帮我省掉一大半排查时间。模型的定位还有一个特别要紧的原则它只能当“参谋”不能当“司令”。所有最终执行动作比如加大增氧功率、启停水泵必须由人点击确认。原因在于本地模型再稳也有幻觉概率我后面会详细讲实际遇到的一次氨氮数据“被编造”的情况。让模型做决策闭环迟早会出事。2. 为什么我坚持把推理链路压到 Ollama 本地2.1 云端大模型API用起来总觉得不对劲我最早其实是用云端 API 做的原型接起来快效果也还行。但认真评估之后发现这个方案的问题比想象的多。第一是费用模型非常不可控。养虾系统凌晨也会因为细微数据波动触发告警连带调用模型做解释一晚上几十次请求很正常一个月下来 token 费用虽然不至于吓人但每张账单都让我觉得不舒服——我养个虾凭什么要给别人的服务器交算力租金第二是延迟不稳定。我实测过晚高峰时段一次完整问答经常要七八秒有时候能到十秒以上。对于“溶氧异常下降”这种需要快速响应的场景十秒的延迟等于没有时效性。第三是最麻烦的传感器数据里包含详细的养殖环境信息每五分钟就要送给外部接口一次我心理上总觉得这块不踏实。数据量再小也是自己的东西能做本地做本地。本地推理最大的收益不仅是省钱而是让整个系统变成了一个完全离线可用的工具。服务器放在养虾棚里网络断了采集和告警照常跑模型解释照常用只是手机端收不到推送而已。这个“断网可用”的性质对养殖环境来说几乎和可靠性一样重要毕竟很多养虾的地方在网络覆盖上真不一定靠谱。2.2 Ollama 相比其他本地推理方案胜在省心和生态我评估过的方案不止 Ollama 一个简单列一下当时的对比结论。工具优势劣势我的判断Ollama安装简单、模型管理方便、自带 OpenAI 兼容接口并发性能一般高并发场景要调参适合个人和中小项目首选llama.cpp 服务性能可控、资源占用低要自己写编译和封装服务程序适合喜欢折腾底层的人FastGPT 全家桶自带知识库、流程编排偏重和 OpenClaw 职责重复加分项但没必要vLLM高吞吐、适合大规模并发显存要求高、配置复杂项目规模到不了这阶段Ollama 对我来说最关键的是两点一个是模型文件管理做得极好一条 ollama pull 命令拉模型、一条命令切换模型跟 Docker 拉镜像一样直觉另一个是它提供了一个 OpenAI 兼容的 HTTP 接口OpenClaw 里的对接组件可以直接把地址指过去不需要写额外的插件层。这两点让我把选型时间压缩到了半天以内其他方案要么让我自己补接口要么让我配一堆基础设施。另外一个其实很现实的好处是Ollama 这类工具已经成了本地模型社区的事实标准之一出问题的时候网上能搜到的经验非常多。本地推理最怕的不是技术难而是卡在一个别人早踩过但你搜不到答案的坑里选社区活跃的主流工具能把这部分风险降到最低。3. 环境搭建和模型选型的几条实测结论3.1 服务端安装和启动参数一个都不能含糊我的正式运行环境是一台放在养虾棚里的旧服务器配置不豪华16GB 内存一张 8GB 显存的显卡。系统是 Ubuntu Server。如果你是在自己的台式机上调试下面的命令基本也一样能用。安装 Ollama 非常直接官方脚本一行命令搞定curl -fsSL https://ollama.com/install.sh | sh装完之后先别急着用有一个参数必须改否则后面 OpenClaw 根本连不上。Ollama 默认只监听本机回环地址 127.0.0.1也就是说只有同一台机器上的进程能访问它。我的 OpenClaw 如果跑在同一台服务器上倒还行但我习惯把调度器装一台机器、模型服务跑另一台机器所以必须让 Ollama 把服务暴露到局域网。做法是编辑 systemd 服务文件加上环境变量sudo systemctl edit ollama在打开的编辑区里写入[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434然后重启服务sudo systemctl daemon-reexec sudo systemctl restart ollama这里确认一下对外网卡的防火墙规则就好。我对局域网设备做了白名单反正养虾棚里的设备也就那么几台没必要让端口裸奔。另外还有两个参数我也在启动环境里预设了一个是并发数 OLLAMA_NUM_PARALLEL默认值是 1意思是同一时刻只处理一个请求。另一个是上下文长度 OLLAMA_CONTEXT_LENGTH默认对小模型来说偏短我之前吃过大亏这两个坑留到后面第五部分专门讲。建议一开始就把它们写进环境变量免得后面被系统静默限流。3.2 模型选型不是越大越好是按场景分配Ollama 装好后接下来就是拉模型。我先说结论不要一上来就追求大参数量模型。本地显存是硬约束7B 级别、4-bit 量化的模型在个人养虾这个场景里完全够用而当前能跑得动的高端模型反而会因为生成速度和资源占用把整个系统的响应拖垮。我拉了三个档位的模型备用各自分工不同档位显存需求实际用途实测情况3B 级别小模型约 2GB日常参数问答、设备状态解释快但复杂推理能力明显不足7B 级别通用模型约 6GB异常归因、周报生成、意图抽取速度和效果平衡点主力13B 级别中文模型约 10GB疑难问题综合判断好但生成速度明显偏慢所有模型我都选了量化版本量化档位是 Q4_K_M也就是把权重压缩到 4-bit 级别。这样做显存占用大概只有原版的一半出头中文理解能力在养殖这种专业词汇量不算大的场景里损失很小。我用同一个异常样本跑过 Q4 和 Q8 两版对比给出的归因结论几乎一样那多出来的显存留给自己跑并发显然更值。拉模型的命令是ollama pull MODEL_NAMEMODEL_NAME 替换成你在 Ollama 模型仓库里选中的具体标识就行。拉完后可以先用交互模式验证基础能力ollama run MODEL_NAME一般来说7B 模型在你原本那张 8GB 显卡上生成阶段大约能跑到每秒 12 到 15 个 token。给一个养虾告警写 300 字的解释大约 20 秒这个速度对“看报告”来说是能接受的。如果你觉得慢可以把问题拆小、让模型用条目式回复生成长度控制在 150 字以内速度会有明显改善。4. OpenClaw 接入 Ollama 的完整对接过程4.1 先理解 OpenClaw 的调度模型再决定怎么接OpenClaw 这个自动化框架的核心理念是把一套复杂流程拆成可编排的步骤每一步由不同的处理器去执行。我把自己项目里的流程拆成这样一条链路传感器数据进入 Kafka 或者 MQTT 主题规则引擎监听主题发现指标超限生成一条事件事件触发一个工作流先聚合数据拼装 prompt再调用模型模型输出经过解析回填到事件字段推给人工确认人工确认后继续执行后续设备动作关键点在于OpenClaw 不会去管模型怎么推理它只提供“调度时机”和“数据处理管道”。所以对接 Ollama本质上就是让 OpenClaw 在一个固定节点上发起一次 HTTP 调用。这种设计对我来说是舒服的想换模型或者换推理服务只改节点配置不用动业务流程。我在 OpenClaw 的节点配置里把大模型服务地址写成了 Ollama 的 OpenAI 兼容端点http://192.168.1.100:11434/v1这个端点直接用 HTTP 的方式转发 OpenAI 风格的请求OpenClaw 大多数现成的对话组件都能认。如果你用了别的推理工具只要它也兼容这套协议大概率可以直接无缝替换。4.2 REST 接口调用和结构化输出的细节如果不想依赖 OpenClaw 内置组件想自己写一个调用脚本也很简单。Ollama 本身提供了一个原生的聊天接口用 Python requests 就能调import requests import json payload { model: MODEL_NAME, messages: [ {role: system, content: 你是养虾水质诊断助手只用提供的数值说话。}, {role: user, content: 温度30.2溶氧4.1氨氮0.8pH8.6请判断问题等级并给出建议。} ], stream: False, options: { temperature: 0.3, top_p: 0.9 } } response requests.post(http://localhost:11434/api/chat, jsonpayload) response.raise_for_status() data response.json() print(data[message][content])这里我把 temperature 压到了 0.3。养虾场景下我不需要模型发挥想象力我要的是稳定、保守、可复现的回答。temperature 越高输出越随机当它被用来解释传感器数据时就非常危险所以宁可让它乏味也不能让它发挥。结构化输出是另一个重要细节。我不想让模型返回一长段自然语言然后靠正则去猜它有没有提到“增氧机”那太脆弱了。Ollama 支持格式化为 JSON只要在请求里带上 format 参数payload[format] json同时在 prompt 里明确指定输出字段比如这样请返回 JSON包含 severity、reason、suggested_actions 三个字段severity 只能是 low/mid/high。实测下来只要 prompt 把字段定义说清楚7B 级别的模型也能稳定输出可解析的 JSON。OpenClaw 拿到这段 JSON 之后就能直接把 suggested_actions 里的内容渲染成确认按钮整个过程没有人工去看“模型原文”的环节效率高出很多。5. 上线后最值得记录的六次踩坑5.1 所有机器都调不通Ollama 默认只听本机说话第一次跑通日志是在 OpenClaw 那台机器上连 Ollamacurl 死活超时。我先是怀疑防火墙全放开了还是不通又怀疑是不是端口被占用ss 一看发现 11434 确实在监听。最后才反应过来监听地址是 127.0.0.1相当于它只跟自己在说话其他机器当然敲不开门。这个坑虽然简单但因为默认行为太反直觉很容易让人先去查防火墙、查代理绕一大圈才回到正题。解决办法就是前面说的 OLLAMA_HOST0.0.0.0:11434。每次在新机器上装 Ollama我都会在第一时间改这个参数不然迟早被坑一次。5.2 并发一高就排队背后的限制参数被忽略了系统上线第三天有次凌晨多个池子同时触发告警OpenClaw 一次性给模型发了五个请求。结果这五个请求全部挤在一个队列里生成完一个才处理下一个等最后一个回答出来当时的告警已经过去十分钟了。查下来发现 Ollama 默认并发数是 1。解决办法是设置 OLLAMA_NUM_PARALLEL我调到 4同时给 OpenClaw 侧做了请求节流最多同时发 3 个模型请求留一个余量。并发问题不是改一个参数那么简单两边的写保护都要做否则模型服务容易在并发上来之后被请求淹没。5.3 周报被截断上下文窗口设小了另一个让我非常纳闷的问题是给模型输入一周的养殖数据让它生成周报结果每次回复到一百多字就突然停掉像话说到一半被人捂住嘴。检查消息内容发现模型输入长度明明没有超限后来才想到是上下文窗口默认值太小。Ollama 对不同模型设置的默认上下文长度不一样但普遍偏短我直接通过环境变量统一拉到了 8192这个长度对一周数据的聚合文本来说才勉强够用。改完之后周报生成就再没截断过。这个参数如果不主动想真的特别容易被忽略因为错误提示往往也不会出现就是静默地“输出到一半停下”。5.4 模型差点编出一套氨氮数据幻觉问题的真实教训有次系统在夜间捕获到氨氮波动模型生成的解释写得很漂亮说“氨氮从0.5缓慢上升到0.9伴随温度同步上升推测投喂过量”。但问题是数据库里那几天的氨氮值一直是 0.5 左右波动根本没有“0.9”这个数据。模型把前后几天的最值张冠李戴编了一个看起来很合理但实际不存在的事实链条好在推送给我之后我手边正好有记录当场发现了。这次之后我做了两件事。第一prompt 里强制要求模型“只能引用消息中给出的数值不得自己补充任何数字”并且加了一句“如果数值缺失请直接说不知道”。第二把温度调低到 0.3限制生成随机性。最重要的是OpenClaw 在调用模型之前会把数据整理成“10月12日 14:00 溶氧5.1 温度28.1”这样的史料式文本喂进去模型的任务是解释史料而不是翻历史数据库。数据进到 prompt幻觉的空间就被压到了最小。5.5 显存不足的无限循环硬上大模型被教做人有一段时间我鬼迷心窍想试试更大参数量的模型觉得效果好一点是一点。结果显存不够Ollama 自动退化成 CPU 推理生成速度掉到每秒两个 token 不到告警解释等得人心慌整个系统体验完全崩掉。后来我撤回 7B 模型把档位降下来一切恢复正常。这个教训直接让我放弃了“在本地追最新最大模型”的执念。设备就那么多显存与其硬上大模型把单次生成拉到一分钟不如让小模型在二十秒内给出一个七成的判断再让人去复核。在养虾这个场景时效性比绝对聪明的程度重要得多。5.6 JSON 输出时好时坏格式约束被提示词污染了我一度以为 formatjson 是无敌的后来发现只要 prompt 里夹杂了太多语气词和示例模型发出的 JSON 里偶尔还是会混进解释性文本。比如它会在 JSON 前面加一句“以下是判断结果”这行字直接把 OpenClaw 的解析器搞崩了。排查下来发现原因有两个一是 prompt 里给了一个很长的人类语气示例模型仿照着开始聊天二是生成时格式约束没有对整条生成序列生效某些采样路径下会把格式丢掉。解决办法是system prompt 和 user prompt 严格分开示例全部用纯 JSON 写不要用文字做括号说明调低 temperature解析时用宽容逻辑发现前导文字就剥离取第一个{和最后一个}之间的内容做兜底。从这之后 JSON 解析再没出过大岔子。6. 模型在养虾现场真正能干的活以及我的经验心得6.1 巡检周报和异常归因把数据变成人话模型接入之后日常里最实用的功能其实是自动周报。原来每周我都要手动拉数据、看图表、判断这周养殖情况有没有恶化趋势。现在 OpenClaw 每周日晚上自动把七日数据聚合成文本交给模型生成周报内容包括本周各指标的平均值、变化趋势、异常事件汇总、下周投喂和增氧策略建议。模型不需要发明新知识它做的事情是“把表格翻译成人话”这对大模型来说没有任何难度但对我来说省下来的时间却是实实在在的。异常归因是更进一步的应用。某天上午溶氧持续下跌我让 OpenClaw 把最近三天的水温、投喂量、增氧机运行时长全部喂给模型它给出的判断是“增氧机夜间运行时长较前日缩短且投喂量上调两者叠加导致溶氧消耗大于补充”这个结论和实际情况非常接近。这种“多项指标交叉归因”的能力恰是普通阈值规则最不擅长的地方也是本地模型在系统里存在感最高的时刻。6.2 自然语言指令下发与参数抽取把“想干啥”变成“具体动作”再往前走一步我用模型做了自然语言指令解析。原来控制增氧机得打开设备界面再点按钮现在直接在 OpenClaw 里输入一句“晚上把增氧机开大一点”模型会抽出一个 JSON 行动指令{ device: aerator, action: set_level, value: 6, scheduled_time: 21:00 }OpenClaw 解析这段 JSON 后把指令变成一条待确认的定时任务我确认后才会真正下发到继电器。这种交互模式大大降低了日常操作的摩擦。实测下来7B 模型做这种槽位抽取很稳只要在 prompt 里给出几个示例它基本能准确识别设备名和动作值。需要注意一点一定要限制 action 枚举值不能让它自己发明动作比如“set_level”写错成“set_power”设备控制逻辑就得跟着改。我在 system prompt 里把可用的 action 和枚举值都列了出来超出范围的输出直接拒绝执行。6.3 提示词设计和小模型使用的三条个人心得第一条心得是prompt 必须做“任务切片”不要一口气让模型干三件事。我之前试过让它同时做“判断告警等级、解释原因、生成周报摘要、提取建议”结果每个任务做得都浮于表面而且很容易在中间环节丢失上下文。拆成三个独立调用之后每个输出质量都明显上升代价是多一次请求但对本地模型来说完全值得。第二条心得是小模型更适合“填空”而不是“创作”。3B 级别的小模型让它自由写解释质量非常一般但同样的小模型如果 prompt 里给好“原因很可能是【 】建议先检查【 】”这种框架它填出来的内容反而有模有样。所以我把很多小模型任务都设计成了槽位式生成效果提升特别明显。第三条心得是要做好降级预案。本地模型服务一旦挂了系统不能跟着罢工。我在 OpenClaw 侧加了一个熔断机制模型调用连续失败三次就切换成“规则模板”模式用预设的 if-else 模板生成解释同时往手机发一条“模型服务异常”的通知。降级之后功能会粗糙但至少系统还在运转。这一步是我在踩完 5.2 并发坑之后补上的建议大家一开始就做别等到真出故障才想起。7. 写在最后的一点实际感受这套改造从动手到稳定运行大约花了一个月。如果让我提炼一条最核心的体会那就是本地模型在垂直场景里真正的价值不在于跟云端大模型比“聪明”而在于把推理能力变成养殖系统里一个随时可用、可控、可验证的组件。7B 模型够不够用我的答案是够前提是你愿意花时间去切分任务、约束输出、设计 prompt并且接受它偶尔给出的判断需要人来复核。对个人养虾这种规模来说这个“偶尔复核”的成本远远低于自己维护一堆脆弱规则的成本。后来的学习里我还在往系统里加两个方向一个是把摄像头画面接进来让模型帮忙看虾的活动状态这个对推理能力要求更高估计会用到更大的模型另一个是把本地语音接进来让人可以不用打字直接对系统说话。这些事情能不能做成另说但至少现在这套骨架已经给它们铺好了路。如果你也在搞类似的东西我的建议很简单先用一个 7B 模型把链路跑通把并发、上下文、JSON 解析这些基础问题都磨平整再考虑更高的能力。一步步来比一次到位要稳得多。