企业官网建设流程全解析

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( name="sections", embedding_function=embedding_functions.SentenceTransformerEmbeddingFunction( model_name="BAAI/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_results=top_k)

向量库只是入口，真正存放“事实”的还是SQLite。把向量检索和元数据查询分开，这个架构一开始就定好，后面加功能会非常省事。

3.3 Agent工具定义与主循环搭建

Agent的“手”就是工具函数。我在这套系统里定义了七个工具：arxiv_search，按关键词搜论文；arxiv_download，下载指定ID的PDF；extract_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 常见问题速查表

我个人在实际项目里最深的体会是，读论文Agent的价值不在于它能把一篇论文总结得多漂亮，而在于它能把“读论文”这个动作变成有积累、可回溯、能被检索的过程。模型负责理解，架构负责记忆，工具负责执行，三者配合，才把一个原本靠人肉坚持的习惯转化成了一套可持续运转的系统。这个系列后面我还会继续写Agent记忆的细化、批量综述的编排、以及如何接入不同模型提供商的方案，欢迎拿这套代码先跑起来折腾。