Kzzzza EN

agent怎么管理科研资料库

3178 字 8 分钟 #Agent

最近花了不少时间研究怎么让 AI agent 更好地帮我读论文。这个过程大概经历了三个阶段，每个阶段都在修上一个阶段的毛病，回过头看还挺有意思的，记录之。

阶段一：把论文拖进网页对话框

最一开始的想法特别朴素——论文 PDF 扔给 AI，让它帮我读，也是之前本地agent没有普及之前，最常见的ai辅助阅读论文的方式。

Zotero 内置的 AI 辅助阅读、各种网页端的论文问答工具，基本都试过一圈。流程倒是简单：上传 PDF → AI 解析 → 我问问题 → 它回答。

不过会存在一些显而易见的问题

  1. 上下文窗口不够用: 一篇正常的 CS 论文转成纯文本大概 8000-15000 词，加上公式、表格、参考文献，轻轻松松超过很多模型的上下文限制。就算勉强塞进去了，多轮对话之后前面的内容也早就被挤出去了。你问着问着，AI 就开始失忆——明明刚才还在聊实验部分，突然就忘了论文用的什么数据集，而且有的时候需要做论文直接的对比和文献综述撰写，需要ai了解更多的论文，上下文窗口限制更加严重。

  2. 还有就是每次都要从头分析：同一篇论文我可能会反复看好几遍，从不同角度去理解。但每次打开新对话都是全新的开始，昨天让 AI 精读过的论文，今天换个问题就得重新上传、重新解析。

  3. 论文笔记撰写：有时候需求不只是读论文，还需要结合论文做一些阅读笔记，我喜欢在笔记里面放一些论文的主图，但是如果只使用网页版的ai是做不到的

  4. 不只是论文：对于我主要关注的泛 CS 领域，这个领域的论文基本上都有对应的开源代码仓库，方法的真实面貌往往在代码里——调参技巧、工程优化、论文里一笔带过的实现细节。但当时的工具链里论文是论文、代码是代码，完全没有交集。看完论文还得自己跑去 GitHub 翻代码，建立代码和论文之间的联系。

阶段二：手搓一个论文综述 Skill

开始使用Claude Code之后，学会一些Skill的使用方法，所以前一段时间做了一个论文笔记辅助的skill

结合 Claude Code 的 Agent 能力，我写了一个专门做论文综述的 skill。功能简单来说说就是：根据我提供的论文（论文名，pdf，URL，论文关键词），完成论文检索下载分析，最后产出一篇结构化的论文综述笔记。

整个 worklflow 分了六个阶段：

完整的七阶段 Pipeline

  1. 论文检索：根据关键词去检索并下载相关的论文PDF
  2. PDF 解析：论文 PDF 通过 MinerU API 转成 Markdown，公式、图片、表格、版面结构完整提出来
  3. 深度单篇分析：每篇论文启动一个独立 subagent，在隔离的上下文窗口里精读全文，按模板提取研究问题、核心贡献、方法论、实验结果、局限性，每篇论文生成一个markdown分析文档
  4. 跨论文关联：把所有单篇分析汇总到一起，找主题聚类、方法论脉络、公式符号对应、共识与冲突、研究空白，生成一个论文关联与概述的markdown文档
  5. 大纲设计：基于关联分析产出结构化的博客大纲，明确每节写什么、引用哪些论文
  6. 初稿写作：逐节按大纲写正文
  7. 终稿打磨：检查引用一致性、LaTeX 正确性、段落过渡、Hook 和结论质量

实际跑下来，产出的综述质量确实不错。尤其是 Stage 3 的跨论文关联——agent 能找到一些我自己可能注意不到的联系。比如几篇看起来方向完全不同的论文，底层数学框架居然能对应上。

但是还是存在一些问题没有解决：

  1. 知识完全不能复用：每次写新综述，相关论文都得从头下载、重新解析、重新分析。明明上一篇综述已经深度分析过的论文，换个 topic 就得全部重来一遍。MinerU 免费额度有限，长论文解析要几十秒到几分钟，重复解析就是纯浪费。

  2. 代码还是缺失的: Skill 只处理论文 PDF，代码仓库完全不碰。算法细节、调参玄学、工程实现的那些知识，还是得我自己去翻 GitHub。Agent 在代码这块完全帮不上忙。

  3. Pipeline 太重了: 七个阶段完整跑下来，适合"我要写一篇正经综述"这种场景。但日常的一些需求——"诶这篇论文讲了什么？""跟昨天看的那篇有啥区别？""代码怎么写的？"——根本用不上这么重的流程，分析得到的论文索引内容没有给其他的skills留出方便的接口。

阶段三：MAPCE —— 论文+代码的个人 RAG 知识库

于是开始想能不能换个思路？

与其每次把论文喂给 Agent，不如先建一个自己的RAG知识库，让 Agent 需要的时候自己查。

这个想法其实比较简单，平时读论文、收藏论文、在 Zotero 里打标签，本质上就是在积累一个个人的知识库。如果这个积累的东西能被 Agent 直接访问，那它就不用每次都从零开始了。

于是就搞了 MAPCE——MCP-based Agent for Paper and Code Exploration（项目名太难取了，随便找一个都是重名。。。。）。希望实现：

建立一个本地个人的科研文献&论文数据库

怎么工作的

