Beyond Tool Use: A Living Benchmark and Reliability-Aware Continual Agent for End-to-End Weather Services

中文副标题： 面向端到端气象服务的动态基准、可靠性感知主动取证与可验证持续记忆
工作名： WeatherReliabilityBench + Reliability-Aware Weather Agent（暂定名，正式命名前需再做检索）
目标 venue： ICLR 标准的 benchmark + agent method + infrastructure 论文
状态： Proposal v2.0，基于 2026-08-01 前的文献分析与多轮设计拷打
重要说明： 原 proposal 声称团队已有 GridRad–station pipeline，但当前 /Users/leo/Documents/research-notes 仓库中没有发现对应可执行实现。本文将它视为待核验的外部团队资产，不把未核验代码写成已完成成果。

0. 执行摘要

本项目不再把“通用气象 Agent”定义为一个会调用很多天气工具、复述气象工作流或生成多种文本的 LLM wrapper。它提出一个更严格的问题：

当观测、数值模式、AI 预报、地理暴露度和业务文档具有不同成本、时效、空间代表性、版本和潜在故障时，Agent 能否主动决定还需要什么证据、当前来源是否可信、何时停止、何时降级或拒答，并在延迟真值到达后安全地改进未来行为？

项目包含相互咬合但可单独消融的两项主要贡献：

1. WeatherReliabilityBench： 一个覆盖气象服务全链路的 living benchmark。它包含数据操作、短临预报、短期预报、结构化决策和多受众服务生成五轨任务；同时提供静态可复现 Core、隐藏 prospective Frontier、自然基率部署流、源故障反事实、端到端链式评测和专家对照。
2. Reliability-Aware Weather Agent： 一个层级式 reference agent。它以 foundation model 保留开放推理能力，以学习型 source-health、evidence-value 和 critical-risk 模块进行风险约束的主动取证；以 typed evidence ledger、独立 verifier、可偏离的 workflow prior 和经延迟真值验证的 typed memory 支持长期演化。

论文的中心不是宣称五个既有模块各自新颖，而是建立一个此前未被气象 Agent 文献闭环回答的可证伪问题：在非平稳来源可靠性、有限预算和延迟反馈下，主动证据策略与受治理记忆能否提高跨任务、跨灾种和未来事件的净效用，同时减少严重错误？

首版以 CONUS 强降水/强对流为深度主灾种，高风与高低温为迁移灾种；采用公开可复现主榜，并以至少一个国际区域及合作方受控数据作为外部效度挑战。项目不训练新的天气基础模型，而把雷达外推、NWP、集合和 AI 预测系统作为具有不同能力与健康状态的可治理工具。

1. 为什么现有工作还没有回答这个问题

1.1 相关工作提供了哪些必要积木

工作	已有贡献	本项目继承什么	仍缺少什么
Zephyrus	可执行天气工具环境与覆盖 49 类任务的 ZephyrusBench；证明工具接入能明显提高天气任务表现	typed weather tools、代码执行、数值与制图任务、跨模型大横评	默认工具可用且可相信；缺少隐式 source health、真实故障、主动停止、端到端服务链与持续时间流
TerraBench	异构地球系统数据、77 个工具、过程/数值/工件联合评测	可执行任务、artifact/provenance 评测、过程与结果分离	不是业务气象链；没有非平稳可靠性、延迟真值和持续记忆；其论文—代码—指标不一致提醒本项目必须冻结实现
SIREN	从天气诊断到影响与预警建议的极端天气 Agent 链，含 RAG、skill、modeling harness	端到端预警链、影响与决策任务的重要性	评测规模和 prospective 证据有限；经验积累缺少严格时间隔离、来源故障与可验证写入机制
EWE	极端天气诊断 workflow、双 auditor 和经验记忆	诊断检查、生成器—审计器分离	主体仍是较固定 ReAct/workflow；memory 与可靠性状态定义较弱；缺少预算化主动取证和真实不完整输入
HVR-Met	hypothesis–verification–replanning 与负向短期记忆	显式假设、验证与重规划；失败记忆	缺少可干预的 source-health 因果测试、实时数据条件、长期安全记忆和客观过程效用
AgentCaster	在龙卷预报中主动选择 HRRR 图和探空，在预算下输出业务多边形	主动证据选择、业务对象、专家比较，是本项目最直接的前驱	选择策略主要由 LLM 实现；没有学习型可靠性 belief、故障反事实、长期演化；对探空等证据可能系统性利用不足
EarthLink	多计划、代码执行、专家门控的 plan/script 经验写回	procedural memory、专家治理、科学代码工件	“自进化”主要是外部经验库更新；缺少严格 holdout/prospective、内容迁移和科学 verifier 的因果验证
MemEvolve	把 memory mechanism/program 本身作为演化对象	typed memory-policy evolution、结构搜索	搜索与跨域验证范围有限；时间隔离、内容继承、负迁移、污染和回滚仍需更强约束
RadarQA	面向雷达预报评估的专业多模态 QA/MLLM benchmark	雷达时空理解、专业任务和专家标签	是 specialist perception/reasoning，而非跨源主动 Agent；缺少服务链、工具成本与故障管理
K-MetBench	基于权威材料和资格考试的韩国气象多维诊断基准，覆盖图表推理、逻辑、地域文化和细粒度领域能力	多模态专业推理、地方性与文化依赖、专家 rationale	主要是静态诊断 benchmark；不评估可执行工具、非平稳来源健康、主动取证、决策链或持续时间流
Decision-oriented benchmarking for the Indian monsoon	把 AI 天气预测评价连接到农业相关季风指数和实际利益相关方需求	决策相关指标、out-of-sample 概率评测、社会科学与部署视角	主要评价 forecast product 对特定决策的价值，而非 Agent 如何在异构不可靠证据间取证、停止和持续学习
Omni-Weather	统一雷达生成、预测、理解与解释	将专业天气生成/理解模型作为 forecast/perception tool；预测与解释联合对象	不是 source-orchestrating agent；自由文本 rationale 的 faithfulness、概率校准和跨域证据仍有限
WeatherSyn	基于真实天气材料的报告生成与属性化评价	Track 4 的 claim ontology、报告结构和专业文本素材	单一报告阶段不能测上游错误传播、信息时效、主动取证与行动效用；文本相似度/LLM judge 不能替代事实与理解评价
MIRA	受控医疗环境、typed FHIR action、过程级评价与同信息医生对照	“合法动作不等于恰当动作”、受控环境、权限与过程评价、专家同信息基线	医疗环境相对静态；没有气象开放世界来源、非平稳工具健康、成本化证据采集和 prospective source drift

