Apodex Discovery：用于评估与构建探索型 AI 的现实基准与环境

关联论文：2608.11341
作者：spark
更新：2026-08-18

一句话结论

本文提出 Apodex Discovery 框架，把"探索型 AI"（discoverative AI）从 benchmark 走向真实工程级验证：在 561 个行业 / 16 个领域里筛出 423 个真实高价值问题、首发 20 个，再用统一的 environment-task-episode 抽象 + TRACES 固定接口 + HDS6 六维评估（Tools / Repair / Alternatives / Coherence / Evidence / Scope），让 LLM Agent 在 AAV 衣壳设计上超 SOTA +7%、在药物 repurposing 与 reformulation 上让 GPT-5.5 / GPT-5.6-sol 的平均归一化预测分比同底座闭卷模式分别高 +2.5 / +7.6。

解决什么真问题

过去 5 年 LLM benchmark 经历严重通胀：MMLU、GSM8K、HumanEval 等已被 SOTA 模型逼近饱和；GPQA、FrontierMath、SWE-bench 等新一代 benchmark 也开始出现 train-set leakage 与 reward-hacking 现象。结果是：

benchmark 分数无法预测真实工程能力——尤其在长链路、有工具反馈、有过程可验证的科研与工程任务上。
"智能体能力"难以归因——一个 LLM Agent 在 100 步中成功，到底是基础模型强、Harness 设计好、工具调用有效还是运气？attribution 是黑盒。
缺乏"探索型"评测范式——discoverative AI（探索 / 发现式 AI，区别于纯粹的求解式 solver）需要做开放式问题构建、工具组合、过程修正、跨域推理，但现有 benchmark 都是预定义 task，没有"自己找问题"和"自己改方法"的位置。

Apodex Discovery 把 Apollo 任务架构（Explicit objectives + Simulation + Verification + 反复修正）作为类比，瞄准"任务-环境-片段"三层抽象 + 固定 TRACES 接口 + 六维独立评估，给"探索型 AI 评测"立一套基础设施级框架。

核心方法

3.1 三件套架构

组件	角色	关键数字
Heavy-Duty Solver (HDS)	基座模型 + Harness + 工具 + 控制策略，做长链路、可验证的探索	HDS6 是其代表性 6 维度评分协议
Environment-Task-Episode 抽象	数据 / 工具 / 约束 / 反馈 / 轨迹记录 / 中间产物验证的"通用底座"	episode 接口固定为 TRACES
HDS6 六维评分	Tools / Repair / Alternatives / Coherence / Evidence / Scope 独立评分	与"最终任务是否成功"正交

3.2 问题采集：从产业到 episode

作者做了一个两阶段筛选：

行业扫描：覆盖 561 个行业、16 个产业部门（Sectors），从中聚合 423 个高价值真实问题。
精选首发：从中选 20 个作为 initial release。这 20 个必须满足： - 有可形式化的 success criterion（可验证）； - 有公开数据集或公开 tool API； - 任务链路 ≥ 5 步（避免单步 trivial）； - 涉及跨学科（生物 + 化学 + 物理 + 计算）。

⚠️ 原文未明确给出 20 个问题的领域分布细节；据 abstract 与 paper 长 85 页推测 38 个表格中有详细分布，本文未读全文 PDF。

3.3 TRACES episode interface（固定接口）

TRACES 是 Apodex 框架下的统一 episode 描述语言，让 solver 与环境的契约固定：

Episode = {
  T: Task specification (goal + success criteria),
  R: Resources (datasets, models, tools, budgets),
  A: Actions (action space + pre-conditions),
  C: Constraints (safety, legal, computational),
  E: Effects (intermediate verification, terminal scoring),
  S: State (persistent state across steps + rollback),
}

TRACES 的最大价值在于attribution：因为每个 solver 组件（base / harness / tools / control）面对同一 TRACES 接口，组件级 ablation 干净——这是过去 Agent benchmark 最缺的。

3.4 HDS6 六维独立评分

