为生物学中的智能体铺路

作者：Laura Luebbert。基于 Ferdous Nasri、Sarah Gurev、Patrick Varilly、Krithik Ramesh、Nuala A. O'Leary、Jonah Cool、Bernhard Y. Renard、Pardis Sabeti 和 Laura Luebbert 的研究。

在这篇文章中，Laura Luebbert 认为我们需要让生物数据基础设施对 agent 更友好。作为一个案例研究，她和她的团队让科研 agent（Claude、Biomni、Edison Analysis、GPT）从 NCBI Virus（病毒学家用于监测和诊断检测开发等任务的数据库）中检索序列数据。即使是最强的模型，也无法始终达到可靠数据集构建所需的准确度。但一旦她和她的团队添加了 gget virus（一个确定性检索层），准确度就提升到了接近 100%。对科研 agent 而言，更广泛的教训是：确定性检索工具（目前）对于使 agent 工作流更可靠至关重要，而生物数据库在设计时需要将 agent 视为规模化用户来考虑。 使用 AI agent 来导航生物数据基础设施，就像开车穿过一个在汽车发明前设计的古老城市：基础设施可能很漂亮，甚至考虑周全，但到处都是狭窄、蜿蜒的街道，现代车辆难以通行（独特的文件格式、分散的数据库和一次性的检索脚本）。¹ 你可以为城市加装交通标志、停车场，偶尔拓宽道路，但基本布局仍然难以通行，因为它原本是为另一种交通方式设计的。相比之下，软件基础设施基本上是为汽车（agent）的需求而建的：铺好的道路、清晰的车道、标准化的信号，以及为从起点到终点快速通行而设计的系统（版本控制、文档完善的 API 和包管理器）。

因此，编码 agent 的进步远快于生物 agent。软件通常提供结构化的数字工作流和可靠的接口，而数据检索和验证所需的计算生物学基础设施往往脆弱、异构且依赖特定流程。我们用来导航这些基础设施的工具必然是定制的，并针对特定领域或假设进行了调优。此外，软件提供可测试的输出，可以快速编译和验证（例如，通过生成一个通过项目测试的补丁来解决 GitHub issue），而生物学则很少提供简单、可验证且有意义的回报。

因此，生物 agent 的瓶颈不仅在于推理能力，还在于缺乏广泛可用的确定性执行层来查询生物数据。科学家可以表达他们的意图（例如，找到所有具有此结构域的人类激酶并提取它们的结构），但 agent 往往缺乏可靠的方式来访问包含所需信息的数据库。

在生物学和科学工作流中，即使是微小的错误也可能导致严重后果。例如，从错误的基因组版本中检索坐标，可能会使下游的生物学解释失效。无意中混合 RefSeq 和 GenBank 记录、将部分基因组视为完整基因组、混淆分段病毒的片段名称、或因元数据字段不一致而遗漏相关记录，都会产生同样的问题。研究的魅力和挑战在于，细节往往至关重要。

就像开车穿过一个意大利山城，如果街道太窄、转弯太急、路线依赖本地知识，那么汽车再强大也无济于事。如果我们希望 agent 帮助科学发现——从疫情应对到药物设计再到生物建模——我们需要构建它们能够像人类一样可靠导航的生物数据基础设施。

Karpathy 关于 Web 开发的演讲告诉我们如何用 AI agent 做生物学

这种 agent 需求与人类构建工具之间的不匹配并非生物学独有。只要 agent 被插入到仅为人类使用而设计的环境中，就会出现同样的摩擦。

几个月前，Andrej Karpathy 做了一个关于 AI 时代软件的演讲，最后他抱怨了一些听起来非常熟悉的事情。他 vibe-coded 了一个小型 Web 应用，但当他试图将其变为现实（身份验证、支付、部署）时，他花了一周时间在浏览器仪表板中点来点去。

正如他总结的那样，“代码是最简单的部分！大部分工作都在浏览器里，点击各种东西。”文档总是告诉他“去这个 URL，点击这个下拉菜单”。他的结论是，没有人应该做这些事。相反，我们必须为 agent 构建。

