让农业Agent真正学会的底层设计——业务数据的三次跃迁

AI+农业 · 思考系列（二）

2026 年 1 月，国家数据局把这一年正式定义为"数据要素价值释放年"。同一个月，《工业制造、现代农业等九个领域"数据要素×"典型场景指引》下发，现代农业被划出 28 个典型场景——从智能播种、变量施肥，到全产业链数字追溯、农业金融信用评估。

政策这一边，窗口彻底打开了。但回到田里你会发现一个尴尬的事实——几乎每一家做了三五年的农业科技团队都会说“我们已经积累了很多数据”，可真把数据调出来想喂给 Agent，能被用上的，不到一成。

差距不在数据量，在数据的结构。这一篇想说清三件事——什么才算"业务数据"、权利怎么分、怎么让业务数据自己长出复利——最后给一份 8 问的自检清单。

一、什么才是农业的业务数据

过去十年，“农业数据”这四个字被用得很松。传感器每十分钟上报一条温湿度，是数据；无人机打一次药飞过来一张正射影像，也是数据；卫星每五天重访一次回传的 NDVI 值，还是数据。攒上三年，硬盘堆到几十 TB，看起来很有底气。

但这些都是原始记录，不是业务数据。两者差的不是一个形容词，差的是能不能被 Agent 用来学习。

1.1 业务数据的最小定义：情境 × 动作 × 结果

一条数据能不能被 Agent 消化，取决于它有没有凑齐三样东西——

三样凑齐，才叫一条业务数据。缺任何一样——传感器流水没动作、无人机影像没结果、农事日志没情境——都是半成品，Agent 学不到因果关系。

这听起来像常识，但真到田间你会发现 90% 的所谓"农业大数据"都是缺一缺二的——无人机飞了几千架次，对应的作业效果从来没系统回填；合作社记了五年的农事台账，旁边没有对应的气象和地块属性；示范基地的产量数据收齐了，但过程中的农艺动作散在微信群里找不回来。

💡 反共识 01

“积累了数据”不等于“积累了业务数据”。前者是硬盘里的数字，后者是能喂给 Agent 的养分。一家农业科技公司真实的竞争力，不是看它采了多少 TB，而是看它能拿出多少条凑齐三元组的业务数据。

1.2 为什么只有业务数据能喂Agent

Agent 从数据里学什么？学的不是数值分布，是因果关系——"在某种情境下，如果采取这个动作，大概率会得到哪种结果"。这个因果关系只能从三元组里提取。

国家数据局 1 月发布的《“数据要素×”现代农业 28 个典型场景指引》里有一句话定得很准——"数据已不再是农业生产经营中简单的辅助参考，而是贯穿农田全生命周期和养殖全流程的核心决策支撑"。成为"核心决策支撑"的前提，是数据能解释"当时为什么这样决定、后来是否奏效"。没有三元组，这句话不成立。

二、从“数据归谁”到“三权分置”

定义说清楚了，下一个绕不开的问题是——这些业务数据到底归谁。

过去两年我见过不少农业科技团队栽在这一件事上——前期投入几千万采数据、装传感器、做平台，签协议时没把权属说清，合作一两年后地方政府说数据是公共资源，合作社说数据归他们，龙头企业说我出了种子化肥、数据当然归我——最后 Agent 训练不了、商业化走不通、项目停摆。

要绕开这个陷阱，就绕不开一个国家层面给出的权威框架——数据产权的“结构性分置”。

2.1 先把官方的话引对：数据二十条的“三权分置”

2022 年底，中共中央、国务院印发《关于构建数据基础制度更好发挥数据要素作用的意见》（即“数据二十条”），第一次在国家文件里明确提出建立——

“数据资源持有权 · 数据加工使用权 · 数据产品经营权”

三权分置的产权运行机制

2026 年 3 月，国家数据局官网专家解读栏目刊发清华大学法学院申卫星教授的文章，把三权内涵讲得最清楚——

