Discovery Foundation Models：迈向开放式 Discovery Intelligence

TL;DR 提出 Discovery Foundation Models，让基础模型超越解题与行动，参与新问题构造、假设检验和证据修订的开放发现过程，用 Zetema / GALILEO 打通干湿实验闭环，使发现成为可学习、可执行、可评估的能力。

问题

问题背景

当前 AI 研究的前沿正从“学习已有知识”转向“通过行动与反馈学习”，基础模型在数学证明、代码生成等封闭式任务上已接近人类水平，但科学发现的核心是开放式问题构造与知识创造，尚未被有效建模。

现有方法局限

现有 scientific AI 范式大多将科研任务压缩为人类预先定义的函数逼近或搜索问题。例如，LLM 驱动的文献挖掘与分子生成通常只执行单轮或有限轮推理，不维护可修订的研究状态，也不参与“提出假设→设计实验→获取外部证据→修订假设”的物理闭环。模型缺乏对未知问题空间的主动枚举能力，表征构建依赖人工给定的特征或数据集 schema，无法在证据冲突时动态修正自身的知识结构。这导致发现结果难以独立验证，跨任务的通用发现技能也无法积累。

难点与重要性

开放发现要求模型同时处理不可枚举的假设空间、因果干预、不确定表征和多模态实验反馈，其学习信号不再是单一正确标签，而是过程质量与证据强度。因此，评估体系必须从最终答案正确性转向过程中心评价，否则无法区分“偶然蒙对”与“可复现发现”。业界关注这一方向，因为它决定 AI 能否从工具升级为科学协作者，直接影响药物研发、材料设计等长周期、高成本领域。

行业类比

这类似于强化学习从“在固定奖励函数下找最优策略”演进到“让 agent 参与设计奖励函数与环境”，LLM 也需要从“做题”走向“出题并验证题目本身”。

核心洞察

• 发现智能的本质转变在于把“研究状态”本身视为可修订对象。现有 AI for science 多数在固定问题和预定义表征下优化，而 DFM 允许模型发现新问题、构建新表征、形成并证实/证伪假设。这种差异使模型能够参与知识结构的构造与修订，而非仅作为求解器。对工程而言，这意味着系统设计需要显式维护 `research state` 并支持其动态演化，同时通过实验门控与外部证据实现可信修订。
• 过程为中心的评价与训练是 DFM 区别于基准的重要创新。论文提出基于中间步骤（问题选择、假设形成、实验设计、修订）的科学反馈信号和跨任务 Discovery Skill 记忆，而非只优化最终答案性能。这类似于强化学习中的过程奖励，但扩展到物理实验闭环（如 GALILEO 的 Wet-Lab 反馈）。工程上可借鉴：构建可验证的中间步骤、偏好学习和 Research World Model，使发现行为可训练、可评估、可迁移。

方法

输入与研究状态

DFM 的输入不是固定格式的题目，而是一组未知现象或初始观察。系统维护可修订的研究状态 research state，包含当前问题集、候选表示、假设、证据记录和归因信息。

关键模块及流程

1. 问题发现与形式化：从开放未知中识别可研究问题，生成形式化描述，而非仅接受人类给定的问题。
2. 表示构建与竞争解释：构造多种候选表示（如特征空间、图结构、符号结构），并生成相互竞争的初步解释。
3. 假设形成与干预设计：在选定的表示下形成可检验假设，并设计干预（干实验模拟或湿实验方案）。
4. 实验门控与证据接地：通过研究世界模型 Research World Model 对干预进行门控验证，外部证据来自 Dry-Lab 推理或 Wet-Lab 实验（如 GALILEO 中机器人湿实验）。验证结果用于证据加权修订研究状态。
5. 跨任务技能提取：Zetema 将单次任务中的成功发现操作抽象为可迁移的Discovery Skill，存入记忆，经过跨任务验证后更新，实现持续发现改进。

输出与闭环

每个发现片段结束于一个候选发现教训，连同完整过程轨迹输出，供过程中心化评估和后续学习。

差异点：与现有科学 AI 在人类预定义的问题表示与假设空间内求解不同，DFM 显式参与问题构造、表示选择与假设修订，且将发现过程本身作为可学习、可执行、可评估对象。

实验

实验设计

论文提出的 Discovery Foundation Models (DFMs) 通过两个实例验证：Zetema 作为通用研究状态动力学系统，显式维护可修订的研究状态，集成验证与实验门控、外部 grounding 及发现技能记忆；GALILEO 作为真实疗法发现系统，将 Dry-Lab 推理、机械臂与人工 Wet-Lab 实验、外部生物学证据及迭代假设修正耦合为闭环物理发现流程。评估采用 过程中心协议，从问题发现、表征构建、假设形成、干预到证据修正分阶段打分，并同时衡量当前进展与未来能力迁移。训练目标包括状态条件模仿、研究操作偏好学习、过程验证、研究世界模型学习、科学反馈强化学习及验证后技能更新。

关键发现

