最近我又盘点了一次自己的文献管理工作流——不是换软件而是试着把 Agent 请进来跟我一起处理科研上下文。做科研的人多少都有这种体验PDF 存了几百篇标签打了不少可真到写综述、改论文的时候想找的那句话不知道藏在哪篇文献里。文献管理这件事真正难管的从来不是文件而是上下文。所谓科研上下文不只是论文本身还包括你读它时的想法、它和别的文献的差异、引用时的规范、你现在研究的卡点。这篇文章就说清楚我这几周跑通的方案人做什么、Agent 做什么、上下文怎么组织、踩过哪些坑以及为什么我觉得“人机协同”才是文献管理的正确打开方式。适合正在做文献综述的研究生、长期跟论文打交道的科研人员以及所有被 PDF 和笔记折磨过的知识工作者。1. 文献管理的真正难题不是“存”而是“上下文”1.1 传统文献管理的三层痛点Zotero、EndNote 这类工具已经把文件层问题解决得很好了。PDF 抓取、元数据重命名、分类打标签、批量引用这些事情十年前要手动折腾半天现在基本是点两下的事情。但文献管理的麻烦恰恰不在这层而在更上面两层。一层是信息层。读完一篇论文你脑子里留下了一些判断这篇文章用的方法和我不一样、这个数据集的规模很关键、作者对噪声的处理说服力不强……这些判断如果没有及时落到笔记里过三个月再翻这篇论文脑袋里只剩下“好像读过印象挺深”具体好在哪里、坏在哪里全忘了。笔记层的断裂是文献管理最常见的失败模式。另一层是表达层。写综述的时候你需要把几十篇文献的观点按照自己的论证逻辑重新组织。人脑不可能同时记住几十篇文章的细节于是只好一遍遍翻 PDF、找原文、看当时画的线。这个过程中你其实是在做一件特别机械的事情——把分散的“上下文”重新拼装回工作区。而拼装本身恰恰是 Agent 最擅长的事。1.2 Agent 能做什么、不能做什么我把 Agent 看成上下文搬运工、整理工、格式化工具而不是第二个大脑。它真正靠谱的能力有三个方向从长文档中抽取结构化信息。比如从一篇论文里抽研究问题、方法、数据集、结论、局限只要你的模板定得清楚它做得又快又稳。把多篇文献的信息拉到一起做对比。比如“这三篇文章分别用了什么评价指标”它能给你一张还不错的对照表。按照指定格式重写、精简、扩写。例如把摘要扩展成要点把啰嗦的笔记压缩成摘要。但它有一件事做不了也是我反复提醒自己的事判断一篇文献对你的研究到底有多重要。Agent 不知道你的问题意识、你的假设、你目前的卡点除非你把这些写进上下文里。即便你写了它也还是缺少真实的学术嗅觉。所以我把“筛选和决策”永远留给人类自己Agent 的输出只能作为供决策的汇总材料。1.3 为什么“现在”才值得做这件事“上下文”这个词在 Agent 领域一直存在但过去实际用来用的上下文窗口太窄塞下两三篇论文就到头了。最近一年大上下文模型逐渐普及有模型已经支持百万级 token 的上下文窗口理论上能把几十篇论文甚至一整个研究专题的笔记都放进去。这听起来很美好但它同时也带来一个陷阱窗口大不等于上下文对。你把五十篇论文全文都扔进去模型可能淹没在细节里反而抓不住你要的问题。所以新一代的玩法不再是“灌更多原文”而是做上下文工程——把对当前任务最有用的材料按照合理的结构组织后交给 Agent。这才是文献管理和 Agent 协同最值得投入的地方。2. 想清楚“上下文”是什么从提示词工程到上下文工程2.1 上下文不只是“对话记录”很多人以为上下文就是“把之前的聊天记录继续传下去”这是一个常见的理解偏差。上下文工程里的上下文指的是影响模型当前输出的全部输入材料它至少包含三类东西任务上下文你希望 Agent 此刻完成什么输出给谁看格式是什么。材料上下文完成这个任务需要依赖的文献、笔记、图表、数据。约束上下文格式要求、术语习惯、不需要覆盖的部分。这就像你给一个临时接手的同事做交接你不会把过去三年所有邮件原封不动转给人家而是会整理出一份结构化的交接文档告诉他项目背景、当前进度、待办事项、哪些坑不能碰。Agent 需要的是这份交接文档不是原封不动的邮件流。人的短期记忆容量有限Agent 的上下文窗口本质上也是一种快速易失的工作记忆。你不可能指望 Agent 自己记住三个月前你对某篇论文批注的深意它唯一能记住的方式是你把这些内容显式地放进上下文里。所以在文献管理这个场景里上下文必须被外置、被结构化、被固定下来。Agent 的长期记忆不在它的模型里而在你的笔记库里。2.2 科研上下文的分层组织我实际跑下来最有用的做法是把科研上下文分成四层每一层都有不同的更新频率和给 Agent 喂送的方式。上下文层级内容示例更新频率给 Agent 的使用方式全局层我的研究问题、核心假设、目前卡点、综述提纲每季度 / 每次研究转向时更新每次重要任务前都附带文献层单篇论文的题录、问题、方法、数据、结论、局限、我的评注每读完一篇更新一次写成结构化的“文献卡片”按需挑选注入任务层当前要写的综述小节、目标段落结构、需要回答的具体问题每次写作任务前重新写和文献卡片一起组成当前对话的主要上下文约束层引用格式、期刊要求、术语偏好、不允许出现的表述长期稳定全局设定常驻在系统提示里全局层我觉得最容易被忽略但它的价值最大。我自己的做法是维护一份research-context.md里面只有三四页内容一句话说清楚我在研究什么、为什么这个问题重要、我目前比较认可的假设、我卡在什么地方、接下来一个月最想突破的点。每次让 Agent 帮忙做文献综述前我都会先问自己一句话“这次任务和我研究问题的关系是什么”然后把答案写进任务上下文里。这比单纯丢一堆论文让 Agent 自由发挥可靠得多。文献层的核心是给每篇论文做一张上下文卡。卡上不是完整读书笔记而是更接近论文的骨架式摘要加上我的评注。字段固定以后Agent 在不同时间读到同一篇文献得到的都是同样的结构检索和对比的效率会明显提升。2.3 从提示词工程到上下文工程过去的提示词工程讲究“把一句话说清楚”——调提示词把指令写明白让模型按你的意思输出。但到了 Agent 时代更关键的是上下文工程如何在有限窗口里选出、组织好最需要的材料。提示词只是让模型听懂你的话上下文工程则决定了模型眼前的材料是否充分、是否结构清晰、是否没有冗余。我自己的体感是写提示词的时间只占三成。七成时间花在整理上下文上这篇论文的信息卡抽好了没有、这个综述小节要对比哪几篇文献、当前研究问题有没有写清楚、格式约束是否已经放进来了。如果上下文本身乱糟糟的再好的提示词也救不回来模型只能在垃圾上下文里生成“合理但没用”的答案。吴恩达的 Agent 教程里也反复提到过类似的观点真正拉开差距的不是让模型“更会思考”而是你有没有给它足够好用、足够干净的材料。文献管理天然适合应用这套思想——材料分散、格式多样、量又大正是上下文工程最能发挥作用的地方。3. 在 Zotero 和笔记库里搭一套自己的 Agent 协同流程3.1 准备一套趁手的工具组合我实际使用的组合比较轻量Zotero 负责文件管理和参考文献元数据一个本地 Markdown 笔记库负责存储上下文卡片再加上一个支持长上下文对话的 Agent 客户端。工具本身不是重点你用 Zotero 还是其他文献管理器用 Notion 还是 Obsidian用哪家的 Agent 都不重要重要的是这套流程必须满足三个条件能快速把单篇论文的结构化信息保存成固定格式的卡片能随时把某几篇文献的卡片组装成一个“上下文包”喂给 Agent能让 Agent 的输出再回流到笔记库形成闭环。我自己的目录结构大概是这样的research/ ├── _global/ │ ├── research-context.md # 全局研究上下文 │ └── writing-style.md # 写作约束术语、引用习惯 ├── _cards/ │ ├── 2024-liu-bert-finetune.md │ ├── 2023-zhang-knowledge-distill.md │ └── ... ├── drafts/ │ ├── intro-lit-review.md # 正在写的综述 │ └── ...每条卡片就是一个文件名带年份和作者的 Markdown 文件。日期和作者放进文件名是为了让卡片之间可以稳定地互相引用、避免重复建卡。3.2 第一步为每篇文献建立上下文卡文献卡模板是我反复调过几次才定下来的字段不宜太多否则维护成本太高很快就坚持不下去。我最后保留了九个字段# 文献卡作者-年份-简短标题 ## 题录 - 标题 / 作者 / 年份 / 期刊 / DOI ## 研究问题 - 作者想解决什么问题一句话说清楚 ## 方法 - 用了什么方法 / 框架 / 实验设计 ## 数据 - 数据集 / 样本量 / 评测方式 ## 核心结论 - 最重要的发现是什么 ## 局限 - 作者自己承认的、或你能看出的问题 ## 与我研究的关系 - 它可以直接引用吗能支撑我哪个论点 ## 我的疑问 - 没看懂的地方或下次要查证的点 ## 关键页码/原文 - 需要回引的句子和页码方便之后核对这个模板最能拉开效果的是“与我研究的关系”这个字段。前几版模板里没有它Agent 每次读卡片都只能给出一堆事实没有偏向加上这个字段以后它会带着我的研究问题去看文献输出也明显更贴合我的综述需要。建卡的方式我试过两种。一种是精读后自己填最稳但费时另一种是让 Agent 先抽人工再核效率更高。第二种的做法很简单把论文 PDF 转成文本配合固定模板提示词让 Agent 一次性生成卡片草稿。示例如下我是一名研究生正在写关于“模型压缩技术在边缘端部署”的综述。 请根据下面这篇论文的全文或关键段落按照我的文献卡模板填写内容。 模板字段题录、研究问题、方法、数据、核心结论、局限、与我研究的关系、我的疑问、关键页码。 注意 1. 研究问题、核心结论必须引用原文中的句子并标注页码。 2. 如果没有出现信息写“未提及”不要编造。 3. “与我研究的关系”请结合我的全局研究上下文来判断。 4. 输出为 Markdown 格式。 论文草稿文本粘贴在下方。这个流程里最重要的一步是逐条核对。我见过好几次 Agent 在“关键页码”上凭空生成一个页码看起来很像那么回事翻过去根本不是那句话。所以页码和原文引用是雷打不动的核对点其他字段可以适当放松但能回引到原文的字段必须人工确认一遍。大概每篇 5 到 10 分钟能搞定比全人工提取快不少也比我曾经试过的“自动划词笔记”要可控得多。3.3 第二步用单篇精读建立初步上下文拿到卡片之后不要急着开始综述。我会先做一次“单篇精读对话”把全局研究上下文写在一段里再贴进这篇文献的卡片让 Agent 帮我以这篇文献为主角做一次分析。这个环节的提示词不需要很复杂但一定把任务描述清楚当前研究问题模型压缩后出现精度下降我在探索哪些蒸馏策略能缓解这个问题。 请基于我提供的文献卡回答 1. 这篇文章与我的研究问题直接相关的核心贡献是什么 2. 它的方法相比同类方法最值得我关注的一点是什么 3. 如果我要引用它来支撑“结构蒸馏在资源受限设备上更有效”这个论点合适吗为什么不适合的话问题出在哪 4. 请指出卡片里可能存在的、需要我回到原文核对的地方。做完这一轮文献才算真正“内化”到了我的上下文库里。这个过程看起来费时但比起之后写综述时再来回翻 PDF前期投入是值得的。3.4 第三步写综述时的上下文重组写综述的时候我不再单篇操作而是采用“一组文献对应一个写作任务”的方式操作。先把任务上下文写好当前打算写综述的哪个小节、这个小节要回答什么问题、打算按什么逻辑组织段落。然后把相关的五六篇文献卡片复制进来。最后一次性丢给 Agent让它做三件事总结各篇文献在本小节中的地位、给出一个可用的对比框架、识别出各文献之间的异同和冲突。举例来说我写“知识蒸馏在边缘端部署中的应用”这一节时任务上下文是这样写的我当前的综述小节目标是说明知识蒸馏方法在边缘端部署场景下的适用边界。 计划段落结构 1. 蒸馏的基本思路 2. 已有方法在处理资源约束时的常见假设 3. 这些假设在真实边缘设备上会被打破的地方。 请基于下列文献卡片 - 总结每篇文献对上述三个部分各自的贡献 - 找出文献之间互相支持或对立的地方做一张对比表 - 指出哪些文献适合放在“常见假设”段落哪些适合放进“假设被打破”段落 - 不要输出完整的综述段落只输出组织建议和对比材料。这一步的关键是不要让 Agent 直接写综述段落。写段落是人的活它是组织材料的活。一旦让 Agent 直接写你得到的是“像模像样的废话”信息密度极低还需要大改。而先让它做对比表和组织建议你得到的材料就可以直接支撑你快速写出有观点、有引用、有逻辑的段落。3.5 第四步引用核对与回流Agent 生成的任何含引用位置的内容都必须和原文核对。我这里的“原文”指的是你要引用的那个版本 PDF而不是翻译软件输出的文本。很多 Agent 上下文里的文献不是完整原文它自己会对内容进行压缩在压缩过程中可能错误关联观点这是我在实验里见过最多的问题。一个实用的技巧是把“核对引用页码”做成一个单独的 Agent 任务。等自己写完综述草稿后把草稿里引用的句子列表交给 Agent让它“去这些文献卡里找出原文并给出页码候选”。它在卡片上找到页码后我再打开 PDF 搜索几个关键词做确认。这样比逐个引用人工翻找要快得多。3.6 多 Agent 协同进阶可选项如果文献量特别大你还可以拆成两个 Agent 角色一个“文献管家”负责维护卡片库、按主题调取卡片一个“写作助手”专门负责根据上下文包生成综述材料。两个角色放在两个对话里不要混在一起。不然上下文会互相污染——管家记忆里全是写作格式要求写作助手反而对文献细节一知半解。但说实话对大多数独立的科研人员来说单 Agent 良好的卡片库结构已经足够了。多 Agent 的收益主要在团队化、工业化的场景里才会明显放大个人用反而增加管理成本。4. 实战中躲不开的问题与排查技巧实录4.1 高频问题速查表用这套流程跑了大概一个多月我整理出一份高频问题速查表。这些问题几乎每个人都有大概率遇到提前了解要比踩一遍坑再修效率高得多。现象可能原因排查与解决Agent 回答里的引用页码对不上PDF 转文本时页码错位或 Agent 自己编造了页码强制要求“引用原文句子页码”并在任务里加一句“无法确定页码时写‘不确定’”核对时回到 PDF 搜索多篇文献卡片一起用时Agent 把 A 的观点安到 B 头上上下文里多篇文献信息结构相似模型产生混淆在每张卡片开头把作者和年份加粗并让 Agent 在对比表里专门输出“观点来源”列上下文太长后输出开始重复或跑题窗口接近上限模型注意力被稀释压缩卡片只保留“结论 与我研究的关系”字段必要时分两轮处理先总结后对比卡片生成质量不稳定提示词要求不具体或论文全文太长先让 Agent 做“分节摘要”再按模板抽取一次只处理一篇文献对话用过一轮后再问它“忘掉”了前面的上下文对话机制的上下文管理问题或新任务覆盖了旧内容每次新任务开头重写任务上下文不依赖模型记忆长期保存靠卡片库不靠对话记录Agent 输出过于积极把不相关的文献也说成“强相关”研究问题描述太泛模型缺少筛选标准给全局上下文加“当前最关心的 3 个具体问题”让 Agent 以此为筛子Markdown 卡片文件越来越多检索困难缺少索引结构建一个_cards/index.md的文献索引表记录编号、主题、结论关键词4.2 三条必须长期遵守的纪律第一事实必须以 PDF 为准。Agent 提取的卡片、生成的对比表、写出的引用页码全部是草稿不是结论。这个心态非常重要它能避免你在不知不觉中把错误信息写进论文。第二每个新任务都带上“当前任务 关键上下文”。哪怕你上一个对话刚讨论过这篇综述新建对话后也不要依赖模型“还记得刚才说过什么”。长期记忆放在笔记库里对话窗口只负责当下的活。第三定期导出和整理对话日志。有些讨论里有很精彩的片段你追问了某个方法Agent 给出了有启发的回答。这些内容不导出过几天对话被清理或上下文被截断就再也找不回来了。我习惯每周末把本周有价值的对话段落复制到drafts/下的笔记里作为写作素材。4.3 一个帮你少掉头发的小技巧给 Agent 的输入里尽量把“不要做什么”也写进去。比如“不要编页码”“不要评价文献质量”“不要输出段落”“不要综述所有文献只综述我给的这些”。负向约束在上下文工程里非常有用模型对“不要”的理解虽然不够完美但至少能把很多低级错误挡在外面。我自己在提示词末尾长期保留了这样一句话“以上所有要求中优先保证信息准确性不确定的地方明确写‘不确定’不要为了完整性编造内容。”这句话的效果比想象中好得多因为上下文里的文献太多时模型会倾向于“硬凑”故意让回答显得完整而这句话能有效抑制这个倾向。5. 我的一点体会Agent 是上下文的整理者不是替代大脑用这套流程跑了快两个月最直接的变化是写综述的效率提高了一截但更让我意外的收获在另一个地方为了持续给 Agent 喂好的上下文我被迫开始正视自己的研究脉络。以前我总觉得“我心里清楚自己在做什么”可一旦要把研究问题、当前卡点、综述结构写成结构化文本才发现很多想法其实含混不清。现在那个全局研究上下文文档成了我给自己做研究规划的最重要的助手——有个问题值得深思它也让我目前的工作流变得比 Agent 更像一个“贴身研究员”。我最后的建议很简单每篇文献花 5 分钟维护上下文卡写综述前先给 Agent 一份清晰的任务上下文最重要的判断永远自己留。如果你也是被文献堆压得喘不过气的人不妨从建第一张“上下文卡”开始。可能你也会发现Agent 并不能替你读文献但它能让你读过的每一篇文献在你需要的时候准确地站在你身边。