当前，编程智能体（Coding Agents）在软件工程领域正迅猛发展。科学家们目睹这一景象，自然满怀期待：AI智能体何时能以同样的速度，助力人类攻克药物设计、病毒监控与生物学建模等重大挑战？
然而，一个残酷的现实是，AI在生物学领域的发展步伐，远落后于编程领域。
近日，Anthropic发布了一篇新博客——《为生物学智能体铺平道路》（Paving the way for agents in biology）。文章的核心观点十分明确：制约生物学AI Agent爆发式增长的根本瓶颈，并非大模型底座的推理能力不足，而是人类现有的生物学数据基础设施过于陈旧和落后。
结论直截了当：若希望AI Agent真正参与生物学研究，生物数据基础设施必须进行一场彻底的变革，使其更契合Agent的使用需求。
这篇文章出自Laura Luebbert之手，她是一位兼具生物学家与机器学习研究员双重身份的作者。有趣的是，Laura透露，这篇博客是在Karpathy官宣加入Anthropic之前一周完成的。由于文中部分内容涉及Karpathy，她一度担心Anthropic是否会认为这篇博客“Karpathy味儿”太重。结果，就在她把初稿发给公司的同一天，那边就官宣了人事变动……
那么，这篇文章究竟提出了哪些关键分析？我们逐一来看。
现有生物数据基础设施，对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埃博拉病毒疫情为例，清晰地说明了这一情况。
当一线研究人员测序出首批突发疫情的病毒基因组后，全球公共卫生官员需要立即回答三个迫在眉睫的问题：
- 这种新毒株与历史上的埃博拉病毒相比，变异有多大？
- 现有的诊断试剂盒还能准确将其检测出来吗？
- 现有的抗体药物和疗法是否依然能保护患者？
而要回答这些问题，分析的第一步，必须是前往NCBI Virus数据库，将新基因组与历史数据进行比对。
然而，在病毒学实验室里，构建这种对照数据集的过滤条件非常复杂，往往作为长长的列表由科学家之间人肉传递。研究人员必须在复杂的Web界面中手动勾选数十个过滤器。对于人类来说，这异常枯燥；而对于旨在通过自动化提升效率的AI Agent来说，简直是一场灾难……
Agent自己尝试检索，会发生什么？
为了理解Agent和数据库之间的鸿沟，研究团队构建了一个基准测试VirBench，包含120个真实风格的病毒序列查询任务，覆盖40种病原体，并配有人工验证的标准答案。任务来自病毒监测、诊断试剂设计、蛋白模型训练数据构建等实际场景。
其中一个任务要求Agent从NCBI检索TaxID 3052462对应的Zaire ebola virus序列，并满足一系列条件：宿主是人类，采样地点在非洲，采样时间在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