Claude误算病毒起源90年全因网页信息

最强模型，栽在了最不该栽的地方：数数上？

说起来有些难以置信，Anthropic最近发布了一项研究，在AI社区里投下了一颗深水冲击波。他们发了一篇科学博客，标题叫《为生物学智能体铺路》。其中一串数字，让人后背发凉。

研究者干了一件听起来毫无难度的事：让当前最强的几个科研智能体——Claude、GPT、Biomni、Edison Analysis——从NCBI Virus数据库里，准确数出符合条件的病毒序列有多少条。结果呢？没有一个能稳定答对。

更离谱的是，同一道题、同一个模型、同一段提示词，问三次，答案能差出几十倍。

举个具体例子。Claude Sonnet 4检索一条埃博拉病毒序列查询，第一次返回106条，第二次15条，第三次5条。而正确答案是266条。

是的，你没看错。这不是模型不够聪明的问题。

这背后藏着一个扎心的真相：在科学领域，智能体真正的短板并非推理能力，而是它压根没有一条稳定、可复现、机器能走的路，去把数据准确地取出来。无专用检索层时，各家系统的平均准确率从16.9%一路散到91.3%，即使是新模型有进步，残留的错误依旧致命——因为这类任务的及格线，实际上是100%。少一条记录，可能就让一个诊断试剂看起来覆盖了所有流行毒株，或者让一场疫情的起点被推算错好几周。

为马车修的城，跑不动汽车

Anthropic给了一个特别形象的比喻：用智能体去跑生物数据库，就像开车穿越一座汽车出现之前建好的老城。街道也许优雅、讲究，但全是为马车设计的窄巷急弯。零散的数据库、千奇百怪的文件格式、一次性的检索脚本，都是这座老城的一部分。你可以给它加点交通标志、辟几个停车场、拓宽一两条路，但底层的城市布局，从一开始就不是为汽车准备的。

软件的世界正相反。它是一座为车而建的新城：平整的柏油路、清晰的车道、标准化的信号灯。版本控制、文档齐全的API、包管理器，一整套让你从起点高速直达终点的系统，天生就为「车」（也就是智能体）铺好。所以代码智能体一日千里，生物智能体却原地打转。软件领域给出的是结构化的数字工作流和可靠接口——一个GitHub issue，生成补丁、跑通测试、当场验证。生物领域给出的是脆弱、异质、依赖具体流程的基础设施，几乎没有简单、可验证又有意义的奖励信号。

具体到NCBI Virus，麻烦更加明显。它本质上是一个网页门户。你在网页上勾选条件：宿主是人类、采样地在非洲、序列长度大于某个值、排除实验室传代样本……后台才把这些条件翻译成对底层多个数据库（GenBank、RefSeq、INSDC体系）的查询，再把结果筛出来给你。

它的过滤逻辑，大量写在网页这一层，没有对外开放成一个干净的程序接口。对于人类病毒学家，这只是浏览器里点几下的事。对于机器——灾难。因为智能体能直接调用的，是底层那几个原始API（REST、Datasets、E-utilities），而这些API并不暴露和网页一模一样的过滤语义。

举一个具体的例子：网页上「采样地在非洲」是一个勾选框，背后可能要把几十个国家的元数据字段对齐，还要处理那些字段写法不统一的记录；「含表面糖蛋白」这种条件，光靠序列本身判断不了，得再去GenBank把每条记录的基因/蛋白注释拉回来比对。这些隐性步骤，网页帮你做了，但原始API不帮你做。智能体只能自己「猜」着把这套逻辑重新拼一遍。拼漏了就少计算（漏掉非洲某国的序列），拼错了就多计算（过滤条件理解偏了）。这正是Sonnet 4同题三答106、15、5的根因：它每次重建的过滤逻辑都不完全一样。

gget virus要解决的，恰恰就是这件事：把网页界面里那套藏着的过滤行为，重新实现成一个稳定、可复现、机器能直接调用的程序化系统，让智能体不必每次再去猜一遍。

数错一条序列，疫情起点偏移几周

如果你觉得「数错几条序列」无伤大雅，下面这个现场会彻底改变你的看法。

2026年5月，刚果（金）爆发邦地布焦型埃博拉疫情。5月14日，金沙萨的INRB分析了13份血样，次日确认其中8例。到5月29日，WHO报告确诊与疑似病例已超1000例，死亡逾200人。研究者面前摆着三个生死攸关的问题：这次的病毒和以往差多大？现有诊断还测得出来吗？现有疗法还管不管用？回答这些，都要把新基因组和NCBI Virus里的历史埃博拉基因组逐一比对。这套分析的第一步，恰恰就是手动点网页、手动复现一长串复杂过滤条件，再祈祷拉出来的数据集是完整、正确的。

