[ blog · tutorial ]10 min read

如何打造不會被限流的科學文獻回顧 Agent

Sarah Choy2026年5月3日 發佈約 10 分鐘閱讀
如何打造不會被限流的科學文獻回顧 Agent

今天直接拿原生的 arXiv + PubMed + Semantic Scholar 來做文獻回顧 Agent,連十篇論文都還沒讀完就會撞上 429。本文說明速率限制為何越收越緊、PaperQA / Undermind 在底層到底做了什麼,以及一個能撐過真實回顧流程的可用模式。

一句話總結

  • arXiv 在 2024 年底開始大舉限流,起因是 LLM 爬蟲掀起的 429 風暴;文件記載的限制是每 3 秒 1 次請求,但實際的爆量容忍度更低。
  • Semantic Scholar 的 1,000 req/sec 是所有未驗證呼叫者共用的 —— 對正式環境的 Agent 來說等同無法使用。
  • PubMed E-utils 對未驗證流量的上限是 3 req/sec;帶 API key 則為 10 req/sec。
  • 能正常運作的 Agent(PaperQA2、Undermind、Elicit)全都在這些來源前面加了一層代理 / 快取。
  • API Pick Academic Search 把 arXiv、PubMed、bioRxiv、medRxiv 包成一個受速率管理的端點 —— 每次呼叫 5 credits,只對成功扣費。

一段話講完問題

免費的學術 API 很棒,而它們正在被活活吃掉。arXiv、PubMed 與 Semantic Scholar 都是在「最糟負載不過是某個研究員寫個腳本每隔幾秒輪詢一次」的年代設計的。如今每個會寫 Python 的大學生都能寫一個 LLM Agent,為了讀一篇論文的參考文獻就同時發出五十個並行呼叫。再乘上數千個類似的 Agent,你就會看到 arXiv 工作人員在 X 上稱為 2024 年底「arXiv 末日」的那種模式 —— 持續不斷的 Rate Exceeded 回應、服務劣化,以及一波對獨立開發者比對惡意行為者打擊更重的新限流規則。

結果就是:一個在開發環境裡能處理五篇論文的文獻回顧 Agent,跑到真實回顧流程一半就垮了。使用者拿到的是只有三條引用、而不是十五條的半成品答案。

本文要談的,就是如何把 Agent 打造成不會發生這種事。

到底是哪裡、哪些被限流了

速率限制為撰寫本文時的記載值。arXiv 與 Semantic Scholar 都保留在事故期間進一步限流的權利 —— 在大量整合前請先確認。
arXivPubMed E-utilsSemantic ScholarOpenAlexAPI Pick Academic
覆蓋範圍物理、數學、CS、生物預印本生物醫學(3,500 萬筆以上)跨領域(逾 2 億筆)跨領域(2.5 億筆以上)arXiv + PubMed + bioRxiv + medRxiv
速率限制(未驗證)1 req / 3 sec3 req / sec共用 1k/sec 池(實際很低)100k req / 天按呼叫計費,無單一使用者限流
速率限制(帶 key)相同 —— key 僅供大量下載用10 req / sec以 key 為單位的配額桶(核准緩慢)相同
是否回傳全文?是(XML / PDF 連結)僅摘要摘要 + 部分無付費牆內容摘要 + 部分標題 + URL + 摘要型 snippet
LLM 友善格式否 —— Atom XML否 —— XML是 —— JSON是 —— JSON是 —— JSON,snippet 已預先整理
費用免費免費(建議申請 key)免費,正式環境需申請 key免費5 credits/次(約 $0.005)

能正常運作的產品實際上怎麼做

PaperQA2、Undermind、Elicit、ResearchRabbit,以及那些 agentic RAG 論文(例如 Open-Source Agentic Hybrid RAG Framework,arXiv 2508.05660)全都收斂到類似的模式。最關鍵的三個工程手段是:

1. 用 DOI / arXiv ID 做快取,而不是用查詢字串

同一篇論文會被許多不同的查詢請求到。在搜尋結果層級做快取幾乎沒幫助;在論文識別碼層級做快取才有效。一個以 doi:10.1038/... 為鍵的小型 Redis(甚至 SQLite)層,在一個下午的 Agent 流量裡就回本了。

