跳转至

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

Ch04.089 Anthropic：生物学Agent的瓶颈不在模型，而在数据基础设施

📊 Level ⭐⭐ | 16.5KB | entities/anthropic-biology-agent-data-infrastructure-virbench.md

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

摘要

Anthropic 于 2026 年 6 月发表科学博客《为生物学智能体铺平道路》（Paving the way for agents in biology），由生物学家兼机器学习研究员 Laura Luebbert 撰写。博客的核心洞察颠覆了业界普遍预期：阻碍生物学 AI Agent 爆发的瓶颈，根本不在于大模型底座的推理能力不够强，而在于人类现有的生物学数据基础设施实在是太落后了。研究团队构建了 VirBench 基准测试，涵盖 120 个真实病毒序列查询任务，结果显示即便最先进的模型（GPT-5.5、Claude Opus 4.7）在原始检索中也仅有 16.9%–91.3% 的准确率，且同一模型重复运行结果波动剧烈。通过开发确定性工具 gget virus 规范数据访问路径后，所有 Agent 准确率均提升至 90% 以上，GPT-5.5 达到 99.7%。这一研究深刻揭示了科学 Agent 领域的一个根本性挑战：在「混乱的老城」式数据基础设施上建造 Agent 系统，每一次都让模型重新发明流程是不可接受的。

核心要点

  1. 生物学 Agent 的瓶颈是数据基础设施，而非模型推理能力：即便 GPT-5.5 和 Claude Opus 4.7 这类顶级模型，在面对混乱的生物数据接口时也表现堪忧
  2. VirBench 基准测试揭示严重不稳定问题：同一个模型在相同提示词下三次运行，埃博拉病毒检索分别返回 106 条、15 条和 5 条序列（标准答案是 266 条）
  3. gget virus 将检索准确率提升至 99.7%：通过确定性工具层屏蔽底层数据源的复杂性，让模型专注推理而非数据访问
  4. Karpathy 的「浏览器点击税」问题在生物学领域更严重：Web 开发中的痛点在生物数据领域被放大数倍
  5. 科学 Agent 需要「无聊但可靠」的底座：创造力和推理留给模型层，稳定性和确定性留给数据访问层

深度分析

1. 生物学 Agent 为什么落后于 Coding Agent

过去两年，Coding Agent 在软件工程领域取得了惊人进展。Claude Code、Cursor 等工具能够自主修复 GitHub issue、编写测试用例、重构代码库，甚至可以多个 Agent 协同完成复杂功能。这些进展让科学界寄予厚望：AI 何时能以同样速度帮助人类攻克药物设计、病毒监控和生物学建模的难题？

然而残酷的现实是，AI 在生物学领域的发展要比编程领域慢得多。Anthropic 的研究指出，这一差距的根源不在于模型能力，而在于两个领域基础设施的本质差异。

软件工程领域的基础设施几乎是为 Agent 天然构建的：Git 提供版本控制，清晰的 API 和包管理器让工具调用可预测，CI/CD 流水线提供自动化验证，代码可以快速编译和测试。当一个 Agent 生成补丁修复 GitHub issue 时，只要补丁通过项目测试，就能立即判断是否有效——这是一种简单、可验证且有意义的奖励信号。

而生物学数据基础设施则完全是另一番景象：各种特有的文件格式（FASTA、GenBank、GFF、BED……）、分散在不同机构的数据库（NCBI、Ensembl、UniProt、EBI……）、一次性的检索脚本、以及充满隐含约定的数据模式。Laura Luebbert 用了一个精准的比喻——让 AI Agent 操作生物数据基础设施，就像开着现代汽车穿过一座在汽车出现前就建好的老城：街道狭窄曲折，缺乏清晰的车道和交通信号，历史悠久的城市规划固然有其用心之处，但现代车辆难以顺畅通行。

2. Karpathy 的「浏览器点击税」与生物学 Agent 的共鸣

几个月前，Karpathy 在一场关于 AI 时代软件开发的演讲中描述了他用 Vibe Coding 写一个小 Web 应用时的体验：代码本身写得很快，但让应用真正跑起来时，身份验证、支付集成、云端部署这些环节花了他整整一周时间在各种后台界面中点击操作。