研究者用前面那条埃博拉查询，让Sonnet 4拉数据、建系统发育树，去推算「最近共同祖先时间（TMRCA）」。这是推断一场疫情何时起源的关键量。人工精校的数据集，给出的TMRCA是2014年1月，和既往报告一致。而Sonnet 4跑出来的三套数据，两套明显存在残缺。其中一套把推算出的起源时间从2014年拉回到了1922年，凭空多算出九十多年。剩下那套看着像模像样，却漏掉了几内亚的序列，把起源时间悄悄挪到了2014年4月，时间线就此被改写。

抗体疗法分析也一样。研究者想看看maftivimab、MBP134这两款埃博拉抗体疗法瞄准的位点，历史上有没有出现过突变，借此判断疗法还能不能跟上病毒进化。结果Sonnet 4三次跑出三种完全不同的突变图景。

失败模式很清楚：拉大结果集时中途停手就漏数；过滤条件用错，就超数。流感A、HIV-1等记录海量的病毒，偏差最大。过滤条件一旦超过三四个并行，性能直接崩。

错得理直气壮，是科研里最可怕的一种错误。

给老城挖一条机器专用隧道

那么，怎么修？Anthropic和NCBI的研究者合作，造了一个叫gget virus的东西。

它不是又一个花哨的「AI插件」，而是一个确定性检索层。本质上，它把NCBI Virus网页界面里那套过滤行为，翻译成了可复现的程序化系统。

技术上，它统筹REST、Datasets、E-utilities几个底层系统，自动判断哪些过滤能走API、哪些得本地校验。它处理批量取数，让大结果集被完整拉下来，而不是中途被截断。它从INSDC体系（NCBI、ENA、DDBJ）下载病毒核苷酸序列和链接元数据，输出FASTA、CSV、JSONL这些人和机器都读得懂的格式，还附带详细日志，告诉你这个结果到底是怎么算出来的。对高频查询，它把数据传输量压缩了超过98%。

效果立竿见影。接入gget virus后，所有被测系统准确率全部冲到90.0%以上，GPT-5.5飙到99.7%。运行之间的随机抖动几乎消失，稳定性升到0.92到1.00。最妙的是，模型之间的差距也被大幅抹平了。

把这句话翻译一下：加上确定性工具层之后，你用哪个模型，不那么重要了。这才是真正值得注意的地方。可靠的数据集构建，本不该取决于你买不买得起最新最贵的模型，也不该取决于你恰好知道哪个模型最适配哪个数据库。便宜的模型配上对的工具，照样稳。

还有一个有趣的细节。在360次运行里，GPT-5.5曾在没被任何提示的情况下，自己找到并用上了gget virus。而那一次，是它在那道题上唯一答对的一次。工具的价值，模型自己用脚投了票。

真正的胜负手：从模型转向地基

将视野拉远一些，这件事远不止关于病毒。同样的摩擦，出现在每一个「为人类、而非为智能体设计」的环境里。

几个月前Karpathy讲AI时代的软件，吐槽自己vibe coding做个小网页应用，真要上线（登录、支付、部署），一周时间全耗在浏览器里点来点去。他的总结是：「写代码是最简单的部分。」

生物学家听完Karpathy的吐槽后，也许能产生强烈的共鸣：这种痛苦，他们可能已经忍了很多年。

gget virus并非个例，同样在搭建这种「上下文引擎」的，还有ToolUniverse、Robin、Biomni等一批生物医学智能体。难题在于：确定性到底该放在哪一层，又该怎么搭。当然，也有人会问：模型进步这么快，万一哪天智能体强到能自己穿越混乱门户、对齐ID、正确翻页、出错自愈，gget virus这类「脚手架」会不会瞬间归零？有可能。但Anthropic的答案是：就算智能体做得到，也不代表每次都该让它从头重新发明一遍。一个能自己趟过这套混乱取数流程的模型，可能太贵、太慢、太难审计、太难信任，撑不起日常科研。

更何况，哪怕脚手架终将过时，给生物数据库的教训依然成立：从现在起，就得把智能体当成规模化用户，从一开始就为大规模调用而建。这场竞赛的表面，是模型谁更聪明。往下一层，比的是谁的地基更适合机器奔跑。我们要模型在生成假设、设计实验时天马行空。但它脚下那层——基因标识符、数据schema、检索逻辑、坐标系统、元数据约定——必须要「无聊」得绝对可靠。

模型曲线还在往上走。但这一轮真正的胜负手，或许不在云端的大模型，而在底下那层没人愿意修、却决定成败的数据基础设施上。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Claude误算病毒起源90年全因网页信息要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题