我把植物交给AI Agent：从传感器到水泵的自动浇水实战

养植物最头疼的，往往不是浇水本身，而是你根本不知道它此刻到底需不需要水。叶子蔫了可能是缺水，也可能是水浇多了烂根——单凭肉眼判断，翻车概率不低。市面上的自动浇花器大多只是定时开关，谈不上「智能」。B站上有位UP主干脆自己动手，用ESP32-S3、多路传感器、摄像头和大模型Agent，搭了一套能感知、会判断、还能动手浇水的植物AI Agent。整个过程的看点不在于最终那个水泵，而在于一个普通人如何借AI之力，把「观察—判断—行动—再观察」的闭环一点点跑通。

先跑最小闭环，再碰真实硬件

面对一个横跨硬件、嵌入式、Web开发和AI判断的项目，一上来就把所有模块接在一起是灾难性的——出了问题根本不知道是哪一层坏了。UP主的做法很克制：先让豆包工作做一个「连传感器数据都是假的」的最小版本，只验证一件事——AI能不能读取植物状态、做出判断、再把结果存回去。

这个思路值得所有做Agent项目的人借鉴。最小闭环跑通，意味着数据流和判断逻辑的骨架是通的，后面每接入一个真实硬件，都只是替换一个已知的输入源，而不是在未知中排查。

骨架通了之后才轮到真刀真枪。核心板是ESP32-S3，负责读传感器并通过WiFi把数据传到电脑上的应用。UP主同样没有一步到位，而是先让Agent帮忙把开发板连上WiFi、上传一组固定数据，确认数据真的能送到应用里。这一步里，豆包工作直接检查电脑环境、自动安装Arduino CLI、编译固件并烧录，回复里内嵌的终端窗口点一下就能测试，省去了来回切终端的麻烦。

ESP32-S3 是乐鑫科技推出的集成 Wi-Fi 与蓝牙 5（LE）的 32 位 SoC，采用双核 Xtensa LX7 架构，主频最高 240 MHz，片上带 512 KB SRAM 和可外挂 PSRAM/Flash。相比经典 ESP32，S3 增加了 AI 指令扩展、USB OTG 与更丰富的外设接口，适合需要摄像头、音频或较复杂本地运算的物联网项目。本文用它做核心板，正是看中其 Wi-Fi 联网能力、GPIO 数量足以挂载多路 I²C 传感器，并且能驱动 ESP32-CAM 这类图像模块；Arduino CLI 对 S3 的支持也已成熟，便于让 Agent 自动编译烧录。

给Agent装上皮肤和眼睛

有了数据通道，接下来是逐层替换假数据。温度与空气湿度用SHT40模块，接线时Agent特意标注了颜色，对新手友好；接完UP主还不放心，专门去看空调显示的温度做交叉验证，结果一致——这种「不轻信AI」的谨慎，恰恰是硬件项目该有的习惯。

光照用VAMO7700模块，这里暴露了一个AI替不了人的问题：按提示接线会挡住面包板同一行的插孔，这种物理空间的约束，AI看不到实物就很容易出错。UP主让Agent重新规划布线，虽然有经验的人一眼能看出仍有小瑕疵，但至少说明硬件信息必须由人反馈给AI。土壤传感器则直接用水杯做简单测试，并且因为尚未正式校准，特意让Agent加了一个「暂不可用于判断」的状态标记，避免AI把未校准的读数当真做决策。

只看数字还不够，叶子下垂、卷曲、发黄，传感器是感知不到的。于是加了一块ESP32-CAM当眼睛。UP主没有追求实时视频，而是定时上传清晰照片——植物变化慢，单张高清图更适合让AI做前后对比。

I²C（Inter-Integrated Circuit）是一种两线制同步串行总线，仅用 SCL（时钟）和 SDA（数据）两根信号线即可挂接多个从设备，每个设备有唯一地址。SHT40 温湿度模块、VAMO7700 光照模块通常都走 I²C，因此它们可以共享同一组引脚并联在总线上，这也是面包板上布线容易互相“打架”的原因——同一行插孔要同时容纳多根跳线和模块引脚。理解 I²C 的地址机制，有助于排查“数据读不到”是接线问题、地址冲突还是上拉电阻缺失；对新手而言，先确认总线能扫描到设备地址，再谈读数校准，是更稳妥的调试顺序。