Karpathy 的感慨是：「代码反而是最容易的部分！大部分工作在浏览器里，靠点击完成。」他由此得出结论：必须为 Agent 重新构建这些流程。

生物学研究人员对 Karpathy 描述的痛点早已感同身受，甚至有过之而无不及。在病毒监测、诊断试剂设计和蛋白模型训练数据构建等场景中，研究人员需要从 NCBI Virus 等数据库中检索特定序列，但这些数据库的网页界面充满了异构信息、隐含约定和需要人工操作的流程。每一个筛选条件都需要用户在网页上手动复现——这就是 Karpathy 所抱怨的「浏览器点击式工作流」在生物学领域的具象化。

以 2026 年 5 月中旬刚果宣告暴发的 Bundibugyo 埃博拉病毒疫情为例：当一线研究人员测序出首批突发疫情的病毒基因组后，全球公共卫生官员需要立即回答三个关键问题：新毒株与历史埃博拉病毒相比变异有多大？现有诊断试剂盒还能准确检测吗？现有抗体药物和疗法是否依然能保护患者？

回答每一个问题都需要从 NCBI Virus 中检索特定条件的病毒序列，但这种检索不是输入几个关键词就能完成的——需要熟悉数据库的筛选逻辑、理解不同字段的含义、手动构建复杂的查询条件。

3. VirBench：系统化评估生物学 Agent 的数据访问能力

研究团队构建的 VirBench 基准测试是这项研究的核心贡献之一。它包含 120 个真实风格的病毒序列查询任务，覆盖 40 种病原体，每个任务都配有人工验证的标准答案。这些任务来自病毒监测、诊断试剂设计、蛋白模型训练数据构建等实际场景，确保了评估的实用性和真实性。

3.1 裸模型的表现：准确率从 16.9% 到 91.3% 不等

当 Agent 独立完成这些查询（没有任何确定性工具辅助）时，不同模型的表现差异巨大：

模型 平均准确率
Claude Sonnet 4 16.9%
Claude Opus 4.7 ~50%（估算）
Biomni 中等
Edison Analysis 中等
GPT-5.2-pro 中等
GPT-5.5 91.3%

即使表现最好的 GPT-5.5，也仍有近 9% 的失败率。更令人震惊的是不稳定性问题——同一个模型在相同提示词下重复运行三次，经常给出差异极大的结果。

以埃博拉病毒查询任务为例，标准答案是 266 条序列，但 Claude Sonnet 4 三次运行分别返回了 106 条、15 条和 5 条。提示词完全相同，模型完全相同，结果却天差地别。

这种不稳定性的后果是致命的。当研究人员用这些不完整的序列数据集构建系统发育树（phylogenetic tree），推断病毒最近共同祖先时间（TMRCA）时，人工整理的完整数据集推断出 2014 年 1 月，与既有研究一致；但 Sonnet 4 检索出的部分数据集因为严重不完整，把共同祖先时间错误地推回到了 1922 年——整整偏差了 92 年。

另一个具体案例涉及抗体疗法研究：研究人员需要检索埃博拉病毒糖蛋白序列，观察 maftivimab 和 MBP134 这两种抗体疗法的靶向区域是否出现过突变。Sonnet 4 三次运行给出了三种截然不同的结论——这种程度的不可靠性在真实科研中是不可接受的。

3.2 不稳定性的根本原因

这种不稳定性的根源不在于模型的推理能力，而在于数据访问层的根本不可预测性。当 Agent 通过自然语言描述向 NCBI Virus 网页发送请求时，它实际上是在模拟一个人类用户在浏览器界面上的操作行为：

  • 数据库的搜索结果可能因服务器状态而异
  • 分页和截断规则可能导致部分结果被遗漏
  • 筛选条件的表达方式可能有多种等价形式，Agent 可能选到表现不佳的那种
  • 数据库的内部状态（如某些字段的更新频率）可能影响检索结果的完整性

Agent 理解了任务，也愿意尝试执行，但它缺少一种机器可操作、可验证、可重复的路径。