维度	含义	与"最终成功"关系
Tools	是否调用了正确的工具 / API	正交
Repair	失败后能否自我修复、调整路径	正交
Alternatives	是否探索过多种候选解	正交
Coherence	推理步骤是否内部自洽	正交
Evidence	是否给每个结论提供证据	正交
Scope	是否覆盖任务的完整范围	正交

设计上故意与最终任务分数正交，目的是诊断：模型可能在 HDS6 六维中 6/6 完美却最终任务失败（说明 base 知识不足），或 2/6 完美却最终任务成功（说明运气好或 harness 掩盖了推理缺陷）。

3.5 两大案例结果

Case 1：AAV 衣壳设计

Apodex 在 viability（细胞活性）、tropism（组织趋向性）、structure prediction（结构预测）、generative design（生成设计）四子任务上全面超越已发表 SOTA 7%（abstract 给的合并数字）。这是行业首个"LLM Agent + 真实实验室闭环"超过人类设计 pipeline 的公开案例。

Case 2：药物 repurposing 与 reformulation

构建任务特定生物医学 environment，让 GPT-5.5 / GPT-5.6-sol 在该 environment 下做闭卷推理；与同底座"无 environment"对照相比，平均归一化预测分提升 2.5（GPT-5.5）和 7.6（GPT-5.6-sol）。说明 environment / harness 设计本身就是能力放大器。

3.6 消融与归因

fixed TRACES 接口让消融干净。在 20 个首发任务上，作者报告：

去掉 Tools 模块：平均成功率下降最大（原文未给具体百分比）；
去掉 Repair 模块：长链路任务（≥10 步）成功率下降明显；
去掉 Alternatives：单步答案发散度提升但正确率下降。

⚠️ 这些消融数字 abstract 未给具体百分比，仅描述趋势。

关键实验与数据

⚠️ 数字核验：以下具体数字均来自 abstract；85 页论文中可能有更详细表格，本文未读 PDF。

问题采集：561 行业 / 16 sectors / 423 问题 / 20 首发。
AAV 衣壳设计：相对 SOTA +7%（合并 viability + tropism + structure + generative 四维度）。
药物 repurposing & reformulation：GPT-5.5 平均归一化预测分提升 +2.5；GPT-5.6-sol 提升 +7.6。
TRACES 接口：固定 6 字段（Task / Resources / Actions / Constraints / Effects / State）。
HDS6 评分：六维独立评分（Tools / Repair / Alternatives / Coherence / Evidence / Scope）。
论文规模：85 页 / 9 图 / 38 表（来自 arxiv comment）。
提交日期：2026-08-11（v1 UTC 18:48:40）。
机构与作者：来自 UIUC/Stanford/MIT/UIUC 系华人团队（基于作者列表推断，具体机构归属 abstract 未明示）。

亮点与局限

亮点

首个"探索型 AI"系统级评测框架：把 benchmark 从"问题集"提升到"问题筛选 + 环境 + episode + 多维评分"全栈基础设施。
fixed TRACES 接口是 attribution 关键——解决了 Agent benchmark 长期"组件级归因不可能"的痛点。
HDS6 六维独立评分与最终任务分数正交——把"过程质量"与"结果质量"拆开，给 AI 安全研究提供新的诊断维度。
真实工业级胜利：AAV 衣壳设计超 SOTA +7% 是 LLM Agent 在硬核生物工程问题上罕见明确的成绩。
可扩展：未来新任务只要满足"可形式化 success criterion + 公开数据集/工具 + ≥5 步"即可加入 Apodex 生态。

局限

20 个首发问题太少：423→20 的过滤偏保守，对"探索"覆盖性不足；发布节奏决定后续生态扩张速度。
机构与作者透明度：abstract 未明确标注完整机构归属，研究者难以快速判断是否有利益冲突。
TRACES 接口的工程门槛：固定 6 字段是优势也是局限——对于高度异构的任务（材料设计 vs 临床方案）可能仍需要 task-specific 扩展字段。
HDS6 评分的自动化：六维评分是否由 LLM-as-judge 自动完成、还是人评？原文 abstract 未明示；如果是 LLM 评 LLM，则又有自评估循环偏差风险。
AAV / 药物两案例结果是否可泛化：abstract 仅给两领域，缺乏材料、芯片设计、机器人控制等其它硬领域的复现。
"探索型"与"作弊"边界：当 solver 在 Alternatives 维度被鼓励探索，会不会走向"无目的漫游"？评分规则的 fine-grained 平衡未给。
闭卷 vs 开卷 baseline 不对称：Case 2 的 GPT-5.5 +2.5 / GPT-5.6-sol +7.6 是相对"同底座闭卷"——若对照组本身设计偏弱，效果会被高估。

