为生物学中的 AI Agent 铺平道路¶
原文发布于 2026 年 6 月 8 日,作者 Laura Luebbert
基于以下研究者的工作:Ferdous Nasri, Sarah Gurev, Patrick Varilly, Krithik Ramesh, Nuala A. O'Leary, Jonah Cool, Bernhard Y. Renard, Pardis Sabeti, Laura Luebbert
核心问题:生物数据基础设施还没有为 Agent 做好准备¶
生物数据基础设施需要变得对 Agent 友好——确定性检索层是当前让 Agent 工作流可靠运行的关键。 作为案例研究,研究团队让多个科学研究 Agent(Claude、Biomni OSS、Edison Analysis、GPT)从 NCBI Virus 数据库中检索序列数据——这是病毒学家用于监测和诊断分析的核心数据库。即使是最强的模型也无法稳定达到可靠数据集构建所需的准确率。然而,当团队引入 gget virus(一个确定性检索层)后,准确率飙升至接近 100%。
更深层的启示:生物数据库必须将 Agent 视为规模化用户来设计。
一个类比:老城中的新车¶
用 AI Agent 在生物数据基础设施中导航,就像在汽车发明之前规划的古城里开车。 城市或许精心设计过,但遍布狭窄蜿蜒的街道,现代车辆很难通行。相比之下,软件基础设施是为 Agent 而生的——拥有"铺好的道路、清晰的车道、标准化的信号灯"。
编程 Agent 之所以比生物 Agent 进展更快,原因在于软件提供了结构化的数字工作流和可靠的接口,而计算生物学的数据检索基础设施"往往脆弱、异构且高度依赖流程"。
| 维度 | 软件领域 | 生物领域 |
|---|---|---|
| 接口 | 结构化 API、标准化协议 | 异构、基于浏览器的门户 |
| 数据格式 | 统一、可预测 | 多种标识符、隐含约定 |
| 容错空间 | 相对宽容 | 微小错误可能导致严重后果 |
| Agent 适配性 | 原生友好 | 脆弱、依赖手动操作 |
在生物工作流中,即便是微小的错误也可能引发严重后果:从错误的基因组构建版本中检索坐标、混淆 RefSeq 和 GenBank 记录、将部分基因组当作完整基因组处理、搞错片段名称、或因不一致的元数据而遗漏记录。
生物 Agent 的瓶颈不仅仅是推理能力,更是"缺乏广泛的确定性执行层来查询生物数据"。
Karpathy 的启示:代码是最简单的部分¶
Andrej Karpathy 在一次演讲中吐槽:vibe coding 写应用只花了很短时间,但在浏览器里点来点去处理认证、支付和部署却浪费了整整一周。 他的结论是:"代码是最简单的部分!大部分工作是在浏览器里点东西。"
研究者们引述这一案例来说明:生物学研究者长期面临同样的困境——让智能系统在"异构信息、隐含约定、以及人类在浏览器中点来点去"的环境中运行,困难重重。Karpathy 的结论同样适用于生物学:为 Agent 而构建。
案例研究:病毒学中的"点击税"¶
背景:现有工具的局限¶
计算生物学家已经开发了大量工具来将生物数据从浏览器界面搬到可编程格式,但生物数据并不存在于单一数据库中。 工具包括 Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget 等。然而,生物数据是一个"杂乱的道路网络"——每个数据库都有自己的标识符、约定、格式和过滤逻辑。
为什么病毒学尤其困难¶
疫苗设计、诊断试剂设计、蛋白质模型训练数据集构建等研究工作流,通常从 NCBI Virus 检索序列开始。数据集策展指令往往以冗长的复杂过滤条件列表形式传播,用户必须在 Web 界面中手动逐一设置。
实例:2026 年埃博拉疫情¶
当前由 Bundibugyo 病毒引发的埃博拉疫情说明了为什么简化病毒数据访问关乎生死。 2026 年 5 月 14 日,INRB 金沙萨在 8 个样本中确认了 Bundibugyo 病毒。至 5 月 29 日,WHO 报告超过 1000 例确诊/疑似病例,其中超过 200 例死亡。
新基因组提出了三个紧迫问题:
- 这次疫情的病毒与之前的埃博拉病毒有多大差异?
- 现有诊断工具能否检测到它?
- 现有治疗手段能否提供保护?
回答这些问题需要将新基因组与 NCBI Virus 和 Pathoplexus 中的历史基因组进行比对——但第一步就涉及在 Web 界面中手动点击。
技术层面的困难¶
NCBI Virus 的大量过滤逻辑仅存在于 Web 界面中。程序化检索可能需要上百行脚本、组合多个 API(REST、Datasets、E-utilities)、逐页检索结果、协调标识符、下载数百 GB 数据后在本地过滤丢弃大部分。
当 Agent 尝试执行时会怎样¶
VirBench 基准测试¶
研究团队开发了 VirBench:包含 120 个现实的病毒序列查询,覆盖 40 种病原体,带有人工验证的标准答案。 这些查询反映了病毒监测、诊断试剂设计和蛋白质模型训练数据构建中的实际任务。
示例查询:检索 TaxID 3052462(Orthoebolavirus zairense)的序列,过滤条件为:人类宿主、非洲地区、日期范围 2014/01/01-2014/06/20、最小长度 15,200 碱基、最多 1,900 个模糊碱基、排除实验室传代样本。
Agent 在没有 gget virus 时的表现¶
| 模型 | 平均准确率 |
|---|---|
| Biomni OSS | 16.9% |
| Edison Analysis | - |
| Claude Sonnet 4 | - |
| Claude Opus 4.7 | - |
| GPT-5.2-pro | - |
| GPT-5.5 | 91.3% |
(各模型准确率在 16.9% 至 91.3% 之间)
这类任务的合格标准实际上是 100%——一条缺失或错误的记录就可能决定诊断试剂是否覆盖了流行毒株的多样性,或者疫情起始日期是否被错误推断。
可重复性问题¶
同一模型对相同查询三次运行产生了截然不同的答案。 以埃博拉病毒查询为例,Sonnet 4 在第一次运行中返回 106 条序列(预期值:266),第二次返回 15 条,第三次返回 5 条——三次使用完全相同的 prompt。
下游后果:系统发育分析¶
使用手动策展的 NCBI Virus 序列构建的系统发育树恢复了 2014 年 1 月的 TMRCA(最近共同祖先时间),与之前关于 2014 年埃博拉病毒疫情的报告一致。而 Agent 检索的数据集产生了不同结果:
- 一次将 TMRCA 推回到 1922 年
- 另一次将其推移到 2014 年 4 月,且遗漏了几内亚的序列

