1. 课程导入与场景锚定
在开始动手写第一行推理代码之前，我们需要先把两件事想清楚：农业视觉到底要解决哪些任务，以及为什么这些任务不能简单地"把图片传到云端跑一个大模型"。这两件事决定了后面 29 章里每一个技术选择的边界——模型为什么必须轻、精度为什么不能一味追高、部署平台为什么常常是 Jetson 或 RK3588 而不是一台服务器。
一、四类典型农业视觉任务及其输出形态
农业视觉任务看似五花八门，但落到模型输出形态上，基本可以归为四类，每类对模型结构和后处理的要求差别很大：
- 病虫害检测：典型输出是目标框加类别，例如"叶片区域 + 病斑框 + 病斑类型（早疫病/白粉病/蚜虫）"。难点在于病斑尺度小、类间差异细微，且同一叶片上可能同时存在多种病害。常用指标是 mAP@0.5，实际田间场景往往要求对小型病斑的召回率单独统计。
- 果实计数：输出是目标框或点标注，核心指标不是 mAP 而是计数误差，例如"单株番茄挂果数误差 ≤ ±2 个"。果实密集遮挡时，检测框容易合并，因此常需要引入密度图或实例分割思路。
- 杂草识别：本质是作物与杂草的语义分割或检测，输出需要落到"喷头开/关"这样的执行决策上。它对实时性要求最高，因为喷施设备在移动，延迟直接转化为除草剂浪费或作物药害。
- 生长监测：输出多为回归量或分割掩膜，例如株高、叶面积指数、冠层覆盖率、生育期阶段。这类任务对单帧精度容忍度较高，但对时序一致性敏感——同一株作物连续多天的测量值不应剧烈跳变。
这四类任务的共同点是：输入都是田间自然图像，光照剧烈变化、背景杂乱、目标密集遮挡；不同点是输出形态和后处理逻辑完全不同。这直接影响了后面模型选型——检测头、分割头、回归头的设计不能一概而论。
二、为什么必须边缘部署：三个绕不开的约束
把农业视觉模型放到边缘设备上，不是技术炫技，而是被现实条件逼出来的选择。具体来说有三个约束：
第一是延迟。以杂草识别为例，喷施机具行进速度约 1.5 m/s，喷头响应窗口只有几十毫秒。如果图像上传云端、等待推理、再回传控制指令，往返延迟轻松超过 200 ms，喷头早已错过目标位置。边缘部署把"采集—推理—执行"压缩在同一台设备内，端到端延迟可以控制在 30～50 ms 量级。
第二是网络。大田、果园、温室的实际网络条件远不如实验室。4G 信号在棚架下衰减严重，山区果园甚至没有稳定覆盖。依赖云端的方案在关键时刻掉线，等于整个系统失效。本地推理让设备在断网时仍能独立工作。
第三是成本与隐私。一个果园可能部署几十个节点，如果每个节点都配 4G 流量卡并持续上传高清图像，流量成本和云端算力成本会迅速超过设备本身。同时，农场图像包含地块位置、作物长势等经营信息，本地处理也降低了数据外流风险。
三、边缘部署的代价：精度、内存与工程复杂度
边缘部署不是免费的午餐。把模型压到边缘设备上，通常要付出三方面代价：
- 精度损失：量化到 INT8、剪枝、蒸馏都会带来精度下降。以检测任务为例，FP32 到 INT8 的量化在 COCO 上通常掉 0.5～1.5 个 mAP 点，但在病斑这类小目标上，掉点可能更明显，需要针对性校准。
- 内存墙：边缘设备内存有限，模型权重之外，中间特征图、输入图像缓冲、后处理临时张量都要占空间。一个 640×640 输入的检测模型，仅输入张量就是 640×640×3×4 字节 ≈ 4.7 MB（FP32），特征图峰值内存往往是权重的数倍。
- 工程复杂度：从 PyTorch 训练到 ONNX 导出、再到 TensorRT 或 RKNN 转换，每一步都可能遇到算子不支持、精度对不齐、后处理需要重写的问题。这部分工作量常常被低估。
四、课程项目总览：一条完整的部署链路
本课程围绕一个贯穿始终的项目展开：面向温室番茄的病虫害检测与果实计数联合模型，部署到 Jetson Orin Nano 上，实现单路摄像头 30 FPS 以上的实时推理。选择这个项目，是因为它同时覆盖了检测（病斑）和计数（果实）两类输出，又落在真实的边缘硬件上，能把课程涉及的主要技术点串起来。
整条链路可以拆成五个阶段，每个阶段对应若干章节：
| 阶段 | 核心任务 | 关键产出 |
|---|---|---|
| 数据与任务定义 | 数据采集、标注规范、类别体系设计、训练/验证/测试划分 | 可训练的数据集与评测协议 |
| 模型选型与训练 | 轻量骨干网络选择、检测头设计、损失函数、训练策略 | FP32 基线模型与精度报告 |
| 压缩与优化 | 剪枝、蒸馏、量化感知训练、INT8 校准 | 精度可接受的压缩模型 |
| 格式转换与部署 | ONNX 导出、TensorRT 引擎构建、后处理 CUDA 化 | 可在设备上运行的推理引擎 |
| 系统集成与评测 | 摄像头接入、流水线并行、功耗与帧率实测、田间验证 | 端到端系统与评测报告 |
需要说明的是，表中给出的硬件型号和帧率目标是本课程设定的教学场景，实际项目中应根据设备规格书和现场测试结果调整。例如 Orin Nano 在不同功耗模式下算力差异明显，15 W 模式与 7 W 模式的实测帧率可能相差近一倍，这些都需要在系统集成阶段实测确认。
五、学习路径建议
对于不同背景的学习者，建议的切入方式略有不同：
如果你有深度学习基础但没做过部署，可以重点跟住"压缩与优化"和"格式转换"两个阶段，这两块是训练工程师转向部署工程师的主要门槛。如果你做过嵌入式开发但模型训练经验较少，建议在"模型选型与训练"阶段多花时间，理解检测头的输出结构和损失函数，否则后面调量化精度时会缺少判断依据。如果两者都有一定基础，可以直接从项目总览出发，按阶段推进，每完成一个阶段就用该阶段的评测指标做一次验收，避免问题累积到最后才暴露。
无论哪种路径，都建议在早期就搭好评测脚本：固定测试集、固定输入分辨率、固定后处理参数，每次模型变动都跑一遍，记录 mAP、计数误差、延迟和内存占用四个数。这四个数会贯穿整个课程，也是判断每一步优化是否值得的依据。