機器之心編輯部

當前，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