4. gget virus：为病毒数据检索构建确定性工具层

研究团队与 NCBI 研究人员合作开发了 gget virus，这是解决上述问题的关键创新。gget virus 的核心思想是在混乱的数据源之上构建一层确定性工具，让 Agent 和人类都可以直接调用。

4.1 设计挑战

构建 gget virus 的工程挑战远超表面看起来的那样。病毒数据检索需要协调多个不同来源的 API： - REST API：提供标准化的数据查询接口 - NCBI Datasets API：提供病毒基因组数据集的批量下载 - E-utilities：NCBI 的底层文献检索工具集

gget virus 需要判断哪些筛选条件可以通过现有 API 完成，哪些必须在本地检查（因为网页界面提供的一些筛选逻辑并没有暴露在单一程序接口中）。它还需要处理批量检索中的分页和截断问题，确保大规模数据集被完整取回而不漏掉任何记录。

最终，gget virus 输出的是人和机器都能读取的标准化结果，并带有详细日志，说明结果是如何产生的——这对于科学研究中的可复现性要求至关重要。

4.2 革命性的效果

加入 gget virus 后，所有 Agent 的准确率都提升到了 90% 以上：

模型 加 gget virus 后准确率
GPT-5.5 99.7%
Claude Opus 4.7 ~95%+
其他模型 90%+

更关键的是，多次运行之间的波动基本消失。之前 Sonnet 4 三次运行给出 106/15/5 条序列的巨大差异，在确定性工具层介入后不再出现。不同模型之间的性能差距也明显缩小——这意味着一个确定性的检索层让模型选择变得不再那么关键。

这一发现具有深远的实践意义：更便宜的模型配合合适的工具，可以达到与顶级模型加混乱接口相当甚至更好的效果。这为更多研究者获得可靠生物学 AI 能力打开了大门。

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

Anthropic 这项研究最重要的启示是：科学 Agent 的架构需要一种根本性的分层设计。

模型层应该负责创造力和推理——生成假设、设计实验、推理机制。模型在这里发挥其强大的模式识别和逻辑推理能力。

基础设施层应该负责稳定性和确定性——基因标识符的规范化、schema 的统一管理、检索逻辑的标准化、坐标系统的转换、元数据约定的遵守、数据访问路径的可靠性。这些「无聊」的工作不需要模型来完成，也不应该让模型每次都重新发明一遍。

gget virus 只是一个具体例子，未来的更大方向是为整个生物数据领域构建「上下文引擎」（Context Engine）——一类可靠、可被 Agent 访问的数据基础设施。类似的探索已经在多个系统中出现：ToolUniverse、Edison Scientific 的 Robin、Biomni 等生物医学 Agent 系统都在朝这个方向努力。

即便 Agent 变得足够强大，能够自己在混乱的门户中穿行，也不意味着每一次都应该让它重新发明一遍流程。对于日常科研工作来说，这种方式仍然可能太贵、太慢、太难审计，也太难让人放心。

Laura Luebbert 在博客结尾提出的原则值得所有科学 Agent 建设者铭记：当我们思考用户是谁时，必须把 Agent 纳入考虑；当我们建设系统时，也必须面向规模化使用来设计。 这意味着未来的科学数据基础设施不仅要服务于人类研究人员，还要原生支持 AI Agent 的规模化访问。

实践启示

  1. 在构建科学 Agent 时，优先投资数据基础设施而非模型选型：在混乱的数据源上使用顶级模型，效果往往不如在干净的数据源上使用普通模型
  2. 为高频科学查询构建确定性工具层：将复杂的网页操作封装为稳定的 API 或命令行工具，让 Agent 从「模拟人类点击」中解放出来
  3. 关注科学 Agent 的可复现性验证：不仅评估模型给出的答案是否正确，还要验证相同条件下能否得到相同结果
  4. 建立生物数据的标准化 schema 和元数据规范：这不仅有助于 Agent 理解数据，也是人类研究者协作效率提升的基础
  5. 在评估 Agent 供应商时，关注其工具生态的成熟度：单独看模型能力是不够的，需要评估其在目标领域是否有完善的工具支撑体系

相关实体