为生物学AI智能体铺路

作者：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 主张我们需要让生物数据基础设施对智能体更加友好。作为一个案例研究，她和她的团队让科学研究智能体（Claude、Biomni Open Source（Biomni OSS）¹、Edison Analysis、²GPT）从 NCBI Virus 中检索序列数据，这是一个病毒学家用于监测和诊断检测开发等任务的数据库。即便是最强的模型也未能持续达到可靠构建数据集所需的准确度水平。但当她和她团队加入 gget virus 这一确定性检索层后，准确率提升到了接近 100%。对科学智能体而言，更广泛的教训是：确定性检索工具（目前）对于让智能体工作流更加可靠至关重要，而生物数据库在设计时也需要将智能体视为规模化用户。

使用 AI 智能体来驾驭生物数据基础设施，就像在一座汽车出现之前就已设计好的老城里开车：基础设施也许很美，甚至考虑周到，但到处都是狭窄蜿蜒的街道，现代车辆很难通行（奇特的文件格式、分散的数据库，以及一次性的检索脚本）。³你可以为这座城市加装交通标志、停车场，偶尔再拓宽几条道路，但基本布局依然难以通行，因为它是为另一种交通方式设计的。相比之下，软件基础设施基本上就是为汽车（智能体）的需求而建的：铺好的道路、清晰的车道、标准化的信号，以及为从起点到终点的快速通行而设计的系统（版本控制、文档完善的 API 和包管理器）。

因此，编程智能体的进展远比生物智能体迅速。软件通常提供结构化的数字工作流和可靠的接口，而数据检索与验证所需的计算生物学基础设施往往脆弱、异构且依赖具体流程。我们用来驾驭这些基础设施的工具必然是定制的，并针对特定领域或假设进行调优。此外，软件提供可测试的输出，能够被快速编译和验证（例如，通过生成一个能通过项目测试的补丁来解决某个 GitHub issue），而生物学则很少提供既简单可验证又有意义的奖励信号。

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

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

就像开车穿过意大利的山城，如果街道太窄、转弯太急，而且路线还得靠本地人的经验，那么车有多强劲都无济于事。如果我们想让智能体助力科学发现——从疫情响应到药物设计再到生物建模——我们就需要构建生物数据基础设施，让智能体能像人类一样可靠地在其中穿行。

Karpathy 那场关于 Web 开发的演讲，对用 AI 智能体做生物学意味着什么

智能体的需求与人类构建的工具之间的这种错配，并非生物学所独有。只要把智能体放进专为人类使用而设计的环境中，同样的摩擦就会出现。

几个月前，Andrej Karpathy 做了一场关于 AI 时代软件的演讲，最后吐槽了一件听起来再熟悉不过的事。他用 vibe coding 写了一个小型 Web 应用，但当他试图把它真正落地（身份验证、支付、部署）时，却在浏览器仪表盘里点来点去，白白搭进去一周时间。

正如他总结的那样：“代码是最简单的部分！大部分工作都在浏览器里，点来点去。”文档一直告诉他“访问这个 URL，点击这个下拉菜单”。他的结论是，不该有人非得干这种事。相反，我们必须为智能体而构建。

Karpathy 在软件智能体的世界里经历了一件生物学研究者长期以来一直苦苦挣扎的新鲜事：试图让智能系统在由异构信息、隐性约定和人类点击浏览器所构成的环境中运行时的那种痛苦。

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

早在 AI 智能体出现之前，计算生物学家和遗传学家就已经开始为传统计算生物学打造工具，逐步削减这一问题。Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget 等软件包，以及许多其他工作流库，都是在努力将生物数据从浏览器界面中搬出来，转移到研究者可以直接对其进行计算的地方。

问题在于，生物数据并不存在于一个拥有单一界面的单一数据库中。它是一张杂乱的道路网络，每条路都有自己的标识符、约定、格式、过滤逻辑和程序化访问程度。有些数据可以很直接地通过程序访问。其他的就没那么容易了。