• DFM 将“行动-结果”学习拓展为“研究状态-证据-结构修正”学习，使模型参与新问题与知识的构建，而非仅解决预设问题。
• Zetema 在跨任务发现技能上实现验证后更新，支持从单次实验反馈中提炼可迁移规则；GALILEO 展示了从干实验假设到湿实验验证再回到表征修订的物理闭环，表明外部实验门控和实体反馈对假设可靠性至关重要。
• 过程评估显示，即使最终答案错误，模型在中间阶段的有效操作也能产生可复用的发现技能，这突破了传统只奖励最终性能的局限。

与基线的深度对比

与以最终答案准确率为目标的 科学问答 / 推理基线 相比，DFM 将评估重心移至研究轨迹的中间过程：基线往往将问题空间视为固定输入，DFM 则要求模型主动构建新问题并接受实验证据的拒斥。与 工具使用型基础模型 相比，后者虽能调用外部 API 或模拟器，但通常缺乏对研究状态的可修订建模以及跨任务的技能记忆更新；DFM 将每次干预与证据反馈写入状态并驱动下一次操作，使得失败实验也能贡献于长期能力形成。由于论文未报告具体量化指标，上述对比基于系统能力边界而非数值差异。此框架定位为开放发现智能的体系结构探索，对工程实现的意义在于分离出 研究状态、验证门控、技能记忆 三个可独立开发的模块，便于标准化接入真实实验环境。

行业影响

落地场景

Discovery Foundation Models (DFMs) 的核心能力是开放端发现智能，即从问题定义、表征构建到假设检验与证据修订的全流程自动化。主要落地场景包括：

• 药物研发：利用 GALILEO 系统将干实验室推理与湿实验室机器人实验闭环，自动生成靶点假设、设计化合物并迭代验证。
• 材料与化学：在模拟环境下探索新分子、新配方，通过实验反馈持续优化属性模型。
• 企业级知识发现：将研究状态显式化，对内部数据与外部文献进行假设生成与验证，加速技术路线决策。

商业价值

DFM 的价值主线是降低研发成本与周期，而非直接增收。传统科研发现依赖人力试错，周期长、失败率高。DFM 通过过程级学习与证据驱动修订，将发现能力变为可训练、可评估的系统性资产，使每一次实验反馈都能沉淀为可复用的 Discovery Skill。在药物研发场景，可将先导化合物发现周期从数月压缩至数周，同时减少无效实验投入；在材料领域则能快速筛选高潜力候选，提升研发 ROI。

与现有产品/工作流的接口

DFM 可作为研究流程编排层，通过 API 或 agent 框架接入现有 stack：

1. 对接 LIMS、ELN、实验自动化平台（如机器人调度系统），执行湿实验验证。
2. 集成云数据仓库与科学计算引擎，用于 dry-lab 推理与模拟。
3. 提供研究状态持久化接口，与项目管理工具（如 Jira、Notion）同步假设、证据与决策记录。

具体落地用例

• 药物发现：药企使用 DFM 针对某靶点自动构建竞争性解释（如不同结合模式），生成合成路线，调用机器人进行合成与活性测试，依据结果更新假设库，并在相似靶点间迁移发现策略。
• 内容平台实验平台：将用户行为数据建模为可修订研究状态，DFM 自动提出“为何留存下降”的假设，设计 A/B 实验或因果推断方案，执行后根据证据修订对用户动机的表征，持续优化推荐策略。

此类场景均不依赖单一最终答案，而是强调过程可审计、能力可积累，契合企业研发数字化转型的长期需求。

局限

• **概念验证为主，缺乏大规模跨领域实证**。论文提出的 Discovery Foundation Models (DFMs) 目前主要停留在框架定义与概念验证阶段。Zetema 案例仅覆盖单一真实 Dry-Lab/Wet-Lab 发现循环，且规模有限，尚未在多个科学领域或长期开放发现任务中展示泛化能力。能力形成过程高度依赖精心设计的交互环境与奖励信号，环境构建成本和可扩展性未被充分讨论。这使其距离可部署的通用发现系统仍有较大差距。
• **与现有科学 AI 范式缺乏定量对比**。相对 AI Scientist、LLM 驱动的实验设计等已有方法，DFM 强调的七项耦合能力和可修订研究状态虽然完整，但缺少系统的实验对比或基准测试，难以判断其相对优势。论文提出的过程为中心评估协议仍处建议阶段，未提供标准化基准或基线结果，评价指标的可操作性和跨任务可比性存疑。因此，其宣称的超越性更多是概念层面，尚未转化为可量化的性能证据。
• **物理闭环的高成本与稳定性挑战**。GALILEO 等闭环物理发现系统高度依赖机器人湿实验基础设施和高质量外部证据，成本高、通量受限。论文未明确如何处理湿实验失败、设备误差及环境噪声对发现过程稳定性的影响，也未讨论系统在资源受限场景下的可行性。此外，持续技能更新和递归修改引入的安全风险仅概述治理原则，缺乏具体技术约束与验证机制，可能限制实际部署的信心。