去年帮一位做农业信息化的朋友诊断他们那套智能问答系统，农户在后台问了一句“我家大棚草莓叶子边缘发黑还卷边，该打什么药”，系统查了半天资料，回了一段教科书式的病害科普。结果农户再没说话。回访才知道，那位农户要的不是“可能是什么病”的科普，而是“现在到底该不该打药、打什么、兑多少水、什么时候打”——这背后得把近期阴雨天气、棚内温湿度、作物生长阶段、病害图谱、农药登记信息串起来做综合判断，是一个典型的多步推理场景。
这种场景正好是普通RAG问答撑不起来的。单轮检索只能给出“像什么病”，却回答不了“基于我家这块地当前的状态，下一步该干什么”。所以我花了几周时间，用langchain把一个农业问答机器人重构成带工具调用的Agent，让它能查气象、查地块档案、查栽培日历、检索病虫害资料，最后生成可执行的农事建议。这篇文章就把整套设计和实现过程完整记录下来，从工具链拆解、记忆管理、混合检索，到实际部署时的成本与踩坑，一次讲清楚。
1. 农业问答为什么必须“会调用工具”，而不是“背课文”
1.1 一个典型农事问题背后的五步推理链
还是回到开头那个例子。“草莓叶子边缘发黑、卷边”这句话抛给模型，如果只是普通聊天机器人，它大概率会给出灰霉病、缺钙、药害三种可能，然后罗列每种病的特征让农户自己对号入座。这话没错，但等于没说。
真正农技人员处理这个问题的思路是一条清晰的推理链：先确认最近一周的天气和棚内湿度，判断是不是高湿环境；再调出这个农户地块的档案，看土壤pH和钙含量，排除缺钙；然后定位到草莓当前所处的花果期，确认哪些药剂在这个阶段允许使用；最后从病虫害图鉴里检索匹配症状的病害资料，找出登记的防治方案，再换算成农户能操作的剂量。
这五步里，天气数据、地块档案、作物生育阶段、病害图谱、农药登记信息，分布在完全不同的数据源里。做Agent之前，我的做法是把这些资料全部塞进向量库，让模型一次检索全给出来。结果可想而知：检索结果混杂着适用于不同地域、不同季节、不同生育期的内容，模型被互相矛盾的资料干扰，给出的答案经常前后打架。
换成人来看就很好理解了。一个刚入行的农技员，也不可能靠背一整本《植保手册》就下地看病。他得先问农户要地块信息，再查当地气象，再翻图谱比对，最后查药品登记表。AI要做的是模拟这套工作流程，而不是把整个图书馆塞进一个提示词里。这就是Agent和聊天机器人的本质区别：聊天机器人靠“记忆”回答，Agent靠“行动”回答。
1.2 农业数据天生分散，这是Agent化的最大理由
农业生产链路里的数据源非常零散。气象数据在气象服务接口，土壤检测报告在检测机构出具的PDF里，栽培技术规程在农技推广部门的文档里，农药登记信息在监管数据库里，农资价格又在各个经销商手里。没有任何一个模型预训练的时候能把所有实时数据装进去，也没有任何一次检索能把所有零散数据一次性拉到上下文里。
所以设计Agent时，我给自己定的原则很简单：**凡是会随时变化的数据，一律走工具实时查询；凡是相对固定的知识，才走知识库检索。**气象、价格、地块档案属于前者，栽培技术、病害特征、农药登记信息属于后者。这条原则帮我省了大量token，也大幅减少了模型输出过时信息的概率。
数据分散造成的另一个问题是：不同数据源之间经常有隐性的关联。比如气象数据里的一周连续阴雨，和病害图谱里“高湿环境诱发灰霉病”的知识点，单独看都是孤立信息，但Agent把它们串起来之后就能给出“未来三天继续阴雨，不建议立即打药，先通风降湿”这种真正有用的农事判断。这种跨数据源的组合推理，是纯RAG系统很难做到的，也是我坚持用Agent架构的根本原因。
1.3 三种用户、三种问法，背后得是同一套大脑
农业助手的用户不只有农户。我在需求调研阶段整理了三个典型角色：农户、农技员、农资店经营者。农户提问最口语化，“叶子黄了用什么药好使”是典型问法；农技员会问专业问题，比如“这茬番茄的灰霉病病原体拉丁名是什么，防治适期如何确定”；农资店经营者则关心“哪个成分的药剂在当地销量好、价格稳定”。
三种人的问法差异很大，但底层需要的是同一套工具和知识库。Agent的好处在于，它可以先识别提问者的身份和意图，再决定用哪些工具、以什么粒度的语言回答。给农户的回答要直接、可操作；给农技员的回答要有学名、有依据；给农资店经营者的回答要带价格区间和登记信息。
我实现这个能力的方式是给Agent的提示词里加了一段“用户身份识别”的规则，让它先判断来问问题的人更像哪类用户，再去调用工具。同时，在检索知识的环节，会对同一个知识点做“通俗版”和“专业版”两套摘要存储，Agent根据用户类型选择读取哪一版。这个小设计非常有效，后面实测阶段也验证了它能显著降低“答案专业但农户看不懂”的投诉率。
2. Agent的工具集拆解：我给农业助手配了五类“手”
2.1 五类工具一览与设计初衷
工具是Agent能“动手干活”的关键。我最初只配了两个工具——天气查询和病虫害检索，跑通后很快发现不够用：没有地块档案，模型不知道“这块地种的是什么”；没有作物日历，模型分不清当前是苗期还是花果期；没有农资行情，模型推荐的药剂价格完全脱离当地市场。
最终沉淀下来的工具分五类，每一类解决一个明确的问题。我用表格梳理一下：
| 工具类别 | 输入 | 输出 | 典型使用场景 |
|---|---|---|---|
| 天气查询 | 地区、日期 | 温度、降水、风力、湿度摘要 | 判断气候是否利于病害扩散 |
| 地块档案查询 | 地块ID或用户ID | 土壤类型、pH、种植作物、播种日期、历史病害 | 一切水肥和用药建议的基础 |
| 作物栽培日历 | 作物、地区、当前日期 | 当前生育阶段及对应农事操作 | 确定喷药窗口、施肥时机 |
| 病虫害图鉴检索 | 症状关键词或图片描述 | 候选病害特征、防治要点 | 症状识别和诊断 |
| 农资行情查询 | 地区、农资品类 | 附近经销商报价区间 | 药剂和肥料采购建议 |
工具不是越多越好，每个工具都必须有明确的“输入边界”。给模型一个输入边界清晰的工具，它才知道什么时候该调、该传什么参数。比如天气查询工具要求传入“地区”和“日期”，模型在回答“明天能不能打药”时，就会自动把“明天”转成具体日期再去查，而不是凭空猜。
2.2 用langchain定义工具：参数Schema和描述文档的决定性作用
langchain里定义一个工具非常方便，核心是@tool装饰器。但真正的坑在函数签名和docstring。Agent用的模型是靠函数名、参数类型和docstring来理解“这个工具是干什么的”，描述写得模糊，模型就会瞎调或漏调。
我写工具时有一个固定套路：参数名用全称，docstring里写清楚“什么时候用”、“输入是什么格式”、“输出是什么样子”。下面是一个天气查询工具的示例：
from langchain.tools import tool @tool def query_weather(region: str, query_date: str) -> str: """ 查询指定农业区域在指定日期的天气概况。 适用场景：判断是否适合喷药、灌溉、露天农事操作； 需要结合近期降水、风速、温度来判断病害发生风险时使用。 参数： region: 农业区域名称，如“城关镇”“柳河乡”，尽量具体； query_date: 日期，格式 YYYY-MM-DD，可延后或提前。 返回： 一段中文摘要，包含最高/最低温度、降水量、平均风速、 相对湿度等关键信息，已按可读性格式化。 """ weather_data = weather_service.fetch(region, query_date) return format_weather_summary(weather_data)这段代码看着简单，但docstring里的每一句话都在给模型做“行为训练”。我测试过一版把docstring写成“查询天气”四个字的工具，结果模型在需要查土壤湿度时也能强行调用这个天气工具，输出完全没法看。后来把所有工具的docstring都改成“适用场景+参数说明+返回说明”三段式，误调用的次数立刻下降了一大截。
还有一点容易被忽略：工具返回的内容应该尽量精简。模型上下文窗口有限，一次对话可能调用多个工具，如果每个工具都返回几十KB的原始JSON，后面的推理质量会明显下降。我的做法是每个工具在return之前都先用本地函数做一次“降噪”，把原始数据压成两三句摘要，只保留跟农事决策相关的那几个字段，跟决策无关的数据直接丢弃。
2.3 工具调用失败时的优雅降级
任何生产环境里的工具都会失败，气象接口可能超时，数据库可能连不上，图鉴服务可能返回空结果。Agent设计里最容易忽略的就是失败处理。模型在工具超时之后陷入沉默，或者在失败后反复重试同一个工具，这两种情况我都遇到过。
我现在的处理分三层。第一层，工具内部做异常捕获，统一返回一个标准失败文本，比如“天气查询失败：接口超时，请稍后再试”，而不是直接抛异常让Agent崩溃。第二层，在AgentExecutor里设置max_iterations参数限制最大迭代轮数，防止模型卡在“调工具-失败-再调工具”的死循环里。第三层，在提示词里写死兜底话术：如果某个工具数据拿不到，不要硬编答案，直接告诉用户“当前无法获取XX数据，建议咨询当地农技站”。
注意：第三层兜底话术非常重要。农业场景万一给错信息，轻则白跑一趟，重则影响收成。我宁可让Agent承认自己不知道，也不要让它编一个看着合理的答案。
3. 记忆管理：让Agent记往地块，又不被闲聊拖垮
3.1 短期记忆：农事追问不能把前文冲掉
农业对话有一个特点：农户的问题经常是一连串追问。“叶子发黑怎么办”——“需要先确认叶片是干枯还是水渍状”——“是水渍状，还带一层灰毛”——“最近有没有连续阴雨？”这一串对话里，最开始的“叶子发黑”被后面几轮信息不断修正，如果模型没记住前文，后面回答就完全对不上。
我用的是ConversationBufferWindowMemory，维护最近几轮对话的完整历史，只保留窗口内的信息。窗口大小经过测试，取6轮最合适：少于6轮，农户追问的信息容易被截断；多于6轮，token开销变大，而且对话主题飘远时模型容易被早期无关内容干扰。
但窗口记忆有个副作用：Agent在调用工具时会把整个对话历史塞给模型，如果中间夹着家长里短的闲聊，会稀释工具调用指令的权重。所以我在提示词里加了一条规则：窗口记忆只作为背景信息，当前轮次的用户问题才是需要响应的主线。这个规则虽然简单，但确实让Agent在长对话中的工具调用准确率稳定了很多。
3.2 长期记忆：给每块地建一本“病历档案”
短期记忆只管当前一次会话，但农事决策最需要的其实是一个农户地块长期的数据积累：去年这块地得过什么病、土壤pH是多少、上一茬种的是什么。这些信息如果每次都要农户重新说一遍，体验就很糟糕，而且农户自己也未必记得清。
我设计了一个地块档案模块，本质上是一张本地数据库表，字段包括地块编号、种植作物、品种、播种日期、土壤类型、pH值、有机质含量、近年病害记录、最近农事操作记录。每次Agent回答完问题之后，如果发现对话中出现了可更新的地块信息，就会调用一个内部维护工具，把新信息写回档案。
这套设计的效果在实测中非常明显。有一个模拟农户连续问了三次同一块地的番茄问题，第一次问完土壤偏酸后，第二次再问“为什么叶片发黄”，Agent直接调出了“该地块土壤pH 5.8，低于番茄适宜范围”的档案，给出的答案直接锁定在酸性土壤引起的养分吸收障碍上，完全没有绕弯子。这个能力让整套系统的回答命中率上了一个台阶。
3.3 从单题回答到任务规划：Plan-and-Execute实践
普通问答是“一个问题一个答案”，但农业里很多需求是“一个目标一串操作”。比如“帮我安排这周大棚的农事计划”，就需要先查未来一周天气，再查当前草莓的生育阶段，再查该阶段的水肥和植保要点，最后还要结合地块档案给出具体哪天浇水、哪天打药。
这类多步任务，用基础的ReAct也能做，但Agent容易东一步西一步，步骤之间没有清晰的顺序依赖。我后来改成了Plan-and-Execute的思路：先让模型把用户的大目标拆成一个小步骤列表，再逐步执行。langchain里可以在提示词中要求模型先输出计划，再开始调用工具。
实际运行效果比直接ReAct稳定得多。比如“安排一周农事计划”，Agent会先输出一个计划草稿：查询天气、查询作物日历、查询地块档案、生成计划。然后按顺序执行，每完成一步就把结果放到上下文里，最后汇总生成一张按天排列的农事任务表。如果某个环节数据缺失，它会在计划阶段就标出来，而不是闷头一路执行到底。这也是我觉得Agent比传统流程引擎聪明的地方——它能在中途根据实际情况动态调整后面的步骤，而不是死板地走固定流程。
4. 知识库与混合检索：回答必须带“证据链”才敢给农户看
4.1 把PDF切成“有身份”的卡片，而不是无脑分块
做农业RAG知识库，第一步就把很多文档切碎重新组装，切成一个个固定长度的chunk，然后一股脑灌进向量库。这种做法的后果是：一条关于“草莓灰霉病防治”的知识被拦腰截断，病征描述、发病条件、药剂方案各自散落在不同的向量片段里，检索的时候经常只能捞到一半，答案自然残缺不全。
我重新设计了一套文档加工流程，核心思想是“按文档自身的语义结构切分，而不是按字符数量切分”。农业技术资料一般都有非常清晰的结构，比如“症状识别—发病规律—防治方法—药剂选择”这四段。我用文档解析工具先把PDF转成带标题结构的文本，识别出各级标题和表格，然后以“病害/品种/技术主题”为单位，把每个完整主题切成一张知识卡片，卡片上保留主题名称、适用作物、适用地区、适用季节、正文内容和来源页码。
切好之后，每张卡片的元数据也要填完整：作物种类、病害名称、地区标签、季节标签、文档来源。这些元数据后面做属性过滤时至关重要——没有它们，向量检索就只是在大杂烩里捞相似文本，有了它们，才能做到“只在本作物、本地区、本季节的卡片里找答案”。
4.2 向量检索+关键词检索+属性过滤的混合策略
在做纯向量检索的时候，我发现一个很典型的问题：农户问“番茄叶子卷了”，向量检索会把“番茄卷叶病毒病”“番茄叶片卷曲生理性原因”“辣椒卷叶病”都捞出来，因为语义上都沾边。但如果先按元数据过滤掉“作物=辣椒”的卡片，再在番茄的卡片里做检索，精确度就能提高一截。
三种检索方式的定位如下：
| 检索方式 | 最适合解决什么 | 薄弱点 |
|---|---|---|
| 向量语义检索 | 症状描述口语化、模糊匹配 | 对精确属性不敏感 |
| 关键词精确检索 | 查询明确的登记证号、药剂成分、专有名词 | 无法理解语义变体 |
| 元数据属性过滤 | 限定作物、地区、季节、发病部位 | 单独使用无法回答开放问题 |
我的落地做法是“先用属性过滤缩小范围，再混合向量和关键词结果，最后按相关度加权合并”。比如“草莓 叶子边缘发黑”，先按作物属性“草莓”过滤出所有草莓相关的卡片，剩下卡片里做向量检索和关键词检索，最后把两类命中的结果按分数合并排序。
合并的具体比例我调了几版，最终稳定在向量召回占七成、关键词命中占三成。因为农业症状描述太口语化，农户很少在问题里提到精确的术语，向量语义匹配的作用远比生硬的关键词匹配重要，但关键词匹配能够在向量检索漏掉“登记证号”“有效成分”这类硬信息时兜底。
4.3 防“药方幻觉”的证据链校验
农业问答最危险的就是“药方幻觉”。模型在检索资料时看到一个病害名，再用自己预训练知识里的药剂知识补全细节，生成一个看起来合理、但实际上没登记、剂量也不对的使用方案。这种事我绝不允许发生——农业生产中用药错误不是一句空话，会让农户一季的劳动打水漂。
我的防线有三层。第一层，所有药剂推荐必须来自知识库原文，模型在输出用药建议时必须附上来源文档的标题和页码；第二层，我把农药登记信息做成一个独立的结构化数据表，包含登记作物、防治对象、推荐剂量、安全间隔期，Agent在给出任何用药建议之前，必须先查这张表，确保推荐的药剂在该作物和病害上有登记记录；第三层，在提示词里写死规则：如果没有检索到明确登记信息，只描述病害特征和防治原则，不推荐具体药剂，宁可让农户去咨询农技站。
这套“证据链校验”机制上线之后，我专门做了一轮压力测试，故意问一些边缘的、冷门的病害组合，看Agent会不会编造药剂名。效果非常理想——它开始频繁输出“根据现有资料，未检索到针对该病害的登记用药方案，建议联系当地农技站”这句话了。看似保守，但这恰恰是农业助手最该有的态度。
5. 实测翻车现场：单位换算、地域物候和脏数据怎么兜底
5.1 单位换算翻车：Agent不知道1亩地有多少平方米
第一次联调的时候，我让测试Agent对着一块3亩地的草莓园推荐水肥方案。数据源里写的湿度监测值是“土壤相对含水量62%”，栽培手册里建议的是“开花期土壤相对含水量60%-70%”，地块档案里写的是“灌溉面积2.5亩”。Agent算了一次用水量，输出的推荐值足足差了三分之一。排查之后发现问题很简单：手册里的滴灌用量单位是“吨/亩”，但地块档案里的面积单位是“平方米”，Agent做换算时按1000平方米当一亩算了，实际上1亩约等于666.67平方米。
这个坑非常典型。大模型对数字单位转换并不总是可靠的，尤其面对农业里五花八门的单位：亩、公顷、平方米、吨、千克、克/株、升/亩。我的处理方式是在工具层彻底统一单位，所有结构化数据从接口拿回来后，先经过一层标准化转换再给模型。地块面积统一转成“亩”，水量统一转成“吨/亩”，叶面肥浓度统一转成“克/升”，让模型永远只需要处理一套单位，不需要自己做换算。
5.2 地域物候差异：同一个品种在不同地区方案完全不同
还有一次实测，一个模拟用户问“春小麦现在可以播种了吗”，Agent按华北平原的物候期给出了“可以开始播种”的答复。但用户的地块在东北高寒地区，那里这个时候地温根本不够。问题出在知识库的文档里，我切分知识卡片时虽然打了“地区”标签，但检索时只在病害场景启用了地域过滤，农事操作类知识完全没做地域维度约束。
修复方案是把地域过滤从“部分场景使用”改成“全链路强制使用”。用户首次进入系统时选择所在区域，这个区域会同步到所有工具调用和检索请求里。知识卡片里没有匹配地区标签的通用知识（比如“种子存放原则”这类全国通用的内容）仍然可以命中，但涉及播期、物候、品种选择的卡片，必须地区标签匹配才允许返回。这之后，再没有出现过“用华北经验回答东北问题”的情况。
5.3 脏数据与重复调用：工具界的“牛皮癣”
实际跑起来，工具的输入数据经常是脏的。气象接口某天缺测了，返回的降水量字段是空值；土壤检测报告里pH值单位写的是“pH值5.5”而不是纯数字；农资行情表的某个品种价格被录成了“--”。这些脏数据被Agent拿到之后，轻则给出错误答案，重则导致Agent连续多轮重试同一个工具。
我在每个工具内部加了一条统一规则：拿到的原始数据先做一次清洗，缺字段就补默认值，格式不对就尝试解析，解析不了就明确标注“数据缺失”。工具返回给模型的内容不再是原始数据，而是已经标注好“哪些字段可靠、哪些字段缺失”的摘要。这样模型就不会对着一个空值编答案，而是会主动告诉用户“当前数据缺失，建议补充土壤检测后再做判断”。
这轮改造之后，Agent在测试集上的“编造缺失数据”行为彻底消失了。以前模型拿到缺降水量的天气摘要，会自己编一个“未来三天降水量5毫米”出来，现在它会老老实实说“未来三天的降水数据暂缺，无法判断田间湿度变化趋势”。对农业场景来说，这种“知道不知道”的能力，比“什么都能答”更宝贵。
6. 成本与落地：怎么样才算真正“用得起”的农业Agent
6.1 Token成本：一次完整农事方案到底烧多少钱
Agent的能力提升是有代价的——每次调用工具，模型的上下文里都要塞进工具描述、调用日志、中间结果，token消耗比普通问答高出好几倍。我统计过，一个简单的单轮问答大约消耗约2000 token，但一次完整的“病害诊断+用药建议”流程，因为涉及三次以上的工具调用和多轮推理，token消耗经常高达1.5万到2万。
成本优化我做了三件事。第一，前面提到的所有工具都输出“降噪摘要”，尽量压缩中间结果。这是个持续优化的过程，每版摘要文本都尽量压短，只保留决策必需字段；第二，对频繁查询的静态知识做结果缓存，比如“某地区常年平均气温”“某品种的标准栽培日历”这类基本不变的内容，直接命中缓存，不走模型推理；第三，简单问题用轻量模型处理，只有复杂农事诊断才切到更强的模型。分流策略是在提示词里让Agent自己判断问题复杂度，再调用对应的模型实例。
6.2 响应速度：农户等不了30秒
成本之外，响应速度是第二个坎。我第一版Agent的完整链路是：用户提问→模型理解→调用工具1→再调用工具2→模型生成答案。工具串行调用加上每个工具的网络延迟，一趟下来常常要25秒以上。让农户对着手机等半分钟才看到回答，基本等于失败。
提速的关键是把没有依赖关系的工具调用并行化。在“草莓叶子发黑”这个案例里，查询天气和查询地块档案这两件事互不依赖，完全可以同时发起。我用langchain里的并行工具调用方式改造后，整体响应时间从25秒压到了10秒以内。再配合轻量模型处理简单请求，整个系统的体验就基本达标了。还有一个看似不起眼但很有效的优化：开场白和引导语用静态模板，不走模型生成，省掉了每次对话启动的第一段token和延迟。
6.3 真正的落地：把回答变成一张“农事任务单”
技术链路的最后一步，是交互形态。我一开始做的Agent是标准的对话框，用户问、Agent答，答完就完了。但是在真实使用中，很多农户要的不是“一段话”，而是“接下来怎么办”的可执行清单。
后来我把整套流程固化成一个输出模板：只要对话中涉及农事操作，Agent就会自动生成一张结构化任务单，按“操作日期、操作内容、用量或参数、注意事项”四个字段列清楚。农户看完对话总结后，直接照着任务单执行，还能一键把任务项加入日历提醒。实测下来，这个“从答案到任务单”的改动，比我在工具链和模型调优上做的所有努力反馈都更强烈。这也印证了我做这个项目一直坚持的判断：农业Agent的终局形态，不是一个更聪明的聊天框，而是一个能帮你把农活安排明白的数字农技员。
