1. 为什么要专门搭一套"OpenResearch"式的研究流水线
先说一下我做这件事的背景。过去很长一段时间，我都在跟研究报告、论文综述、技术调研这类任务打交道，日常工作流基本是这样的：打开十几个浏览器标签页，一边在数据库检索文献，一边把摘要复制到笔记软件里，再手动整理出每个方法的核心论点、实验结果和局限性。单篇文献读起来不费劲，但任务一多，尤其是需要横向对比十几篇方法、梳理同一主题下不同方案异同的时候，纯人工操作的时间成本高得吓人。
后来我开始把大语言模型接进这个流程里，最初的尝试很粗糙：把几篇摘要粘贴进对话框，让它"总结一下"。试过几次之后你会发现，零散的问答式交互根本撑不起完整的研究任务，因为模型没有全局视野，它不知道你前面读过哪些文献，也不会主动检索新的资料，更不会帮你把一整轮调研沉淀成结构化文档。我做"OpenResearch"这个项目的初衷，就是想用一套明确的、可复用、可扩展的自动化流水线，把"检索文献—筛选相关研究—对比分析方法—生成结构化报告"整个链路串起来，让自己从重复劳动中解放出来。整个项目依赖的都是公开接口和开源组件，完全可以在本地或者自己的服务器上复现，不需要什么特殊资源。
这篇博文会从系统架构、检索策略、成本控制、质量控制几个方面拆解我的实现方案，最后会分享实测数据和踩过的坑。无论你是想用类似方式提升文献调研效率的研究者，还是打算在公司内部搭建一套辅助写作或调研工具的工程师，这篇文章都能给你一个可以直接参考的落地路径。
我在这里要特别说明一下，整套流水线的设计思路大体上借鉴了公开可查的研究辅助类工具的常见范式：用户输入研究主题之后，系统负责补全研究计划、检索文献、抽取关键信息、迭代追问、最终产出一份带引用的结构化报告。但OpenResearch这套实践并不是某一个现成产品的复刻，而是我把这类工具的通用思路落地到自己的技术栈之后，总结出的一个可以稳定运行的具体实施方案。
2. 系统架构与核心模块：它是怎么一步步逼近研究结论的
OpenResearch的完整工作流可以划分成五个模块：规划模块、检索模块、阅读抽取模块、分析综合模块、生成模块。很多人以为这类工具的核心在"生成报告"这一步，实际上前四个模块才决定了最终报告的上限。生成模型再强，喂给它的素材质量不行，输出照样是垃圾。
2.1 研究规划模块
用户输入一个研究主题之后，第一个被调用的模块是研究规划器。它的任务不是直接回答用户的问题，而是生成一整份研究方案。方案里至少包含这样几个部分：研究目标的重述、需要回答的核心子问题列表、每个子问题对应的检索方向、可能涉及的关键概念和潜在的关键词组合。
举个我实际跑过的例子，用户输入的主题是"多模态大模型在医学影像分析中的应用现状"，规划器会拆出大概八个子问题，包括：当前主流的多模态融合架构有哪些、公开的医学影像数据集有哪些、评估指标如何设计、不同方法之间报告性能差异有多大、临床落地的挑战集中在哪些环节等等。每个子问题再映射到一个具体的检索式。
这个环节的核心价值是"对齐预期"。人的研究需求往往是不完整的，用户在输入一句话主题的时候，脑子里已有的信息远比输入的文字多。规划模块强制模型把这个模糊需求展开成结构化的问题清单，相当于在启动耗时的检索之前，先给整个任务画了一张地图。实测下来，有了这一步之后，后续模块的检索目的性和回答准确度明显提升，出报告的返工率低了不少。
2.2 检索模块
检索模块根据规划阶段输出的每个子问题，构造查询语句，并对接多个信息源。我目前接入了两类来源：一类是学术数据库的公开接口，比如arXiv的API、Semantic Scholar的Graph API、PubMed的E-utilities；另一类是通用网页搜索接口，用于补充学术数据库覆盖不到的工程实践资料、开源代码库、行业报告等。
每个子问题会生成5到10个查询变体，原因是学术检索领域的"同义词问题"非常严重。同一个概念，在不同论文里可能叫"model compression""network pruning""knowledge distillation"，侧重点各不相同，只用一个词去搜大概率漏掉重要文献。所以我在查询生成阶段就要求模型为每个子问题扩展同义词和相关概念，再提交给上游搜索引擎。
检索结果统一整理成一个文档列表。每条记录保存了文献标题、摘要、作者、发表时间、DOI、原文链接和完整正文（如果接口允许获取的话）。这一步的关键是保留元数据，后续所有引用、去重、排序都依赖这些字段。
2.3 阅读抽取模块
检索回来的文献不能一股脑全部塞给生成模型，原因有两个：一是上下文窗口有限，塞不进去；二是文献与当前任务的相关性差异巨大，噪声太多会影响回答质量。所以每篇文献在正式进入综合分析环节之前，都要经过一道"过滤器"。
我设计的阅读抽取模块分三层。第一层做相关性初筛，用模型判断这篇文献跟当前子问题是否相关，给出0到1之间的相关度分数，并附一句判断依据；第二层做信息抽取，对通过筛选的文献，抽取它的核心贡献、使用的方法、实验设置、关键结果、局限与未来工作；第三层做去重，基于标题和摘要的文本相似度合并同一研究的不同版本（比如会议版和期刊版）。
这个三层结构的处理方式，是后续控制API成本的关键杠杆之一。分类、抽取这类任务的模型参数规模需求远低于最终的总结生成任务，我在初筛和抽取阶段使用的是小规模模型，成本只有最终生成模型的大约十分之一，但效果完全够用。
2.4 分析综合模块
文献抽取出结构化信息之后，分析综合模块开始真正的"思考"。这个模块的设计参考了Chain-of-Thought的思路，但落地形态不是让模型光在输出里写"让我们一步步思考"，而是把思考过程显性化成具体的任务状态迁移。
具体做法是维护一个研究状态对象，里面记录了当前子问题的列表、每个子问题的已有证据摘要、还没有覆盖的信息缺口、产生了哪些新的追问。模型每处理一个子问题，就更新一次这个状态对象。如果发现某个子问题的证据不足或存在相互矛盾的结论，它会自动生成一轮补充检索请求，重新丢给检索模块。
这个机制解决了我早期实现中最大的一个痛点：单轮检索获取的信息往往是片面的，第一轮检索到的文献可能只覆盖了某个技术方向的一部分分支，如果直接就这些不完整的素材生成报告，结论很容易出现偏差。有了"检索—分析—发现缺口—再检索"这个迭代闭环之后，报告的分析深度比单轮方案有了质的提升。实践中我通常设置最多三轮迭代，超过三轮之后信息收益递减明显，要继续深挖的成本会不成比例地放大。
2.5 报告生成模块
最后一个模块把分析综合阶段产出的结构化证据组织成可读的调研报告。由于前序阶段已经把证据抽取、整理好了，这个阶段的重点在于结构编排和表达润色。
报告默认包含：执行摘要、背景介绍、各子问题的分析小节（逐项列出关键文献和发现）、跨子问题的综合讨论、研究现状的评价、未解决问题与未来方向、参考文献列表。每一条陈述都要求标注证据来源，对应到具体的文献条目。这一步直接决定了报告的可信度，没有引用的调研报告只是观点输出，不构成研究工作。
到这里，系统的整体框架就清晰了。接下来我想单独展开一个对工程实现来说非常重要的部分：成本控制。很多人照着教程搭出类似系统之后，跑一个任务烧掉几十美元，立刻放弃了。我在这块做了很多实测，有一些很实用的经验。
3. 成本控制与模型分层策略：跑一次深度调研到底要花多少钱
大多数类似工具的直接成本来源是大模型API调用。如果不做任何优化，一个涉及五轮检索、二十篇文献的分析任务，可能会触发上百次模型调用，账单相当可感。我的优化策略概括成一句话就是：不同难度的工作交给不同档位的模型去做，绝不为了一个分类任务去调最大的模型。
3.1 任务分层与模型选型
我把流水线里的模型任务按认知难度分成了四层。
| 任务层 | 典型任务 | 模型档位 | 单次调用成本级别 |
|---|---|---|---|
| 轻量分类 | 相关性筛选、去重判断 | 小型开源模型 | 极低 |
| 中等抽取 | 关键信息抽取、摘要生成 | 中型模型 | 低 |
| 较重推理 | 子问题规划、证据分析、矛盾识别 | 旗舰级模型 | 中高 |
| 最高难度 | 综合分析、长篇报告写作 | 旗舰级最强模型 | 高 |
这里的关键认知是，像相关性筛选这种任务，本质上是一个世界上已经研究得非常透彻的文本分类问题，你不需要一个拥有顶级推理能力的模型去判断某个摘要是否与查询相关。我在初筛阶段用了一个参数规模很小的开源模型，准确率在同量级任务上和大型模型差距在5%以内，但成本差了一个数量级还多。
在分析综合和报告生成阶段，我才会启用最强的模型，因为这两个环节是整个流水线的"大脑"，它们处理的是真正的推理任务——比如对比两篇论文中看似矛盾的数据结论，判断它们是否真的矛盾，还是因为实验设定、评估指标不同导致的表层冲突。这类任务对幻觉的容忍度极低，用弱模型去跑，相当于为了省油给发动机换了个小排量，爬坡时一定会出问题。
3.2 减少无效调用的三条规则
除了模型分层，我还总结了三条减少无效调用的实战规则，每条都用真金白银换来的教训。
规则一：能缓存就缓存。同一篇文献的摘要抽取结果、同一对文献的相似度分数，在不同任务里可能反复用到。我在抽取模块前加了一层基于文本哈希的缓存，命中缓存直接拿结果，绕开模型调用。实测中，处理多主题系列任务时，缓存命中率能到30%以上。
规则二：先小模型试跑，再大模型纠错。有些任务确实需要强模型，但不是每一次都需要。我设计了一个"级联"流程：先让弱模型给出答案和置信度，置信度高于阈值就直接输出；置信度低于阈值才升级到大模型重试。这个方案来自一个很常见的观察——AI失败的模式不是均匀分布在高难度任务上，而是集中在少数"中等难度但触及知识边界"的问题上。用置信度做路由信号，可以在保住上限质量的同时，把大模型的调用量压到原来的40%左右。
规则三：精简单轮调用中的冗余上下文。同一个子问题下可能有七八篇文献，如果每篇文献都完整塞进提示词里让模型分析，上下文消耗会非常大。我的做法是在进入分析综合阶段前，把抽取阶段得到的结构化摘要（通常只有300到500字）作为主要输入，原文正文作为可选深度参考。这样做有非常实际的理由：大模型API的计费里，输入和输出tokens都算钱。一个动辄上万tokens的输入上下文，哪怕生成部分只有几百tokens，单次成本也已经很高了。
把这些策略叠加之后，跑一篇常规深度调研报告的成本大约是2到5美元，具体取决于检索深度和文献数量。相比纯人工写综述花费的时间，这个成本是完全可以接受的。
4. 检索策略的工程细节：同义词扩展、相关性打分与迭代补检
检索是整个流水线的数据源头，源头烂了，后面所有环节都是空转。这一节讲我在检索模块里的几个关键设计决策，以及它们背后的考量。
4.1 同义词扩展与检索式生成
我用一个专门的提示模板让模型生成检索式。模板会要求模型先列出与研究主题相关的核心概念、同义词、下位词和英文关键词（我的研究场景中很多文献是英文的），然后用这些词组合出多条独立的查询语句。
学术数据库的搜索接口通常接受关键词组合，但不同的接口对查询语法支持不一样。arXiv自带一个支持布尔运算的搜索界面，但API的query过滤条件用起来有一些需要注意的地方，最好在组合查询时控制关键词数量，或者拆成多次简单查询再合并结果。Semantic Scholar的API则接受更灵活的查询串，同样建议分开检索以避免超时或返回结果过多导致的排序问题。
这一步没什么高深理论，纯粹是工程经验：查询越具体，返回的相关性越高；查询越宽泛，召回越高、噪声越大。我给每个子问题安排5到10个查询变体，就是为了在"精确匹配"和"尽量召回"之间找一个平衡点。你可以把这种查询方式理解成钓鱼时同时甩好几根竿子，每根竿子的饵不太一样，最后总能多钓上来几条。
4.2 结果排序与相关性重打分
搜索接口自带的排序逻辑往往基于数据库内部的分值，不一定符合你所处上下文的"相关性"定义。举例来说，Semantic Scholar默认会优先展示引用数高的论文，但引用数高跟"与当前子问题是否高度相关"是两码事。一篇奠基性的经典论文被引用几千次，但可能只跟你研究问题的背景相关，而一篇刚发表的预印本可能恰好直接解决你的子问题。
因此我加了一层重打分环节，把搜索返回的前20到50条结果重新排序。重打分器接收文献标题和摘要作为输入，输出一个0到1之间的相关度分数。这个环节同样使用小型模型，因为要处理的结果量不算小，而逐条排序的成本需要控制住。实践中这个分数会被用来设置一个阈值，低于阈值的文献直接丢弃，不再进入阅读抽取阶段。
4.3 迭代补检机制
前面提到过，系统会通过"发现信息缺口"来触发补充检索，这里说一下具体的实现逻辑。
分析综合模块在处理某个子问题时，会维护一个证据列表。每条证据都标记了一句话事实、来源文献、支撑强度。如果模型判断某个关键问题缺少足够的证据支撑，比如"当前收集到的文献都没有报告在真实临床数据上的性能指标"，它就把这个缺口表述成一条新的检索请求，塞回检索队列。下轮循环中，检索模块会生成针对这个缺口的补充查询。
这个机制让系统从一个"一次查询、一次总结"的浅层工具变成了一个有研究策略的智能体。它不会一直沿着最初的检索方向走到黑，而是随着信息积累不断调整关注点。
这里有一个很现实的工程问题：迭代轮数设置多少合适？我的经验是三轮左右。第一轮多半能覆盖主流文献，第二轮补上遗漏的细分方向，第三轮通常只能补到很少量的新内容。超过三轮之后，边际收益会变得非常低，但API成本和等待时间却在线性增长，性价比已经不值得。
5. 内容质量控制与引文溯源机制：如何让AI输出可信的研究结论
面向研究场景的输出，最致命的不是内容不够长或者措辞不够好，而是"看起来很有道理但其实是错的"。AI生成内容的通病是流畅性和信心度远高于其真正的准确度。为了应对这个问题，我在完整的流水线里设置了三道质量关卡。
5.1 关卡一：证据-论点一致性校验
报告生成阶段结束后，会运行一个独立的校验器，逐条检查报告中的关键论断是否能在抽取阶段的证据列表里找到对应支撑。如果某个论点没有来源，它会被标记为"未证实"，并在最终报告中降级为"推测性说法"或干脆删除。
这个校验器本身也是一个模型，但它不看原文，只对比"报告论断"和"证据摘要"之间的语义一致性。我选了比推理模型弱一个档位、但比抽取模型强一个档位的中间模型来做这件事——它不需要创造新知识，但需要准确判断信息之间的一致性，这个任务难度居中，中间档位刚好胜任。
5.2 关卡二：引文编号的准确性验证
大模型在生成带引文的文字时，很容易编造不存在的引文编号，或者把编号错误地映射到与上下文无关的文献上。这个问题的根源在于模型缺乏逐字指向外部文档原句的机制，它更多地是通过统计关联猜测"这句话大概应该引某篇文献"。
我的处理办法是从生成提示词层面绕开这个陷阱：要求模型在观点后标注的是证据ID而非文献序号，证据ID直接在分析综合阶段的证据列表里就已经存在。生成模型只需要把证据ID映射到最终参考文献列表的对应编号，而这个映射关系由代码逻辑完成，不由模型自行发挥。这样一来，引文和文献之间的关联是程序强制保证的，基本不会出错。
5.3 关卡三：矛盾信息的外显化处理
综述类研究中，不同文献的结论存在分歧是常态，而不是异常。早期版本的OpenResearch在遇到这类矛盾时，会把冲突信息强行抹平，生成一段带有强烈确定性的漂亮话。这本质上是一种幻觉，因为它让读者误以为该领域已有明确共识，而实际科研共同体还在争论中。
现在的设计会把矛盾直接呈现在报告中，用专门的板块列出"不同研究在同一问题上的分歧点"，并解释可能的原因——比如测评基准不同、数据规模差异、实验环境不一致等。对于研究工作来说，指出矛盾点比给出一个虚假的统一结论有价值得多，因为它能真实反映该领域的开放性问题，为后续研究提供方向。
这道关卡的价值在实测中体现得非常明显。在一次关于"对比学习在小样本场景下的表现"调研中，不同论文的性能差距大得离谱，有的结果显示对比学习远超有监督基线，有的结果显示两者没差别。如果我没有做矛盾外显化处理，生成模型很可能就按照引用最多的那篇论文口径写了。但经过分析综合模块的交叉比对，最终报告里明确指出这一分歧并剖析了可能的来源，为读者还原了一个更接近真实科研生态的图景。
6. 从零搭建的完整实操记录：依赖选型、关键代码与运行流程
前几节讲的是设计思路，这一节给想要亲手搭建的人一份可以直接照着走的清单。整个项目的代码量在1000行上下，核心依赖包括一个OpenAI兼容的模型调用库、一个arXiv客户端封装和Semantic Scholar的官方Python SDK。我用的是Python 3.10加FastAPI，把所有模块封装成一个HTTP服务，通过API接口交互。
6.1 环境准备
我的运行环境是一台4核16G内存的云服务器，操作系统是Ubuntu 22.04。坦白讲，这个配置对运行流水线本身来说是溢出的，因为模型推理都在API端完成，本地只负责编排、检索和文本处理。如果你有大量PDF需要解析，CPU性能会有些影响，但配置到2核8G也能跑。
# 创建虚拟环境 python3 -m venv openresearch_env source openresearch_env/bin/activate # 安装核心依赖 pip install fastapi uvicorn requests openai pip install arxiv semantic-scholar pypdf一个重要的提醒：我自己在初始搭建时使用过一个开源的PDF解析库来读取下载回来的论文全文，实测发现它对扫描版PDF（也就是书页图片型）的解析效果不理想，乱码和内容丢失的情况都比较常见。更好的做法是优先让检索接口返回结构化元数据而非依赖PDF全文解析，当确有必要获取正文文本时，再根据PDF是否有文本层做区分处理。很多论文存储库的官方API是支持返回摘要和结构化字段的，原生的文本解析API反而更稳定。
6.2 关键代码片段
下面这段代码展示了检索模块的核心逻辑——接收子问题，生成查询变体，并行检索多个数据源，合并结果并去重。
import asyncio from typing import List, Dict import arxiv from semantic_scholar import SemanticScholar async def retrieve_evidence(sub_question: str, variations: List[str]): """ 检索证据：针对子问题的查询变体，分别查询 arXiv 和 Semantic Scholar。 返回汇总后的候选文档列表。 """ tasks = [] for q in variations: tasks.append(_query_arxiv(q)) tasks.append(_query_s2(q)) results = await asyncio.gather(*tasks) merged = {} for batch in results: for doc in batch: key = doc["title"].strip().lower() # 简单标题去重，后续再做深度语义去重 if key not in merged: merged[key] = doc return list(merged.values()) async def _query_arxiv(query: str) -> List[Dict]: client = arxiv.Client(page_size=20, delay_seconds=3) search = arxiv.Search( query=query, max_results=20, sort_by=arxiv.SortCriterion.Relevance ) results = [] for r in client.results(search): results.append({ "title": r.title, "abstract": r.summary, "authors": [a.name for a in r.authors], "published": str(r.published), "url": r.entry_id, "doi": r.doi, "source": "arxiv", }) return results async def _query_s2(query: str) -> List[Dict]: s2 = SemanticScholar() try: data = s2.search_paper(query, limit=20) results = [] for p in data: if p.title is None: continue results.append({ "title": p.title, "abstract": p.abstract or "", "authors": [a["name"] for a in p.authors or []], "published": (p.publication_date or ""), "url": p.url, "doi": p.external_ids.get("DOI") if p.external_ids else None, "source": "semanticscholar", }) return results except Exception as e: # 实时接口容易超时或限流，失败时留空不影响主流程 print(f"[warn] S2 query failed: {e}") return []要特别说明的是，Semantic Scholar的公开接口有速率限制，并发太高会被临时封禁。我最初没有控制并发，结果跑了几轮任务之后IP被限流，整整一个小时无法访问。后来我在查询逻辑里加了一个指数退避重试机制，每次请求间隔至少1秒，并发控制在5以内，一个月下来再没出过问题。
6.3 运行流程与状态管理
服务的核心是一个状态机。用户提交研究主题后，系统创建一个任务，状态依次为planning、retrieved、extracting、analyzing、writing、completed。每个状态都持久化到SQLite中，服务宕机后可以从最近状态恢复，不至于整轮重跑。这个设计在一次服务器迁移时帮了大忙，任务跑到分析阶段机器需要重启，恢复后直接从断点继续，省掉了此前下载文献的耗时。
以下是一个简化的HTTP接口调用流程：
# 1. 提交研究任务 curl -X POST http://localhost:8000/tasks \ -H "Content-Type: application/json" \ -d '{"topic": "多模态大模型在医学影像分析中的应用现状"}' # 2. 查询任务状态 curl http://localhost:8000/tasks/{task_id} # 3. 任务完成后获取报告 curl http://localhost:8000/tasks/{task_id}/report整个流程跑下来，一篇中等规模的调研报告耗时大约10到20分钟，具体取决于检索接口响应速度。其中最耗时的是检索阶段，因为要等外部API返回结果，而不是生成模型本身。
7. 实测数据与质量对比：OpenResearch vs 纯人工调研 vs 单轮LLM问答
搭完系统之后，我针对自己的日常任务做了一组横向对比实验。对比对象有三个：OpenResearch完整流水线、纯人工检索+阅读、单轮LLM对话式问答。任务主题选择了两个我很熟悉的领域，方便人工判断输出质量。
下表是一次中等难度主题"知识蒸馏在边缘设备上的部署优化"的对比结果。
| 维度 | 纯人工方式 | 单轮LLM问答 | OpenResearch |
|---|---|---|---|
| 总耗时 | 约6小时 | 10分钟 | 18分钟 |
| 覆盖文献数 | 18篇 | 依赖训练语料 | 32篇 |
| 引文可信度 | 高 | 低（易编造） | 高（程序强制映射） |
| 结论的时效性 | 取决于检索时间 | 受限于训练数据 | 通过API获取最新预印本 |
| 分析深度 | 深 | 浅 | 中深 |
| 综合对比能力 | 强 | 弱 | 强（有证据迭代机制） |
单轮LLM问答在速度上有碾压性优势，但它的参考信息完全依赖模型的训练语料，无法获取最新研究成果，而且引文真实性没有保证。纯人工方式深度最好，但时间成本是其他两种方式的20倍以上。OpenResearch作为折中方案，速度接近LLM问答，但分析深度通过证据链迭代机制得到了有效提升。
我必须要坦率地讲，OpenResearch不会取代研究者，它能取代的是"人肉搜索复制粘贴整理摘要"这种机械劳动。它产出的报告适合作为正式研究的前期调研基础，但真正的科学判断、实验设计、领域洞察，仍然需要人类研究者完成。在一些需要深度推演未来方向、判断研究路线优劣的高级任务上，它目前还达不到资深研究者的水平。
8. 自己动手搭建时的几件事：优先级排序与避坑建议
如果有人想在自己的领域里复刻一套OpenResearch，我最后给出几条基于实测的优先级建议和避坑提示，按重要程度排序。
第一，先把检索链路打通，再考虑生成效果。工具的输出质量上限很大程度上由素材决定。先确认你需要的文献能够稳定地从公开API获取，再花时间调优提示词。很多仿照同类工具做出来的Demo看着不错，实际一用就露馅，问题往往出在检索覆盖不足，而不是大模型能力不够。
第二，做任何功能性增强之前，先做成本监控。我建议在系统里从头就内置日志功能，记录每一次API调用的模型、输入规模、输出规模、费用。没有监控的话，你可能直到收到月账单才发现某个隐含循环把成本翻了好几倍。这种排查在事后做非常痛苦。
第三，不要迷信单一大模型，优先做模型分层。“一个模型走天下”的实现方式在原型阶段没问题，但一旦进入生产使用，成本曲线会让你不得不重构。哪怕只做简单的两层分层——轻量任务用便宜模型、重任务用最强模型——也能立刻省下50%以上的API费用。
第四，把"信息矛盾"的呈现当成必须项而不是可选项。研究场景中用户往往是鉴别能力比较强的人，一眼就能看出报告刻意回避矛盾。主动呈现分歧反而会提高系统的可信度。做这类工具的人天然倾向于让输出"看起来完美"，但在研究这个场景里，真实比完美的价值高得多。
第五，接口的速率限制是最大的隐形杀手。对接外部API时，先仔细阅读它的限流策略，在代码里做好退避重试和并发控制。我第二次重写检索模块，就是为了把并发控制从手写线程池改成asyncio信号量，这个改动看似小，但在实际运行中避免了大量"接口突然拒绝服务"的故障。
我个人在实际运行这套系统的过程中，最大的体会是这类研究辅助工具的价值从来不在“生成报告”那一瞬间的惊艳，而在于它把研究者从繁琐的信息收集与整理中解放出来，让人把省下来的精力和时间投入到真正需要人类判断力的地方——发现真问题、构思真方法、验证真假设。人工处理和机器处理之间不是互相替代的关系，而是一种分工。工具做得越顺手，研究的起点就越高，这才是它真正值钱的地方。
如果你也想搭一套类似的系统，建议从最小可行版本开始：先做"输入主题—检索文献—生成带引用的综述"这条主干链路，跑通之后再逐步增加迭代补检、矛盾分析、缓存优化这些进阶能力。把主干跑顺了，后面所有优化都只是在给一辆正常行驶的车加装功能；而如果一开始就想把系统做成一个面面俱到的庞然大物，大概率会因为调试困难而中途放弃。