2. 把引用關係圖當成緩慢變動的索引

Semantic Scholar 的強項不是關鍵字搜尋,而是引用關係圖。PaperQA2 用它從一篇種子論文擴展到一整個相關叢集,而不是從零開始發掘論文。這樣的請求量小得多 —— 每篇論文一次呼叫,而不是上百次 —— 也能穩穩低於速率限制。

3. 把延遲當成代價接受,或者,把速率限制代理掉

要嘛你讓使用者等 30 至 60 秒,換來一個謹慎、尊重限流的查詢(PaperQA2 的選擇),要嘛你加一層服務,把跨使用者的流量彙整起來,對 Agent 呈現一個能容忍爆量的單一介面(API Pick 的選擇)。兩條路都行得通。把它們混在一起 —— 在受限流的公開 API 上做低延遲體驗、卻沒有緩衝層 —— 才是會失敗的那種。

可用程式碼:一個跑得完的文獻 Agent

能撐過真實回顧流程的最小可行 Agent:

import requests
from anthropic import Anthropic

KEY = "pk_yourkey"
client = Anthropic()

def fetch_tool(path: str) -> dict:
    return requests.get(f"https://www.apipick.com{path}/tool-schema").json()["claude"]

# Two tools: academic search + URL extract for the full body
TOOLS = [
    fetch_tool("/api/search/academic"),
    fetch_tool("/api/extract"),
]

SYSTEM = """You are a literature-review research assistant. Process:

1. Use academic_search with the user's question to find relevant papers
   from arXiv, PubMed, bioRxiv, and medRxiv. One call usually returns
   the right set of seed papers.

2. For papers worth citing in detail, use extract_urls on the paper's URL
   to pull the body. Batch up to 5 URLs per call.

3. Answer the user's question with inline citations in the form
   [Author Year, doi/arxiv URL]. Quote findings verbatim where possible.

4. If the search returned <3 substantive results, expand the query and
   try once more. Don't loop indefinitely — say "I couldn't find a strong
   answer in the indexed literature" if nothing matches.

Be precise. Cite every factual claim. Distinguish preprints (arXiv,
bioRxiv, medRxiv) from peer-reviewed (PubMed) when it matters."""

def call_tool(block):
    name_to_path = {"academic_search": "/api/search/academic", "extract_urls": "/api/extract"}
    r = requests.post(
        f"https://www.apipick.com{name_to_path[block.name]}",
        json=block.input,
        headers={"x-api-key": KEY},
        timeout=60,
    )
    return {"type": "tool_result", "tool_use_id": block.id,
            "content": r.text, "is_error": r.status_code != 200}

def review(question: str) -> str:
    msgs = [{"role": "user", "content": question}]
    while True:
        r = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            system=SYSTEM,
            tools=TOOLS,
            messages=msgs,
        )
        msgs.append({"role": "assistant", "content": r.content})
        if r.stop_reason == "end_turn":
            return "\n".join(b.text for b in r.content if b.type == "text")
        if r.stop_reason == "tool_use":
            results = [call_tool(b) for b in r.content if b.type == "tool_use"]
            msgs.append({"role": "user", "content": results})

print(review("Recent advances in LLM-based protein structure prediction (2025)"))

每個問題的成本:

  • 1-2 次 academic_search 呼叫(5-10 credits = $0.005-$0.010)
  • 1 次 extract 呼叫,涵蓋 3-5 篇論文(6-10 credits = $0.006-$0.010)
  • 約 5,000 個輸入 + 1,200 個輸出 token 給 Claude(約 $0.04)

取整來說:一個帶引用的文獻回顧答案約 5 美分。每天 100 個問題就是 $5/天 —— 大概就是一位中規中矩的研究員每天的咖啡因花費。

各次領域的微調

生物醫學文獻

讓 Agent 偏向 PubMed(同儕審查),並明確把 bioRxiv/medRxiv 的命中標記為預印本。當問題是 「最新證據怎麼說」 時,Agent 應該把同儕審查的權重調高。在系統提示詞裡加一句 —— 「若預印本與同儕審查來源說法不一致,以同儕審查為準並標註出落差」 —— 就能乾淨俐落地處理這件事。

