智慧农业生态 Agri-Eco

智慧农业生态 · 全球分区农业 AI 助手

以数据平台分析为基座，孵化多层级农业 AI 关键节点生态

🎯 项目目标口径（单一权威）：见 docs/CORE_OBJECTIVE.md —— AI + 机器人驱动的农业精准控制基础设施（v1.1，2026-11-06 用户确认）。

一句话：以「全球水文/土地/气候数据库」为数据底座，做「农村/片区/城市差异化分布」，形成「大规模 vs 建筑内精细化双模式」的 AI 精准控制要素，成为未来大农业基础设施和产业链的关键生态位。

一级目标：让 MCP server 被外部 agent 真实调用（≥500 次 / ≥20 独立调用方）。诚实边界：新定位含待建方向（机器人执行/全球水文库/大规模大田），G1 达标前不宣称"被依赖"。

阶段门禁数字见 docs/north_star_and_phase_gates.md；全面扫描与提升报告见 docs/full_liftup_assessment_2026-10-08.md；2026-10 前沿视角提升评估见 docs/DIMENSION_LIFTUP_2026-10-28.md。

🧭 前沿定位（2026-10-28）：在农业 AI「大模型 + 机理模型 + 专业小模型」协同体系（农民日报 2026-09-30）中，本项目扮演 机理模型 + 专业小模型层——是农业大模型的机理约束器 + 可执行配方 + 可审计资产，与神农 4.0 / 农业世界模型 SNWM 1.0 互补非竞争（它们提供理解与调度，我们提供科学约束与可复现执行）。护城河五点：可执行配方 / 可审计血缘 / 零依赖可复现 / 保形置信区间 / MCP 2026-07-28 无状态对齐。生态位定案见 docs/CORE_OBJECTIVE.md §十二（含 §12.1 2026-11-06 基础设施生态位扩展）。

🚀 已上架官方 MCP Registry：io.github.lm203688/agri-eco v1.1.0（2026-10-08）

curl -s "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.lm203688/agri-eco"

🔎 市场入口（4 家全覆盖）：

• 官方 MCP Registry：io.github.lm203688/agri-eco v1.1.0 ✅
• Smithery：smithery.yaml 已就绪，仓库自动发现（搜索入口）✅
• Glama：已提交（2026-10-11，POST /api/mcp/servers/submit.data 200），等 Glama 审批邮件补 Dockerfile 后索引（目录入口）🟡
• LobeHub：lm203688-smart-agri-eco（2026-10-08 自动发现）✅

📋 分发就绪度自检（每次评审/发布前跑一次）：

python scripts/check_distribution_readiness.py

一次性验证 10 类分发入口：MCP server / A2A Card / Agent Plugin / Smithery / 官方 Registry / MCPB 包 / CI workflow / Demo 部署 / 市场材料 / GitHub 同步。

CI：41 步 × Python 3.10/3.11/3.12 全绿 · 单测 956 OK · Demo 端点 14/14 · MCPB 构建确定性可复现 · GitHub 本地=远端（差异 0）· Skill 注册表 11/11 一致 · AgriRecipeBench 69/69 通过（四轴齐全：M1 目标预测 25 + M2 状态滚动 21 + M3 反事实响应 17 + M4 跨情境泛化 6，覆盖 8 分区 × 主要作物 × 边界条件）。

🏆 AgriRecipeBench（benchmarks/agri_recipe_bench/）——Env Recipe 环境配方的可复现评测基准，独立于功能回归测试。M15-B1 把用例从 11 扩到 69（四轴全部达标、覆盖 8 分区、含负例与退化检测）：

python benchmarks/agri_recipe_bench/run_bench.py                # 跑全部

python benchmarks/agri_recipe_bench/run_bench.py --axis target_prediction --strict python benchmarks/agri_recipe_bench/run_bench.py --case case_luobo_mediterranean --json python scripts/expand_bench_cases.py # 幂等生成器（重新生成新用例）