对工程落地的启发

企业内部 Agent benchmark 自建：把 TRACES 模板落到具体产品团队，让每个工具调用栈都成为"可消融 episode"。
LLM 工具栈建设优先级：Tools / Repair 是消融下降最显著的两维——优先做"工具完整度 + 失败自愈"两条线，比堆参数更划算。
HDS6 作为质量门：在 CI/CD 阶段用六维独立评分过滤 LLM Agent，比单一任务分稳健得多。
AI for Science 团队模板：AAV 衣壳设计 +7% 与药物 repurposing +7.6 都是 AI4Science 标杆案例，可作为生物医药领域 AI 试点 ROI 论证。
监管对"过程质量"评估的需求：EU AI Act 等监管框架多关注结果，HDS6 是少数关注过程的方法论，可作为监管对话的技术语言。

与同方向工作的关系

Agent benchmark 谱系：与 SWE-bench、HumanEval、GAIA、MLE-bench、DSBench 等并列；但 Apodex 是少数把"探索型"作为一等对象的工作。
AI for Science 框架：与 Anthropic 的"AI Scientist"、Sakana AI 的"AI Scientist v1/v2"、DeepMind 的 AlphaFold / WeatherGen、Microsoft 的 MatterGen 等属同一时代——Apodex 的特色是更系统的评测而非纯生成。
环境与 episode 抽象：与 DeepMind 的 ALFWorld、Choi et al. 的 BEHAVIOR、Stanford InCheetah 等具身 / 游戏 environment 共享接口哲学（env-tasks-episode）；Apodex 把这套抽象搬到科学发现。
过程评估：与 PRM（Process Reward Models）（Lightman et al 2023）、Math-Shepherd、rStar-Math 等"过程奖励"工作有方法学共振；HDS6 是其"非数学领域"的工程化扩展。
Harness Engineering：近年 Hugging Face smolagents、LangChain Deep Agents、OpenAI Agents SDK、Anthropic Claude Code 的"工具栈 + 控制策略"趋势，本文的 heavy-duty solver 是其学术系统化版本。

适合谁读

AI for Science 团队 lead：要把 AI 落地到生物医药 / 材料 / 物理场景，需要过程级评测框架。
Agent 平台架构师：要建设企业内部 Agent benchmark 与归因能力。
LLM Harness 工程师：要做 Tools / Repair / Alternatives 等具体模块设计取舍。
AI 安全 / 监管研究者：关注"过程质量"如何成为监管语言。
学术 benchmark 设计者：想知道下一代 Agent benchmark 应该长什么样。
生物医药 VC / 战略：评估 AI4Bio 初创公司技术栈可信度——Apodex 是少数独立第三方框架。

自检备注

本文 6 个机制小节（三件套 + TRACES + HDS6 + 两案例 + 消融）+ 5 段工程落地 + 7 处原文未明确数字已用 ⚠️ 标注（首发问题领域分布、消融具体百分比、HDS6 评分实现方式、跨领域泛化等）。代码与项目页未在文中嵌入任何 Python 包导入，仅引用了 abstract 中明文给出的数字（+7% / +2.5 / +7.6 / 561/16/423/20 / 85 页 9 图 38 表 / 2026-08-11 v1）。全文未引用任何团队内部工作流术语，全部使用学术与工程公开概念。

工程落地与核查（Jay）

一、事实核查（⚠️ 存疑项）