Karpathy 在软件 agent 世界中经历了一些新事物，而生物学研究人员已经为此挣扎了很长时间：试图让智能系统在围绕异构信息、隐式约定和人类通过浏览器点击而构建的环境中运行的痛苦。

案例研究：病毒学中的“点击税”

早在 AI agent 出现之前，计算生物学家和遗传学家就已经开始为传统的计算生物学生产工具，这在一定程度上解决了这个问题。像 Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget 以及许多其他工作流库，都是为了将生物数据从浏览器界面转移到研究人员可以直接计算的地方。

问题在于，生物数据并不存在于一个具有单一接口的单一数据库中。它是一个杂乱的道路网络，每条路都有自己的标识符、约定、格式、过滤逻辑和程序化访问程度。有些数据很容易通过程序化方式访问，其他的则不然。

特别是病毒学，是较难的案例之一。从疫苗和诊断检测设计到为蛋白质模型构建训练数据，研究工作流通常从从 NCBI Virus 检索序列开始。NCBI Virus 是一个来自 GenBank、RefSeq 和国际 INSDC 生态系统（包括 Pathoplexus）的病毒序列记录集合，位于一个可搜索的 Web 界面之后。作为为病毒疫情监测构建工具的研究人员，我们深知这些检索背后隐藏着多少专业知识。在病毒学实验室中，针对 NCBI Virus 的数据集整理说明通常以长长的复杂过滤器列表形式传递，用户必须在 Web 界面中手动重现这些过滤器：这正是 Karpathy 抱怨的那种浏览器点击工作流。

刚果民主共和国目前由本迪布焦病毒引起的埃博拉疫情，是一个鲜明的例子，说明了简化的病毒数据访问如何能产生关乎生死的现实后果。2026 年 5 月 14 日，刚果民主共和国金沙萨的 INRB 分析了 13 份血液样本，并于次日确认了 8 例本迪布焦病毒病病例，² 随后宣布爆发埃博拉疫情。到 5 月 29 日，WHO 报告刚果民主共和国已有超过 1,000 例确诊和疑似病例，其中包括 200 多例死亡。研究人员还生成了首批近乎完整的疫情基因组，有助于确定此次疫情是由一次新的溢出事件引起的。

这些基因组给公共卫生官员带来了三个紧迫的问题。首先，这次爆发的病毒与以前见过的埃博拉病毒有多大不同？其次，现有的诊断方法还能检测到它吗？第三，现有的治疗方法还能保护人们免受其害吗？回答这些问题需要将新基因组与通过 NCBI Virus 和 Pathoplexus（与 NCBI Virus 同步）获得的埃博拉历史基因组进行比较。但这个过程并不容易自动化，分析的第一步涉及手动点击 Web 界面，手动重现复杂的过滤器，并希望得到的数据集是完整和正确的。

这个工作流难以自动化的原因是，NCBI Virus 的大部分过滤逻辑只存在于这个 Web 界面中。这对人类来说很烦人，对 agent 来说则很糟糕。如果研究人员想要 2025 年发布的所有包含表面糖蛋白的 SARS-CoV-2 序列，一位经验丰富的病毒学家可能只需在浏览器中点几下。但通过程序化方式，可能需要一个数百行的脚本，将多个 API（REST、Datasets、E-utilities）粘合在一起，逐页检索结果，协调标识符，并下载数百 GB 的数据，然后在本地过滤后丢弃大部分。

即使某个资源有 API，由于各种原因，agent 也可能难以可靠地使用它，例如，如果 API 没有暴露与 Web 界面相同的过滤语义，如果元数据字段文档不完善或标准化不一致，如果标识符在来源之间发生变化，或者如果“正确答案”依赖于专家人类知道但机器必须推断的约定。

当 agent 无论如何都要尝试时会发生什么