持有权——对数据的自主管控：存储方式、加密手段、访问权限。核心是"数据管家"的角色，负责防御数据持有状态不受侵犯，并承担数据安全责任。

使用权——在授权范围内对数据进行读取、分析、建模、二次开发。训练 Agent 用的就是这一权。

经营权——对外转让、许可、商业化利用。把训练好的 Agent 卖出去，卖的是这一权。

申卫星教授强调一个非常关键的判断——数据具有非消耗性、非竞争性、规模报酬递增、多源共生四个特点，一份数据可以被多个主体同时使用而不减损价值，反而因复用和融合而倍增。所以数据根本不该套用"单一所有权"的框架，必须分层。三权可以"三权俱备、三权单立、三权组合"——某一主体可以同时享有三项，也可以只享有一项。

这个理论底座放到农业里，直接解开了前面那道死结——谁都不用争所有权，三方各按贡献拿一层。

2.2农业场景的三权映射 · 一张四方授权模板

把“持有／使用／经营”三权按农业场景里的角色落下来，大致是这样一张表——

这张表最值得记下的是三个"不要做"——

• ▸不要跟生产主体抢"持有权"——持有权是他们的安全感底线；
• ▸不要免费拿"使用权"——免费来的使用权，合作一出问题立刻被收回；
• ▸不要回避"经营权"的分账条款——经营权没谈清楚，Agent 商业化走到第二年必出争议。

💡 反共识 02

不要去拼“数据归谁所有”——这场官司赢不了。要去设计“三权怎么分”——把持有权留给生产主体，把使用权谈成正式授权，把经营权用分账合同锁住。三权分置不是法律术语，是农业 Agent 团队能不能活过第三年的工程问题。

三、业务数据的三次跃迁

定义和权属落地后，下一个问题是——业务数据本身能长出什么？

这件事有个成熟度曲线。我习惯把它分成三档——80% 的农业科技团队停在档位一，10% 做到档位二，真正做到档位三的，凤毛麟角。

STAGE 01 · 档位一

原始数据存下来 · Raw Logging

传感器流水、无人机影像、GPS 轨迹都按时间戳存进库。量大，看起来扎实，但没有动作和结果，没法回喂模型——这是多数数字农业项目的真实状态。

STAGE 02 · 档位二

业务数据配成 · Contextual Pairing

情境、动作、结果三元组齐了。每一次农艺动作都能追回当时的气象、土壤、生长期，也能对回最终的产量／品质／成本。到这一档，Agent 才有因果关系可学——这是做一个“真·垂直农业 Agent”的最低门槛。

STAGE 03 · 档位三

经验结构化 · Skill-ification

把业务数据里反复出现的判断模式抽成结构化的经验条目——某品类在某情境下的最佳处理、某类异常的处置 SOP、某种气候下的配套农艺。这正是系列(一)里提到的 Hermes Skills 闭环——让经验变成可被 Agent 自动召回的资产。真正的复利，从档位三开始。

三档之间不是自然过渡，每一次跳档都要踩对一个关键动作。

3.1从档位一跳到档位二：补动作和结果

升级的关键不是再多装几个传感器，是把动作和结果补齐。动作靠什么补？靠让 Agent 反过来去问——播种之后 Agent 在微信群里追一次“今天谁播了几亩、用的什么种”；打药之后自动发一张小程序表单让确认；收获前对接磅码台把产量拉回来。这是 Browser-use 思路的农业化——Agent 自己去抓，而不是等人来填。

3.2从档位二跳到档位三：让经验“长出形状”

这一跳最容易被低估。很多团队以为三元组多了 Agent 就自然会学会——其实不是。原始三元组攒到几十万条，检索效率和匹配精度会塌方。必须抽一层——把重复出现的"情境模式 → 最佳动作 → 预期结果"抽成结构化的经验条目。Hermes 在 Agent 领域给出的答案叫 Skill；放到农业里，它可能是某品类某生长期异常处置 SOP，或者某气候事件下的配套农艺。

用最直白的话说——业务数据是原料，结构化经验才是菜。大部分团队忙着囤原料，忘了下锅。