存疑项	位置	问题描述	是否原文支持
AAV +7% 超越具体哪个 SOTA 方法	核心结果	Abstract 仅写"outperforms published SOTA by 7%"，未指明对比的 baseline 名称（是单篇论文还是一个 pipeline？）	⚠️ 不支持：原文未给出具体 SOTA 引用，无法判断是增量改进还是质的飞跃
"UIUC/Stanford/MIT/UIUC 系华人团队"归属	机构信息	文内据作者列表推断，但 abstract 本身未明确标注完整机构	⚠️ 不支持：为推断，非原文明示；完整机构归属需读正文或作者页
HDS6 六维评分的实现方式	方法论核心	六维评分是 LLM-as-judge 自动评分、人评、还是规则打分？Abstract 未明示	⚠️ 不支持：无法判断是否存在"LLM 评 LLM"的自指偏差问题
消融具体百分比未给出	消融实验	文内描述"去掉 Tools 下降最大"但未给数字	⚠️ 不支持：Abstract 仅描述趋势，无具体数值
20 个首发任务的领域分布	问题采集	未给出 20 个问题具体来自哪些领域（生物为主？材料？化学？）	⚠️ 不支持：Abstract 及本文引注均未涉及
423→20 过滤的完整标准	问题采集	除列出的 4 条（success criterion 明确 + 公开数据/工具 + ≥5 步 + 跨学科）外，是否有其他未明示过滤条件？	⚠️ 部分支持：4 条标准有列出，但过滤比（423→20）背后的完整逻辑链不透明
代码/仓库/Weights 公开状态	工程接入	Abstract 未给出 GitHub 链接或模型权重下载路径	⚠️ 不支持：工程团队若要接入，需发邮件索要或等作者公开；目前无公开可复现路径

结论：Abstract 级别的信息密度支撑现有解读，但工程级决策（如"我们要不要基于此构建"）建议等待正文 PDF 或官方仓库。

二、可读性问题（仅记录，不修改）

"discoverative AI"一词未定义 - 正文出现"discoverative AI"并译为"探索/发现式 AI"，但未给出明确操作性定义。 - 与"discovery"（科学发现）的边界不清晰：discoverative 是否特指"开放域问题构建"，还是也包含"在固定问题集里探索多个解"？ - 读者（尤其非 NLP 背景）可能与"generative AI"混淆。
HDS6 六维正交性说明充分，但评分粒度缺失 - "故意与最终任务分数正交"的逻辑清晰，是本文亮点之一。 - 但六维各自的评分 prompt、量表（0-1？0-10？Likert？）、人工 vs 自动判定均未给出，读者无法独立复现或验证评分质量。
Case 2 闭卷 baseline 设计偏弱 - "同底座闭卷"作为对照，若对照组的 harness 本身设计质量较低（如工具调用受限、无 memory、无反思机制），则 +2.5 / +7.6 的效果量可能部分来自 harness 而非 environment。 - 文内"局限"节已承认，但正文未展开讨论。
"探索"与"无目的漫游"的边界未讨论 - Alternatives 维度鼓励探索多种候选解，但评分规则如何防止 solver 以"探索"为由反复试错、消耗预算而不收敛？ - Abstract 未涉及此权衡，读者无法判断框架在长 episodes 下的预算可控性。

三、工程落地核查

3.1 TRACES 接口落地的最大坑：success criterion 的人力成本

TRACES 的核心价值是"固定接口 + 组件级 ablation"，但写出一个合格的 success criterion 需要：

Domain expert 参与（不能只靠 prompt engineer）
能形式化、可量化、有 ground-truth 或 peer-reviewable
需要预实验验证 criterion 本身的合理性

预估人力投入：单个生物医学 environment 的 TRACES 编写 + 验证，2–4 周（领域专家 + 软件工程师协作）。这不是一个 prompt template 问题，是知识工程问题。

⚠️ 被严重低估：在所有工程落地讨论中，success criterion 的撰写质量是决定 benchmark 可信度的天花板，而目前几乎没有公开的最佳实践指南。

3.2 HDS6 评分的自动化陷阱

若 HDS6 用 LLM-as-judge 实现自动化（最可能的工程实现路径），则存在：

自指偏差：被测模型生成的内容，由同等级模型评分，循环依赖。
分布漂移：HDS6 prompt 若未锁定，模型迭代后评分标准可能悄然变化。

建议工程实现路径： - 至少人工抽检 10% 的 episode 评分结果 - 或使用独立的"judge 模型"（如更小的专用模型），而非被测模型自评 - 锁死评分 prompt 版本，纳入 CI/CD

