Anthropic最新博客：生物学Agent的瓶颈不在模型，而在数据基础设施

📋 背景

当前，Coding Agents 在软件工程领域一路高歌猛进，科学家们看到此场景，也不禁寄予厚望：AI 智能体何时能以同样的速度，帮人类攻克药物设计、病毒监控与生物学建模的重重难关？

然而，一个残酷的现实是，AI 在生物学领域的发展要比编程领域慢得多……

近日，Anthropic 发表了一篇新科学博客 ——《为生物学智能体铺平道路》（Paving the way for agents in biology），文章指出：阻碍生物学 AI Agent 爆发的瓶颈，根本不在于大模型底座的推理能力不够强，而在于人类现有的生物学数据基础设施实在是太落后了。

🔍 详细内容

因此，如果希望 AI Agent 真正参与生物学研究，生物数据基础设施必须变得更适合 Agent 使用。

这篇文章由 Laura Luebbert 撰写，她是一位生物学家与机器学习研究员。

有意思的是，Laura Luebbert 透露，这篇博客是在 Karpathy 官宣加入 Anthropic 之前一周就完成的，因为文中部分内容涉及 Karpathy ，还担心 Anthropic 会不会觉得这篇「Karpathy 味」太重。没想到的是，就在她把初稿发给 Anthropic 的同一天，他们就官宣了……

下面，我们就来详细看一下，这篇文章是如何分析的？

作者用了一个很有意思的类比，让 AI Agent 去操作生物数据基础设施，有点像开车穿过一座在汽车出现前就建好的老城：这座城市也许很美，规划也有其用心之处，但里面到处是狭窄、曲折的街道，现代车辆难以顺畅通行。对应到生物数据领域，就是各种特有的文件格式、分散的数据库，以及一次性的检索脚本。

当然，你也可以试着给这座城市补上交通标志、停车场，甚至偶尔拓宽几条道路，但它最基本的布局仍然难以通行，原因在于它原本就是为另一种交通方式设计的。

相比之下，软件基础设施几乎天然就适合「汽车」，也就是 Agent 使用：铺好的道路、清晰的车道、标准化信号，以及支持从起点到终点快速通行的系统，也就是版本控制、文档清晰的 API 和包管理器。

因此，Coding Agent 的发展速度明显快于生物学 Agent。

软件领域通常具备结构化的数字工作流和可靠接口，而计算生物学中用于数据检索和验证的基础设施，往往脆弱、异构，并且高度依赖具体流程。对应的，用来操作这些基础设施的工具，也就不得不变得定制化，并且只适用于特定领域或特定假设。

此外，软件可以给出容易测试的结果，并能快速编译和验证。例如，一个 Agent 可以通过生成补丁来解决 GitHub issue，只要补丁通过项目测试，就能判断是否有效。但在生物学中，这种简单、可验证、同时又有意义的奖励信号并不多。

所以，生物学 Agent 的瓶颈不只在推理能力，也在于缺少一种广泛可用的确定性执行层，来支持对生物数据的查询。科学家可以很自然地表达自己的意图，比如「找到所有带有这个结构域的人类激酶，并拉取它们的结构」。但 Agent 往往缺少一条可靠路径，去访问那些包含所需信息的数据库。

在生物学和科学工作流中，即使很小的错误，也可能带来严重后果。比如，从错误的基因组版本中提取坐标，可能会让后续的生物学解释失效；无意中混用 RefSeq 和 GenBank 记录、把部分基因组当作完整基因组、混淆分节病毒的片段名称，或者因为元数据字段不一致而漏掉相关记录，也都可能造成同样的问题。

科研的美感和难点正在于此：细节往往极其关键。

因此，如果希望 Agent 真正帮助科学发现，就需要对生物数据基础设施进行建设。

作者认为，Agent 的需求与人类构建的工具之间存在错配，并不是生物学领域独有，只要把 Agent 放进那些完全围绕人类使用习惯设计的环境里，类似的摩擦就会出现。

几个月前，Karpathy 在一场关于 AI 时代软件开发的演讲时吐槽，他用 Vibe Coding 写了一个小型 Web 应用，但让它真正跑起来时，身份验证、支付、部署这些环节，让他花了一周时间在浏览器后台到处点击。

为此，Karpathy 感慨：「代码反而是最容易的部分！大部分工作都在浏览器里，靠点击完成。」麻烦的是「打开这个 URL，点击这个下拉菜单。」

