日期:2026-11-08
我们对接的设施农业基地,几十个大棚,温湿度、光照、土壤墒情和肥料浓度原来靠人工看表、凭经验开关通风和水肥设备。问题是人的注意力覆盖不了几十个棚,水肥和通风常常跟不上作物节律,同一个品种在不同棚的长势差异明显,产量和品质波动大。老板想上自动调控,但提了一个很现实的要求:别一上来就全自动,他怕系统乱动作把一棚菜搞坏。
我们进场时确实也谨慎,农业这事容错低,一个错误通风指令在盛夏能直接毁一棚。这个项目最后做成的是"模型给建议、人工在关键节点确认、逐步放权",而不是黑盒全自动。我们当时坚持这一点,是因为见过同行全自动调控翻车的案例,作物不会给你后悔的机会。
落地后,边缘物联网网关接每个大棚的温湿光、土壤墒情和肥液浓度,做本地聚合后回传。AI 底座这边做两件事:一是按作物种类和生长阶段建环境节律模型,知道这个棚此刻该是什么温湿光;二是基于模型给调控建议,比如该通风到什么程度、水肥补给的量和时机。
调控不是模型直接下发设备指令,而是先给建议,常规安全的动作(小幅通风、补水)自动执行,涉及较大幅度或跨阈值的关键动作,推给棚管员确认后再执行。设备联动执行后回采实际环境变化,验证调控是否生效,没生效的标记异常。后台看环境达标率、水肥节约率、产量波动收窄幅度和告警时延。
绕不开的是多棚环境节律建模。不同作物、不同生长阶段对环境的需求差很多,不能用一套参数。我们按"品种加阶段"建模型,每个棚的实际数据回流持续校准基线,模型不是一次性训好就完事,而是跟着季节和作物滚动更新。
紧接着要处理的是边缘算力与弱网。大棚现场网络不稳,网关不能依赖中心实时算。我们把推理轻量化后下沉到边缘,断网时本地也能按最近基线做基本调控,中心恢复后补传数据,不让网络问题让棚子失管。
再往下是调控建议的可信度。模型给的建议不能只是个数字,得带依据,比如"当前温度高于本阶段基线 2.3 度,建议通风至 X"。我们让建议可解释,棚管员才敢确认,黑盒指令没人敢点。这也是为什么关键动作必须人工确认,信任是一步步建立的。
最后是设备联动的可靠性。执行指令后环境没按预期变化,可能是设备卡了。我们加了回采校验,执行后一段时间复测,偏差超阈值就告警并标记设备,不让"指令发了就等于做好了"的错觉酿成事故。
案例片段(已脱敏): 节律建模与调控确认配置(节选):
edge_inference: model: light_节律_v2 offline_baseline_fallback: true # 断网用最近基线 control: auto_safe_actions: [micro_vent, top_up_water] human_confirm_actions: [big_vent, fert_dose] suggestion_explainable: true # 建议带依据 post_exec_verify: true # 执行后回采校验 verify_dev_alarm: 0.8运行日志:环境达标率由 71% 升至 89%,水肥节约 17%,同品种跨棚产量波动收窄 22%。
运行一个种植季,环境达标率,即各棚实际环境落在节律基线的时长占比,从七成一升到八成九,几十个棚的管护水平被拉齐。水肥按模型精施,整体节约约一成七,主要是减少了凭经验多施的部分。同品种跨棚的产量波动收窄了两成二,原来有的棚明显长得好、有的差,现在差距压下来了。
告警时延,从人工发现到系统提示,做到分钟级。关键动作的人工确认率很高,棚管员对带依据的建议接受度好,没有被黑盒指令坑过。因调控失误导致的绝产事故为零。文中数据为项目复盘口径,均为示意值,非审计级精确数字。
我们当时纠结全自动能做到什么程度,实际跑下来,人工确认这一步非但没拖慢,反而建立了信任,棚管员现在愿意把更多常规动作交给自动。这点上当初的保守是对的。
农业调控别追求一上来全自动,作物容错低,模型给建议、关键动作人工确认、逐步放权,这条路最稳,信任是一步步建立的。节律模型要按品种加阶段建,且跟着季节和作物持续校准,训一次就完事的思想在农业里行不通。
边缘算力弱网是常态,轻量模型下沉到网关、断网用最近基线兜底,不能让网络问题让棚子失管。调控建议必须可解释,带依据才有人敢确认,黑盒指令没人点。执行后一定要回采校验,指令发了不等于做好了,设备卡了要有告警。
这个项目让我坚持做对的一件事,是没一上来就全自动。农业容错太低,作物不会给你后悔机会,一个错误通风指令在盛夏能直接毁一棚。先给建议、关键动作人工确认、逐步放权,信任是一步步建立的,这点上当初的保守救了几个棚。现在棚管员愿意把更多常规动作交给自动,是看系统没乱来之后才真正放心的。
顺带,回采校验的偏差阈值别定太宽,我们起初宽松,设备卡了也没告警,后来收紧才灵。轻量模型下沉到边缘这一步不能省,大棚网络不稳是常态,断网还能按最近基线兜底,棚子才不会失管。