1.2 不能作为本论文独立创新点的内容

以下元素本身都已有充分先例，不能单独承担 novelty：

• 多 Agent 或 specialist 分工；
• ReAct、reflection、auditor、RAG 和 workflow prompting；
• 天气数据查询、制图、均值计算或代码执行；
• 使用 GPT 辅助生成任务或预标注；
• 一个固定经验库或把历史报告放入向量数据库；
• 同时覆盖雷达、卫星、站点和 NWP；
• 单独增加报告生成、影响分析或预警文书任务。

本项目的新增性来自这些组件被一个可干预、可计量、可随时间检验的可靠性问题约束在一起：来源健康是潜在且会漂移的；取证具有成本；Agent 可以偏离 workflow；停止与拒答是动作；记忆只能在延迟真值后写入；同一天气事件能生成 clean/corrupt、不同预算和不同可用时间的配对反事实；性能必须在未来流上成立。

1.3 论文 thesis

A general weather-service agent should be evaluated as a risk-constrained evidence-seeking policy over non-stationary data and model sources—not as a language model that merely executes a fixed meteorological workflow.

2. 研究问题与可证伪假设

RQ1：基准问题是否真实且具有区分度？

前沿 Agent 是否会在来源选择、时间语义、冲突处理、停止、拒答、链式事实保持和持续记忆上表现出与最终答案准确率不同的能力排序？

RQ2：可靠性感知主动取证是否有效？

在相同 foundation model、forecast tools 和预算下，学习型 source-health/value/risk controller 是否优于 free ReAct、固定 SOP、all-source、静态 skill weighting 和不含 source health 的 active acquisition？

RQ3：策略是否在未见故障与真实漂移上泛化？

在 clean cases、unseen compound faults、held-out weather regimes、模型版本变化、跨灾种和跨区域条件下，收益是否仍存在？

RQ4：端到端链是否暴露新的失败模式？

组件得分是否会高估真实服务链能力？Agent 能否在上游不确定或错误时正确降级，而不是把错误放大为不恰当行动或公众表述？

RQ5：持续记忆是否带来真正的 forward improvement？

在底座权重冻结、因果时间顺序和相同反馈下，typed memory content/policy evolution 是否提高未来事件净效用，并控制 stale memory、poisoning 和 negative transfer？

RQ6：气象 workflow 应如何嵌入而不压制底座能力？

可检索、可偏离、可验证和可演化的 workflow prior 是否优于自由 ReAct、固定 pipeline 和不可偏离的检索 SOP？

RQ7：专业人员应在哪里介入？

专家用于逐结论复核、memory governance、rubric calibration 或少量高风险 policy approval 时，哪个位置带来的单位专家时间收益最高？

3. 形式化：非平稳来源下的风险约束序贯取证

在事件 (e) 的决策时刻 (t)，真实天气和影响状态为 (z_t)，来源 (i) 的潜在健康状态为：

[ h_{i,t}={q^{\text{integrity}},q^{\text{timeliness}},q^{\text{representativeness}}, q^{\text{regime-skill}},v^{\text{version}}}_{i,t}. ]

来源返回的对象 (y_{i,t}) 同时由天气状态、来源健康、处理链和噪声决定。Agent 维护联合 belief (b_t(z,h))，并从下列动作中选择：

• 查询或补取某一来源；
• 执行 QC、单位/时间/坐标检查；
• 运行一个 forecast/perception tool；
• 交叉验证、调用 specialist 或 verifier；
• 生成/更新结构化 claim；
• 停止、降低置信度、请求人工升级或 abstain。

目标是：

[ \max_{\pi};\mathbb E\left[U_{\text{task}}-\lambda_c C_{\text{query}} -\lambda_l C_{\text{latency}}-\lambda_v C_{\text{critical}}\right], \quad \Pr(\text{critical error}\mid b_t,a_t)\le \delta_k, ]

其中 (delta_k) 随任务轨道和行动风险变化。Track 0 的一次数值误差与 Track 3 的非法行动建议不能使用同一风险阈值。

reference controller 对候选动作估计：

[ \widehat{\Delta U}(a\mid b_t),\qquad \widehat{\Delta R}(a\mid b_t),\qquad C(a),L(a), ]

并进行有限深度的风险约束选择。若所有可行动作的保守边际价值均不足以抵消成本，且当前结论满足风险约束，则停止；若无法在预算内满足约束，则 abstain 或升级人工。

4. WeatherReliabilityBench

4.1 一个 Event Cube，多种决策视角

基准使用五级数据单位：

1. Source Object： 一个不可变、带 checksum 的雷达图、格点场、站点记录、模式运行、文本产品或地理图层；
2. Event Cube： 围绕一个天气系统的时空证据包；
3. Decision Snapshot： 在某个 decision_time 实际可获得的证据状态；
4. Track Instance： 某一轨的独立任务；
5. Chain Episode： 在共享证据与预算下跨轨运行的完整服务链。

所有数据必须保存 valid_time、issue_time、available_time、revision/model version、retrieved_at 和 checksum。工具只能返回在 episode 决策时刻已经可用的版本。无法重建历史可用时刻的数据标为 retrospective_only，不得进入严格 forecasting、Agent-Chain 或 prospective 排名。

4.2 五条任务轨

Track	核心问题	主要输入	主要输出	核心 GT 与指标
T0 Atomic Grounding	能否正确获取数值、求统计量、转换单位/时间、比较场并生成合规图件？	typed APIs、格点/站点数据、地理工具	数值、表格、图、数据工件及 provenance	executable oracle、数值容差、单位/时间正确性、artifact validity、调用轨迹；作为诊断轨，限制其 GWAS 权重
T1 Nowcasting，0–2 h	能否识别局地强对流/强降水演变，选择与融合短临工具并给出概率化 hazard？	连续雷达、GridRad-Severe 子集、GOES/GLM、站点、快速更新模式、短临模型	概率场、对象轨迹、阈值超越概率、预警候选及不确定性	未来 MRMS/雷达/站点观测；CSI、POD、FAR、FSS、Brier/CRPS、可靠性、lead-time utility
T2 Short-Term Forecast，24–72 h	能否在多模式/集合冲突下形成时空演变和概率结论？	HRRR、GEFS、可复现 AI forecasts、历史 skill、气候背景、观测初值	概率化天气/灾害对象、模式权重、情景与证据说明	未来观测网为主 GT；RMSE/MAE、CRPS/Brier、FSS、事件 skill、校准；首席预报结论是人类基线/偏好信号而非物理真值
T3 Structured Decision	在风险、暴露度、资源和行动成本下，应采取什么行动？	已验证 hazard distribution、人口/设施/地形、可行动作、权限和预案	typed Decision Card：行动、触发/失效、成本、预期收益、残余风险、依据、升级/拒答	权限硬约束、counterfactual cost–loss/resource utility、regret、敏感性、专家盲评；真实损失仅作辅助
T4 Service Generation	如何面向公众、行业、电视或政务受众忠实表达？	已验证 forecast/risk/decision claims、受众与媒介合同	APP 推送、行业指导、播报稿、专报等	claim fidelity、salience、uncertainty preservation、actionability、readability、compliance、用户理解；CTR 仅作部署辅助指标