MAPCE 本质上就是一个本地向量数据库（LanceDB）+ 一个 MCP Server。

索引侧大概长这样：

1
PDF/arXiv/代码仓库 → MinerU解析 → 多层分块 → 向量嵌入 → LanceDB 存储

论文和代码都做了分层分块，这块是整个系统里最核心的设计：

论文端：三级分块 + 图表

  • L1 论文级：标题 + 摘要 + 关键词（~200-500 tokens）→ 粗筛用的
  • L2 章节级：每个章节完整内容（~500-2000 tokens）→ 精细排序用
  • L3 段落级：独立段落（~200-500 tokens）→ 上下文注入用
  • 额外的图片块和表格块：标题 + 文件路径/HTML 内容

由于RAG使用的Embedding模型不是多模态的，所以图片和表格这种特殊且重要的信息需要单独处理

代码端：五级分块 + 配置文件

  • L1 仓库级：README 摘要 + 目录树 + 入口点 + 构建信息
  • L2 文件级：文件路径 + imports + 函数/类签名列表
  • L3 函数/类级：完整实现 + 调用关系 calls[] + 被调用关系 called_by[]
  • L4 模块级：顶层常量、registry 装饰器、__main__ 块
  • L5 测试级：测试函数 + 关联的被测符号
  • 配置文件块：YAML/JSON/TOML 的超参数和配置

同时还在数据库中建立了论文与代码库的对应关系

检索侧用了渐进式的四阶段策略：先判断查询意图（论文导向还是代码导向还是混合的），然后 L1 粗筛 top-20，再在候选集里做 L2 精排，最后围绕最佳匹配拉取相邻段落、调用图、图表等上下文——控制在一个合理的 token 预算内。

最后通过 MCP 协议暴露 8 个工具给 Claude Code：搜索论文、搜索代码、索引新论文、索引代码仓库、列出已索引论文、获取论文概览、删除论文、查看统计。Agent 用这些工具就跟查数据库一样自然，不需要我手动去翻什么。

数据源

目前支持四种来源加论文：

  • arXiv：搜 arXiv API 然后批量下载索引
  • 本地 PDF：单个文件或者整个目录递归扫描，自动去重
  • Zotero：直接读本地 Zotero 的 SQLite 数据库——Zotero 开着也能用，会自动复制到临时文件绕开锁（这个 feature 花了不少时间调试）
  • URL：给 arXiv 链接就能下

还做了三层去重（arxiv_id 精确匹配 → DOI 精确匹配 → 标题 embedding 相似度 > 0.95），同一篇论文从不同来源各加一次也不会重复索引。

解决了什么，还差什么

MAPCE似乎?解决掉一些问题：

  • 知识复用了。 一篇论文索引一次，之后一直在库里。不管我换什么 topic、写什么方向的综述，之前积累的论文都能随时检索到。MinerU 调用次数从"每篇综述 × N 篇"变成了"每篇论文 × 1"，额度省了很多。

  • 论文和代码能一起查了。 同一个库里既有论文段落又有对应代码实现。查"这个 attention 变体怎么写的"，能同时拿到论文里的公式描述和仓库里的 attention.py。阶段二的时候这完全是空白。

  • 日常查询够轻量。 "这篇论文讲了什么""最近索引的几篇 diffusion 论文有什么共同点"——直接搜就行，不用启动六阶段 pipeline。

  • 增量更新。 新论文随时加，自动去重，不影响已有数据。

当然，现在 MAPCE 只是一个比较草台班子的零号机：

  • 代码分析比较粗糙。 Python 用 AST 解析得还可以，C++/CUDA 只能用正则硬上——模板元编程和复杂的宏展开基本处理不了。很多论文仓库还是多语言的，Makefile、Dockerfile、shell 脚本这些目前没覆盖到。
  • 检索质量很吃分块策略。 分太粗检索不准，分太细上下文不够。现在的三层/五层是迭代了几轮的折中方案，大部分场景 OK，但结构特殊的论文和代码仓库就吃力了。
  • 缺自动更新。 arXiv 论文会发新版本，代码仓库有新 commit，目前都得手动触发重新索引。理想状态应该是订阅式的自动追踪，最好是运行在个人服务器上，挂一个loop，可以自动检测并使用Wechat or feishu询问用户是否需要更新数据库。
  • 没有前端。 现在纯靠 MCP 工具和命令行操作，Agent 用着方便，但用户使用时候想直接浏览索引内容就不太友好。
  • 测试不够：现在的这个数据库还只是限于"可以用"的程度，但是能不能真实提供给agent好的知识，能不能节约token，检索召回率是多少，还需要后续进行一些测试。~我自己估计性能还有许多可以提升的空间~
  • 和Zotero的深度集成：现在项目和zotero的联系只是简单的提取论文的pdf，后续能不能也把zotero中用户的笔记也加入到数据库中，或者可以提供一个zotero集成的agent插件？

最后

三个阶段搞下来，其实就是一个不断给试图让自己偷懒的过程。

写到这里发现好像就是一个不断造轮子的过程。 不过每个阶段造的轮子，确实解决了一些问题。从"把论文拖进对话框"，到skill，再到"搭个人知识库"——每一步都是被实际需求推着走的，没有一步是为了技术而技术。

接下来想做的事还不少，如果你对这些方向有兴趣或者建议，欢迎来 MAPCE 讨论，提 issue，提PR。