2026/9/7 14:58:22
FEATURED · 精选文章 
AI读论文这个选题其实是我自己先被逼到墙角的产物。这周我在群里又看到有人吐槽ArXiv上每天几十篇新论文收藏了上百篇“待读”真正看完的可能不到五篇。确实干这行的都知道光靠人肉刷论文一天时间搭进去也看不完几篇而且看完过两周就忘等于白看。后来我花了一个周末用Agent智能体把“读论文”这件事拆成了流水线从抓取、解析、精读、笔记入库到基于个人知识库的追问全自动跑通。这篇文章就是这个“AI读论文-Agent系列”的第一篇想把我当时的项目设计、框架选型、踩坑记录和完整实现思路摊开来讲给准备做agent开发、或者正在纠结怎么用AI辅助自己读论文的朋友一个可以抄作业的参考。先说清楚这套东西到底解决什么问题。它不是一个简单的论文问答机器人像一个对话框问你“这篇论文在讲什么”然后吐一段摘要那样其实没什么用。我想要的是一个真正能“干活”的助手你丢给它一个论文标题或者一个研究方向它能自己去检索相关论文、下载PDF、拆解全文结构、把摘要、方法、实验数据、结论整理成结构化笔记存进你自己的知识库里之后你再问它“之前看过那篇关于注意力机制改进的论文关键公式是什么”它能基于长期记忆翻出来告诉你。整个链路里Agent的主动规划、工具调用和记忆模块才是核心而不是模型本身。1. 项目定位与整体设计思路1.1 为什么单单一个大模型不够用很多人刚开始会有一个疑问ChatGPT、Claude这些大模型本身就能读论文为什么还要专门搞一个Agent项目我当时的回答是你问一次可以但没法持续地、批量地、按固定流程地处理论文。具体来说用大模型对话框读论文有几个硬伤。第一是上下文窗口有限一篇动辄十几页、带大量公式图表的论文一次性塞进去不是不行但算力和成本都很高而且塞进去之后你再想让它和之前读过的另一篇论文做对比它就“失忆”了。第二是它不会主动干活你得手动上传PDF、手动复制标题、手动把笔记粘出来整个过程半点不省心。第三是最关键的——没有沉淀读完就完知识无法积累。所以我在设计这套系统时先给自己定了三条底层原则一是让Agent成为流程的驱动者而不是被动问答的聊天框二是必须带长期记忆每一次阅读的结果都要沉淀下来形成个人论文库三是所有中间环节下载PDF、解析文本、向量化入库、生成笔记都做成可插拔的工具函数方便后面扩展。1.2 三个核心需求拆解这个项目表面上叫“AI读论文”拆开来看其实是由三个子需求叠加而成的。第一个是论文资源的自动获取。包括从ArXiv按关键词或论文ID拉取元数据与PDF也包括本地已经囤好的PDF文件批量导入。不能假设用户一定会从某个入口拖文件系统要兼容“标题检索下载”和“本地文件上传”两条路径。第二个是内容的深度解析。论文不是普通文档它有摘要、引言、相关工作、方法、实验、结论这些固定结构还有公式、表格、图表这些非纯文本元素。解析的目标是把PDF变成结构化数据至少要有章节标题层级和正文段落最好还能把每个章节的核心观点抽出来。第三个是知识沉淀和记忆。这一块我放到架构层面重点设计因为普通的RAG检索增强生成只能解决“从库里找内容”但Agent要解决的是“记住你看过什么、你对它的评价是什么”。所以系统里需要两种记忆短期记忆用来保持当前对话的连贯性长期记忆用来记录论文的元信息、向量索引和用户手写的笔记。这三个需求对应的技术模块分别是检索工具模块、PDF解析模块、记忆与向量库模块。后面三章我会逐个展开讲实现。1.3 读论文Agent的典型使用场景我做了几个具体的场景来约束功能边界不然项目容易失控。场景一是“定向精读”用户说“帮我读一下Attention Is All You Need”Agent自动去ArXiv下载PDF生成结构化精读笔记包括核心方法、关键公式、实验结论和个人思考建议。场景二是“主题综述”用户说“最近三个月Transformer轻量化有什么进展”Agent批量检索相关论文逐个生成摘要再汇总成一份带引用链接的综述草稿。场景三是“知识追问”用户问“上次看的那篇用知识蒸馏压缩BERT的论文训练温度设置的多少”Agent需要去长期记忆里检索而不是重新去网上找。这三个场景要求系统同时具备检索、解析、记忆、生成四条核心能力缺一条体验都会断掉。2. Agent架构、框架选型与记忆设计2.1 单体Agent加工具集合还是多Agent协同做Agent开发时第一个要拍板的问题就是架构到底做一个全能Agent还是拆成多个各司其职的子Agent。我见过一些项目一上来就搞三个Agent互相聊天一个负责搜索一个负责总结一个负责审核听起来很智能实际上调试的时候全是坑。子Agent之间的消息传递、上下文隔离、死循环控制每一项都要额外花大量精力。我的建议是在读论文这个垂直场景里单体Agent加工具集合是性价比最高的架构。也就是说只有一个主Agent负责理解用户意图、决定下一步调用什么工具工具包括检索论文、解析PDF、查记忆库、写笔记等。主Agent本身不需要维护多轮“对话”的状态它只需要在跑完当前这一步之后根据结果决定下一步去哪。这种设计的好处是流程可控、问题可追踪坏处是并行度不够高但读论文这个场景本身对实时并发的要求不高。如果后面非要升级成多Agent我建议把“批量综述”拆成一个独立的编排任务让它内部串行处理多篇论文。这个后续系列文章里我会专门写一篇。2.2 框架选型LangGraph、Spring AI和轻量自建选框架是个很现实的问题。我当时在LangGraph、Spring AI、还有完全自己写循环这三者之间纠结了很久最后选了LangGraph。理由有三个它有状态图机制天然适合把“检索-解析-总结-记忆”这种多步骤流程画成图来执行它有内置的checkpoint机制可以在每一步保存状态万一中间某次工具调用挂了可以从最近的成功状态恢复不用重头跑第三是Python生态里做向量化、PDF解析的工具最全。Spring AI我也简单调研过它是Java生态里做AI应用的标准方案如果你是Java后端团队不想引入Python服务用它没问题。但从我实际体验来看Spring AI目前的抽象层级还比较浅复杂的状态编排要自己写不少胶水代码而且社区里的AI Agent案例明显比Python这边少。轻量自建方案我也认真想过核心逻辑无非是while循环加工具函数分发代码确实很透明但有两个坑很难绕过一个是记忆管理对话历史的截断、摘要、持久化自己写容易写得粗糙另一个是工具调用的重试与异常恢复没有图状态管理中断以后从哪一步继续就要自己记。所以最后我明确主力用LangGraph局部模块自建。2.3 记忆模块设计短期、长期与向量记忆Agent记忆一直是被很多人忽略、但又最影响体验的部分。读论文场景里我把记忆分成三层。短期记忆就是当前任务上下文。用LangGraph的messages key来存跑一次任务可能产生几十条消息记录我会在每轮工具调用后做一次消息裁剪把太老的对话记录改成摘要避免上下文窗口被无关内容塞满。长期记忆是论文知识库的核心。我用一个SQLite数据库存论文的元信息包括论文标题、作者、年份、原文链接、本地PDF路径、阅读状态、用户笔记。这些信息是结构化的用数据库存方便查询。向量记忆用来存论文的语义向量。这里特指章节级别的向量不是整篇论文一个向量那样太粗。比如一篇论文有六个章节我就把引言、方法、实验这帮块分别做向量化存进向量库。查询的时候用户可以问“关于相对位置编码的讨论”向量库能定位到具体章节而不是把整篇论文找出来。这三层记忆在系统里各有分工配合起来用效果最好。我见过有些开源项目只做一层向量库结果用户问“我上个月看了哪些关于目标检测的论文”这种元信息问题向量库一点办法都没有因为这个问题根本不需要语义相似度直接查SQL就行。3. 核心功能模块的实现细节3.1 论文解析从PDF到干净的结构化文本读论文的第一个拦路虎是PDF解析。我一开始图省事直接用PyMuPDF把PDF每一页抽成纯文本跑通以后发现效果不太行。学术论文尤其是双栏排版的PyMuPDF抽出来的文本经常出现左右栏交错、段落断裂的问题一段话读起来前言不搭后语。公式更是重灾区解析出来的内容全是乱码和符号错位根本没法用。后来我换了思路解析分两步走。第一步用PyMuPDF抽取原始文本和页面信息但只拿它做“粗提取”第二步用MinerU或者Grobid做版面分析MinerU能识别出标题、段落、图表、公式的区域位置输出的Markdown格式非常干净双栏也能处理。代价是MinerU体积大、第一次跑要下载模型但效果确实值得。代码大概长这样import fitz from mineru import MinerU def extract_pdf_content(pdf_path: str) - str: # 第一步PyMuPDF粗提取检查PDF是否加密或损坏 doc fitz.open(pdf_path) page_count doc.page_count doc.close() # 第二步MinerU精细解析输出markdown mineru MinerU() result mineru.analyze(pdf_path) # 返回典型结构{title: ..., sections: [{heading: ..., body: ...}]} return result.to_markdown()这里有个很重要的细节解析结果不要直接丢给大模型让它总结全文而是先把结果拆成章节块按章节来读。比如我先让Agent看一眼目录结构再按顺序读取每个章节内容。这样做的好处是避免一次塞太多内容导致上下文爆炸也能让Agent在读到“实验”这一章时主动去对比“方法”那一章里的设定。3.2 检索与向量化让论文可以按语义被找到解析完的论文要变成可检索的知识就得做向量化。我用的向量库是ChromaDB选它的原因很简单轻量、纯Python、支持持久化个人项目跑在本地完全够用不需要额外起一个服务。如果你论文量超过一万篇再考虑换Milvus或者Qdrant。嵌入模型我试过OpenAI的text-embedding-3-small和本地的BGE-M3。如果只是自己用我推荐BGE-M3中文和英文都支持效果不输商业模型而且完全本地部署论文内容不会因为做向量化而被发到第三方接口这对很多做研究的人来说是底线要求。向量化要注意颗粒度问题我刚开始把整篇论文作为一个向量存进去检索效果很差问一个具体概念召回的是一整篇论文还要靠模型二次筛选。后来改成章节级切块每个章节作为一个document带上标题和论文ID。查询的时候先做向量检索找到TopK个相关章节再通过章节里的论文ID去SQLite里把对应的论文元信息拉出来两个库一配合效果立刻好了很多。核心代码import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./paper_kb) collection client.get_or_create_collection( namesections, embedding_functionembedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-m3 ), ) def add_paper_section(paper_id: str, section: dict): collection.upsert( ids[f{paper_id}:{section[index]}], documents[section[content]], metadatas[{paper_id: paper_id, heading: section[heading]}], ) def search_sections(query: str, top_k: int 5): return collection.query(query_texts[query], n_resultstop_k)向量库只是入口真正存放“事实”的还是SQLite。把向量检索和元数据查询分开这个架构一开始就定好后面加功能会非常省事。3.3 Agent工具定义与主循环搭建Agent的“手”就是工具函数。我在这套系统里定义了七个工具arxiv_search按关键词搜论文arxiv_download下载指定ID的PDFextract_paper解析PDF并拆分成章节search_paper_kb在本地知识库里做向量检索query_paper_meta按标题或作者查SQLite元数据save_note把当前论文和用户笔记写入长期记忆list_recent_papers列出最近读过的论文。工具定义好以后主Agent的作用就是判断当前应该调用哪个工具以及根据工具返回的结果决定下一步做什么。LangGraph里我把流程定义成一个状态图节点包括plan、call_tool、observe、write_memory节点之间根据状态转移。核心代码结构如下from langgraph.graph import StateGraph, END class PaperReadingState(TypedDict): task: str current_paper: dict notes: str messages: list def route(state: PaperReadingState) - str: if not state[current_paper]: return search if 笔记 in state[task] or 总结 in state[task]: return write return search graph StateGraph(PaperReadingState) graph.add_node(search, arxiv_search_node) graph.add_node(parse, parse_pdf_node) graph.add_node(summarize, summarize_node) graph.add_node(write, save_note_node) graph.add_conditional_edges(search, route) graph.add_edge(parse, summarize) graph.add_edge(summarize, write) graph.add_edge(write, END)可能有人会问直接写Python脚本按顺序跑不就行了为什么非要上Agent框架。区别在于脚本是对固定输入的固定处理而Agent能根据用户的任务描述动态决定执行哪条路径。比如用户说“搜一下最新的目标检测论文挑一篇读一下然后写个50字笔记”Agent会在搜索之后自己判断要下载哪一篇、解析哪一篇而不是所有论文都全流程跑一遍这中间差的就是Agent的规划能力。4. 实战把Agent跑起来到对外提供服务4.1 环境准备与项目结构我建议这个项目先本地跑通再考虑服务化否则调试成本太高。硬件方面一台16G内存的普通电脑足够不需要GPU因为嵌入模型用小模型生成部分我接的是云端大模型API。项目结构我按模块拆paper-agent/ ├── agent/ │ ├── graph.py # LangGraph状态图 │ ├── nodes.py # 各节点逻辑 │ └── tools.py # 工具函数 ├── parser/ │ └── pdf_parser.py # PDF解析封装 ├── memory/ │ ├── vector_store.py # ChromaDB封装 │ └── meta_store.py # SQLite封装 ├── data/ │ ├── pdfs/ # PDF存放目录 │ └── kb/ # 向量库与数据库 ├── requirements.txt └── run.py # 入口依赖方面核心就几个langgraph、chromadb、sentence-transformers、pymupdf、mineru、fastapi和uvicorn。版本要注意锁定LangGraph的API在0.2到0.3版本之间改过不少我一开始没锁版本升级之后状态图报错排查了半天才发现是兼容性问题。4.2 跑通一次完整的读论文流程搭好框架后我拿一篇论文做端到端测试输入就是一句话“帮我读一下Attention Is All You Need然后写一篇200字的笔记存进库里。”整个流程跑下来是这样走完的。第一步Agent在plan节点里识别到“读一下”这个动作匹配到工具链需求先走arxiv_search工具搜索到论文的元信息和PDF链接。第二步调用arxiv_download把PDF下载到data/pdfs目录。第三步extract_paper解析PDF每篇论文大概会生成7到10个章节块我把这些块打印出来确认结构是否干净。第四步summarize节点逐块读取内容并调用模型生成结构化总结。第五步save_note把论文元数据和用户要求的200字笔记写入SQLite同时把章节向量写入ChromaDB。实测跑完整个流程大约需要一到两分钟主要时间花在MinerU解析PDF上生成总结反而是很快的。这一步验证通过以后我立刻加了一个用户确认机制写进知识库之前Agent会先把笔记草稿给用户看用户回复确认才写入。原因是AI生成的笔记可能带幻觉比如实验数据明明不存在模型会根据上下文猜一个结果出来这种错误一旦写进长期记忆后面再查出来会误导自己。确认机制虽然多了一步人工操作但对知识库的洁净度非常必要。4.3 从命令行到FastAPI服务化命令行跑通以后我开始做服务化。其实理由很简单命令行没法让手机或者其他设备随时调用而且我想把能力开放给家里人用总不能让他们去命令行里敲指令。服务层我用FastAPI包了一层暴露两个接口。一个是同步的health检查另一个是异步的任务提交接口调用时传入用户的任务描述返回一个task_id后台用队列跑Agent流程完成后把结果存到数据库前端通过task_id轮询拿结果。这样设计不是为了炫技是因为Agent跑一篇论文要一两分钟同步HTTP请求大概率会超时后台异步处理是标准解法。这里有个安全细节token级别权限隔离必须提前设计。我一开始没做隔离所有用户共用一个知识库结果测试的时候我自己写的论文笔记和别人读的论文全混在一起了。后来我在所有表和向量集合上都加了user_id字段每个用户独立存储。部署的时候我踩过一个很典型的坑。当时想用Agent辅助做部署让它帮我写Dockerfile和启动脚本它在本地跑的时候一切正常换成Docker以后向量库和PDF目录的路径没有挂载出来容器重启数据就全没了。排查到最后发现Agent生成配置时根本不知道宿主机上data目录的位置这种事还是得人工盯着。所以后来我养成了一个习惯凡是涉及数据持久化的配置做完之后一定手动检查一遍路径映射。5. 常见问题与排查技巧实录5.1 图表和公式识别失败这是读论文项目里最普遍的问题尤其是公式密集的数学类论文。PyMuPDF抽出来的公式都是一堆乱码符号MinerU会好很多但还是会在复杂矩阵和特殊符号上出错。我的处理办法是双通道。文本通道用MinerU解析当识别到“该部分包含复杂公式文本提取置信度较低”这类情况时触发图像通道将这一页渲染成图片调用带视觉能力的大模型接口让模型直接读图理解公式。这个兜底策略实测效果很好但成本会高一些我只在特定章节启用。5.2 长论文上下文爆炸有的论文正文加附录一共三十多页如果一股脑全塞给模型一来费用高二来模型会忽略中间细节。我的做法是分级读取先让Agent只读章节标题和第一段生成一个论文地图然后根据用户问题只读取相关章节的完整内容。比如用户只关心实验设置Agent就不读相关工作那一章的细节。5.3 记忆污染与重复入库同一个论文标题用户反复导入多次每次都会生成新的向量记录长期累积下来知识库非常臃肿。我在入库前加了一层去重判断依据是ArXiv的论文ID如果是本地PDF用文件内容的SHA256哈希做指纹重复导入时不再重建向量而是直接返回已有记录。5.4 工具调用过程中的异常与中断Agent在跑的过程中偶尔会出现“工具执行报错”的情况比如ArXiv接口限流、PDF下载超时、向量库写入失败。LangGraph的checkpoint机制在这种时候很有用能从上一次成功的节点恢复但我还是额外加了一个重试逻辑每个工具函数都包了一层retry装饰器连续失败三次才把错误抛给Agent让Agent决定是否换一种方式完成任务。5.5 常见问题速查表问题可能原因解决办法解析出的文本双栏错乱直接用了PyMuPDF提取文本改用MinerU或Grobid做版面分析检索到的章节和问题无关向量化颗粒度太粗改为章节级切块绑定论文ID笔记里出现论文没有的数据大模型幻觉增加用户确认再写入长期记忆重新部署后历史记录丢失数据目录未挂载处理Volumes映射Paper存放目录必须持久化Agent答非所问短期记忆被旧任务污染每次任务开始前清空messages上下文读论文耗时长MinerU解析过慢对已解析过的论文做缓存按哈希跳过我个人在实际项目里最深的体会是读论文Agent的价值不在于它能把一篇论文总结得多漂亮而在于它能把“读论文”这个动作变成有积累、可回溯、能被检索的过程。模型负责理解架构负责记忆工具负责执行三者配合才把一个原本靠人肉坚持的习惯转化成了一套可持续运转的系统。这个系列后面我还会继续写Agent记忆的细化、批量综述的编排、以及如何接入不同模型提供商的方案欢迎拿这套代码先跑起来折腾。
AI读论文Agent实战：从PDF解析到知识库记忆的完整实现
AI读论文这个选题其实是我自己先被逼到墙角的产物。这周我在群里又看到有人吐槽ArXiv上每天几十篇新论文收藏了上百篇“待读”真正看完的可能不到五篇。确实干这行的都知道光靠人肉刷论文一天时间搭进去也看不完几篇而且看完过两周就忘等于白看。后来我花了一个周末用Agent智能体把“读论文”这件事拆成了流水线从抓取、解析、精读、笔记入库到基于个人知识库的追问全自动跑通。这篇文章就是这个“AI读论文-Agent系列”的第一篇想把我当时的项目设计、框架选型、踩坑记录和完整实现思路摊开来讲给准备做agent开发、或者正在纠结怎么用AI辅助自己读论文的朋友一个可以抄作业的参考。先说清楚这套东西到底解决什么问题。它不是一个简单的论文问答机器人像一个对话框问你“这篇论文在讲什么”然后吐一段摘要那样其实没什么用。我想要的是一个真正能“干活”的助手你丢给它一个论文标题或者一个研究方向它能自己去检索相关论文、下载PDF、拆解全文结构、把摘要、方法、实验数据、结论整理成结构化笔记存进你自己的知识库里之后你再问它“之前看过那篇关于注意力机制改进的论文关键公式是什么”它能基于长期记忆翻出来告诉你。整个链路里Agent的主动规划、工具调用和记忆模块才是核心而不是模型本身。1. 项目定位与整体设计思路1.1 为什么单单一个大模型不够用很多人刚开始会有一个疑问ChatGPT、Claude这些大模型本身就能读论文为什么还要专门搞一个Agent项目我当时的回答是你问一次可以但没法持续地、批量地、按固定流程地处理论文。具体来说用大模型对话框读论文有几个硬伤。第一是上下文窗口有限一篇动辄十几页、带大量公式图表的论文一次性塞进去不是不行但算力和成本都很高而且塞进去之后你再想让它和之前读过的另一篇论文做对比它就“失忆”了。第二是它不会主动干活你得手动上传PDF、手动复制标题、手动把笔记粘出来整个过程半点不省心。第三是最关键的——没有沉淀读完就完知识无法积累。所以我在设计这套系统时先给自己定了三条底层原则一是让Agent成为流程的驱动者而不是被动问答的聊天框二是必须带长期记忆每一次阅读的结果都要沉淀下来形成个人论文库三是所有中间环节下载PDF、解析文本、向量化入库、生成笔记都做成可插拔的工具函数方便后面扩展。1.2 三个核心需求拆解这个项目表面上叫“AI读论文”拆开来看其实是由三个子需求叠加而成的。第一个是论文资源的自动获取。包括从ArXiv按关键词或论文ID拉取元数据与PDF也包括本地已经囤好的PDF文件批量导入。不能假设用户一定会从某个入口拖文件系统要兼容“标题检索下载”和“本地文件上传”两条路径。第二个是内容的深度解析。论文不是普通文档它有摘要、引言、相关工作、方法、实验、结论这些固定结构还有公式、表格、图表这些非纯文本元素。解析的目标是把PDF变成结构化数据至少要有章节标题层级和正文段落最好还能把每个章节的核心观点抽出来。第三个是知识沉淀和记忆。这一块我放到架构层面重点设计因为普通的RAG检索增强生成只能解决“从库里找内容”但Agent要解决的是“记住你看过什么、你对它的评价是什么”。所以系统里需要两种记忆短期记忆用来保持当前对话的连贯性长期记忆用来记录论文的元信息、向量索引和用户手写的笔记。这三个需求对应的技术模块分别是检索工具模块、PDF解析模块、记忆与向量库模块。后面三章我会逐个展开讲实现。1.3 读论文Agent的典型使用场景我做了几个具体的场景来约束功能边界不然项目容易失控。场景一是“定向精读”用户说“帮我读一下Attention Is All You Need”Agent自动去ArXiv下载PDF生成结构化精读笔记包括核心方法、关键公式、实验结论和个人思考建议。场景二是“主题综述”用户说“最近三个月Transformer轻量化有什么进展”Agent批量检索相关论文逐个生成摘要再汇总成一份带引用链接的综述草稿。场景三是“知识追问”用户问“上次看的那篇用知识蒸馏压缩BERT的论文训练温度设置的多少”Agent需要去长期记忆里检索而不是重新去网上找。这三个场景要求系统同时具备检索、解析、记忆、生成四条核心能力缺一条体验都会断掉。2. Agent架构、框架选型与记忆设计2.1 单体Agent加工具集合还是多Agent协同做Agent开发时第一个要拍板的问题就是架构到底做一个全能Agent还是拆成多个各司其职的子Agent。我见过一些项目一上来就搞三个Agent互相聊天一个负责搜索一个负责总结一个负责审核听起来很智能实际上调试的时候全是坑。子Agent之间的消息传递、上下文隔离、死循环控制每一项都要额外花大量精力。我的建议是在读论文这个垂直场景里单体Agent加工具集合是性价比最高的架构。也就是说只有一个主Agent负责理解用户意图、决定下一步调用什么工具工具包括检索论文、解析PDF、查记忆库、写笔记等。主Agent本身不需要维护多轮“对话”的状态它只需要在跑完当前这一步之后根据结果决定下一步去哪。这种设计的好处是流程可控、问题可追踪坏处是并行度不够高但读论文这个场景本身对实时并发的要求不高。如果后面非要升级成多Agent我建议把“批量综述”拆成一个独立的编排任务让它内部串行处理多篇论文。这个后续系列文章里我会专门写一篇。2.2 框架选型LangGraph、Spring AI和轻量自建选框架是个很现实的问题。我当时在LangGraph、Spring AI、还有完全自己写循环这三者之间纠结了很久最后选了LangGraph。理由有三个它有状态图机制天然适合把“检索-解析-总结-记忆”这种多步骤流程画成图来执行它有内置的checkpoint机制可以在每一步保存状态万一中间某次工具调用挂了可以从最近的成功状态恢复不用重头跑第三是Python生态里做向量化、PDF解析的工具最全。Spring AI我也简单调研过它是Java生态里做AI应用的标准方案如果你是Java后端团队不想引入Python服务用它没问题。但从我实际体验来看Spring AI目前的抽象层级还比较浅复杂的状态编排要自己写不少胶水代码而且社区里的AI Agent案例明显比Python这边少。轻量自建方案我也认真想过核心逻辑无非是while循环加工具函数分发代码确实很透明但有两个坑很难绕过一个是记忆管理对话历史的截断、摘要、持久化自己写容易写得粗糙另一个是工具调用的重试与异常恢复没有图状态管理中断以后从哪一步继续就要自己记。所以最后我明确主力用LangGraph局部模块自建。2.3 记忆模块设计短期、长期与向量记忆Agent记忆一直是被很多人忽略、但又最影响体验的部分。读论文场景里我把记忆分成三层。短期记忆就是当前任务上下文。用LangGraph的messages key来存跑一次任务可能产生几十条消息记录我会在每轮工具调用后做一次消息裁剪把太老的对话记录改成摘要避免上下文窗口被无关内容塞满。长期记忆是论文知识库的核心。我用一个SQLite数据库存论文的元信息包括论文标题、作者、年份、原文链接、本地PDF路径、阅读状态、用户笔记。这些信息是结构化的用数据库存方便查询。向量记忆用来存论文的语义向量。这里特指章节级别的向量不是整篇论文一个向量那样太粗。比如一篇论文有六个章节我就把引言、方法、实验这帮块分别做向量化存进向量库。查询的时候用户可以问“关于相对位置编码的讨论”向量库能定位到具体章节而不是把整篇论文找出来。这三层记忆在系统里各有分工配合起来用效果最好。我见过有些开源项目只做一层向量库结果用户问“我上个月看了哪些关于目标检测的论文”这种元信息问题向量库一点办法都没有因为这个问题根本不需要语义相似度直接查SQL就行。3. 核心功能模块的实现细节3.1 论文解析从PDF到干净的结构化文本读论文的第一个拦路虎是PDF解析。我一开始图省事直接用PyMuPDF把PDF每一页抽成纯文本跑通以后发现效果不太行。学术论文尤其是双栏排版的PyMuPDF抽出来的文本经常出现左右栏交错、段落断裂的问题一段话读起来前言不搭后语。公式更是重灾区解析出来的内容全是乱码和符号错位根本没法用。后来我换了思路解析分两步走。第一步用PyMuPDF抽取原始文本和页面信息但只拿它做“粗提取”第二步用MinerU或者Grobid做版面分析MinerU能识别出标题、段落、图表、公式的区域位置输出的Markdown格式非常干净双栏也能处理。代价是MinerU体积大、第一次跑要下载模型但效果确实值得。代码大概长这样import fitz from mineru import MinerU def extract_pdf_content(pdf_path: str) - str: # 第一步PyMuPDF粗提取检查PDF是否加密或损坏 doc fitz.open(pdf_path) page_count doc.page_count doc.close() # 第二步MinerU精细解析输出markdown mineru MinerU() result mineru.analyze(pdf_path) # 返回典型结构{title: ..., sections: [{heading: ..., body: ...}]} return result.to_markdown()这里有个很重要的细节解析结果不要直接丢给大模型让它总结全文而是先把结果拆成章节块按章节来读。比如我先让Agent看一眼目录结构再按顺序读取每个章节内容。这样做的好处是避免一次塞太多内容导致上下文爆炸也能让Agent在读到“实验”这一章时主动去对比“方法”那一章里的设定。3.2 检索与向量化让论文可以按语义被找到解析完的论文要变成可检索的知识就得做向量化。我用的向量库是ChromaDB选它的原因很简单轻量、纯Python、支持持久化个人项目跑在本地完全够用不需要额外起一个服务。如果你论文量超过一万篇再考虑换Milvus或者Qdrant。嵌入模型我试过OpenAI的text-embedding-3-small和本地的BGE-M3。如果只是自己用我推荐BGE-M3中文和英文都支持效果不输商业模型而且完全本地部署论文内容不会因为做向量化而被发到第三方接口这对很多做研究的人来说是底线要求。向量化要注意颗粒度问题我刚开始把整篇论文作为一个向量存进去检索效果很差问一个具体概念召回的是一整篇论文还要靠模型二次筛选。后来改成章节级切块每个章节作为一个document带上标题和论文ID。查询的时候先做向量检索找到TopK个相关章节再通过章节里的论文ID去SQLite里把对应的论文元信息拉出来两个库一配合效果立刻好了很多。核心代码import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./paper_kb) collection client.get_or_create_collection( namesections, embedding_functionembedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-m3 ), ) def add_paper_section(paper_id: str, section: dict): collection.upsert( ids[f{paper_id}:{section[index]}], documents[section[content]], metadatas[{paper_id: paper_id, heading: section[heading]}], ) def search_sections(query: str, top_k: int 5): return collection.query(query_texts[query], n_resultstop_k)向量库只是入口真正存放“事实”的还是SQLite。把向量检索和元数据查询分开这个架构一开始就定好后面加功能会非常省事。3.3 Agent工具定义与主循环搭建Agent的“手”就是工具函数。我在这套系统里定义了七个工具arxiv_search按关键词搜论文arxiv_download下载指定ID的PDFextract_paper解析PDF并拆分成章节search_paper_kb在本地知识库里做向量检索query_paper_meta按标题或作者查SQLite元数据save_note把当前论文和用户笔记写入长期记忆list_recent_papers列出最近读过的论文。工具定义好以后主Agent的作用就是判断当前应该调用哪个工具以及根据工具返回的结果决定下一步做什么。LangGraph里我把流程定义成一个状态图节点包括plan、call_tool、observe、write_memory节点之间根据状态转移。核心代码结构如下from langgraph.graph import StateGraph, END class PaperReadingState(TypedDict): task: str current_paper: dict notes: str messages: list def route(state: PaperReadingState) - str: if not state[current_paper]: return search if 笔记 in state[task] or 总结 in state[task]: return write return search graph StateGraph(PaperReadingState) graph.add_node(search, arxiv_search_node) graph.add_node(parse, parse_pdf_node) graph.add_node(summarize, summarize_node) graph.add_node(write, save_note_node) graph.add_conditional_edges(search, route) graph.add_edge(parse, summarize) graph.add_edge(summarize, write) graph.add_edge(write, END)可能有人会问直接写Python脚本按顺序跑不就行了为什么非要上Agent框架。区别在于脚本是对固定输入的固定处理而Agent能根据用户的任务描述动态决定执行哪条路径。比如用户说“搜一下最新的目标检测论文挑一篇读一下然后写个50字笔记”Agent会在搜索之后自己判断要下载哪一篇、解析哪一篇而不是所有论文都全流程跑一遍这中间差的就是Agent的规划能力。4. 实战把Agent跑起来到对外提供服务4.1 环境准备与项目结构我建议这个项目先本地跑通再考虑服务化否则调试成本太高。硬件方面一台16G内存的普通电脑足够不需要GPU因为嵌入模型用小模型生成部分我接的是云端大模型API。项目结构我按模块拆paper-agent/ ├── agent/ │ ├── graph.py # LangGraph状态图 │ ├── nodes.py # 各节点逻辑 │ └── tools.py # 工具函数 ├── parser/ │ └── pdf_parser.py # PDF解析封装 ├── memory/ │ ├── vector_store.py # ChromaDB封装 │ └── meta_store.py # SQLite封装 ├── data/ │ ├── pdfs/ # PDF存放目录 │ └── kb/ # 向量库与数据库 ├── requirements.txt └── run.py # 入口依赖方面核心就几个langgraph、chromadb、sentence-transformers、pymupdf、mineru、fastapi和uvicorn。版本要注意锁定LangGraph的API在0.2到0.3版本之间改过不少我一开始没锁版本升级之后状态图报错排查了半天才发现是兼容性问题。4.2 跑通一次完整的读论文流程搭好框架后我拿一篇论文做端到端测试输入就是一句话“帮我读一下Attention Is All You Need然后写一篇200字的笔记存进库里。”整个流程跑下来是这样走完的。第一步Agent在plan节点里识别到“读一下”这个动作匹配到工具链需求先走arxiv_search工具搜索到论文的元信息和PDF链接。第二步调用arxiv_download把PDF下载到data/pdfs目录。第三步extract_paper解析PDF每篇论文大概会生成7到10个章节块我把这些块打印出来确认结构是否干净。第四步summarize节点逐块读取内容并调用模型生成结构化总结。第五步save_note把论文元数据和用户要求的200字笔记写入SQLite同时把章节向量写入ChromaDB。实测跑完整个流程大约需要一到两分钟主要时间花在MinerU解析PDF上生成总结反而是很快的。这一步验证通过以后我立刻加了一个用户确认机制写进知识库之前Agent会先把笔记草稿给用户看用户回复确认才写入。原因是AI生成的笔记可能带幻觉比如实验数据明明不存在模型会根据上下文猜一个结果出来这种错误一旦写进长期记忆后面再查出来会误导自己。确认机制虽然多了一步人工操作但对知识库的洁净度非常必要。4.3 从命令行到FastAPI服务化命令行跑通以后我开始做服务化。其实理由很简单命令行没法让手机或者其他设备随时调用而且我想把能力开放给家里人用总不能让他们去命令行里敲指令。服务层我用FastAPI包了一层暴露两个接口。一个是同步的health检查另一个是异步的任务提交接口调用时传入用户的任务描述返回一个task_id后台用队列跑Agent流程完成后把结果存到数据库前端通过task_id轮询拿结果。这样设计不是为了炫技是因为Agent跑一篇论文要一两分钟同步HTTP请求大概率会超时后台异步处理是标准解法。这里有个安全细节token级别权限隔离必须提前设计。我一开始没做隔离所有用户共用一个知识库结果测试的时候我自己写的论文笔记和别人读的论文全混在一起了。后来我在所有表和向量集合上都加了user_id字段每个用户独立存储。部署的时候我踩过一个很典型的坑。当时想用Agent辅助做部署让它帮我写Dockerfile和启动脚本它在本地跑的时候一切正常换成Docker以后向量库和PDF目录的路径没有挂载出来容器重启数据就全没了。排查到最后发现Agent生成配置时根本不知道宿主机上data目录的位置这种事还是得人工盯着。所以后来我养成了一个习惯凡是涉及数据持久化的配置做完之后一定手动检查一遍路径映射。5. 常见问题与排查技巧实录5.1 图表和公式识别失败这是读论文项目里最普遍的问题尤其是公式密集的数学类论文。PyMuPDF抽出来的公式都是一堆乱码符号MinerU会好很多但还是会在复杂矩阵和特殊符号上出错。我的处理办法是双通道。文本通道用MinerU解析当识别到“该部分包含复杂公式文本提取置信度较低”这类情况时触发图像通道将这一页渲染成图片调用带视觉能力的大模型接口让模型直接读图理解公式。这个兜底策略实测效果很好但成本会高一些我只在特定章节启用。5.2 长论文上下文爆炸有的论文正文加附录一共三十多页如果一股脑全塞给模型一来费用高二来模型会忽略中间细节。我的做法是分级读取先让Agent只读章节标题和第一段生成一个论文地图然后根据用户问题只读取相关章节的完整内容。比如用户只关心实验设置Agent就不读相关工作那一章的细节。5.3 记忆污染与重复入库同一个论文标题用户反复导入多次每次都会生成新的向量记录长期累积下来知识库非常臃肿。我在入库前加了一层去重判断依据是ArXiv的论文ID如果是本地PDF用文件内容的SHA256哈希做指纹重复导入时不再重建向量而是直接返回已有记录。5.4 工具调用过程中的异常与中断Agent在跑的过程中偶尔会出现“工具执行报错”的情况比如ArXiv接口限流、PDF下载超时、向量库写入失败。LangGraph的checkpoint机制在这种时候很有用能从上一次成功的节点恢复但我还是额外加了一个重试逻辑每个工具函数都包了一层retry装饰器连续失败三次才把错误抛给Agent让Agent决定是否换一种方式完成任务。5.5 常见问题速查表问题可能原因解决办法解析出的文本双栏错乱直接用了PyMuPDF提取文本改用MinerU或Grobid做版面分析检索到的章节和问题无关向量化颗粒度太粗改为章节级切块绑定论文ID笔记里出现论文没有的数据大模型幻觉增加用户确认再写入长期记忆重新部署后历史记录丢失数据目录未挂载处理Volumes映射Paper存放目录必须持久化Agent答非所问短期记忆被旧任务污染每次任务开始前清空messages上下文读论文耗时长MinerU解析过慢对已解析过的论文做缓存按哈希跳过我个人在实际项目里最深的体会是读论文Agent的价值不在于它能把一篇论文总结得多漂亮而在于它能把“读论文”这个动作变成有积累、可回溯、能被检索的过程。模型负责理解架构负责记忆工具负责执行三者配合才把一个原本靠人肉坚持的习惯转化成了一套可持续运转的系统。这个系列后面我还会继续写Agent记忆的细化、批量综述的编排、以及如何接入不同模型提供商的方案欢迎拿这套代码先跑起来折腾。 