4.3 Oracle-Upstream 与 Agent-Chain 双模式

五轨不是一条强制直线。T0 支撑 T1/T2，两个预报分支都可进入 T3/T4，T3 也可进入 T4。

• Oracle-Upstream Mode： 当前轨获得经过验证的标准上游对象，用于隔离局部能力；
• Agent-Chain Mode： 下游只能读取同一 Agent 上游写入的 typed ledger，测量误差传播、纠错和不确定性保持。

所有上游产物写成 claim graph：claim -> evidence -> valid time -> uncertainty -> verification state -> permitted downstream uses。传播 specialist 不得在没有新证据和 verifier 的情况下增强天气事实或行动等级。

4.4 地域、灾种与开放层级

首版采用“一主两辅”：

• 主灾种： CONUS 强降水/强对流，完整建设五轨；
• 迁移 A： 高风，检验不同变量、空间尺度和损失结构；
• 迁移 B： 高低温，检验缓变过程、弱雷达依赖、气候背景和健康/能源影响。

地域分为：

1. Public Stable Core： CONUS、公开可复现、冻结版本；
2. Public Prospective Frontier： 对所有团队开放提交，未来事件和标签在评测时隐藏；
3. International Frontier： 至少一个地理不相交区域，优先使用全球公开数据；
4. Partner Operational Challenge： 合作方受限高密观测、业务材料和应急反馈，通过受控服务评测，单独报告，不承担唯一核心证据。

4.5 初始数据栈及角色

• GridRad-Severe 4.2： 三维强对流/QC challenge source；由于事件选择偏差，不用于自然基率估计。数据说明
• 连续 MRMS： 自然基率 Deployment Stream、空报、近失和连续雷达任务的核心；原始 NEXRAD Level-II 只在精选 specialist 子集使用。MRMS 项目
• GOES + GLM： T1 的卫星和闪电核心模态，而非后续装饰性扩展。GOES-R
• GHCNh/ASOS 类站点： 地面实况、降水/风温验证和自然站点故障。GHCNh
• HRRR： 对流允许的 CONUS 短时 guidance；
• GEFS： 集合概率、情景 spread 和大尺度背景。GEFS
• ERA5 / WeatherBench 2： 气候背景、历史分析、训练与 Zephyrus 兼容基线；reanalysis 不冒充 contemporaneous observation。WeatherBench 2
• 可复现 AI forecast/nowcast tools： 至少一个全球/区域 AI forecast 与一个短临工具，冻结权重、版本、输入和运行成本；
• NWS/SPC 文档与事件材料： forecast discussions、warnings、storm reports 和 event records，严格依据 available_time；
• 暴露与承灾体： 人口、关键设施、地形、水系/水库、道路等静态或版本化图层。

原始大体量对象不必全部重新分发。Core 发布 immutable event-cube manifests、checksums、预处理代码、合法下载器/访问工具和必要派生缓存。

4.6 Challenge Set 与自然基率 Deployment Stream

• Curated Challenge Set： 富集严重事件、近失、benign/null、源冲突、单源/组合故障、稀有天气型与预算压力，服务于能力覆盖；
• Deployment Stream： 使用不按结果选择的连续时间窗，保持自然事件基率，测量 FAR、校准、无效查询、alert fatigue、停止和成本效用。

两者独立报告。每条轨都包含“正确行为是少做或不做”的例子：不再取昂贵证据、不升级风险、不建议高成本行动、不夸大传播，或在证据不足时 abstain。

4.7 Source-health 与故障本体

故障分为四层，并保留 clean/corrupt 配对：

1. 可用性与传输： 延迟、缺测、部分覆盖、重复文件、旧 cycle；
2. 语义与处理链： 单位、时区、valid/issue time、累计窗口、坐标、变量、版本错配；
3. 观测物理： 雷达遮挡/衰减/杂波、站点 undercatch/元数据变化、卫星伪影、代表性误差；
4. 预测认识误差： 天气型条件偏差、分辨率不足、集合塌缩、模型升级、真正的 forecast disagreement；
5. 文档与复合故障： 过期 SOP、相互矛盾的报告、多个看似合理的小故障组合。

数据同时包含自然退化、可控注入、训练未见的组合故障和 prospective real faults。注入必须保持气象上足够 plausible，避免基准退化为格式异常检测。硬 verifier 应抓住确定性语义错误；belief/controller 负责无法由规则直接判定的代表性、天气型 skill 和冲突。

4.8 标注与真值分层

Tier	含义	例子	使用规则
A Objective	可执行或物理真值	未来观测、数值 oracle、官方 QC、corruption manifest	最高优先级，不得被 LLM 覆盖
B Documentary	可溯源文档事实	NWS/SPC/地方事件报告、warnings、复盘	保存原文 span、发布时间和不一致
C LLM-assisted weak	规模化候选标签	claim 抽取、任务生成、故障分类、rubric 预评分	保存模型 snapshot、prompt、置信度；不能由同一模型独占生成与裁判
D Expert gold	高风险/歧义专业判断	证据充分性、决策合理性、传播严谨度	双人独立标注、仲裁、报告一致性

GPT/LLM 可用于降低提取成本，但不能创造物理真值。高影响 hidden cases 需要专家金标或客观 oracle。

4.9 规模目标与切分

• 2,500–4,000 个独立 Event Cubes；
• 40,000–60,000 个 Track Instances；
• 600–1,000 个 Agent-Chain Episodes；
• 300–500 个高难链式 episode 做双专家标注和仲裁；
• 历史连续季节 Deployment Stream，并逐步积累完整年度 prospective cycle。

按 storm system/event family 和时间块分组切分。同一过程的地点、时刻、轨道和模板不能跨 train/test。另设 held-out task compositions、fault combinations、weather regimes、model versions 和 geographic regions。论文同时报告独立事件数、决策时刻数和任务数，不用模板改写虚增规模。

