[ blog · tutorial ]10 min read

如何构建一个不被限流的科研文献综述 Agent

Sarah Choy发布于 2026年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、生物预印本生物医学(3500 万+ 条记录)跨学科(>2 亿)跨学科(2.5 亿+)arXiv + PubMed + bioRxiv + medRxiv
速率限制(匿名)每 3 秒 1 次每秒 3 次共享 1k/sec 池(实际很低)每天 10 万次按调用计费,无按用户限流
速率限制(带 key)一样——key 只用于批量每秒 10 次按 key 计的独立配额(发放慢)一样
返回全文?是(XML / PDF 链接)仅摘要摘要 + 部分无付费墙内容摘要 + 部分标题 + URL + 摘要形态的片段
LLM 友好格式否——Atom XML否——XML是——JSON是——JSON是——JSON,片段已预整理
成本免费免费(建议申请 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 缓存,而不是按 query 缓存

同一篇论文会被许多不同的 query 请求到。在「搜索结果」层做缓存几乎没用;在「论文标识符」层做缓存才有效。一个以 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 次覆盖 3-5 篇论文的 extract 调用(6-10 credits = $0.006-$0.010)
  • 给 Claude 约 5,000 input + 1,200 output token(约 $0.04)

取个整数:一次带引用的文献综述答案约 5 美分。每天 100 个问题就是 $5/天——差不多就是一位研究者一天的咖啡钱。

子领域的微调

生物医学文献

让 Agent 偏向 PubMed(同行评审),并明确把 bioRxiv/medRxiv 的命中标记为预印本。当被问到 「最新证据怎么说」 时,Agent 应给同行评审内容更高权重。在系统提示词里加一句——「若预印本与同行评审来源相互矛盾,以同行评审为准并指出分歧」——就能干净利落地处理这一点。

数学 / CS

这里 arXiv 占主导。信噪比比生物医学好,而对于奠基性工作,引用次数比时效性更重要。用更宽泛的 query 搜索,再让 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。通过邮件向 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。