拒绝if-else，让AI学会说「不确定」

真正的分水岭在判断逻辑。如果只是「土壤湿度低于某值就开水泵」，一个简单程序就够了，根本不需要AI。UP主给Agent定的规则是：必须同时看照片、温度、空气湿度、光照和可靠的土壤数据，信息不足时直接说「不确定」。

第一次综合判断时，因为土壤数据没校准，Agent没有硬给结论，而是输出了「不确定」。这正是想要的效果——不能让AI为了回答而硬答。这种设计在Agent落地中常被忽视：明确的能力边界比强行输出更有价值。

但每次检查都要重复交代一遍规则，太麻烦。UP主把这套流程固化成一个叫「植物健康询检」的skill，之后一句话或点一下就能按固定流程执行。他还故意关掉设备测试，Agent发现拿到的是过期数据后，没有继续拿旧数据判断，而是直接报告信息已过期——Agent开始有了「知道自己不能判断」的自觉。

Agent Skill 可以理解为一段被封装好的、可复用的提示词加工具调用流程：它把“要读哪些传感器、按什么顺序看、满足什么条件才下结论”固化成一份可被 Agent 调用的能力单元。与每次在对话里重复交代规则相比，skill 的好处是流程稳定、可被定时任务或其他 Agent 触发，也便于版本化管理。本文把巡检逻辑做成“植物健康询检”skill、把代码审查交给“全站代码质检官”，本质上是把 Agent 从“一次性问答”升级为“可编排的能力模块”，这也是当前 Agent 工程化的主流做法。

让AI自查、定时巡检与远程盯梢

页面设计是否合理，UP主没有自己逐项检查，而是让豆包工作直接操作浏览器打开植物控制台，以用户视角看页面。结果Agent发现了设备在线状态不直观、模拟数据和真实数据易混淆等问题。随后他又找来HTML和数据可视化相关的skill，把传感器卡片、设备状态、AI判断、照片、历史曲线和移动端一并做好。

代码越写越多，UP主担心同一个Agent从头写到尾，前面的错误会被一路继承。他没有另起多个Agent，而是调用了一个「全站代码质检官」的工作伙伴专门挑问题。这位质检官一口气挑出24个问题，把严重问题先修掉，避免了长期运行后的翻车。

skill需要人主动触发，于是又用定时任务让它按固定时间调用巡检skill，实现无人值守。人在外面怎么知道系统还在正常工作？通过远程控制，手机和电脑登录同一账号，手机端直接选择家里那台电脑和对应项目，问一句就能看到状态，两端任务同步。

最后一步才是水泵，而且必须加安全锁

真正接管浇水前，UP主先解决了那堆杂乱的线——这是必须由人确认的物理信息，Agent重新设计布线后清爽了不少。水泵接入时，他没有让AI一判断缺水就立刻启动，而是加了一层安全限制：只有判断结果明确需要浇水、且当前状态满足执行条件，水泵才允许工作。

这个项目最有意思的地方，其实已经不是「AI会不会浇水」。土壤干了就开水泵，简单程序也能做。真正有价值的是整个过程：从拆解项目、读真实传感器、看照片做综合判断，到把流程沉淀成skill、让Agent自查页面、用工作伙伴做质检、定时巡检、手机远程查看，最后才谨慎地控制水泵。这是一条完整的「观察—判断—行动—再观察」链路，也是一个普通人借AI把想法落地的样本。

执行器安全联锁是自动化控制中的常见设计：当且仅当多个条件同时满足时才允许执行动作，任一条件不满足即保持关闭。放到浇水场景，就是“AI 判断需要浇水”只是必要条件之一，还要叠加土壤数据已校准、设备在线且数据新鲜、水泵未处于故障或手动禁用状态等条件，才能通电启动。继电器或 MOS 管驱动水泵时，还应考虑断电默认关闭（fail-safe）、单次浇水量与最长运行时间上限，避免传感器误读或网络抖动导致持续喷水。这类硬性约束不能交给大模型自由裁量，必须在代码层强制实现。