图 1:使用 Delphy 推断的扎伊尔埃博拉病毒(2014 年西非流行)系统发育树。节点按采样国着色;灰色表示缺失/错误的国家元数据。红色虚线标记估计的 TMRCA。左上为手动检索序列构建的树;Run 1-3 为 Sonnet 4 Agent 检索集。分析与可视化:Gage Moreno。
下游后果:治疗药物分析¶
研究团队检索埃博拉病毒糖蛋白序列以检查 maftivimab 和 MBP134(抗体治疗药物,WHO 优先治疗候选方案)结合的表位。 Sonnet 4 在第一次尝试中接近正确,第二次遗漏了大部分突变残基,第三次则标注了完全不同的一组——三次运行给出了三种不同的变异性印象。

图 2:扎伊尔埃博拉病毒糖蛋白中的现有突变(红色显示,越深频率越高)。球体表示抗体治疗药物 maftivimab 和 MBP134 的结合足迹。最左为手动策展的 NCBI 数据集;Run 1-3 为 Sonnet 4 Agent 结果。PDB 结构 7TN9。分析与可视化:Sarah Gurev。
失败模式总结¶
| 失败模式 | 说明 |
|---|---|
| 漏检 | 无法检索大型结果集时计数不足 |
| 过检 | 过滤器应用错误导致计数过多 |
| 大数据集偏差 | 记录量大的病毒(流感 A、HIV-1、SARS-CoV-2)偏差最大 |
| 上下文依赖字段 | 处理依赖上下文的元数据字段时表现不佳 |
| 多过滤器退化 | 超过 3-4 个同时过滤条件时性能显著下降 |
解决方案:确定性病毒数据检索层 gget virus¶
开发背景¶
gget virus 与 NCBI 研究人员合作开发。最初看起来只是连接正确的 API 调用,实际上远比想象中复杂。 NCBI Virus 是一个覆盖多个底层资源的门户,包括国际同步的序列数据库。
gget virus 的工作原理¶
- 跨 REST、Datasets 和 E-utilities API 进行协调
- 判断哪些过滤器可通过现有 API 应用,哪些需要本地检查
- 处理大型结果集的批量检索(SARS-CoV-2、流感 A)
- 当过滤依赖于其他数据库中的信息(如 GenBank 记录中的蛋白质内容)时,先检索这些记录再应用过滤
- 返回人和机器都可读的标准化输出
- 提供详细日志展示结果如何产生
引入 gget virus 后的表现¶