病毒学尤其属于较为棘手的案例之一。从疫苗与诊断检测设计，到为蛋白质模型构建训练数据，研究流程往往始于从 NCBI Virus 检索序列——这是一个汇集了来自 GenBank、RefSeq 以及国际 INSDC 生态（包括 Pathoplexus）的病毒序列记录的集合，置于一个可搜索的网页界面之后。作为构建病毒暴发监测工具的研究者，我们 firsthand 深知这些检索背后隐藏着多少专家知识。在病毒学实验室里，针对 NCBI Virus 的数据集整理说明常常以长长的复杂筛选条件清单形式流传，用户必须在网页界面中手动复现：这正是 Karpathy 所抱怨的那种浏览器点击式工作流程。

刚果民主共和国当前由 Bundibugyo 病毒引发的埃博拉病暴发，是一个鲜明的例证，说明简化病毒数据获取为何能带来现实世界中生死攸关的后果。2026 年 5 月 14 日，刚果民主共和国的 INRB Kinshasa 分析了 13 份血液样本，并于次日确认了 8 例 Bundibugyo 病毒病，⁴随后宣布埃博拉暴发。截至 5 月 29 日，WHO 已报告刚果民主共和国超过 1,000 例确诊和疑似病例，其中包括 200 多例死亡。研究人员还生成了首批近乎完整的暴发基因组，帮助确认此次暴发是由一次新的溢出事件引起的。

这些基因组向公共卫生官员提出了三个紧迫问题。第一，此次疫情中的病毒与以往见过的埃博拉病毒有多大差异？第二，现有诊断方法是否仍能检测出它？第三，现有疗法是否仍能对其提供保护？要回答这些问题，就需要将新基因组与通过 NCBI Virus 和 Pathoplexus（会同步至 NCBI Virus）获取的历史埃博拉基因组进行比对。但这一分析并非易于自动化，其最初几步需要手动点击网页界面、手工复现复杂筛选条件，并指望得到的数据集完整且正确。

这一工作流之所以如此难以自动化，是因为 NCBI Virus 的筛选逻辑很大一部分仅存在于这个网页界面中。这对人类来说很烦人，对智能体来说则极为糟糕。如果研究人员想要 2025 年发布的所有包含表面糖蛋白的 SARS-CoV-2 序列，一位经验丰富的病毒学家在浏览器里点几下就能完成。但从编程角度看，这可能需要一个数百行的脚本，把多个 API（REST、Datasets、E-utilities）拼接在一起，逐页获取结果，协调标识符，并下载数百 GB 的数据，结果在本地筛选后大部分都被丢弃。

即使某个资源提供了 API，智能体仍可能因多种原因难以可靠使用它，例如该 API 未暴露与网页界面相同的筛选语义、元数据字段文档不完善或标准化不一致、标识符在不同来源之间发生变化，或者“正确答案”取决于人类专家熟知但机器必须推断的惯例。

当智能体无论如何都要尝试时会发生什么

为了更好地理解将智能体与数据库对接所面临的挑战，我们设计了一项测试，考察当前最先进的科学研究智能体（Claude、Biomni OSS、Edison Analysis、GPT）在利用现有基础设施从 NCBI Virus 检索病毒序列时的能力。我们的基准测试 VirBench 包含 120 个真实的病毒序列查询，覆盖 40 种病原体，并配有经人工核验的真实结果计数。这些查询反映了病毒监测、诊断检测设计以及蛋白质模型训练数据构建中出现的任务。例如，其中一个查询要求智能体“从 NCBI 检索 TaxID 3052462（Orthoebolavirus zairense（ZEBOV））的病毒序列，且须符合以下条件：宿主生物：人类，样本采集地理位置：非洲，采集日期为 2014 年 1 月 1 日或之后，采集日期为 2014 年 6 月 20 日或之前，最小序列长度：15,200 个碱基，最多 1,900 个模糊字符（N），排除实验室传代样本。”

