作者：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 认为，我们需要让生物数据基础设施对 AI 智能体更加友好。作为案例研究，她和团队让科学研究智能体（Claude、Biomni Open Source (Biomni OSS)¹、Edison Analysis²、GPT）从 NCBI Virus 数据库中检索序列数据，该数据库是病毒学家用于监测和诊断检测开发等任务的工具。即使是最强的模型，也无法始终达到构建可靠数据集所需的精度水平。但一旦她和团队添加了确定性检索层 gget virus，准确率便提升至接近 100%。对于科学智能体而言，更广泛的启示是：确定性检索工具（目前）对于提高智能体工作流的可靠性至关重要，而生物数据库在设计时也需要将智能体作为规模化用户纳入考量。使用 AI 智能体来驾驭生物数据基础设施，就像驾驶汽车穿行于一座在汽车发明之前设计的古老城市：基础设施可能精美且富有巧思，但到处是狭窄蜿蜒的街道，现代车辆难以通行（例如特异的文件格式、分散的数据库、一次性的检索脚本）³。你可以通过增设交通标志、停车场，偶尔拓宽道路来改造这座城市，但其基本布局仍然难以通行，因为它原本是为不同的交通方式设计的。相比之下，软件基础设施基本上是为汽车（智能体）的需求而造的：铺装道路、清晰的车道、标准化的信号，以及为从起点到终点快速通行而设计的系统（版本控制、文档完善的 API 和包管理器）。
因此，编码智能体的发展速度远快于生物智能体。软件通常提供结构化的数字工作流程和可靠的接口，而计算生物学中用于数据检索和验证的基础设施往往脆弱、异构且依赖于具体流程。我们用来驾驭这些工具的方法必然是定制化的，并针对特定领域或假设进行了调整。此外，软件能提供可测试的输出，这些输出可以快速编译和验证（例如，通过生成一个能通过项目测试的补丁来解决 GitHub 问题），而生物学领域则很少有简单、可验证且有意义的奖励机制。
因此，生物智能体的瓶颈不仅在于推理能力，还在于缺乏广泛存在的、用于查询生物数据的确定性执行层。科学家可以表达其意图（例如，找到所有具有此结构域的人类激酶并提取它们的结构），但智能体往往缺乏可靠的方法来访问包含所需信息的数据库。
在生物学和科学工作流程中，即使是微小的错误也可能导致严重后果。例如，从错误的基因组版本中检索坐标，可能会使后续的生物学解释失效。无意中混合使用 RefSeq 和 GenBank 记录、将部分基因组视为完整基因组、混淆分段病毒的片段名称、或因元数据字段不一致而遗漏相关记录，都会产生同样的问题。研究的魅力与挑战在于，细节往往至关重要。
就像驾车穿行于意大利的山城小镇，如果街道过于狭窄、弯道过于急转，并且路线依赖于当地知识，那么汽车马力再大也无济于事。如果我们希望智能体能够协助科学发现——从疫情应对到药物设计，再到生物建模——我们就需要构建它们能够像人类一样可靠地驾驭的生物数据基础设施。
Karpathy 关于 Web 开发的讲座，对于使用 AI 智能体进行生物学研究有何启示
智能体需求与人类构建工具之间的这种不匹配并非生物学领域独有。只要智能体被投放到专为人类使用而设计的环境中，同样的摩擦就会显现。
几个月前，安德烈·卡帕西在一次关于人工智能时代软件的演讲中，抱怨了一件听起来再熟悉不过的事。他用“氛围编程”方式写了一个小型网页应用，但当他试图将其落地（添加身份验证、支付、部署功能）时，却在浏览器仪表盘里点来点去，浪费了一周时间。
正如他所总结的：“代码反而是最简单的部分！大部分工作都在浏览器里，到处点击。”文档总是告诉他“前往这个网址，点击这个下拉菜单”。他的结论是，没有人应该忍受这种事。相反，我们必须为智能体构建环境。
卡帕西在软件智能体领域体验到了一种新现象，而生物学研究人员早已为此挣扎许久：试图让智能系统在充斥着异构信息、隐性约定以及人类通过浏览器点击操作的环境中运行所带来的痛苦。
案例研究：病毒学中的“点击税”
早在AI智能体出现之前，计算生物学家和遗传学家就已经开始开发传统计算生物学工具，逐步攻克这个问题。诸如Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget以及许多其他工作流库，都是致力于将生物数据从浏览器界面中解放出来，转移到研究人员可以直接进行计算的场所。
问题在于，生物数据并不存在于一个拥有单一接口的单一数据库中。它是一张错综复杂的道路网络，每条路都有自己的标识符、惯例、格式、过滤逻辑以及程序化访问程度。有些数据可以轻松通过程序访问，而另一些则没那么容易。
病毒学尤其是一个难度较高的领域。从疫苗和诊断检测方法设计，到为蛋白质模型构建训练数据，研究工作流程通常始于从 NCBI Virus 检索序列。NCBI Virus 是一个通过可搜索网页界面访问的病毒序列记录集合，其数据来自 GenBank、RefSeq、国际 INSDC 生态系统（包括 Pathoplexus）。作为为病毒暴发监测构建工具的研究人员，我们深知这些检索背后隐藏着多少专业知识。在病毒学实验室中，针对 NCBI Virus 的数据集整理说明通常以一长串复杂过滤器的形式流传，用户必须在网页界面中手动重现这些操作——这正是 Karpathy 所抱怨的那种浏览器点击工作流程。
当前刚果民主共和国由本迪布焦病毒引起的埃博拉疫情暴发，是一个鲜明的例子，说明简化的病毒数据访问为何能产生关乎生死的现实影响。2026 年 5 月 14 日，刚果民主共和国金沙萨国家生物医学研究所分析了 13 份血液样本，并于次日确认其中 8 份为本迪布焦病毒病阳性，随后宣布埃博拉疫情暴发。到 5 月 29 日，世界卫生组织报告刚果民主共和国境内已出现超过 1000 例确诊和疑似病例，其中包括 200 多例死亡。研究人员还生成了首批近乎完整的疫情基因组序列，有助于确定此次疫情是由一次新的跨物种传播事件引起的。
这些基因组序列给公共卫生官员带来了三个紧迫问题。第一，此次疫情病毒与以往见过的埃博拉病毒有多大差异？第二，现有的诊断检测方法是否仍能检测出该病毒？第三，现有的治疗方法是否仍能有效应对？要回答这些问题，需要将新基因组序列与通过 NCBI Virus 和 Pathoplexus（其数据会同步至 NCBI Virus）获取的历史埃博拉基因组序列进行比对。然而，这一分析的第一步并非易于自动化，而是需要手动点击网页界面，手工重现复杂的过滤器，并期望最终得到的数据集完整且正确。
这个工作流之所以难以自动化，很大程度上是因为 NCBI Virus 的许多过滤逻辑只存在于这个网页界面中。这对人类来说很烦人，对 AI 智能体来说更是糟糕透顶。如果研究人员想要获取 2025 年发布的所有包含表面糖蛋白的 SARS-CoV-2 序列，一位经验丰富的病毒学家在浏览器里可能只需点击几下。但通过编程方式实现，则需要编写一个数百行的脚本，将多个 API（REST、Datasets、E-utilities）拼接在一起，逐页检索结果，比对标识符，并下载数百 GB 的数据，最后在本地过滤后丢弃其中大部分。
即使某个资源提供了 API，由于多种原因，AI 智能体仍然难以可靠地使用它，例如：API 没有暴露与网页界面相同的过滤语义；元数据字段文档不完善或标准化不一致；不同来源的标识符会发生变化；或者“正确答案”依赖于人类专家知晓但机器需要推断的惯例。
当 AI 智能体执意尝试时会发生什么
为了更好地理解将 AI 智能体与数据库连接起来的挑战，我们开发了一项测试，用于评估当前最先进的科学研究 AI 智能体（Claude、Biomni OSS、Edison Analysis、GPT）在利用现有基础设施从 NCBI Virus 检索病毒序列时的能力。我们的基准测试 VirBench 包含 120 个真实的病毒序列查询，涵盖 40 种病原体，并附有人工验证的真实数据计数。这些查询反映了病毒监测、诊断检测设计以及蛋白质模型训练数据构建中出现的任务。例如，一个查询要求 AI 智能体“从 NCBI 检索 TaxID 3052462（扎伊尔型埃博拉病毒（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.55 的平均准确率在 16.9% 到 91.3% 之间。对于这些数据检索任务而言，标准实际上是 100%：在某些情况下，一条缺失或错误的记录可能决定一项诊断检测是否覆盖了循环多样性，或者一次疫情暴发被推断为比实际早几周或晚几周开始。此外，当同一个模型被三次询问同一个问题时，它往往给出截然不同的答案，这损害了可靠科学工作流程所需的准确性和可复现性。以上述埃博拉病毒查询为例，Sonnet 46 在一次运行中返回了 106 条序列（预期为 266 条），第二次运行返回了 15 条，第三次运行返回了 5 条，尽管每次收到的提示词完全相同。
诸如此类的不一致会对下游分析产生影响。我们使用上述查询来检索埃博拉病毒序列并构建系统发育树，这是一种分析病毒样本在疫情期间如何关联的标准方法。从系统发育树中，我们可以获得一个重要的量值，即最近共同祖先时间（TMRCA）。这是推断出的疫情起始日期，它可能改变关于病毒起源时间与地点，以及病毒传播时长的结论。在本案例中，基于手动整理的 NCBI Virus 序列集构建的树，得出的 TMRCA 为 2014 年 1 月，这与先前关于 2014 年埃博拉病毒疫情的报告一致（95% 最高后验密度区间为 1 月 27 日至 3 月 14 日）。相比之下，Sonnet 4 检索到的三个序列集中有两个明显不完整，其中一个树将推断的 TMRCA 推后至 1922 年。剩余的数据集（运行 1）表面上看似合理，但未能检索到来自几内亚的序列，并将估计的 TMRCA 移至 2014 年 4 月，从而改变了推断的疫情时间。
NCBI Virus 检索尝试之间的变异性也会影响关于治疗方法的结论。我们检索了埃博拉病毒糖蛋白序列，以检查由马夫替单抗和 MBP134 所结合的抗原表位，这两种抗体疗法是针对扎伊尔埃博拉病毒开发的，并且是当前埃博拉病毒疫情中世界卫生组织的优先治疗候选方案。我们探究了在这些抗体所靶向的区域中，相关的扎伊尔埃博拉病毒序列此前是否出现过突变。这类分析可以让研究人员了解，随着病毒的进化，某种治疗方法是否仍能继续保护患者。如果底层序列不完整或提取有误，则可能推翻他们的结论。在我们的示例中，Sonnet 4 首次检索到的序列与通过手动 NCBI 查询获得的结果非常接近。在重复运行时，它遗漏了大部分突变残基。而在第三次运行时，它又突出了另一组不同的残基，从而对这些靶向区域的变异性给出了三种不同的印象。
这两个例子都揭示了科学领域的一个普遍模式：看似微小的检索选择细节，可能会改变生物学结论。在本案例中，病毒序列检索中模型表现的不一致性以及故障模式的本质表明，大部分差异源于基础设施的缺陷。当智能体未能检索到大型结果集时，它们会少计数；而当过滤器应用不当时，它们会多计数。例如，与预期计数偏差最大的情况出现在拥有大量可用记录的病毒上，包括甲型流感病毒、HIV-1 和 SARS-CoV-2，在这些情况下，检索中途停止以及后续过滤不当会严重扭曲最终数据集。它们还在处理元数据字段时遇到困难，这些字段的含义取决于上下文、惯例或信息恰好存储的位置。随着查询变得愈发复杂，尤其是同时使用三个或四个以上过滤器时，性能会下降。
最终，这些智能体通常能够理解任务并尝试执行，但它们缺乏一种机器可操作的方式来执行、验证和重复该任务。由此得出的答案可能看似合理，但实际上是错误的，这尤其危险，因为序列检索通常是更长的生物学工作流程中的第一步。
用于病毒数据检索的确定性层
如需更详细地了解 VirBench 和 gget virus，请阅读预印本。
为了让智能体和人类能够直接调用病毒数据检索功能，我们与美国国家生物技术信息中心（NCBI）的研究人员合作开发了 gget virus。起初，这似乎只是连接正确 API 调用的问题。但实际上，这要困难得多：NCBI Virus 是一个整合了多个底层资源的门户，包括由美国、欧洲和日本共同维护的国际同步序列数据库，因此，回答一个看似简单的查询往往需要将来自多个来源的信息拼凑起来。
为了复现 NCBI 病毒网页界面的行为，gget virus 需要协调其底层的多个不同系统，包括 REST、Datasets 和 E-utilities 等 API。gget virus 会判断哪些筛选条件可以通过这些现有 API 应用，哪些则必须在本地检查，因为网页界面所暴露的筛选行为无法通过单一的程序化端点实现。它还负责处理批量操作，以便全面检索大型结果集（例如 SARS-CoV-2 和甲型流感数据集），而不是随意截断。当筛选依赖于存储在独立数据库中的额外信息时（例如 GenBank 记录中表明某序列是否包含特定病毒蛋白的信息），gget virus 会检索这些记录，利用它们来应用筛选条件，并在最终输出中保留相关的 GenBank 信息。随后，它会返回标准化输出，这些输出既可供人类阅读，也可供机器读取，并附带详细的日志，说明最终结果是如何生成的。8
当我们让智能体使用 gget virus 后，所有智能体的准确率都提升至 90% 以上，其中 GPT-5.5 的准确率最高，达到了 99.7%。运行结果之间的差异基本消除，不同模型之间的性能差距也显著缩小。换句话说，增加一个确定性的检索层，使得模型选择变得不那么重要了。这一点意义重大，因为可靠的数据集构建不应依赖于能否使用最新或最昂贵的模型，也不应依赖于了解哪个模型对特定数据库效果最好。相反，将更便宜的模型与合适的工具相结合，可以减少结果差异，并让更多人能够使用。
gget virus 通过将复杂的、基于浏览器的检索工作流转化为精确且可复现的接口，使现有智能体在病毒数据检索方面更加可靠。回到我们之前关于步行友好城市的类比，这就像我们在人行基础设施下方修建了一条高速公路隧道，配备了完整的出入口匝道、顺畅的立交桥，以及以已知里程标志为参照的出口编号。
正如 Karpathy 所说：“让[基因组数据]对智能体可访问”
我们希望模型在生成假设、设计实验或推理机制时具有创造性。但创造性之下的那一层——基因标识符、模式、检索逻辑、坐标系统、元数据约定以及数据访问路径——必须做到枯燥的可靠（或者说，确定性）。gget virus 是构建这些上下文引擎的更广泛努力中的一个例子：为生物数据提供可靠、可供智能体访问的基础设施。其他努力来自人工智能驱动科学系统，其中许多依赖于将智能体连接到生物数据源的模型框架，包括 ToolUniverse、Edison Scientific 的 Robin、Biomni 以及相关的生物医学智能体。挑战在于弄清楚这种确定性应该存在于何处，以及如何构建它。
当我们考虑到模型能力变化之快时，连接器和工具链（harness）的工作就变得更加棘手。如果我们根据上述结果将模型能力曲线向前延伸，很容易想象一个（非常近的）未来，届时像 gget virus 这类工具的优势将趋近于零：智能体将变得足够强大，能够自行导航混乱的接口、协调标识符、正确分页，并从故障中恢复。在那个世界里，工具链或许就不再需要了。不过，即使智能体能够做到，也不意味着每次任务都应该由智能体来处理（并重新发明轮子）。一个能够艰难穿越混乱生物信息学工作流的模型，对于常规科研工作而言，可能仍然过于昂贵、过于缓慢、难以审计，或难以信任。而如果智能体最终真的让今天的工具链过时，那么对生物数据库的启示依然成立：我们在思考用户时，必须将智能体纳入考量，并且要为规模化而构建。
致谢
我们感谢 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 对本文观点、框架和写作所做出的重大贡献。
脚注
- Biomni 开源版（Biomni OSS）指的是 Biomni 的开源版本（https://github.com/snap-stanford/Biomni, v0.0.8），其底层大语言模型为 Claude Sonnet 4。该版本并不反映 Phylo 公司 Biomni Lab 产品的性能。
- 评估于 2026 年 2 月 26 日。由于任务性质，Edison Analysis 使用了较旧的备用模型，例如 Claude Sonnet 4，这些模型能够完成基准测试而不会触发生物安全相关的访问限制。因此，Edison Analysis 的结果不应被解读为与 Opus 4.7 获得的结果直接可比。
- 关于生物软件为何常常显得零散、维护不足且难以使用的更深入阐述，请参阅 Elliot Hershberg 的文章《生命科学中的软件实际如何运作（以及为何不奏效）》。
- 我们感谢并认可刚果民主共和国国家生物医学研究所（INRB）和乌干达中央公共卫生实验室（CPHL）的团队，他们在 2026 年 5 月疫情暴发期间，对最初的布迪布焦病毒基因组进行了快速测序、分析并开放共享。
- 在 360 次运行中的一次（查询 32，第三次重复），GPT-5.5 独立识别并使用了 gget virus，尽管并未被明确提示这样做。这是该问题唯一一次得出正确答案的运行。
- Claude Sonnet 4 代表了 Anthropic 最新公开可用的、可用于此评估的模型，原因是后续对较新模型实施了生物安全相关的访问限制。
- 此处执行的所有分析仅供说明之用，不旨在提供医疗或公共卫生指导；关于埃博拉疾病的治疗建议，请参考世界卫生组织的官方指南。
- 借用 Nils Homer 最近关于 AI 就绪生物信息学工具的观点：“AI 助手需要能够处理你的代码、你的输出以及你的分析逻辑。”这使得智能体不仅能够检查检索到了什么，还能检查是如何检索到的，从而将一个看似合理的答案转变为可核查和可复现的结果。