★ FEATURED ARTICLE 几年前我帮一个材料课题组搭内部工具看到他们每个人的浏览器里都挂着一百多个标签页一半是论文从检索入口进来就再也出不去了。这个场景给我的印象很深——文献检索只是科研流程的第一步后面跟着泛读、精读、笔记、实验设计、写作、引用管理每一站都有工具但站与站之间全是断头路。所以当AI Agent的概念火起来以后我第一反应不是再做一版能聊天的文献搜索框而是认真考虑一个问题能不能用一个 Agent 体系把从检索到产出的整条链路串起来做成一个真正可用的学术生态。这篇文章就是我们团队从0到1搭建这套系统的完整复盘包括架构思路、关键实现、踩坑记录以及我个人的取舍判断。1. 先把问题定义清楚AI Agent 到底接管科研的哪一段1.1 科研流程里的九个环节断点全在中间我把科研工作流拆过一遍大致是九个环节选题定义、文献检索、泛读筛选、精读理解、笔记与知识管理、实验或调研设计、数据分析、论文写作、参考文献与投稿管理。传统工具在这九个环节上其实都做得不错Zotero管文献Notion管笔记Overleaf管写作GraphPad管数据但麻烦在于这些工具之间没有数据通路。检索出来的论文不会自动变成笔记里的条目笔记里的观点不会自动成为写作时的引用素材写作时需要的参考文献格式又得重新手工整理一遍。我见过太多研究生把时间耗在这些衔接动作上下载PDF、改文件名、写摘要卡、在Word里手调参考文献格式。这些工作不创造任何学术价值但每天吃掉几个小时。AI Agent 在这里的真正价值不是更聪明的搜索而是把九个环节之间的断点接起来让信息从检索结果开始一路流到最终的论文产物里去。1.2 Agent 和聊天机器人的本质区别闭环执行与工具调用很多团队上来就想做一个学术问答助手用户提问、它回答看起来很像AI Agent但本质还是一个带RAG的聊天框。我理解的 Agent 有一个关键特征它能对一个目标做闭环执行。用户不说帮我搜索一下钙钛矿文献而是说我准备研究柔性钙钛矿太阳能电池的弯折稳定性帮我整理研究进展、找出待解决的问题、生成一份开题提纲这时候系统需要自主决定先检索、再精读、再归纳、再写作每一步还要调用实际工具去执行而不是只输出一段文字。学术场景给这个闭环执行加了一个很强的约束可溯源、可复现。这是Agent系统在科研领域和通用助理领域最大的区别。一般闲聊场景里模型编一句没问题的学术场景里每一条结论都得能指回某篇文献的某一段话否则这个系统不仅没用还会害人。这个约束决定了我们在技术选型上不能只依赖提示词必须把检索质量、证据链和人工确认做扎实后面的章节我会逐个展开。2. 文献检索层学术生态的入口我们是怎么搭的2.1 Query改写 多源召回别让 Agent 在一个数据库里打转文献检索是整个学术生态的地基原因很简单下游所有的阅读、设计、写作都建立在检索结果之上。检索质量差后面做的再多都是垃圾进垃圾出。这一层我们花了最多时间打磨第一件事就是解决检索式生成的问题。用户真实说出口的话往往不适合直接拿去检索。比如我想找钙钛矿太阳能电池稳定性相关的综述和最近两年的实验文章这句话里有论文类型综述/实验、有领域钙钛矿太阳能电池、有时间范围最近两年直接丢给arXiv搜索接口效果很差。我们让Agent先做一个Query改写动作把这句话解析成结构化的检索条件关键词拆成多个组合指定文献类型为review和experimental限定时间范围再根据来源库的语法各自生成检索式。改写这一步不复杂但收益极高最直观的变化是召回结果的准确率明显上升。改写之后是召回。我们采取了多源并行策略同时调用arXiv、PubMed、Semantic Scholar以及跨库聚合API再加一份本地私有文档库。为什么坚持多源因为学术文献高度分散材料类文章可能在ElsevierAI类文章主要在arXiv生物医学在PubMed单库检索永远有视野盲区。每个子Agent并行抓取用异步任务池控制并发聚合阶段再做合并。2.2 去重、过滤与两阶段重排让顶层的结果值得看多源召回带来一个新的问题同一个工作会在不同数据库里出现好几次而且每个库的元数据格式不一样。我们做了一个去重模块主键用DOI没有DOI的用标题归一化首作者年份生成指纹。这一层能去掉大约百分之二十到三十的重复结果别小看这个比例它对下游体验的影响很大。去重之后是过滤和排序。用户的需求往往带隐含偏好比如想要高引用的经典文章、想要近两年的新工作、想要开放获取的能下载全文的。我们把这几类偏好做成可配置的过滤规则再走两阶段排序。第一阶段用embedding模型算用户Query和候选文献的向量相似度粗筛出top50第二阶段用cross-encoder重排模型精排因为向量相似度对主题接近但实际不相关的情况区分度不够cross-encoder能对候选对做更细粒度的语义打分虽然慢但结果更准。两阶段合起来单次耗时大概增加两秒换来的是用户愿意多看几页的检索质量。2.3 溯源是第一诉求每一条结论都必须能指回原文学术场景做RAG最忌讳的是总结式回答。用户问最近钙钛矿稳定性研究的主流策略有哪些如果Agent只是汇总一段流畅的文字哪怕内容是对的用户也没法判断哪些话来自哪篇论文等于没法用。我们的做法是强制证据链输出。我把RAG的链路做了调整PDF解析成段落之后每个段落有唯一块ID向量检索命中某几个块时不是把块一股脑丢给模型生成而是要求模型输出结论-证据块ID的对应关系。比如采用二维/三维混合结构是提升稳定性的主要策略之一引用块IDdoc_238_p3这一句是示例实际展示中会以引用卡片形式呈现。展示层的摘要卡分三个字段结论、支持证据、来源块ID点击来源块可以直接跳回PDF原文段落。这样的设计在生成时确实增加了约束难度模型偶尔会产出没有对应证据的句子但我们宁可让系统少说两句也绝不让它无中生有。这一步是我们和很多RAG Demo拉开差距的关键也是学术用户信任这个系统的前提。3. 四段式Agent编排把科研全流程真正接起来3.1 子Agent的职责划分检索、阅读、设计、写作文献检索跑通之后我们开始往全流程延伸。架构上没有做一个万能大管家而是拆成四个职责单一的子Agent加一个主控Agent。职责划分是这套系统的核心每个子Agent只做一件事工具列表也精简到最少这样既好调试也好评估。子Agent核心输入核心输出主要工具检索Agent用户自然语言意图结构化文献列表、检索报告多源API、去重、重排模型阅读Agent文献全文或重要段落摘要卡、对比矩阵、证据块清单PDF解析器、向量库、抽取模型设计Agent对比矩阵、研究目标问题清单、实验方案草案、可行性分析模板库、引用库写作Agent提纲、笔记、引用素材章节初稿、参考文献条目Overleaf接口、BibTeX导出、风格模板为什么拆成四个而不是一个原因很简单它们对模型的温度、上下文策略、工具集合的诉求都不一样。检索Agent需要低创造性分析要冷静写作Agent需要一定的语言组织能力但又要受风格模板约束设计Agent最需要发散收敛两段式思考。如果塞进一个Agent提示词会互相打架改成四个独立的Agent加一个调度者之后每个模块的迭代都轻松很多。3.2 主控Agent不是流程图而是状态机加任务看板最初一版主控逻辑我写成了硬编码流程图检索 → 阅读 → 设计 → 写作顺序写死。上线之后很快发现问题——真实科研流程根本不是线性的。有的用户想先写综述再回头补检索有的用户已经有文献列表了只想直接做精读还有人希望先设计实验验证可行性后再去查文献。硬编码流程对这种场景毫无办法。第二版我们改成了状态机加任务看板。主控Agent负责把用户目标拆解成若干个子任务但子任务之间的关系不是预设的顺序而是依赖图。每个子任务有状态待处理、执行中、等待用户确认、已完成。用户可以在看板上调整顺序比如跳过当前阶段先做下一阶段。主控Agent在每个决策点做两件事判断哪些子任务满足执行条件以及判断要不要在关键节点停下来找用户确认。这套机制在两个月的真实使用中证明比流程图稳定得多它允许系统被用户打断和重定向这在科研协作里非常必要。3.3 一次完整会话走查从一句需求到一份开题提纲用一个真实例子走查全套流程。用户输入帮我看看柔性钙钛矿太阳能电池的弯折稳定性研究进展准备开题。主控把目标翻译成四个子任务检索相关文献、精读提取关键信息、生成问题清单和研究方案、起草开题提纲。任务看板先把检索Agent置为执行中。检索Agent完成多源召回、去重、重排后返回12篇核心文献列表和理由说明。此时主控没有直接进入下一步而是停下来问用户以下12篇文献是否符合方向有需要增删的吗——这个确认点我们刻意保留因为文献集合决定了后面所有分析的质量。用户确认后阅读Agent并行处理12篇全文产出每篇的摘要卡和一篇跨文献的对比矩阵对比维度包括材料体系、弯折测试方法、衰减机理、主要结论和待解决问题。用户修改了矩阵中两处表述标记确认。接着设计Agent基于矩阵和用户的研究目标生成四类输出现有研究的空白点、可复用的实验方案模板、关键表征手段建议、以及一份需要补充阅读的文献清单。用户删掉一条不切实际的建议后进入写作阶段。写作Agent基于前述所有材料生成开题提纲参考文献通过BibTeX自动挂接并输出到Overleaf草稿。完整走下来大约三十分钟中间有两次人工确认节点。同样的工作如果没有Agent一个有经验的博士生大概需要一到两天。更关键的是过程中的每一步产物都可视化保留用户随时知道现在推进到哪一步依据是什么。3.4 多Agent通信与会话隔离上下文不能串台多Agent协作时最容易翻车的问题就是上下文污染。很多平台都有类似疑问一个Agent能不能读取另一个Agent的会话内容技术上都支持但这通常不是功能需求而是事故隐患。如果子Agent之间共享上下文一个模块的中间噪声会污染另一个模块的判断出了问题还难以追责。我们用了一个轻量级的消息总线每个子Agent之间不共享任何对话历史只通过结构化消息传递信息。消息格式大致是这样包含来源Agent、目标Agent、任务类型、数据载荷、追踪ID。追踪ID贯穿一次完整任务日志里能查到当前结论来自哪一轮检索、哪一轮阅读、哪些文献块。会话隔离的代价是每个子Agent需要更完整的输入才能干活必须把 待精读文献的摘要卡和粗解析结果 打包传给阅读Agent。但这个代价非常值得隔离之后的系统行为规律很多几乎不存在A的输出影响B的判断这种玄学问题。4. 生态的底盘私有知识库、模型选型与工具链集成4.1 私有知识库不能只靠大模型的记忆科研文献是典型的长尾数据大模型训练时不可能覆盖每个课题组关心的细分方向。因此私有知识库是整个学术生态的另一个地基。我们用了大约一周时间搭知识库管线核心是四个环节。第一PDF解析。科研PDF最麻烦的是版面复杂页眉页脚、双栏排版、公式图表都会干扰解析。我们用解析器加版面分析模型提取正文段落过滤掉页眉页脚和纯图表区域。第二智能切块。按章节边界切块每个块控制在500到800字符之间块之间保留约百分之二十的重叠确保跨段语义不丢。第三向量化存储。用bge-m3这类中文英文都能处理较好的Embedding模型对块做向量化存入向量库并建立BM25倒排索引形成混合检索能力。第四增量更新。每篇文献入库时计算内容哈希重复文件直接跳过新文献增量写入不需要全量重建。这里我想强调混合检索的必要性。向量检索擅长语义相似但处理作者名年份特定术语这类精确条件时不稳定BM25恰恰擅长关键词精确匹配。线上实际效果里混合检索召回率比纯向量检索高出接近一成重排之后前五条的准确率改善更明显。4.2 让Agent真正动手Function Calling集成Zotero、Overleaf与笔记系统Agent如果没有操作工具的能力输出再准确也只能停留在建议层面。我们在第二期迭代里重点打通了工具执行核心方式是Function Calling。每个外部工具都封装成函数声明为结构化接口主控Agent在需要时发起调用。举几个实际封装的工具向Zotero添加文献条目并打标签、在Overleaf项目中写入TeX片段和更新参考文献BibTeX文件、在Notion或Obsidian中创建笔记页面、读取本地文献管理目录并重命名文件。每个函数都要返回结构化执行结果比如添加成功条目ID是xxx这样Agent才能依据真实结果做下一步决策而不是猜测。工具集成里最容易被低估的是错误处理。工具调用不是每次都会成功网络超时、接口限流、文件路径变动都发生过。我们给所有工具调用都加了明确的异常返回格式和重试策略并在看板上提示用户某个工具执行失败是否重试。这套机制在做技术选型时如果团队是Java技术栈可以参考Spring AI对Function Calling的声明式封装我们用的Python技术栈直接基于FastAPI写了统一的工具注册中心两种路线看队伍熟悉度没有绝对优劣。4.3 模型选型与成本控制通用对话模型加专业小模型混合整套系统的模型策略是混合调度而不是迷信单一最强模型。规划、拆解、用户沟通类的任务对推理能力要求高我们使用通用大模型比如GPT或Claude系列。但向量化、重排、摘要抽取这类重复性高、量大的任务放在通用模型上成本吃不消改用本地部署的开源模型qwen系列和bge系列足够用。这个决策是看了账单之后做的。通用模型的调用费用主要被三块吃掉检索Query改写与重排、全文摘要抽取、长期会话的历史压缩。这三块业务场景相对固定开源小模型完全能够胜任切过去之后成本降到原来的十分之一以下延迟也低了。另一个经验是缓存同一篇文献的摘要只要用户不主动要求刷新就不会重复调用模型生成直接命中缓存。学术场景里文献内容基本不变缓存命中率非常高。5. 从Demo到可用系统稳定性设计的四道坎5.1 LLM接口的不确定性重试、降级与JSON兜底Demo阶段谁都能跑通上了生产环境才知道模型接口有多脆弱。我们遇到的故障大致有三类连接超时、限流、返回内容解析失败。第一类用指数退避重试解决第一次失败等一秒再失败等四秒第三次等十六秒。第二类通过请求配额控制和服务端限流响应处理解决。第三类最烦人模型请求了JSON输出偶尔返回里还是夹带多余文字或者JSON结构少个逗号。我们的处理是三层兜底提示词里增强格式约束解析失败后用正则尝试截取JSON片段仍然失败就让主控Agent重新生成一次。这三层叠加之后JSON解析失败率从最初的百分之五降到了千分之一以内。另一个非常重要的体感是不要让Agent一次完成太多步骤宁可增加一次和用户的确认交互也不要让Agent在单轮里执行一个会失败的巨型任务。5.2 上下文窗口不是无限大长流程的上下文管理科研全流程是个长任务一轮开题提纲走下来中间涉及几十篇文献和多轮计算结果上下文不可能全部塞给模型。我们的思路是滑动窗口加摘要压缩。每个子Agent只保留本模块最近几轮的完整上下文更早的历史压缩成结构化摘要。主控Agent存任务级别的摘要不做全文记录。比如阅读Agent处理到第三篇文献时前两篇的完整文本已经被压缩成目标、方法、结论三行摘要只有需要精确引用时才回到知识库拉取原文块。这样一轮完整流程走完主控Agent的上下文占用仍然可控模型不会在后期因为上下文过长而质量下降。5.3 评估体系没有评测的Agent改造都是盲改我见过太多团队改Agent靠感觉换一个提示词试几条例子觉得不错就上线。这个做法在学术场景行不通因为案例太少偶然性太大。我们上线前就建了一套评估集包含70条覆盖检索、精读、设计、写作四类任务的典型输入其中至少一半来自真实用户历史请求。指标分三组。检索质量看RecallK和MRR衡量正确文献是否排进前列生成质量看忠实度和引用准确率小样本人工标注加LLM-as-judge辅助任务完成度看端到端成功率比如能否完整产出一份可用的开题提纲设定为一票否决项。每次改动提示词、换模型或者调整工具调用逻辑都要跑一遍这70条评估集对比指标变化。这个习惯帮我们挡掉了好几次感觉变聪明了实际变笨了的改动比如有一次换了更强的新模型对话体验明显提升但引用准确率掉了一截还好评估集拦住了没有上线。5.4 兜底机制人工接管与结果审计最后必须说清楚边界这个系统从来没有试图取代科研人员的判断。所有关键节点都有两道兜底。第一道是人工确认节点。检索结果、对比矩阵、实验方案建议、写作提纲这四个节点都要经过用户确认或修改才会进入下一环节。Agent产出的所有内容都标记为草稿状态用户接受后才转为正式材料。第二道是审计面板系统会展示每个结论的证据链结论来自哪个Agent、引用了哪些文献块、使用了哪个工具的哪次返回结果。用户点开就能看到推理过程发现可疑结果可以一键撤销并重新执行。这两道兜底机制从产品上线第一天就有它牺牲了一定的全自动噱头但换来了科研群体最基本的安全感。系统跑了三个月之后我最深的体会是学术界不缺写作工具也不缺文献数据库缺的是一个把碎片串成流程的胶水层。AI Agent 恰好能扮演这个角色但前提是你必须老老实实把检索质量、证据溯源和人工兜底做扎实。如果有人在你的楼下想复刻这套体系我会劝他别一上来就上多Agent先把检索到溯源这一段跑通让用户愿意用、敢用再向全流程扩展。技术栈会过时模型会迭代但这个循序渐进的路子我目前看下来还没走错。
阅读完成 · 觉得有帮助？