• M1 target_prediction（25 用例）：预测值 vs 公开农艺基准，覆盖 8 分区 × 主要作物
• M2 state_rolling（21 用例）：数学边界（周期≥1 / harvest≥start / yield>0），含 adapt_score=0 / 冬季播种 / 超短周期 / 无 recipe 等 5 类边界场景
• M3 counterfactual（17 用例）：6 种扰动类型（adapt_score / growth_cycle / env_recipe_temperature / env_recipe_light / zone_climate / 组合扰动）——反事实机制内核直接证据
• M4 generalization（6 用例）：5 作物跨分区泛化，含退化实现检测（不同分区产量完全相同即失败）
• 挂钩：SNWM 神农世界模型四轴协议完整版，详见 benchmarks/agri_recipe_bench/docs/PROTOCOL.md

---

🔐 可验证 AI 三件套（2026-10-11 新增，对标 SNWM 可验证协议与 MCP 2026-08 路线图）：

# 生成 A2A Card JWS 签名

AGRI_A2A_SIGNING_KEY="your-secret" python scripts/sign_agent_card.py

校验（调用方 / CI 都用这条）

AGRI_A2A_SIGNING_KEY="your-secret" python scripts/verify_agent_card.py

---

🌱 受控自进化系统（Bounded Self-Evolution）（2026-10-13 新增，对标 SNWM 可验证协议 + Theseus Labs RSI 五级框架 + PenguinHarness 棘轮门禁）：

# 棘轮门禁（CI 硬门禁 / 本地手动跑）

python scripts/run_evolution_ratchet.py # 阈值 0.5，默认通过 python scripts/run_evolution_ratchet.py --min-score 0.9 # 提高阈值 python scripts/run_evolution_ratchet.py --check-files # 只检查白名单文件存在 python scripts/run_evolution_ratchet.py --json # 供 CI 消费

Köppen 栅格点查询（抽象层，不依赖真实数据）

python -c "from core.climate_grid import build_synthetic_grid_dict, KoppenGrid; \ g = KoppenGrid(cells=build_synthetic_grid_dict()['cells'], ...); \ print(g.query(40.0, 116.0))" # → 概率分布 + 项目分区映射

关键设计原则：自进化必须先有"不可进化区"，再有"可进化区"——否则"自我改进"会侵蚀项目唯一真实的资产（诚实性与可复现性）。内回路（离线棘轮）是唯一不依赖任何外部条件、现在就能转起来的飞轮，同时服务三个目的：①保证科学改进不退步；②产出对外可引用的评测资产；③喂养 RSI 度量。

---

🔍 编排层可审计性（Orchestration Audit）（2026-10-14 新增，agent/orchestration_audit.py，29 项单测守卫）：

把「诚实暴露不确定性」的元层能力从单点输出（M11 可信层）扩展到多 Agent 协作层（M10 编排层）。落地 per_module_deep_assessment_2026-10-13.md §M10-O2「跨 Agent 一致性检查」+ §M10-O4「编排 trace 可导出」：

# 完整 pipeline 会自动带 consistency_audit + orchestration_trace

python -c " from agent.orchestrator import AgriOrchestrator r = AgriOrchestrator().run_pipeline( {'lat':30.0,'lon':120.0,'scene':'balcony','budget_cny':300}, verify=True, record_memory=False) print(r['consistency_audit']) print(r'orchestration_trace', r'orchestration_trace')"

单独跑一致性检查

python -c " from agent.orchestration_audit import check_cross_agent_consistency

传入 pipeline result 会得到冲突列表与严重度分级"

关键设计原则：advisory only——审计不阻断流水线、不写回任何 Agent 输出（与 JEV 门控纪律同构）；冲突显式暴露给用户，让用户判断严重程度，而不是让系统自作主张「消解」矛盾。这是本项目对多 Agent 编排层的诚实性承诺，与单点输出的 T-1/T-3 证书形成同构。

---

🛡️ AgriTrust Verified 公共复算 API（2026-10-14 新增，scripts/verify_trust_mark.py + MCP 工具 agri_verify_trust，34 项单测守卫）：

把 T-1 可信标记从内部纪律升级为对外公共复算资产。落地 per_module_deep_assessment_2026-10-13.md §M11-T1「可信标记产品化」——外部消费者可独立验证任何 AgriTrust 输出，无需依赖私有代码。

# 1. 导出当前信任标记供外部下载

python scripts/verify_trust_mark.py current > mark.json

2. 用外部 mark 端到端复算（用 issued_at 严格重现 signature）

python scripts/verify_trust_mark.py from-mark mark.json

3. 最强验证：不仅证书对象一致，其引用的数据文件也未被修改