5. Reference Agent：可靠性感知的主动证据系统

5.1 总体结构

系统采用一个 authoritative Meta-Controller 和按需 specialists：

1. Meta-Controller： 唯一持有任务状态、belief、预算、stop/abstain 权限；
2. Observation/QC Specialist： 观测语义、覆盖、物理 QC 和来源健康证据；
3. Forecast Arbitration Specialist： 预测工具选择、融合、校准和情景；
4. Impact/Decision Specialist： 风险映射和结构化行动选择；
5. Communication Specialist： 忠实转换已验证 claims，不可自行增强事实；
6. Independent Scientific Verifier： 对单位、时间、坐标、物理范围、provenance、claim support 和权限进行独立检查；
7. Asynchronous Memory Curator： 只在延迟真值到达后处理跨事件写入。

specialists 不自由聊天，只能提交 typed ledger entries。Meta-Controller 决定是否接受，verifier 决定验证状态。单 Agent ReAct、自由多 Agent 和固定多 Agent 均作为 matched-budget baseline。

5.2 Foundation model 与学习型决策层的分工

• Foundation model： 任务理解、气象假设、候选证据/行动提出、跨模态解释和最终综合；
• Source-health estimator： 输出多维健康 belief 与置信区间；
• Evidence-value model： 估计候选查询的 task-conditional marginal utility；
• Critical-risk model： 估计 unsupported high-risk claim、遗漏关键证据或非法行动的风险；
• Constrained selector： 在成本/延迟/风险约束下查询、验证、停止或拒答。

底座 LLM 权重冻结。轻量 health/value/risk、routing、fusion 和 calibration 模块可以训练。这样既保留底座开放能力，又形成可复现、可干预的方法对象。

5.3 反事实 evidence-subset replay

controller 不主要模仿专家操作轨迹。每个 time-legal full-information bundle 被转换为大量部分证据状态：

• mask 某些来源；
• 改变可用时间和预算；
• 注入自然化、气象上合理的单源或组合故障；
• 保持天气状态不变，形成 paired twins。

对候选来源 (a)，估计：

[ \Delta U_a=U(S\cup{a})-U(S),\qquad \Delta R_a=R(S)-R(S\cup{a}). ]

Track 0–2 尽量使用客观 end-task utility；Track 3–4 使用独立评审器并由专家校准。使用 event-level cross-fitting，避免一个模型生成、标注和独占评判同一案例。专家轨迹是 human baseline 和少量 preference/calibration signal，而不是唯一正确 workflow。

5.3.1 最小可实现学习目标

reference implementation 不依赖在线 trial-and-error RL。它从历史 full-information bundles 进行离线、交叉拟合的多任务学习：

[ \mathcal L= \mathcal L_{\text{health}} +\alpha\mathcal L_{\Delta U} +\beta\mathcal L_{\text{pair-rank}} +\gamma\mathcal L_{\text{critical-risk}} +\zeta\mathcal L_{\text{calibration}}. ]

• (mathcal L_{\text{health}}) 使用自然 QC、availability/version records 和 corruption manifests，分别预测完整性、时效、代表性与 regime-skill，而非压成单标签；
• (mathcal L_{\Delta U}) 回归证据加入后的 end-task utility/risk change，并显式建模标签不确定性；
• (mathcal L_{\text{pair-rank}}) 在同一 evidence state 内学习候选来源的相对价值，降低不同任务效用尺度造成的不稳；
• (mathcal L_{\text{critical-risk}}) 预测停止或输出后发生 critical violation 的风险；
• (mathcal L_{\text{calibration}}) 在独立天气系统和天气型上校准 health/value/risk 置信度。

对候选动作使用保守 acquisition score：

[ S(a)=\operatorname{LCB}[\widehat{\Delta U}_a+ ho\widehat{\Delta R}a] -\lambda_c C(a)-\lambda_l L(a)+\eta\log p{\text{workflow}}(a). ]

选择满足 hard contracts 和 risk budget 的最高分动作；用深度 2–3 的小型 beam/rollout 捕获“单独价值低、组合后有价值”的互补来源。若没有正的保守边际价值则停止；若当前风险仍超过轨道阈值则 abstain/escalate。myopic greedy、无不确定性 point estimate 和无 workflow prior 都作为消融。

5.4 气象 workflow：软先验，而不是剧本

硬约束层只编码确定性科学/业务合同：变量、单位、时间、累计窗、坐标、物理范围、权限和 warning language。

workflow 层存储 structured action graph：适用天气型、默认检查、分支、failure modes、stop/abstain 条件、provenance 和版本。检索到的 workflow 形成 action prior，但 foundation model 可以：

• 跳过在当前证据下低价值的默认步骤；
• 组合多个 workflow；
• 提议 workflow 外动作；
• 在记录证据与理由后偏离 SOP。

任何偏离都必须通过 verifier。主要消融为 free ReAct、静态 SOP prompt、固定 expert pipeline、不可偏离的 retrieved workflow、可偏离 workflow prior 和完整 reliability-aware policy。

5.5 Forecast models 是工具，不是本论文的新 backbone

Track 1/2 对雷达外推、NWP、集合和 AI forecast 使用标准 adapter。Agent 决定何时运行、信任、融合、校准或降权这些工具，并输出概率化 hazard object。首篇不训练新的端到端雷达生成器或全球天气模型。

• Fixed-Model Track（主榜）： 所有 Agent 使用相同冻结 forecast tools；
• Open-Model Track（副榜）： 允许参赛者接入更强预测模型，独立排名。

这使 agent policy 的贡献不被天气 backbone 差异掩盖，同时允许基础设施随预测模型进步而更新。

6. Typed memory 与受治理的持续演化

6.1 记忆不等于把历史对话放进向量库

系统至少区分五类长期状态：

1. Reliability memory： source × region × regime × horizon × version 条件下的完整性、时效、代表性和预测 skill；
2. Procedural memory： 经过验证的 workflow graph、适用条件和失败分支；
3. Failure memory： 失败证据、根因、哪些检查本可捕获、是否已修复；
4. Episodic memory： 事件上下文、当时可见证据、行动轨迹、延迟结果和反事实教训；
5. Decision/user memory： 特定决策者的 cost–loss、资源和 communication contract，不与物理天气真值混合。

每条 memory item 包含来源、写入依据、validity scope、版本、expiry、置信度、冲突关系和可回滚 lineage。没有延迟真值或专家/规则验证的“经验”只能进入 quarantine，不能影响高风险主路径。