數學 / CS

arXiv 在這裡是主力。訊噪比比生物醫學更好,而且對於奠基性的工作而言,引用比時效性更重要。用較寬的查詢去搜,再讓 Agent 自己修剪。

藥物發現 / 臨床

搭配 Clinical Search(ClinicalTrials.gov + FDA 標籤 + ChEMBL + DrugBank),補上學術搜尋無法涵蓋的法規與生物活性維度。這組合 —— 同儕審查文獻 + 試驗登錄 + 結構資料 —— 正是讓一個藥物再利用或藥物安全監測 Agent 真正派上用場的方式。

這套做法可以推廣到哪裡

速率限制問題並非學術搜尋獨有。任何在前 LLM 時代就推出 API 的公開資料集,如今都被施加了同樣的負載模式:SEC EDGAR、USPTO、EPO、公共紀錄資料庫、氣象服務、政府開放資料。同一套工程模式對它們全都適用 —— 在實體層級做快取、疊一層受管理的代理,並在你負擔不起代理時,把延遲當成替代方案接受。

更深層的轉變是:到了 2026 年,期待一個免費公開 API 直接吸收 LLM Agent 的負載,已不再合理。這些端點不會消失 —— 但它們正被一層付費的受管理服務包起來,這層服務存在的目的,就是把「有禮貌的人類研究員」的速率限制,轉譯成「能容忍爆量的 Agent 流量」。API Pick Academic Search 就是文獻回顧這個使用場景的其中一層。未來會有更多。

常見問題

arXiv 為什麼從 2024 年起限流變得這麼兇?

因為 LLM 驅動的爬蟲。arXiv 工作人員在他們的開發者郵件群組、以及 X 上的 @arxiv 都明講過這個模式:一個 LLM Agent 為了抓取單篇論文的參考文獻,會同時發出 50 個並行請求,再乘上數千名跑類似工作流程的使用者,整個索引就被拖垮了。每次請求間隔 3 秒的規則其實一直都寫在文件裡,但從 2024 年底 / 2025 年初開始才嚴格執行。

Semantic Scholar 的 1,000 req/sec 真的是共用的嗎?

是的 —— 那是未驗證的共用池,由每個打到公開 API 的 IP 一起分。實務上,無論你個人的速率多低,未驗證請求在尖峰時段就是會開始失敗。官方建議是申請 API key,這樣會把你移到以 key 為單位的配額桶。申請要等好幾週,而且是建立在你做的是學術而非商業用途的前提下才核准。

那 PubMed 的 E-utils 呢?

比其他幾家好 —— 沒 key 是 3 req/sec,有 key 是 10 req/sec。透過 email 向 NCBI 申請 API key,若說明是研究用途,通常當天就會核准。但即便如此:10 req/sec 對單一使用者夠用,但對多使用者產品就不夠 —— 每個使用者的提問都會展開成好幾次 PubMed 呼叫。

為什麼 PaperQA2 跑得動,我自己手寫的 Agent 卻不行?

三個原因。(1) PaperQA2 大量做批次與快取 —— 同一個 DOI 查詢絕不查第二次。(2) 它主要把 Semantic Scholar 當引用關係圖來用(每篇論文一次呼叫),而不是當搜尋索引。(3) 它接受每個問題花較長的牆鐘時間,換取不超出速率限制。如果你想在使用者期待 5 秒回應的產品裡做出同樣的體驗,你就需要一層吞吐量更高的服務。

API Pick Academic Search 實際上解決了什麼?

它替你管好速率限制與來源覆蓋,讓你的 Agent 不必操心。一次 POST /api/search/academic 呼叫,就會一併回傳來自 arXiv、PubMed、bioRxiv、medRxiv 的排序結果,並已預先整理成適合 LLM 消化的格式。每次呼叫 5 credits(≈$0.005),且只在 HTTP 200 時扣費。你只要專注在 Agent 迴圈與提示詞上;限流是我們的問題。

本文使用的 API

Sarah Choy
作者
Sarah Choy
CEO, API Pick

Sarah Choy 是 API Pick 的 CEO,專注於為 AI Agent 與 LLM 工作流打造可用於正式環境的 API。