python scripts/verify_trust_mark.py current --certificate > cert.json python scripts/verify_trust_mark.py from-certificate cert.json --verify-artifacts

诚实边界：signature 是内容一致性 SHA256，非密码学签名（无密钥）——它证明"数据未被修改"，不证明"我们就是签发者"。这一边界写进 schema 与 verify API 输出，不静默通过，任何降级/缺失都返回 verified=False + 具体原因。这是本项目"可验证 AI"三件套（T-1/T-3/D-4）在对外接口上的延伸。

---

项目定位

一句话：做 AI + 机器人驱动的农业精准控制基础设施——以全球水文/土地/气候数据库为底座，做农村/片区/城市差异化分布，形成大规模 vs 建筑内精细化双模式的 AI 精准控制要素，成为未来大农业基础设施和产业链的关键生态位（v1.1，2026-11-06 用户确认；权威口径见 docs/CORE_OBJECTIVE.md §一）。诚实边界：含待建方向（机器人执行/全球水文库/大规模大田），G1 达标前不宣称"被依赖"。

核心架构（对标 SwarmLabs 科研 Agent Infra 的工程路径）：

输入（地块信息 / 种植者需求 / 环境参数）

│ ▼ ┌──────────────────────────────────────────────────────────┐ │ L0 数据底座层 全球分区气候/土壤/水文元数据 │ │ └─ data/zone_meta/ (Köppen 气候带 + FAO 农业分区) │ ├──────────────────────────────────────────────────────────┤ │ L1 多 Agent 协同层（含 L2/L3 专项 Agent） │ │ ├─ ClimateAgent 气候/水文/土壤分区匹配 │ │ ├─ CropAgent 作物-分区适配推荐 │ │ ├─ GrowthAgent 生长周期管理 + 病虫害诊断 │ │ ├─ EcoAgent 多层级生态撮合（供需/社区/设备） │ │ ├─ PestAgent / NutritionAgent / SeasonAgent 按需调用 │ │ ├─ ForecastAgent(L2) 采收期 / 产量 / 风险预测 │ │ └─ ControlAgent(L3) 生长计划→执行指令 + 执行补偿 │ ├──────────────────────────────────────────────────────────┤ │ L2 Skill 注册表 可复用能力模块 │ │ └─ skills/registry/ (climate_match / crop_adapt / ...) │ ├──────────────────────────────────────────────────────────┤ │ L3 可信输出层 evidence + confidence + constraints │ │ └─ docs/agent_output_contract.md │ └──────────────────────────────────────────────────────────┘

---

---

覆盖边界（已闭环）：分区库现建模 8 个气候带（含 v1.1 新增的热漠 hot_arid 与高原 highland）。

迪拜（波斯湾热漠）→ hot_arid、拉萨（青藏高原）→ highland 现由 ClimateAgent 正确路由（rubric 0.95、给出真实作物推荐），

不再静默归入「亚热带湿润」给出错误方案；v1.1 之前的「显式拒答」降级路径已随分区补齐而关闭。

两新分区的 Env Recipe 与 P3 校准作物已于 2026-10-06 回填，详见 outputs/zone_coverage_decision_2026-09-23.md（历史背景）。

两个诚实性约定（2026-09-23 起生效，均有测试锁死）：

1. monthly_precip_mm 虽是月度序列，但每个元素是月内日均降水（mm/day），不是月累计量。

NASA POWER 与 Open-Meteo 两条路径口径一致，agent/climate_data.py 统一以 PRECIP_UNITS 声明并透传

monthly_precip_mm_units。生态位校准的降水通道依赖「同口径区间命中」，不得对该字段乘天数换算。

2. 预设城市清单的唯一数据源是 data/preset_cities.json，前端与 MCP Server 均经

agent/preset_cities.py 读取；拉萨/迪拜随 v1.1 已建模（modeled: true），12 城全部有对应分区。

七层生态架构（来自项目战略指引）

⚠️ 口径已修订（2026-10-08）：七层是分析框架，不是交付清单。当前阶段只交付 L0-L3；L4/L5/L6 已正式暂缓（判定依据与重新打开条件见 docs/CORE_OBJECTIVE.md §三 N6/N7、§六）。

下表"本项目状态"列已按实测校正，此前"已落地/进行中"的表述存在与代码不符之处，此处一并修正。

---

核心模块