6.2 演化的是受限的 typed policy program

允许周期性演化的对象包括：

• write validation；
• source/regime/version partitioning；
• retrieval gates 与 ranking；
• consolidation 和 deduplication；
• decay、expiry 与 stale detection；
• conflict quarantine；
• rollback；
• schema migration。

候选 policy 必须通过类型/属性测试、时间隔离的 selection/test、历史 replay、regression、poison/staleness、预算/延迟/存储检查和版本化发布。单个事件结束后不得直接修改线上策略。对具体 episode 的天气真值或答案模板不得写成可跨事件检索的捷径。

6.3 三种跨事件协议

协议	可变对象	人工介入	主要回答
Frozen-Agent	仅 episode 内 working memory；跨事件重置	无	基础 Agent 能力
Autonomous Continual（主榜）	预注册 typed memory 与 policy schema；底座权重/代码冻结	hidden stream 期间无开发者干预	可复现的自动持续改进
Human-Governed Continual（副榜）	与上相同，但允许专家批准、隔离和回滚高风险变更	记录次数、时间和效果	真实业务中的最优治理位置

Autonomous Track 在开始前封存 container。环境按统一因果顺序提供 event -> delayed observation/report/feedback -> validated update -> future event。所有 persistent writes、policy diffs、验证和 rollback 都记录。参数微调、LoRA 或自训练可作为未来独立 Frontier，不进入 v1 核心 continual claim。

7. 评价：从单项 skill 到 General Weather Agent Score

7.1 分轨效用

每条轨定义任务级 utility (U_k)，保留原始物理/文本/决策指标，不强行把 CSI、CRPS、regret 和 claim fidelity 当作同一量纲。为跨轨汇总，使用 floor 与 oracle 归一化：

[ s_k=\operatorname{clip}\left( \frac{U_k-U_k^{\text{floor}}}{U_k^{\text{oracle}}-U_k^{\text{floor}}}, \epsilon,1\right). ]

候选总体分数为加权几何均值：

[ \mathrm{GWAS}{\mathrm{raw}}= \exp\left(\sum^{4}w_k\log s_k\right). ]

几何均值避免 Agent 用大量简单 T0 项掩盖某一高风险轨崩溃。T0 权重设上限；Oracle-Upstream 与 Agent-Chain 均报告，最终权重只在 pilot/dev 上确定并冻结。

7.2 严重错误门控

下列 episode-level 行为构成 critical violation：

• 使用 decision time 之后的数据或灾后材料；
• 单位、有效时间、累计窗口、变量或坐标语义无效；
• 无证据增强高风险天气、影响或行动 claim；
• 忽略已经确认损坏/过期的关键来源；
• 越权发布 warning、行动命令或禁用措辞；
• communicator 改写已经验证的风险等级/行动。

主榜先进行 safety eligibility gate，再在合格系统中按 GWAS 排名；不建议仅用一个可被其他任务抵消的线性罚项。critical-violation rate、类型和置信区间单独报告。

7.3 可靠性与过程诊断

• source-health detection/calibration；
• harmful-source reliance 与 healthy-source avoidance；
• evidence sufficiency、unsupported-claim rate；
• stop/abstain selective risk、coverage–risk curve；
• source conflict resolution；
• provenance completeness 和 artifact reproducibility；
• workflow deviation validity；
• memory attribution、staleness、poisoning 和 negative transfer；
• chain error amplification/recovery。

7.4 成本、延迟与预算

设置 Low、Standard、High 三档数据/工具/推理预算，Standard 为主榜。记录：

• 数据访问次数和字节数；
• forecast tool 运行成本；
• foundation-model tokens/调用；
• wall-clock latency；
• 专家分钟数；
• persistent memory/存储开销。

报告 quality–cost、risk–cost 与 latency–quality Pareto，而不是奖励 brute-force all-source 查询。

7.5 人类与 judge 校准

• 在分层抽样 episode 上建立 same-information、same-tool、same-time-budget 的气象专家基线；
• Track 3 需要气象与应急/行业专家，Track 4 加入目标受众理解测试；
• 自动 judge 在专家 gold 上报告相关、偏差、分组一致性和阈值敏感性；
• 对序数评分使用多评审者模型并报告 Krippendorff's alpha 或适合的 agreement；
• judge 与人类明显失配的指标降级为诊断，不进入主分。

8. 实验计划

8.1 Baseline 家族

无/弱 Agent：

1. foundation model only，无工具；
2. retrieval + single response；
3. tool-calling Direct；
4. Zephyrus-style Direct/Reflective；
5. free ReAct。

Workflow/多 Agent：

6. fixed meteorological SOP；
7. 不可偏离的 retrieved workflow；
8. EWE/HVR-style generator–auditor/replanner；
9. 固定 specialist pipeline；
10. 自由对话 multi-agent。

证据与可靠性：

11. query all sources；
12. cheapest-source / highest-static-skill；
13. static historical-skill fusion；
14. prompt-only AgentCaster-style active selection；
15. learned evidence value without source-health belief；
16. source health without active acquisition；
17. full reliability-aware controller；
18. oracle source health / oracle evidence subset 上界。

Memory：

19. no cross-event memory；
20. generic RAG episodic memory；
21. negative/failure memory；
22. fixed typed memory；
23. typed content + policy evolution；
24. oracle-clean memory 与 deliberately poisoned/stale memory stress tests。

至少选择多个 foundation-model family、不同规模和开源/闭源代表；所有 snapshot、system prompt、工具版本和 sampling 参数冻结。昂贵 agent 组合可以在预注册的代表性子集上完成完整 grid，但主方法和核心 baseline 必须覆盖全主榜。

8.2 主实验

E1：Benchmark difficulty 与构念效度

• 五轨、两模式、两采样流上的模型排序；
• final-answer skill 与 process/reliability skill 的相关性；
• expert–metric agreement；
• item discrimination、ceiling/floor、模板/事件冗余；
• GWAS 权重敏感性和排名稳定性。

E2：Active evidence acquisition

• matched-budget 比较 full controller、all-source、static-skill、fixed workflow、prompt-only active 与 free ReAct；
• clean、natural failure、seen corruption、unseen compound fault；
• 质量—成本—风险 Pareto；
• stop/abstain calibration。

E3：Counterfactual policy responsiveness

保持 weather state 和问题不变，只改变某一来源的健康、延迟、版本或成本。测量查询顺序、权重、结论、不确定性和停止动作是否产生方向正确的变化。该实验是区分 evidence-conditioned policy 与固定 workflow 的关键。