为了更好地理解将 agent 与数据库桥接起来的挑战，我们开发了一个测试，用于评估最先进的科研 agent（Claude、Biomni、Edison Analysis、GPT）在要求使用当前可用基础设施从 NCBI Virus 检索病毒序列时的能力。我们的基准测试 VirBench 包含 120 个真实的病毒序列查询，涵盖 40 种病原体，并带有手动验证的真实计数。这些查询反映了病毒监测、诊断检测设计和蛋白质模型训练数据构建中出现的任务。例如，一个查询要求 agent “从 NCBI 检索 TaxID 3052462（扎伊尔埃博拉病毒 (ZEBOV)）的病毒序列，这些序列需满足以下条件：宿主生物：人类，样本采集地理位置：非洲，采集日期在 2014 年 1 月 1 日或之后，采集日期在 2014 年 6 月 20 日或之前，最小序列长度：15,200 个碱基，最多 1,900 个模糊字符 (N)，排除实验室传代样本。”

当 agent 被要求自行解决这些查询时，不同系统的性能差异很大，并且较新的前沿模型有显著改进。然而，即使是最强的模型，也无法始终达到可靠数据集构建所需的准确度和可重复性。Claude Sonnet 4、Claude Opus 4.7、Biomni、Edison Analysis、GPT-5.2-pro 和 GPT-5.5 ³ 的平均准确度从 16.9% 到 91.3% 不等。对于这些数据检索任务，标准实际上是 100%：在某些情况下，一条缺失或错误的记录可能决定诊断检测是否看起来覆盖了流行的多样性，或者疫情被推断为比实际早几周或晚几周开始。此外，当同一个模型被问及同一个问题三次时，通常会产生截然不同的答案，这破坏了可靠科学工作流所需的准确性和可重复性。对于上面埃博拉病毒查询的例子，Sonnet 4 ⁴ 在一次运行中返回了 106 条序列（预期：266 条），第二次运行返回 15 条，第三次运行返回 5 条，尽管每次收到的提示完全相同。

这种不一致性对下游分析有影响。我们使用上面显示的查询来检索埃博拉病毒序列并构建系统发育树，这是重建疫情中病毒样本之间关系的标准分析。我们可以从系统发育树中获得的一个重要量是到最近共同祖先 (TMRCA) 的估计时间。这是推断出的疫情根日期，它可以改变关于病毒何时何地起源以及病毒传播了多长时间的结论。在这种情况下，从手动整理的 NCBI Virus 序列集构建的树恢复了 2014 年 1 月的 TMRCA，这与 2014 年埃博拉病毒疫情的先前报告（95% 最高后验密度区间为 1 月 27 日至 3 月 14 日）一致。相比之下，Sonnet 4 检索到的三个序列集中有两个明显不完整，其中一个树将推断的 TMRCA 推回到了 1922 年。剩余的数据集（运行 1）表面上看起来合理，但未能检索到来自几内亚的序列，并将估计的 TMRCA 移到了 2014 年 4 月，改变了推断的疫情时间。

2014 年西非疫情中扎伊尔埃博拉病毒的系统发育树，使用 Delphy 推断。尖端按采样国家着色；灰色表示缺失或错误检索的国家元数据。红色虚线标记每棵树到最近共同祖先 (TMRCA) 的估计时间。左上角的树是从通过 NCBI Web 界面手动检索的序列构建的，而运行 1-3 是由 Sonnet 4 agent 使用 Web 搜索和代码执行工具组装的序列集生成的。分析和可视化由 Gage Moreno 完成。

NCBI Virus 检索尝试之间的变异性也会影响关于治疗方法的结论。我们检索了埃博拉病毒糖蛋白序列，以检查 maftivimab 和 MBP134 所结合的抗原表位，这两种抗体疗法是针对扎伊尔埃博拉病毒开发的，并且是正在进行的埃博拉病毒疫情中的 WHO 优先治疗候选药物。我们询问了在相关的扎伊尔埃博拉病毒序列中，这些抗体靶向的区域是否先前出现过突变。这种分析可以让研究人员了解，随着病毒的进化，某种治疗是否还能继续保护患者。如果底层序列不完整或获取错误，可能会推翻他们的结论。在我们的例子中，Sonnet 4 检索到的序列在第一次尝试时接近通过手动 NCBI 查询获得的结果。在重复运行时，它错过了大多数突变残基。而在第三次运行时，它突出了另一组不同的残基，对这些靶区域的可变性产生了三种不同的印象。⁵