当让智能体自行解决这些查询时，不同系统的表现差异很大，而在更新的前沿模型中则有显著提升。然而，即便是最强的模型，也未能稳定达到可靠数据集构建所需的准确率和可复现性水平。Claude Sonnet 4、Claude Opus 4.7、Biomni OSS、Edison Analysis、GPT-5.2-pro 和 GPT-5.5⁵ 的平均准确率介于 16.9% 到 91.3% 之间。对于这些数据检索任务，实际标准就是 100%：在某些情况下，一条缺失或错误的记录就可能决定一项诊断检测是否看起来覆盖了流行多样性，或者一次疫情是否被推断为比实际早或晚数周开始。此外，同一个模型在同一个问题被问三次时，往往会产生显著不同的答案，这既损害了可靠科学工作流所需的准确率，也损害了其可复现性。对于上面那个 Ebolavirus 查询示例，Sonnet 4⁶ 在一次运行中返回了 106 条序列（预期：266 条），第二次运行返回 15 条，第三次运行返回 5 条，尽管每次收到的提示词完全相同。

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

NCBI Virus 检索尝试之间的这种可变性，也会影响关于疗法的结论。我们检索了埃博拉病毒糖蛋白序列，以检查 maftivimab 和 MBP134 所结合的表位——这两种抗体疗法是针对扎伊尔型埃博拉病毒开发的，并且是当前埃博拉疫情中 WHO 优先治疗候选方案。我们想弄清，在这些抗体所靶向的区域内，相关扎伊尔型埃博拉病毒序列中此前是否出现过突变。这类分析可以让研究人员判断，随着病毒演化，某种疗法是否仍能继续保护患者。如果底层序列不完整或抓取有误，就可能使他们的结论出现偏差。在我们的示例中，Sonnet 4 检索到的序列在第一次尝试时就接近通过人工 NCBI 查询得到的结果。而在重复运行时，它漏掉了大多数突变残基。到了第三次运行，它又突出显示了另一组残基，从而对这些靶向区域的可变性给出了三种不同的印象。⁷

这两个例子都说明了科学中的一个更普遍的模式：看似只是次要的检索选择，其细节却可能改变生物学结论。在这个案例中，病毒序列检索中不一致的模型表现以及失败模式的性质都凸显出，大部分变异都可归因于基础设施的不足。智能体在未能检索到大型结果集时会少计，而在过滤器被错误应用时会多计。例如，与预期计数偏差最大的情况出现在可用记录数量庞大的病毒上，包括甲型流感、HIV-1 和 SARS-CoV-2，在这些情况下，检索中途停止以及下游过滤错误会大幅扭曲最终数据集。它们还在处理那些含义取决于上下文、惯例或信息恰好存储位置的元数据字段时遇到困难。随着查询变得更加复杂，性能随之下降，尤其是在同时使用超过三到四个过滤器时。

归根结底，这些智能体往往对任务理解得足够好，能够尝试去做，但它们缺乏一种机器可执行的方式来执行、验证并重复这项任务。由此得到的答案可能看起来合理，却仍然是错误的，而这尤其危险，因为序列检索通常只是一个长得多的生物学工作流程中的第一步。

用于病毒数据检索的确定性层

关于 VirBench 和 gget virus 更详尽的说明，请阅读预印本.

为了将病毒数据检索转化为智能体和人类都能直接调用的功能，我们与 NCBI 的研究人员合作开发了 gget virus。起初，这似乎只是连接正确的 API 调用那么简单。但实际上要困难得多：NCBI Virus 是一个建立在多个底层资源之上的门户，包括在美国、欧洲和日本之间维护的国际同步序列数据库，因此回答一个看似简单的查询往往需要从多个地方拼凑信息。

为了复现 NCBI Virus 网页界面的行为，gget virus 必须在其底层的不同系统之间进行协调，包括 REST、Datasets 和 E-utilities API。gget virus会判断哪些过滤器可以通过这些现有 API 应用，哪些必须在本地检查，因为网页界面暴露了一些无法从单一编程端点获得的过滤行为。它处理批处理，以便像 SARS-CoV-2 和 Influenza A 数据集这样的大型结果集能够被完整检索，而不是被任意截断。当过滤依赖于存储在单独数据库中的额外信息时，例如指示某条序列是否包含特定病毒蛋白的 GenBank 记录，gget virus会检索这些记录，用它们来应用过滤器，并在最终输出中保留相关的 GenBank 信息。随后，它返回标准化的输出，既可供人类阅读也可供机器读取，并附带详细日志，展示最终结果是如何产生的。⁸