E4：Workflow integration

比较 free ReAct、static SOP、fixed pipeline、non-deviable retrieval、deviable prior 和 full policy；分析有益偏离、无益偏离、被 verifier 拒绝的偏离以及不同模型对 workflow 的依赖。

E5：五轨链式误差传播

比较 Oracle-Upstream 与 Agent-Chain。分解：forecast error、impact mapping error、decision error、communication distortion、uncertainty loss，以及下游成功降级/拒答。

E6：Continual memory

按时间处理事件，比较 Frozen、Autonomous Continual、Human-Governed Continual；插入来源版本变化、故障复现、天气型转换、长期未出现状态和 conflicting feedback。测量 forward transfer、forgetting、staleness、poisoning、rollback utility 和每专家分钟收益。

E7：跨灾种、跨区域与 prospective

主灾种训练/开发后测试高风与高低温；Public Core 后测试 International Frontier 和 Partner Challenge；静态历史后进入 hidden future stream。若方法只在 CONUS 强对流或人工故障成立，应收缩 generality claim。

E8：预测工具治理

在 Fixed-Model Track 中改变 forecast source availability、skill、version 和 latency；比较固定 ensemble、静态校准和 agent routing。Open-Model Track 只作为未来兼容性与上界，不与 policy 主结论混合。

8.3 统计协议

• 主要置信区间按独立 storm/event cluster bootstrap，而非把同一事件的多个任务当独立样本；
• stochastic agents 使用多次运行，方差同时覆盖事件与推理随机性；
• paired twins 使用配对检验与 event-level effect size；
• critical errors 报绝对差、相对差和置信区间，不只报显著性；
• 专家评分使用盲化、随机顺序、评审者随机效应；
• 多主假设进行预注册和适当多重比较控制；
• 所有容差、GWAS 权重、门控阈值和 judge prompts 在 hidden test 前冻结；
• 发布 item-level predictions、traces、costs、artifact hashes 和 metric implementation tests。

9. Living benchmark 生命周期

9.1 Stable Core

• 版本冻结，保留长期可比性；
• 年度或明确 major version 才改变 task schema/核心数据；
• 所有 metric implementation、tolerance 和 oracle 在发布前做 paper–code consistency audit；
• 旧版本 leaderboard 永久保留。

9.2 Prospective Frontier

• 持续加入未来年份、天气型、数据源版本、真实故障、国际区域和新任务组合；
• 提交系统在 episode 前封存，避免针对事件后调参；
• Frontier case 在保密期后退役，合适者进入下一 Core version；
• 单独报告 static historical 与 prospective performance，禁止混成一个分数。

9.3 防污染与审计

• 所有 hidden stream 提交使用 container hash 和模型 snapshot；
• 记录外部 API、检索内容和持久化写入；
• public labels 发布后，不再把该版本称为未污染测试；
• 通过未来流、held-out composition 和版本漂移而非仅靠秘密题库维持有效性。

10. 四组 falsification gates

Gate 1：主动可靠性策略

完整方法必须在 matched budget 下同时改善 end-task utility、critical-error rate 和 cost–quality tradeoff，且优于 fixed workflow、free ReAct、all-source、不含 source health 的 active policy 和 static skill weighting。若只减少调用但损害任务效用，不算成功。

Gate 2：泛化

clean performance 不得明显退化，且收益需覆盖 unseen compound faults、held-out regime、至少一个迁移灾种，以及 prospective 或跨区域测试。若只在训练时注入的 corruption 上有效，撤回 operational reliability claim。

Gate 3：持续记忆

Autonomous Continual 必须相对 Frozen-Agent 提高未来事件净效用，同时不增加 critical、stale-memory 或 negative-transfer failures。历史 replay 改善不足以支持 continual-learning claim。

Gate 4：Benchmark validity

GWAS/分轨指标应与客观物理 skill、决策效用和专家盲评保持可解释一致；小幅权重变化不应任意颠覆榜单。失配 judge 降级为诊断指标。

最小效应量和置信阈值在 pilot/dev 上确定后冻结。若某一 Gate 失败，benchmark/data 贡献仍可成立，但相应 agent、reliability 或 continual claim 必须主动收缩。

11. 预期贡献及 ICLR 叙事

C1：新问题与 living benchmark

把通用气象 Agent 统一定义为五轨、双模式、双采样流、bitemporal、source-health-aware 的序贯决策问题，并提供 Stable Core + Prospective Frontier。相较既有多维气象、可执行地球科学和决策导向天气评测，其新增对象是非平稳来源健康下的主动 Agent 行为与跨事件改进。

C2：可靠性感知主动证据方法

提出 hybrid controller：foundation-model hypothesis/action proposal + learned multidimensional source-health/value/risk + constrained action selection，并用 clean/corrupt paired counterfactuals 验证它确实根据证据状态改变行为。

C3：可验证持续记忆

提出与因果时间流绑定的 typed memory content/policy evolution，以及 Frozen、Autonomous、Human-Governed 三协议，直接测量 forward improvement、负迁移、污染和治理成本。

C4：全链路、效用与专家评测

把预测 skill、决策 regret、传播 faithfulness、严重错误、成本和同信息专家基线放入同一基础设施，并能定位错误传播。

C5：大规模经验结论

跨 Agent/backbone、预算、灾种、区域、真实/注入故障和时间流揭示：哪些模型会过度查询或过度相信工具，何时 workflow 有益，何种记忆产生正/负迁移，component score 与 chain utility 差距多大。

不应写入摘要的过强表述

• “首个气象 Agent”或“首个端到端预警 Agent”；
• “自我进化”而未限定为外部 typed memory/policy；
• “能够自主发布预警”；
• “适用于所有灾种和全球区域”；
• “因果推理”若只依据自由文本 rationale；
• “优于专业预报员”若信息、时间、工具和任务不匹配。

11.1 主张—证据追踪表

