为生物学的 AI Agent 铺平道路

来源: Anthropic Research
发布日期: 2026年6月8日
分类: 科学
作者: Laura Luebbert
研究论文: arXiv:2606.06749
合作者: Ferdous Nasri, Sarah Gurev, Patrick Varilly, Krithik Ramesh, Nuala A. O’Leary, Jonah Cool, Bernhard Y. Renard, Pardis Sabeti 与 Laura Luebbert

在这篇文章中，Laura Luebbert 主张我们需要让生物数据基础设施对 AI Agent 更加友好。作为案例研究，她和她的团队让多个科学研究 Agent（Claude、Biomni 开源版（Biomni OSS）¹、Edison Analysis²、GPT）从 NCBI Virus 中检索序列数据——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-coding 的方式做了一个小型 Web 应用，但当他试图让它真正上线（身份验证、支付、部署）时，他在浏览器仪表板中点来点去浪费了整整一周。

正如他总结的那样："代码是最简单的部分！大部分工作是在浏览器里，点点这点点那。"文档不停地告诉他"去这个 URL，点击这个下拉菜单。"他的结论是：没有人应该做这种事。相反，我们必须为 Agent 而构建。

Karpathy 在软件 Agent 的世界中体验到的东西，正是生物学研究者长期以来一直在挣扎的：试图让智能系统在围绕异构信息、隐式约定和人类点击浏览器的环境中运行的痛苦。

---

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

早在 AI Agent 出现之前，计算生物学家和遗传学家就已经开始为传统计算生物学开发工具，逐步解决这个问题。像 Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget 等软件包以及许多其他工作流库，都是将生物数据从浏览器界面中移出，放到研究人员可以直接进行计算的地方的努力。

问题在于，生物数据并不存放在单一数据库中使用单一接口。它是一个混乱的道路网络，每条路都有自己的标识符、约定、格式、过滤逻辑和不同程度的可编程访问能力。有些数据通过编程方式访问比较直接，其他的则不然。

病毒学尤其是一个更棘手的领域。从疫苗和诊断检测设计到蛋白质模型训练数据构建的研究工作流，通常从 NCBI Virus 检索序列开始——NCBI Virus 是 GenBank、RefSeq 以及包括 Pathoplexus 在内的国际 INSDC 生态系统中的病毒序列记录集合，背后是一个可搜索的 Web 界面。作为构建病毒疫情监测工具的研究人员，我们亲身体会到这些检索背后隐藏了多少专业知识。在病毒学实验室中，NCBI Virus 的数据集策展指令通常以复杂筛选条件的长列表形式在研究者之间传递，用户必须在 Web 界面中手动复现这些条件：这正是 Karpathy 所抱怨的那种浏览器点击式工作流。

当前在刚果民主共和国由 Bundibugyo 病毒引发的埃博拉疫情，就是一个鲜明的例子，说明简化的病毒数据访问可以产生真实的、生死攸关的后果。2026 年 5 月 14 日，刚果（金）金沙萨的 INRB 分析了 13 份血液样本，次日确认其中 8 份为 Bundibugyo 病毒病⁴，随后宣布埃博拉疫情暴发。截至 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 OSS、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 OSS、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 月，改变了疫情的推断时间线。

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

治疗分析

NCBI Virus 检索尝试之间的变异性也会影响关于治疗方法的结论。我们检索了埃博拉病毒糖蛋白序列，以检查 maftivimab 和 MBP134 结合的表位——这些是针对扎伊尔埃博拉病毒开发的抗体治疗药物，也是当前埃博拉疫情中 WHO 优先治疗候选药物。

我们查询了在这些抗体靶向的区域中，相关的扎伊尔埃博拉病毒序列此前是否出现过突变。这种分析可以让研究人员了解随着病毒的进化，治疗方法是否能继续保护患者。如果底层序列不完整或获取错误，结论就会被颠覆。在我们的示例中，Sonnet 4 检索的序列在第一次尝试时接近通过手动 NCBI 查询获得的结果。在重复运行中，它遗漏了大多数突变残基。而在第三次运行中，它高亮了一组不同的残基，对这些靶向区域的变异性产生了三种不同的印象。⁷

扎伊尔埃博拉病毒糖蛋白上已有的突变以红色显示，颜色越深表示突变频率越高。球体表示抗体治疗药物 maftivimab 和 MBP134 的已知结合足迹。最左侧的可视化是从手动策展的 NCBI 数据集构建的，而运行 1–3 是从 Sonnet 4 Agent 使用网络搜索和代码执行工具组装的序列集生成的。显示的 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 放在心上，我们需要为规模化而构建。

---

关键要点

维度	发现
AI Agent 裸跑表现	准确率 16.9%–91.3%，同一模型重复运行结果差异巨大
加入 gget virus 后	准确率全部 >90%，GPT-5.5 达 99.7%
核心洞察	生物数据基础设施需要为 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，他们对本文的观点、框架和写作做出了重大贡献。

---

脚注

---

文章原始链接: https://www.anthropic.com/research/agents-in-biology
下载日期: 2026年6月13日
出和你的分析逻辑。"这使得 Agent 不仅能够检查检索到了什么，还能检查它是如何被检索的，将一个表面合理的答案转化为可以检查和复现的结果。

---

文章原始链接: https://www.anthropic.com/research/agents-in-biology
下载日期: 2026年6月13日

---

1. Biomni 开源版（Biomni OSS）指 Biomni 的开源版本（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 的文章 “How Software in the Life Sciences Actually Works (And Doesn’t Work)”。 ↩︎

4. 我们认可并感谢刚果（金）国家生物医学研究所（INRB）和乌干达中央公共卫生实验室（CPHL）的团队在 2026 年 5 月疫情期间的快速测序、分析以及 Bundibugyo 病毒初始基因组的公开共享。 ↩︎

5. 在 360 次运行中的一次（查询 32，第三次重复），GPT-5.5 在没有被明确提示的情况下，自主识别并使用了 gget virus。这是该问题唯一产生正确答案的运行。 ↩︎

6. Claude Sonnet 4 代表可用于此评估的最新公开可用 Anthropic 模型，因为后续较新的模型受到了生物安全相关的访问限制。 ↩︎

7. 本文中的所有分析仅供说明目的，不构成医疗或公共卫生指导；关于埃博拉疾病的治疗建议，请参考 WHO 官方指南。 ↩︎

8. 呼应 Nils Homer 最近关于 AI 就绪生信工具的观点："AI 助手需要能够处理你的代码、你的输出和你的分析逻辑。"这使得 Agent 不仅能够检查检索到了什么，还能检查它是如何被检索的，将一个表面合理的答案转化为可以检查和复现的结果。 ↩︎