当我们让智能体接入 gget virus 后，所有智能体的准确率都升至 90% 以上，GPT-5.5 最高达到 99.7%。运行间的波动基本消除，模型之间的性能差距也大幅缩小。换言之，加入一个确定性的检索层后，模型选择变得不那么重要了。这一点尤其关键，因为可靠的数据集构建不应依赖于能否使用最新或最昂贵的模型，也不应依赖于是否知道哪个模型对某个给定数据库效果最好。相反，更便宜的模型搭配合适的工具，就能减少波动并实现更广泛的可用性。

gget virus 将复杂的、基于浏览器的检索工作流转化为一个准确且可复现的接口，从而使现有智能体在病毒数据检索方面更加可靠。回到我们那个可步行城市的类比，这就像我们在步行基础设施下方加了一条公路隧道，配有上下匝道、顺畅通行的立交桥，以及与已知里程标记对应的出口编号。

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

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

当我们考虑到模型能力变化之快时，围绕连接器和 harness 的工作就变得更加棘手。如果我们根据上述结果把模型曲线向前延伸，很容易想象一个（非常近的）未来：像 gget virus 这样的工具所带来的收益趋近于零——智能体变得足够强大，能够自行应对混乱的门户网站、协调标识符、正确分页，并从失败中恢复。在那个世界里，harness 可能不再被需要。尽管如此，即便智能体能够做到，也并不意味着这项任务每次都应该由智能体来处理（并重新发明）。一个能够艰难闯过令人困惑的生物信息学工作流的模型，对于常规科学工作而言，可能仍然过于昂贵、过于缓慢、过于难以审计，或者过于难以信任。而如果智能体最终确实让今天的 harness 变得过时，对生物数据库的教训依然成立：我们在思考用户时，需要始终把智能体放在心上，并且我们需要为规模化而构建。

致谢

我们感谢 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. Biomni 开源版（Biomni OSS）指的是 Biomni 的开源版本（https://github.com/snap-stanford/Biomni，v0.0.8），底层 LLM 为 Claude Sonnet 4。它不代表 Phylo 公司 Biomni Lab 产品的性能。
2. 评估于 2026 年 2 月 26 日进行。由于该任务的性质，Edison Analysis 使用了较旧的备用模型，例如 Claude Sonnet 4，这些模型能够在不会触发生物安全相关访问限制的情况下完成基准测试。因此，Edison Analysis 的结果不应被解读为可与 Opus 4.7 获得的结果直接比较。
3. 关于生物软件为何常常显得碎片化、维护不足且难以使用，更深入的论述可参见 Elliot Hershberg 的文章《生命科学中的软件实际上是如何运作的（以及为何行不通）》。
4. 我们认可并感谢刚果（金）国家生物医学研究所（INRB）和乌干达中央公共卫生实验室（CPHL）的团队，他们在 2026 年 5 月的疫情暴发期间迅速完成了测序、分析，并公开分享了初始 Bundibugyo 病毒基因组。
5. 在 360 次运行中的一次（Query 32，第三次重复），GPT-5.5 在未被明确提示的情况下，自行识别并使用了gget virus。这是该问题唯一一次产生正确答案的运行。
6. Claude Sonnet 4 是可用于本次评估的最新公开可用的 Anthropic 模型，因为后续更新的模型受到了与生物安全相关的访问限制。
7. 此处进行的所有分析仅供说明之用，不旨在提供医疗或公共卫生指导；关于埃博拉病的治疗建议，请参阅世界卫生组织的官方指南。
8. 呼应 Nils Homer 最近就 AI 就绪的生物信息学工具提出的一个观点：“AI 助手需要能够处理你的代码、你的输出以及你的分析逻辑。”这使得智能体不仅能够检查检索到了什么，还能检查是如何检索的，从而将一个看似合理的答案转变为可核查、可复现的结果。