结论是：我们必须为 Agent 重新构建这些流程。

这正是生物学研究人员早已长期面对的痛点：我们试图让智能系统在一套为人类点击浏览器而设计的环境中工作，而这个环境充满了异构信息、隐含约定和各种需要人工操作的流程。

早在 AI Agent 出现之前，计算生物学家和遗传学家就已经开始开发传统计算生物学工具，试图缓解这个问题。Biopython、BioPerl、BioJulia、Entrez Direct、BioMart、gget 以及许多其他工作流库，都是为了把生物数据从浏览器界面中解放出来，让研究人员可以直接对这些数据进行计算。

但问题在于，生物数据并不存放在统一数据库，也没有统一接口，更像一张混乱的道路网络：每条路都有自己的标识符、约定、格式、筛选逻辑和程序访问能力。有些数据可以很方便地通过程序调用，有些则困难得多。

病毒学则是难度较高的场景之一。从疫苗设计、诊断试剂开发，到为蛋白模型构建训练数据，很多研究工作流的第一步，都是从 NCBI Virus 中检索序列。NCBI Virus 是一个病毒序列记录集合，汇集了来自 GenBank、RefSeq 和国际 INSDC 生态系统的数据，其中也包括 Pathoplexus，并通过一个可搜索的网页界面提供访问。

参与病毒疫情监测工具建设的研究人员非常清楚，这些检索流程背后隐藏着多少专家知识。在病毒学实验室里，围绕 NCBI Virus 的数据集整理说明，常常是以一长串复杂筛选条件的形式流传。用户必须在网页界面中手动复现这些条件。

而这正是 Karpathy 所抱怨的那类「浏览器点击式工作流」。

文章以 2026 年 5 月中旬刚果宣告暴发的 Bundibugyo 埃博拉病毒疫情为例，说明了这一情况。

当一线研究人员测序出首批突发疫情的病毒基因组后，全球公共卫生官员需要立即回答三个迫在眉睫的问题：

而要回答这些问题，分析的第一步必须是前往 NCBI Virus 数据库，将新基因组与历史数据进行比对。

然而，在病毒学实验室里，构建这种对照数据集的过滤条件非常复杂，往往作为长长的列表由科学家之间人肉传递。研究人员必须在复杂的 Web 界面中手动勾选数十个过滤器。对于人类来说这异常枯燥，而对于旨在通过自动化提升效率的 AI Agent 来说，简直是一场灾难……

作者表示为了理解 Agent 和数据库之间的鸿沟，研究团队构建了一个基准测试 VirBench，包含 120 个真实风格的病毒序列查询任务，覆盖 40 种病原体，并配有人工验证的标准答案。任务来自病毒监测、诊断试剂设计、蛋白模型训练数据构建等实际场景。

比如其中一个任务要求 Agent 从 NCBI 检索 TaxID 3052462 对应的 Zaire ebolavirus 序列，并满足一系列条件：宿主是人类，采样地点在非洲，采样时间在 2014 年 1 月 1 日到 2014 年 6 月 20 日之间，序列长度至少 15200 个碱基，模糊字符 N 不超过 1900 个，并排除实验室传代样本。

当 Agent 独立完成这些查询时，结果差异很大。

Claude Sonnet 4、Claude Opus 4.7、Biomni、Edison Analysis、GPT-5.2-pro、GPT-5.5 的平均准确率从 16.9% 到 91.3% 不等。也就是说，前沿模型表现更好，但即便如此，也没有稳定达到可靠数据集构建所需的准确性和可复现性。

对这类任务来说，标准几乎必须接近 100%。因为漏掉或多拿一条记录，就可能影响诊断试剂是否覆盖当前流行病毒多样性，或者影响对疫情起点的判断。更麻烦的是，同一个模型在相同问题上重复运行三次，经常会给出差异很大的结果。

在上面的埃博拉病毒查询任务中，标准答案是 266 条序列，但 Claude Sonnet 4 三次运行分别返回了 106 条、15 条和 5 条。提示词完全相同，结果却高度不稳定。

这种不稳定会直接影响下游分析。研究团队用这些序列构建系统发育树，用来推断疫情中不同病毒样本之间的关系。其中一个重要指标是最近共同祖先时间，也就是 TMRCA。人工整理的数据集推断出的时间是 2014 年 1 月，和既有研究一致；但 Sonnet 4 检索出的部分数据集明显不完整，甚至有一次把共同祖先时间推回到 1922 年。