现有扎伊尔埃博拉病毒在其糖蛋白上的突变以红色显示，较深的阴影表示较高的突变频率。球体表示抗体疗法 maftivimab 和 MBP134 的已知足迹。最左边的可视化是从手动整理的 NCBI 数据集构建的，而运行 1-3 是由 Sonnet 4 agent 使用 Web 搜索和代码执行工具组装的序列集生成的。显示的 PDB 结构是 7TN9。分析和可视化由 Sarah Gurev 完成。

这两个例子都说明了科学中的一个更广泛模式：看起来像微小检索选择的细节可能会改变生物学结论。在这种情况下，病毒序列检索中不一致的模型性能以及失败模式的本质表明，大多数变异可归因于基础设施的缺陷。当 agent 未能检索到大型结果集时，它们会低估计数；而当过滤器应用不正确时，它们会高估计数。例如，与预期计数的最大偏差出现在具有大量可用记录的病毒中，包括甲型流感、HIV-1 和 SARS-CoV-2，在这些情况下，检索中途停止和不正确的下游过滤会严重扭曲最终数据集。它们还在元数据字段上遇到困难，这些字段的含义取决于上下文、约定或信息恰好存储的位置。随着查询变得更加复杂，尤其是超过三四个同时过滤器时，性能会下降。

最终，agent 通常足够理解任务以尝试执行，但它们缺乏一种机器可操作的方式来执行、验证和重复它。由此产生的答案可能看起来合理，但仍然是错误的，这尤其危险，因为序列检索通常是更长的生物学工作流的第一步。

病毒数据检索的确定性层

有关 VirBench 和 gget virus 的更详细解释，请阅读预印本。

为了将病毒数据检索转变为 agent 和人类可以直接调用的东西，我们与 NCBI 的研究人员合作开发了 gget virus。起初，这似乎可能只是连接到正确 API 调用的简单问题。实际上，这要困难得多：NCBI Virus 是一个覆盖多个底层资源的门户，包括在美国、欧洲和日本维护的国际同步序列数据库，因此回答一个看似简单的查询通常需要将来自多个地方的信息拼凑起来。

为了重现 NCBI Virus Web 界面的行为，gget virus 必须协调其下的不同系统，包括 REST、Datasets 和 E-utilities API。gget virus 决定哪些过滤器可以通过这些现有 API 应用，哪些必须在本地检查，因为 Web 界面暴露了单个程序化端点无法提供的过滤行为。它处理批处理，以便全面检索大型结果集（例如 SARS-CoV-2 和甲型流感数据集），而不是任意截断。当过滤依赖于存储在单独数据库中的附加信息时（例如，指示序列是否包含特定病毒蛋白的 GenBank 记录），gget virus 会检索这些记录，使用它们来应用过滤器，并在最终输出中保留相关的 GenBank 信息。然后，它返回人和机器都可读的标准化输出，并带有显示最终结果如何生成的详细日志。⁶

AI agent 在 VirBench 基准测试上使用和不使用 gget virus 的性能。VirBench 评估 agent 正确检索病毒序列数据集的能力。最后一个柱状图显示直接运行 gget virus，不通过 agent。图改编自 Nasri 等人，2026。

当我们让 agent 访问 gget virus 时，所有 agent 的准确度都上升到 90% 以上，GPT-5.5 达到 99.7%。运行间的变异性基本消除，模型之间的性能差距显著缩小。换句话说，添加一个确定性检索层使得模型选择变得不那么重要。考虑到可靠的数据库构建不应依赖于访问最新或最昂贵的模型，或知道哪个模型对给定数据库效果最好，这一点尤其重要。相反，更便宜的模型与正确的工具配对可以减少变异性并实现更广泛的访问。

gget virus 通过将复杂的、基于浏览器的检索工作流转换为准确且可重复的接口，使现有 agent 在病毒数据检索方面更加可靠。回到我们步行城市的比喻，这就像我们在人行基础设施下方增加了一条高速公路隧道，配有入口和出口匝道、顺畅的立交桥以及与已知里程标志相关联的出口编号。