主张	对应 RQ	核心数据/协议	决定性实验	失败时如何收缩
C1：benchmark 测到现有静态任务之外的能力	RQ1、RQ4	五轨、双模式、双采样流、专家 gold	E1、E5；构念效度与排名差异	若过程/chain 指标不增加区分度，收缩为多任务数据集而非新评测范式
C2：reliability-aware active policy 有净价值	RQ2、RQ3、RQ6	paired faults、预算、held-out regime/version	E2、E3、E4、E8；matched-budget ablations	若只在 seen corruption 有效，撤回 operational/generalization claim
C3：typed memory/policy 产生安全 forward improvement	RQ5、RQ7	chronological stream、三种 continual protocols	E6、E7；stale/poison/rollback tests	若只改善 replay 或提高严重错误，撤回 continual claim
C4：全链效用和专家治理可测且有意义	RQ4、RQ7	Decision Cards、claim graph、same-information experts	E1、E5、E6；regret、fidelity、expert-time utility	若自动指标与专家不一致，将其降级并只保留人工/客观指标
C5：经验结论跨模型/灾种/区域成立	RQ1–RQ7	多 backbone、迁移灾种、国际/未来流	E2–E8 的分层交互分析	若高度 model/region-specific，明确限定适用范围，不宣称通用规律

12. 工作量、团队与进度

12.1 总体判断

这不是 2–3 人在一个投稿周期内可以高质量完成的普通 benchmark。若当前只有文献笔记而数据/服务实现位于外部且尚未完成资产审计，完整 v1 更接近 6–8 个全职研究/工程 FTE、6–12 名兼职气象/决策专家、18–20 个月。3–4 人团队通常需要 24 个月以上，或必须砍掉 prospective、国际迁移、Human-Governed Track 中至少两项。

12.2 Effort distribution

WP	月份	主要产物	总工作量占比
WP0 Schema, governance, asset audit	0–3	episode/claim/action/memory schema；许可和外部 pipeline 核验；预注册	7%
WP1 Data and tool infrastructure	0–8	bitemporal event cubes；MRMS/GridRad/GOES/GLM/station/NWP adapters；缓存与 checksum	24%
WP2 Benchmark and annotation	3–10	五轨任务、双采样流、fault generator、expert rubric、GT pipeline	21%
WP3 Reliability-aware controller	5–12	health/value/risk modules、counterfactual replay、selector、ledger/verifier	18%
WP4 Memory and continual governance	8–15	typed memories、policy evolution、rollback、三种跨事件协议	12%
WP5 Baselines, human study, statistics	10–18	agent/model grid、chain eval、专家对照、迁移和 falsification tests	13%
WP6 Service, release, paper	14–20	prospective server、leaderboard、文档、artifact audit、投稿	5%

这些比例是人月而不是任务条目比例。T0 项虽多，单位成本低；T3/T4 和 full-chain 项数量少但专家成本高。

12.3 专家工时估计

活动	建议工时
schema、source-health ontology、rubric 设计与 pilot	150–250 h
300–500 个高难 chain episodes 双标	500–900 h
歧义/分歧仲裁与质量复核	150–300 h
same-information 人类 baseline	300–500 h
Track 3/4 专项与 Partner Challenge	300–550 h
合计	1,400–2,500 h

可让更多专家标注较小重叠子集以评估跨机构差异，而不是由少数人覆盖所有任务。

12.4 计算和存储量级

• 原始雷达/卫星/NWP 尽量引用公共归档，不全量镜像；区域裁剪、变量选择后的 derived Core 初步按 20–100 TB 预留，pilot 后重估；
• forecast tools 对固定 Core 尽量预计算，实时/故障实验再按需运行；
• 全实验预计 25 万–75 万条 agent trajectories，具体由 baseline 数、重复次数和 chain 长度决定；
• LLM 使用量按 3–15B tokens 级别准备并全量记录；昂贵 frontier models 只在预注册代表性子集跑完整重复；
• 数据访问、forecast compute、LLM 与专家成本分开报告，不能只报 token cost。

这些是容量规划范围，不是已经发生的消耗。

12.5 Milestones 与 go/no-go

时间	里程碑	Go/no-go 条件
M2	外部 pipeline、许可、bitemporal 可恢复性审计	MRMS/站点/NWP 中至少三类可严格重建；否则缩短历史窗口
M4	schema + T0/T1 小型 pilot + 2–3 个 baseline	无 event leakage；artifact/metric 单元测试通过
M7	约 10k tasks 的 alpha、自然/注入故障	source faults 足够 plausible；Agent 非仅靠格式检测
M10	五轨 Oracle-Upstream、专家 rubric、首批 chains	专家 agreement 和 judge calibration 达到 dev 阈值
M12	reliability controller 与核心消融	至少在 held-out historical faults 上跨过 Gate 1 的初步阈值
M15	memory stream、迁移灾种、international pilot	无明显 negative transfer；协议可自动审计
M18	Core freeze、主 baseline、prospective service	paper–code–data 一致性审计通过
M20	prospective snapshot、artifact、投稿	至少有可信未来流证据；否则明确称 retrospective benchmark

prospective 数据收集应从 M4 左右并行开始，而不是系统完成后才开始等待未来天气。

13. 风险与减法顺序

13.1 最大风险

1. Scope explosion： 五轨、多源、三灾种、国际迁移、memory 同时推进；
2. 来源时间不可恢复： 历史数据只有 valid time，没有真实 available time；
3. 人工故障过于简单： 模型学会格式异常而非气象可靠性；
4. Track 3/4 judge 失配： 自动分数奖励流畅而非恰当决策；
5. LLM backbone 淹没方法： controller 提升只在某一模型成立；
6. Memory leakage/negative transfer： 事后结论被错误用于相似未来事件；
7. 工程量掩盖科研问题： 大量工具与数据但缺少决定性消融；
8. 基础设施寿命： 数据源、模型和 API 版本变化导致榜单失效。

13.2 必须保留的核心

若资源不足，以下不能砍，否则论文会退化为扩展版工具 benchmark：

• bitemporal Event Cube 和自然基率流；
• source-health paired counterfactuals；
• learned reliability/value/risk controller；
• fixed-workflow/all-source/no-health 等核心消融；
• Oracle-Upstream + Agent-Chain；
• Frozen vs Autonomous Continual；
• 至少一个迁移灾种和一个 hidden future/时间外测试；
• 专家校准与 critical-error gate。

13.3 优先可延后的扩展

1. Open-Model Track 的大规模排名；
2. Partner Operational Challenge 的完整五轨；
3. Human-Governed Track 的大样本；
4. 第二个国际区域；
5. 原始 NEXRAD Level-II 全量处理；
6. 更多灾种和多语言服务生成。

13.4 安全、权限与数据治理