另一个例子涉及抗体疗法。研究人员检索埃博拉病毒糖蛋白序列，观察 maftivimab 和 MBP134 这类抗体药物靶向区域是否出现过突变。

结果显示，Sonnet 4 三次运行给出了三种不同印象：第一次接近人工查询结果，第二次漏掉大部分突变位点，第三次又强调了一组不同残基。

这说明，在科学研究中，看似只是检索细节的小差异，可能改变生物学结论。Agent 往往理解了任务，也愿意尝试执行，但缺少一种机器可操作、可验证、可重复的路径。最终答案可能看起来很合理，却是错的。

而这尤其危险，因为序列检索通常是更长时间生物工作流程的第一步……

💡 分析与影响

为了解决这个问题，研究团队和 NCBI 研究人员合作开发了 gget virus，目标是把病毒数据检索变成 Agent 和人类都可以直接调用的稳定工具。

一开始，这似乎只是把几个 API 接起来，但实际情况复杂得多。NCBI Virus 是一个覆盖多个底层资源的门户，这些资源又分布在多个国家维护的国际同步序列数据库中。一个看似简单的查询，往往需要从多个地方拼接信息。

为了复现 NCBI Virus 网页界面的行为，gget virus 需要协调 REST、Datasets、E-utilities 等不同 API，它会判断哪些筛选条件可以通过现有 API 完成，哪些必须在本地检查，因为网页界面提供的一些筛选逻辑，并没有暴露在单一程序接口中。

它还会处理批量检索，确保 SARS-CoV-2、甲型流感这类大规模数据集被完整取回，而不会因为分页或中途截断而漏掉记录。如果筛选条件依赖另一个数据库里的补充信息，比如 GenBank 记录中某个序列是否包含特定病毒蛋白，gget virus 会取回这些记录，用它们完成过滤，并把相关 GenBank 信息保存在最终输出中。

最终，gget virus 输出的是人和机器都能读取的标准化结果，并带有详细日志，说明结果是如何产生的。这样一来，Agent 给出的答案不再只是「看起来合理」，而是可以检查、复现和审计。

加入 gget virus 后，所有 Agent 的准确率都提升到了 90% 以上，GPT-5.5 最高达到 99.7%。多次运行之间的波动也基本消失，不同模型之间的性能差距明显缩小。也就是说，一个确定性的检索层，让模型选择变得没有那么关键。

这一点很重要。可靠的数据集构建不应该依赖最新、最贵的模型，也不应该依赖研究人员知道哪个模型最适合哪个数据库。更便宜的模型加上合适工具，也可以减少不稳定性，让更多人获得可靠能力。

在文章的最后，作者强调，模型在生成假设、设计实验、推理机制时应该有创造力，但支撑这些创造力的底层部分，比如基因标识符、schema、检索逻辑、坐标系统、元数据约定、数据访问路径，必须足够稳定、确定、可复现。

gget virus 只是一个例子，未来更大的方向，是为生物数据构建一类「上下文引擎」：可靠、可被 Agent 访问的数据基础设施。类似探索也已经出现在 ToolUniverse、Edison Scientific 的 Robin、Biomni 以及其他生物医学 Agent 系统中。

当然，作者也承认，如果沿着上面实验结果所呈现出的模型能力曲线继续往前推，可以想象，在不远的未来，像gget virus这类工具可能会显得「没那么必要」：Agent 变得足够强，能够自己穿过混乱的门户网站、协调不同标识符、正确处理分页，并从失败中恢复过来……到了那个时候，工具框架也许就不再是必需品。

但即便 Agent 能够做到，也不意味着每一次都应该让它来处理，并且重新发明一遍流程。一个模型也许可以硬闯复杂混乱的生物信息学工作流，但对于日常科研工作来说，这种方式仍然可能太贵、太慢、太难审计，也太难让人放心。

而且，即便未来 Agent 真的让今天这些工具框架变得过时，这个教训对生物数据库依然成立：当我们思考用户是谁时，必须把 Agent 纳入考虑；当我们建设系统时，也必须面向规模化使用来设计……

https://x.com/AnthropicAI/status/2064054837294354677

https://www.anthropic.com/research/agents-in-biology

https://x.com/NeuroLuebbert/status/2064055392016212080

游侠云AI普通

收藏 链接