正如 Karpathy 所说：“让 [基因组数据] 对 agent 可访问”

我们希望模型在生成假设、设计实验或推理机制时具有创造性。但创造性之下的那一层——基因标识符、模式、检索逻辑、坐标系统、元数据约定和数据访问路径——必须可靠得令人乏味（或者换句话说，是确定性的）。gget virus 是构建这些 上下文引擎（可靠、agent 可访问的生物数据基础设施）的更广泛努力中的一个例子。其他努力来自 AI for Science 系统，其中许多依赖于将 agent 连接到生物数据源的模型 harness，包括 ToolUniverse、Edison Scientific 的 Robin、Biomni 以及相关的生物医学 agent。挑战在于弄清楚这种确定性属于哪里以及如何构建它。

当我们考虑到模型能力变化的速度时，关于连接器和 harness 的工作变得更加棘手。如果我们从上面的结果向前绘制模型曲线，很容易想象一个（非常近的）未来，其中像 gget virus 这样的工具的好处趋近于零：agent 变得足够好，可以导航混乱的门户、协调标识符、正确分页并自行从失败中恢复。在那个世界里，可能不需要 harness。尽管如此，即使 agent 能做到，也不意味着每次都应该由 agent 来处理（并重新发明）这个任务。一个能够艰难通过混乱的生物信息学工作流的模型，对于常规科学工作来说，可能仍然太昂贵、太慢、太难审计或太难信任。而且，如果 agent 最终使今天的 harness 过时，那么对生物数据库的教训仍然成立：在考虑我们的用户时，我们需要将 agent 放在心上，并且我们需要为规模化而构建。

致谢

我们感谢 Xander Balwit、Ethan Dyer、Stuart Ritchie、Rebecca Hiscott、Alyssa Morrow、Keir Bradwell、Eric Kauderer-Abrams、Jonah Cool、Andrej Karpathy、Patrick Varilly、Cesar Arze、Blake Lash、Philine Guckelberger、Nisha Gopal、Elliot Hershberg、Pardis Sabeti 和 Jonathan Feldman 富有见地的反馈、仔细的编辑和有益的对话，这些改进了本文。

我们特别感谢 Sarah Gurev 和 Gage Moreno 在开发和执行示例病毒学分析方面的帮助，以及 Ferdous Nasri 和 Krithik Ramesh，他们对本文的想法、框架和写作做出了重大贡献。

脚注

1. 关于为什么生物软件常常感觉碎片化、维护不善且难以使用的更深入描述，请参阅 Elliot Hershberg 的文章 “生命科学中的软件实际上如何运作（以及不运作）”。
2. 我们感谢并认可刚果民主共和国国家生物医学研究所 (INRB) 和乌干达中央公共卫生实验室 (CPHL) 的团队，他们在 2026 年 5 月疫情期间快速测序、分析并开放共享了最初的本迪布焦病毒基因组。
3. 在 360 次运行中的一次（查询 32，第三次重复），GPT-5.5 独立识别并使用了 gget virus，尽管没有明确提示它这样做。这是该问题唯一产生正确答案的运行。
4. Claude Sonnet 4 代表了可用于此评估的最新公开 Anthropic 模型，这是由于后续与生物安全相关的访问限制对较新模型的影响。
5. 此处执行的所有分析仅供说明之用，无意提供医疗或公共卫生指导；有关埃博拉疾病治疗建议，请参考 WHO 官方指南。
6. 呼应 Nils Homer 最近关于 AI 就绪生物信息学工具的观点：“AI 助手需要与你的代码、你的输出和你的分析逻辑一起工作。”这允许 agent 不仅检查检索了什么，还检查是如何检索的，将一个看似合理的答案转变为可以检查和重现的东西。

相关内容

社会科学中的编码 agent

一项针对 1,260 名社会科学家关于 AI 和编码 agent 使用的调查结果。

Project Glasswing：初步更新

关于我们从 Project Glasswing 中学到的东西的早期更新。

阅读更多