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

本文来自微信公众号： 机器之心 ，作者：关注AI的

当前，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的同一天，他们就官宣了……

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

现有生物数据基础设施，对Agent来说太难走了

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

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

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

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

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

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

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

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

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

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

Karpathy关于Web开发的「吐槽」，和生物学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埃博拉病毒疫情为例，说明了这一情况。

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

1. 这种新毒株与历史上的埃博拉病毒相比，变异有多大？

   
   

2. 现有的诊断试剂盒还能准确把它检测出来吗？

   
   

3. 现有的抗体药物和疗法是否依然能保护患者？

   
   

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

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

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往往理解了任务，也愿意尝试执行，但缺少一种机器可操作、可验证、可重复的路径。最终答案可能看起来很合理，却是错的。

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

gget virus：给病毒数据检索加一层确定性工具

为了解决这个问题，研究团队和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%。多次运行之间的波动也基本消失，不同模型之间的性能差距明显缩小。也就是说，一个确定性的检索层，让模型选择变得没有那么关键。

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

真正的启示：科学Agent需要「无聊但可靠」的底座

在文章的最后，作者强调，模型在生成假设、设计实验、推理机制时应该有创造力，但支撑这些创造力的底层部分，比如基因标识符、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