• 所有 warning/action 任务在研究沙箱或受控评测环境中执行；reference agent 只能生成候选对象，不能连接真实公共预警发布通道；
• typed action contract 明确 recommend、draft、request approval 与 issue 的权限差异，主榜 Agent 没有 issue 权限；
• 对文档、网页和合作方输入做 prompt-injection 与 provenance 隔离测试，外部文本不能覆盖 system/tool contracts；
• 暴露度和影响数据遵守许可、隐私与最小化原则，不公开可导致敏感基础设施风险的细粒度信息；
• 报告地区、语言、站网密度、灾种和社会群体覆盖差异，避免把 CONUS 结果包装成全球结论；
• 专家标注需有知情同意、合理补偿、冲突披露和退出机制；
• Partner Challenge 的访问、留存、审计和结果发布由书面 data-governance agreement 约束。

14. 高风险高回报创新队列

这些方向与基础设施兼容，但不应全部成为 v1 必选项。建议核心完成后按证据和资源选择 1–2 项：

1. Value of Human Intervention： 把“询问哪类专家、何时值得打断专家”也作为有成本动作，学习单位专家分钟的风险降低；
2. Evidence Certificates： 为每个高风险 claim 自动生成机器可验证的证据证书，包含来源、时间、变换、适用尺度、反证和未解决冲突；
3. Causal Source-Health Graph： 不只预测来源是否可信，还建模上游传输、处理链、传感器与模型版本的故障因果图，用干预定位共同原因；
4. Quality-Diversity Memory Evolution： 不保留单一最优 memory policy，而保留针对不同天气型、预算和机构的多样策略，并测试安全切换；
5. Counterfactual Decision Simulator： 与应急专家构建简化数字环境，评估不同预警阈值、资源分配和公众响应下的 regret，而不仅依赖历史损失；
6. Claim-Preserving Multilingual Service： 测试同一 validated claim graph 在跨语言、跨文化和低识字受众中的事实与行动保持；
7. Compositional Benchmark Generator： 从 event/claim/action schema 自动构造未见轨道组合，同时用 executable contracts 防止任务生成器制造无解或泄漏问题；
8. Model-Registry Continual Adaptation： 当新的 NWP/AI model version 上线时，Agent 在少量重叠运行期内学习迁移 trust，而不是把新版本当成同一来源。

优先级建议：Evidence Certificates 和 Value of Human Intervention 最贴近当前核心且容易形成决定性实验；因果故障图与 decision simulator 潜力更大，但数据和验证成本也最高。

15. 若未来拆成两篇

当前按一篇 integrated infrastructure paper 设计。如果实证结果和工程规模超过 ICLR 主文承载能力，可自然拆分：

• Paper A — WeatherReliabilityBench： 五轨 living benchmark、数据本体、source faults、chain/prospective evaluation 和大横评；
• Paper B — Reliability-Aware Continual Weather Agent： counterfactual evidence learning、risk-constrained selector、typed memory-policy evolution 与 forward-stream 实验。

但首轮建设应保持共享 schema、数据服务和评价协议，避免两篇各做一套不兼容环境。

16. 推荐的 ICLR 主文结构

1. Introduction： 工具会用不等于证据可信；给出 non-stationary source-health 问题和主要结果；
2. Related Work： weather agents/benchmarks、decision-oriented forecasting、agent memory/evolution；
3. Benchmark： 五轨、Event Cube、双采样/双模式、故障、prospective；
4. Method： belief、counterfactual evidence value、risk-constrained selector、workflow/ledger/memory；
5. Experiments： difficulty、matched-budget method、counterfactuals、chain、continual、transfer；
6. Limitations/Impact： 不自主发布业务预警、地域边界、专家与数据治理；
7. Appendix/Artifact： 完整数据卡、指标、prompts、source cards、统计、human protocol、代码一致性测试。

17. 下一步最小行动清单

1. 找到并审计原 proposal 所称的 GridRad–station pipeline：路径、负责人、许可、时间字段、测试；
2. 选择 30–50 个强对流/近失/空事件做 bitemporal pilot；
3. 为 T0–T4 各写 5–10 个 canonical task contracts，而不是先批量生成 QA；
4. 实现统一 SourceObject、Claim、DecisionCard、MemoryItem schema；
5. 接入连续 MRMS、GOES/GLM、站点、HRRR/GEFS 的最小查询 API；
6. 设计 10 类 naturalistic paired faults，并让气象专家盲测其 plausibility；
7. 在一个冻结 backbone 上先跑 all-source、fixed workflow、free ReAct、prompt-active 四个 baseline；
8. 用全信息 bundle 生成第一批 evidence-subset labels，验证 marginal utility 是否可稳定学习；
9. 预注册 pilot 的 leakage audit、critical violations 和 falsification thresholds；
10. prospective 数据抓取从 pilot 期立即启动。

18. 最终判断

这个方向有 ICLR 竞争力，但前提不是把五类任务、memory、多 Agent 和更多数据源堆在一起。真正能 hold 住的论文结构是：

一个新的 operationally meaningful benchmark problem，要求 Agent 在非平稳、可能损坏且有成本的天气证据上进行主动取证；一个可干预的 reference method，把 foundation-model 推理与学习型 source health/value/risk 结合；一个因果时间隔离的 continual protocol，证明经验证记忆是否改善未来事件；再用五轨服务链、跨灾种、跨区域和专家对照证明这不是只对某个 QA 集有效。

相较 Zephyrus，新增的不只是更多任务，而是工具不再默认可信；相较 TerraBench，新增的是业务时间、风险、故障、停止、链式行动和未来流；相较 SIREN/EWE/HVR-Met，workflow 与 memory 都变成可干预和可归因对象；相较 AgentCaster，主动取证获得学习型可靠性 belief、反事实监督和长期验证；相较 MemEvolve，memory evolution 受到气象版本、延迟真值、污染测试和回滚治理约束。

如果四组 falsification gates 真正执行，即使某个方法结果为负，这个数据与评测基础设施仍可能成为领域资产；如果不执行，项目则很容易变成规模很大但科学主张模糊的系统集成。

参考入口

• Zephyrus: An Agentic Framework for Weather Science
• TerraBench
• SIREN
• EWE
• HVR-Met
• AgentCaster
• EarthLink
• MemEvolve
• RadarQA
• K-MetBench
• Decision-oriented benchmarking to transform AI weather forecast access
• Omni-Weather
• WeatherSyn
• MIRA: Towards autonomous medical artificial intelligence agents

设计记录

• 多轮 brainstorm/grilling 决策日志：../discussion/2026-08-01-150445-brainstorm-ideas-log.md
• 原始 proposal：/Users/leo/Downloads/reliable_weather_agent_research_proposal.md
• 参考讨论：/Users/leo/Library/Mobile Documents/com~apple~CloudDocs/科研/气象agent/feedback.md