四、让 Agent 自己把数据喂自己

三次跃迁讲的是“业务数据长什么样子”，这一章讲“业务数据从哪里长回来”。

过去十年数字农业项目最痛的点，是“靠人录入”的模式几乎没跑通过——乡镇农技员没时间、合作社负责人不愿学系统、一线农户更没动机。每个项目前三个月录入热闹非凡，三个月之后台账全部停更。

到了 Agent 时代，这件事有机会换个做法——Browser-use 或 CLI 这类技术把“让 Agent 用人的界面”变成了现实，换句话说，Agent 在给出建议的同时，可以自己把结果抓回来，不再需要人填。

4.1三种可行的回流路径

①  执行反馈回路

Agent 把一条建议推给合作社长 → 合作社长执行后在微信群里回“做了／没做” → Agent 抓到状态 → 若干天后再抓产量、影像变化 → 自动回填三元组。

②  人在环中校正

农艺师给每一条建议打“同意／修改／驳回”三个标签——每一次校正都是对 Agent 最直接的监督信号。农业容错低，这条回路必须保留。

③  定期评估回路

季末或年末对 Agent 本期所有建议做命中率盘点——命中率高的经验升级为 Skill，命中率低的打回去重新标注。这一条让档位二真正跳到档位三。

三条路径必须至少跑通两条，单跑任何一条都会留下系统性漏洞——只跑 ① 会让 Agent 胡说无人纠；只跑 ② 会把农艺师累死；只跑 ③ 会把当季的错误积到年底才发现。

💡 反共识 03

数据飞轮不是自动的，是回流机制设计出来的。没有回流闭环的 Agent 只是一台建议机器，不是一个会学习的系统。记一句话——每一条建议都必须有一次反馈；没有反馈的建议，在业务数据意义上等于没发生。

五、给建设者的业务数据 8 问

前四章是判断，这一章是自检。下面 8 问分成三组——定义、权属、回流。能清楚回答 5 个以上的团队，大概率已经走在 80% 同行前面。

第一组 · 定义层

01 ·你过去三年积累的数据里，三元组齐全率大约是多少？低于 30% 仍在档位一。

02 ·你能不能一句话说清自己的业务数据定义？情境、动作、结果三列都有命名规范吗？

03 ·对照国家数据局《“数据要素×”现代农业 28 个典型场景》，你的业务数据能覆盖哪几个场景？

第二组 · 权属层

04 ·和生产主体之间，持有权、使用权、经营权是不是在合作协议里逐条写清？

05 ·你的经营权授权有没有场景、年限、收益分成三项明确条款？

06 ·数据被三方同时用的场景，有没有预设争议处理机制（调解 / 仲裁 / 解除）？

第三组 · 回流层

07 ·你的 Agent 每给出一条建议，结果走哪条路径回来？执行反馈 / 人在环中 / 定期评估，至少跑了几条？

08 ·三年之后，你能拿出多少条结构化的经验条目？100 条是及格线，300 条是护城河的雏形。

系列(一)的末尾说过一句话——技术面每 18 个月重置一次，场景进入权过了窗口就重置不了。这一篇再加一句——框架每 18 个月重置，业务数据每一年复利。

这是留给农业团队的真护城河。云南某个烟草产区十年的病虫害＋物候＋产量配对数据，全世界只有一份；黑土地某片核心产区五年的玉米密植农艺结果，也不会凭空出现在 Hugging Face 上。业务数据不是采出来的，是一年一年种出来的、结算出来的、回流进来的。

所以如果你问我农业 Agent 的底层设计从哪里开始——答案不是选模型、不是搭平台、不是写 Prompt。答案是两件事——先把业务数据定义写清楚，再把三权分置和回流闭环搭起来。剩下 Agent 工程侧的事，等 18 个月后再选最好的那套 SDK 就行。

下一篇系列(三)会接着讲“切场景”——为什么农业 Agent 不能做成"一个大脑管所有品类"，以及单品类 + 单环节最小闭环的切法。

— END —