图 3:AI Agent 在 VirBench 基准测试上的表现(有/无 gget virus)。VirBench 评估 Agent 正确检索病毒序列数据集的能力。最右侧柱状图显示直接运行 gget virus(无 Agent)的结果。图表改编自 Nasri et al., 2026。
| 指标 | 无 gget virus | 有 gget virus |
|---|---|---|
| 最佳模型准确率 | 91.3%(GPT-5.5) | 99.7%(GPT-5.5) |
| 所有模型准确率 | 16.9%-91.3% | 均 > 90% |
| 运行间变异性 | 极大 | 几乎消除 |
| 模型间性能差距 | 悬殊 | 显著缩小 |
关键洞察:"添加确定性检索层使模型选择变得不那么重要了。" 更便宜的模型配合正确的工具就能减少变异性并扩大可访问性。
更广泛的启示¶
上下文引擎(Context Engines)¶
gget virus 是构建"上下文引擎"——可靠的、Agent 可访问的生物数据基础设施——这一更广泛努力中的一个实例。 其他相关工作包括 ToolUniverse、Edison Scientific 的 Robin、Biomni 以及相关生物医学 Agent。
未来展望¶
研究者承认模型能力在快速变化——可以想象 Agent 终将强大到能自行导航混乱的门户系统。但即使 Agent 能做到,也不意味着应该每次都重新发明流程。一个在混乱工作流中挣扎的模型可能"太贵、太慢、太难审计、或者太难信任以用于常规科学工作"。
对生物数据库的建议:将 Agent 视为用户来设计,并为规模化做好准备。
注释¶
-
Biomni OSS 指开源版本(github.com/snap-stanford/Biomni, v0.0.8),底层 LLM 为 Claude Sonnet 4。不代表 Phylo 的 Biomni Lab 产品。
-
Edison Analysis 于 2026 年 2 月 26 日评估。由于生物安全访问限制使用了较旧的备选模型(如 Claude Sonnet 4)。结果与 Opus 4.7 不直接可比。
-
参考了 Elliot Hershberg 在 newscience.org 上的文章 "How Software in the Life Sciences Actually Works (And Doesn't Work)"。
-
感谢 INRB 金沙萨(刚果民主共和国)和 CPHL(乌干达)在 2026 年 5 月疫情期间快速测序和开放共享初始 Bundibugyo 病毒基因组。
-
在 360 次运行中的一次,GPT-5.5 在未被提示的情况下独立识别并使用了 gget virus——这是该问题唯一产生正确答案的运行。
-
Claude Sonnet 4 是由于生物安全访问限制可用于此评估的最新公开 Anthropic 模型。
-
所有分析仅供说明,不构成医学/公共卫生指导。
-
呼应了 Nils Homer 关于 AI-ready 生物信息学工具需要与代码、输出和分析逻辑协同工作的观点。