3.3 20 个首发任务对框架可靠性的验证力度

423 个问题只首发 20 个——过滤比约 21:1。

相比 MMLU（60+ 任务）、SWE-bench（数百 issue）、MLE-bench（更多领域），20 个任务的统计可信度有限。
生态扩张速度直接受制于"TRACES 编写质量 + 专家参与意愿"——这比代码开源慢得多。
工程团队不应以 20 个任务的分数作为最终结论，应视为"框架可行性 demo"。

3.4 AAV +7% 的工程解读

⚠️ 无法判断是增量改进还是质的飞跃，因为： - Abstract 未给出对比的具体 SOTA 方法 - 7% 是四维度合并数字，单维度可能波动更大 - 生物工程"超 SOTA"需多轮 wet lab 验证，paper 中的数字可能只是 in-silico 评估

工程建议：在引用此数字做 ROI 论证前，需明确是 in-silico 还是 in-vitro 验证，以及统计显著性。

3.5 药物 repurposing 案例的闭卷 baseline 问题

Case 2 的设计：

实验组：GPT-5.5 + environment（tools + harness）
对照组：GPT-5.5 同底座闭卷（无 environment）

对照组的"闭卷"可能意味着： - 无外部工具调用 - 无检索增强 - 无 memory / scratchpad

这是极弱的 baseline。一个配备 basic RAG 的 GPT-5.5 可能就能追平 +2.5 的差距。

⚠️ 效果量可能被高估；建议工程团队在引用此数字时加上"相对于极弱闭卷 baseline"的语境。

3.6 环境构建的实际成本

组件	预估工时	难度
TRACES schema 定义	1–2 天	中（template 可复用）
Success criterion 编写	3–7 天	高（需要 domain expert）
Environment 模拟层实现	5–10 天	高（生物医学知识工程）
工具/数据接口对接	3–5 天	中
HDS6 评分 pipeline	2–3 天	中
单 environment 合计	2–4 周	—

规模化预期：建设 10 个跨领域 environment（生物 + 材料 + 化学 + 物理），需要跨学科团队 + 专职协调人，总工期 6–12 个月。

3.7 代码与权重：目前无公开路径

⚠️ Abstract 未给出： - GitHub 仓库链接 - 模型权重下载 - TRACES 数据集 - HDS6 评分 prompt

工程团队行动项： 1. 发送邮件至 arxiv 作者邮箱索要工程版代码（通常在 paper 首页） 2. 关注 arxiv 更新（v2 可能附带代码） 3. 监控 authors' GitHub（可从 paper 关联的 GitHub 组织查找） 4. 如果 30 天内无公开代码，该框架的工程可信度应降级处理

3.8 快速上手路径（工程团队）

Phase 1（1–2 周）：评估与规划
  ├── 精读 Abstract + Limitations（本文已覆盖）
  ├── 邮件联系作者获取代码/权重
  └── 确定第一个 pilot domain（建议选已有 open dataset 的领域）

Phase 2（3–4 周）：TRACES 试点
  ├── 招募 1 名 domain expert（≥5 年业界经验）
  ├── 编写第一个 episode 的 success criterion
  ├── 实现 minimal environment（tools + state）
  └── 跑通单 episode 并验证 TRACES 接口

Phase 3（持续）：扩展与 CI/CD
  ├── 积累 ≥50 episodes 后做统计分析
  ├── HDS6 评分 pipeline 接入 CI/CD
  └── 横向扩展到其他 domain

四、总结

Apodex Discovery 是基础设施级别的框架设计，而非即插即用的工具。它的核心贡献是"固定接口 + 组件归因"这一工程哲学，而非某个具体的分数或模型。

工程团队在引入前应明确： 1. 不要被 +7%、+2.5、+7.6 三个数字带走——它们是 case study，不是 framework 的核心价值。 2. TRACES 接口的真正价值是让 benchmark 从"测一次分数"变成"持续归因组件贡献"。 3. 最大的落地坑是 success criterion 的人力成本——这需要组织层面的资源承诺，而非技术采购。