1. 先说痛点100篇文献到底有多难啃完1.1 写综述最耗时的不是写作是文献处理做科研的人应该都有这种体会真正动手写综述之前的文献筛选阶段才是最折磨人的。我见过太多人刚下载完100篇PDF兴冲冲打开EndNote或Zotero准备大干一场结果三天后还停在第三篇——每篇Abstract读完读一半就忘读完下一篇又想不起上一篇讲了什么。最后只能打开Excel一行一行记笔记这篇是队列研究、那篇是RCT、哪几篇样本量太小不能用、哪个团队的工作相互矛盾……我算过一笔账。一篇完整的综述如果目标是覆盖某个方向近3到5年的进展核心文献量基本在50到150篇。按每篇完整阅读加笔记需要40分钟算100篇就是4000分钟折合66个小时不吃不喝也要将近3天。再加上文献分类、观点归纳、写作框架搭建、引用格式整理一周时间就这么进去了。这还没算上写作过程中反复回去翻原文确认观点、补查引用信息的碎片时间。1.2 为什么团队里总有人能在deadline前交综述你身边一定有这样的同事同样是写综述人家三天能交初稿你三周还在文献堆里挣扎。以前我总觉得是人家英语好、写法熟后来观察多了才发现真正拉开差距的是文献处理的效率。写综述本质上是个信息蒸馏的过程。你走的路径是全文阅读→形成理解→笔记摘录→知识重组→写出来而效率高的人走的是摘要粗筛→定位关键章节→提取核心结论→按主题组织→写出来。前者是逐篇精读后者是先建立全局地图再定点深入。问题在于即使你有先看摘要再定位全文的意识纯靠人工操作摘要、全文、分类、归纳这些动作还是得一遍遍重复换数据源后又要重来一遍。我当时就在想能不能把这些重复动作全部交给智能体来做我不需要它替我思考但需要它帮我完成文献的获取、初筛、结构化提取和初步归纳。这就是睿思综述智能体的起点。1.3 我从人肉读文献转向智能体辅助的转折点转折点发生在我准备一篇关于绝经后骨质疏松药物治疗进展的综述时。这个方向文献量特别大PubMed上6万多篇光近3年的就有1万多篇。我按关键词筛了两轮还是有大概240篇候选文献。当时我导师和我说你先看摘要筛到80篇再精读。那个周末我在图书馆坐了两天筛完还剩160篇——因为很多摘要写得太模糊光看摘要根本判断不了有没有价值。后来我实在受不了了花了一个晚上搭了一个粗糙的脚本用PubMed的E-utilities把所有候选文献的摘要拉下来按标题和摘要里的核心词分组再用规则把同一主题下的文献聚在一起最后把每个主题下的摘要合并成一段话丢给我看。那一跑下来我大概花了40分钟就摸清了这160篇文献的版图哪些子方向研究密集、哪些方向结论一致、哪些互相矛盾、哪些是明显灌水。虽然这个脚本很简陋但那个下午给我的冲击特别大——过去两天干的事被一个几百行脚本40分钟跑完了。也是从那天起我决定认真做一个完整的综述智能体。2. 睿思综述智能体的整体架构一条流水线解决四件事2.1 四个核心模块拆解睿思综述智能体这个名字听起来很唬人但实际上它的架构并不复杂。我把它拆成了四个模块文献获取模块、理解与索引模块、综述生成模块、质量控制模块。整个链路就是一条流水线各模块各管一段互不干扰。文献获取模块负责和PubMed交互核心逻辑是接收用户输入的检索式调用E-utilities接口获取文献ID列表再逐条抓取标题、摘要、作者、期刊、年份、DOI、PMID等元数据。这个模块的产出是一份规范化的文献清单JSON文件。理解与索引模块负责把抓下来的文献读进去。每篇文献的摘要和MeSH词条先经过文本清洗去掉无效字符然后按固定格式拼接成一条带元数据的文本块写入向量数据库做RAG检索用。同时这个模块还会提取每篇文献的关键发现字段、研究类型、样本量等结构化信息存入一个独立的表格方便后续做统计。综述生成模块是用户能直接感知的部分。它接收主题限定条件目标字数这几个参数先从向量库里检索相关文献片段然后按主题分层生成。这里我用了两次生成第一轮按小主题生成各子章节的综述草稿第二轮把所有子章节合并、去重、润色成完整的综述长文。两轮之间会强制插入参考文献编号标注确保每句话都有文献来源支撑。质量控制模块是容易被忽略但价值最高的一块。它在综述生成后自动做三件事第一检查每个章节的引用密度如果某一段超过三句话没有任何引用就标记为疑似主观堆砌打回重写第二把正文里的引用编号与参考文献列表逐一比对防止出现引了文献1但列表里没有或编号错位的问题第三用规则过滤掉AI常见的空话套话比如近年来随着…这类在综述里毫无信息量的句子并给出替换建议。2.2 我为什么选这个技术组合说实话市面上的智能体平台和框架已经很多了Dify、Coze、AgentScope、Trae这些我都试过。最早我用的是LangChain自建好处是灵活想怎么改就怎么改坏处是维护成本高一个版本升级就可能把之前的调用链打断。后来我把工作流搬到了Dify上主要看重的是它的可视化编排和内置工具节点。这里多说一句平台选型的思路。如果你只是给自己用不想折腾部署Coze或者Dify云端版都够用如果你想做成一个团队内部的科研工具需要对接单位里的统一身份认证或者内网数据库那建议自建Dify社区版至少数据是自己掌控的如果你像我一样后期想接更多自定义的数据源和算法模块可以先用自建代码把核心逻辑跑通再固化成工具节点放到工作流平台里。我的建议是优先选一个成熟平台做编排但核心能力用代码实现这样兼顾效率和可控性。我最终定的方案是Dify工作流自研PubMed工具节点向量库检索。统一入口放在Dify的Agent节点上用户只需要在聊天窗口输入主题和几个参数后面的事情全部由工作流编排完成。这样不需要每个用户都了解代码组里的师妹也能直接在界面上用。2.3 智能体与普通文本生成插件的本质区别很多人一听综述智能体觉得这就是个能生成文字的AI插件无非是把提示词写好一点。但实际上智能体和普通文本生成工具之间最大的区别在于它具备行动能力。普通插件是你把文献喂给它它帮你写一段总结智能体是你说我要这个方向的综述它自己去PubMed检索、自己筛选、自己读取、自己生成、自己校正引用格式。整个过程中它是在多个环节做决策的而不只是生成环节。举个例子普通文本生成工具在写骨密度下降与骨折风险的关系这段时它只能依赖你塞给它的文本智能体在写这段时如果发现向量库里相关的文献证据不够它会自动发起一次补充检索把漏掉的关键文献拉进来再继续写。这就是行动和生成的区别。这也是为什么我说睿思综述智能体本质上是一个会自己查文献的研究助理而不是一个会写字的编辑器。3. 联网PubMed让智能体具备活水检索能力3.1 PubMed E-utilities API的基础用法联网PubMed是整个智能体的地基。没有真实的、可追溯的文献来源生成的综述再流畅也没有意义。PubMed官方提供了E-utilities接口这是最规范、最稳定的接入方式不需要申请复杂的密钥只要设置好API Key并遵守频率限制就行。核心接口有三个esearch用来获取满足检索条件的文献PMID列表esummary用来获取文献的基本信息标题、作者、期刊、年份等efetch用来抓取完整记录包括摘要、MeSH词、DOI等。我的工作流里是这样串起来的先esearch拿ID列表再esummary快速过滤一遍最后efetch抓取精筛后的文献详情。以下是我的工具节点里esearch请求的简化示例import requests from urllib.parse import urlencode base https://eutils.ncbi.nlm.nih.gov/entrez/eutils/ params { db: pubmed, term: (osteoporosis[MeSH]) AND (postmenopause*[Title/Abstract]) AND 2020:2025[dp], retmax: 200, retmode: json, sort: relevance } resp requests.get(base esearch.fcgi, paramsparams, timeout30) data resp.json() pmids data[esearchresult][idlist]这里有个小细节esearch的sort默认是most recent按时间新到旧但对于综述写作按relevance排序往往更实用。因为一个方向上的经典文献不一定是最新的而Relevance排序能在一定程度上把引用高、匹配度高的文献排前面。我实测下来按relevance检索后人工精筛的通过率比按时间排序高出大概20%到30%。3.2 检索词构造与排序策略检索词是整个检索环节里最考验功底的部分。直接用一句osteoporosis treatment去查出来的结果肯定又杂又乱。我的做法是让智能体在检索前先想一想根据用户给的综述主题自动拆解出核心概念、可选同义词、MeSH词、限定条件再组合成完整的检索式。比如输入绝经后骨质疏松的药物干预智能体会构造出这样的检索式(osteoporosis, postmenopausal[MeSH]) AND (drug therapy[Subheading] OR pharmacological treatment[Title/Abstract]) AND (bisphosphonate*[Title/Abstract] OR denosumab[Title/Abstract] OR teriparatide[Title/Abstract]) AND 2015:2025[dp] AND (humans[MeSH Terms])构造检索式的策略其实有个由宽到窄、再由窄到宽的流程先按最核心的主题词检索看数量数量多了就加限定条件时间、研究类型、人群数量少了就替换同义词再试。这个判断逻辑用代码实现不复杂但收益特别大。我把这套逻辑做成了一组条件分支节点放在esearch之前让智能体根据每次检索返回的文献数量自动调整检索式。3.3 速率限制、重试机制与增量更新用E-utilities有个非常现实的坑不设API Key的时候一条请求和三秒钟的间隔规则限制很严厉频繁调用会直接封IP。我一开始没注意结果跑了一次100篇文献的全量efetch大概发了300多个请求中途就被NCBI限流了报HTTP 429。解决方法是两件事。第一注册一个NCBI账号申请API Key这样可以把速率从每秒3次提升到每秒10次对一个小工具来说绰绰有余第二在代码里必须做带退避指数的重试机制。我的实现是这样如果某次请求失败等待2的n次方秒后再试最多试5次连续失败5次就放弃当前文献把它的PMID记录到日志里等整个流程跑完再补抓一次。增量更新这个点也值得提一下。综述写作往往不是一次性的——你写了一个月中间新发表的文献要不要收进来我在智能体里加了一个数据刷新模式它会读取上次运行时保存的PubMed检索时间戳只抓取这个时间点之后新收录的文献然后追加到已有文献库里而不是每次把全部文献重新抓一遍。这样既省时间又能保证综述在投稿前能覆盖到最新研究成果。3.4 引用格式与文献去重处理联网检索还带来一个容易被忽略的问题——文献去重和引用格式匹配。PubMed检索式稍微写得宽一点很容易出现同一篇文献用不同形式重复命中。比如同一篇论文既在drug therapy子标题下又出现在denosumab关键词检索结果里。如果不去重参考文献列表会出现两遍或者正文里同一个研究被当成两个独立研究讨论了。我的处理方案是在文献获取模块的最后加一道归一化操作。按PMID去重是第一层但同一研究可能以预印本和正式发表两个版本存在这时候PMID会不同。所以我额外按DOI第一作者年份做了第二层去重。另外我的工具节点会保留每条文献在检索时的排序位置和命中次数这两个字段在后续精筛时很有用——同一篇文献在多个检索式中命中的次数越多说明它和主题的相关性越强排序时应该适当靠前。引用格式方面PubMed的esummary接口会返回文献的完整题录信息我把它转换成按期刊要求的BibTeX和GB/T 7714两种格式覆盖了国内核心期刊和国际英文期刊的两大场景。生成综述正文时正文内引用编号和文末参考文献条目是同一套数据生成的从源头避免了正文引用了但文末没有的错位问题。4. 万字长文生成如何让AI真正读完100篇文献4.1 上下文窗口不够时RAG不是唯一答案把100篇文献扔给任何一个大模型让它一次性读完并写出综述这在当前的模型能力下都是不现实的。上下文窗口再大也有两个问题一是成本高全量塞进去的Token消耗会让普通科研团队吃不消二是注意力稀释文献一多模型会忘了前面几篇讲了什么生成的后半段质量明显下降。RAG检索增强生成是常规解法把文献切片后存进向量库生成时按语义相似度检索相关片段喂给模型。但我做这个智能体的过程中强烈感受到对综述这种写作场景纯靠RAG是不够的。因为综述的本质是梳理多个研究之间的关系而不是回答某个具体问题。你在写药物A和药物B的对比这段时需要的不是某几段孤立摘要而是所有同时讨论过A和B的文献的全貌。向量检索很容易漏掉这些跨文档的关联信息。所以我在RAG之上加了一个主题预聚合步骤。在生成之前先把100篇文献按MeSH词和标题的共现词自动聚成五到十个主题簇每个簇内部按发表时间排序。生成正文时先以主题簇为粒度检索簇内的文献摘要全部拼接后一次性送给模型做局部总结再进入全局整合。这一步从实际效果看比单纯用向量检索的命中率高了不止一个档次。4.2 分层综述先局部后全局的生成策略这里再展开说下我的两轮生成策略。第一轮生成的单位是主题簇输出的是每个子主题下的分章节综述每一段控制在300到500字附带内部引用的文献编号。第二轮生成的单位是全文我把所有分章节的结果按逻辑顺序拼接再让模型做全局润色和过渡段补充。这种先局部后全局的写法和人写综述的思路其实是一致的。人写综述也不会从头到尾一口气写完一定是先整理归纳好各个子方向再搭框架最后串联成文。用这种方式还有一个额外的好处任一分章节质量不达标时只需要单独重写那一段而不用整篇推倒重来。我在工作流里就加了一个人工抽检节点——各分章节生成后用户可以逐章审阅觉得不行就打回重写不影响其他章节。具体到生成参数我这里有一个实测下来比较稳的设置temperature设为0.2不为了创意而创意综述最怕自由发挥max_tokens按分章节700字、全文总结时按目标字数动态计算重复惩罚系数设为1.2左右防止生成时反复说同一句话。这些参数看起来不起眼但确实直接影响成文质量。4.3 引用标注与防幻觉的强制约束综述生成最大的风险是幻觉引用——模型编造一篇根本不存在的文献或者张冠李戴把文献A的结论安到文献B头上。这个问题在普通对话场景下可能只是尴尬在学术写作场景下就是学术不端是绝对的红线。我在智能体里做了三道约束。第一道是在生成提示词里强制规定每一句涉及具体数据或结论的话末尾必须用方括号标注来源文献编号且编号只能来自本轮提供的文献列表不能自己编。第二道是在输出的后处理环节用代码逐个检查正文中出现的引用编号是否在文献池中存在不在池子里的直接删除整个句子并标记为引用未通过校验。第三道是证据回溯对生成结果里的关键陈述工作流会反向从文献池中提取该编号文献的摘要片段跑一次相似度比对。如果正文句子和原文摘要的语义相似度过低说明模型可能做了过度解读这条内容会被标黄提示。这三道约束执行下来我测试了几十轮幻觉引用的比例从早期的30%以上降到了5%以下。不要小看这个数字对一个需要直接用于论文初稿的工具来说五句话里就有一句可能是编的和二十句话才有一句需要人工核实是完全不同的体验。4.4 结构化输出综述不是摘要叠加初版智能体生成出来的东西说是综述其实更像100篇摘要的拼接。每段开头都是某研究指出某团队发现读起来完全没有逻辑脉络。后来我意识到问题出在提示词上——如果只是告诉模型把这些文献综合一下它很容易按文献逐篇罗列而不是按主题组织观点。正确的做法是让模型先产出综述的大纲框架再往框架里填内容。睿思综述智能体的工作流增加了一个环节在综述生成之前先用文献池里的主题聚类结果生成一份大纲大纲的每个节点都带上这个主题下的关键文献编号然后要求模型严格按照大纲结构来写正文。同时我明确要求每个分节的综述要体现研究进展的时间脉络、不同研究团队的观点异同、尚未解决的一致性问题这样生成的综述就有了议论和评价成分而不是单纯的文献列表。举个例子同样是写双膦酸盐类药物研究进展摘要叠加式的写法是2020年某研究观察了……2021年某研究探讨了……而结构化综述会这样写双膦酸盐类药物在降低椎体骨折风险方面已有大量证据支持但在非椎体骨折与颌骨坏死风险之间仍存在明显争议。支持者们引用……而持保留意见的研究集中在……。近年来的研究方向正逐步转向个体化给药间隔的探索。后者才是综述该有的样子。5. 真实运行记录把100篇文献变成万字综述的完整过程5.1 一次完整的运行流程记录拿我最近一次完整的测试来举例。主题是维生素D补充与绝经后骨质疏松的综述运行环境是8核16G的服务器加一个普通商用大模型的API。整个流程耗时大约26分钟。前三分钟是PubMed检索和文献获取阶段esearch返回了817个候选PMID经过MeSH过滤和关键词精筛后剩172篇esummary快速过了一遍剔除了综述类文章和会议摘要保留118篇原始研究efetch抓取全文摘要和元数据去重后实际入库112篇。接下来大约6分钟是索引阶段文本清洗、分块、向量化存入本地Milvus库。之后是主题聚类分出了7个主题簇比如维生素D与骨密度“血清25(OH)D水平与骨折风险“联合钙剂治疗“不同剂型和给药方式等。然后进入到综述生成阶段7个分章节各生成3到5分钟不等最后全文整合用了4分钟。全程没有人工干预。最终输出了一篇12600多字的综述初稿包含38条参考文献我把112篇按时间范围截取和相关性打分后留了38篇作为核心引用文献结构上有引言、方法说明、按主题划分的正文部分、讨论与展望。我花了大概一个半小时通读一遍补了两段自己觉得需要强调的临床意义调整了几处用词然后作为课程综述作业交上去了。导师给的批注是框架清楚引用扎实个别段落可以再展开——作为一个半自动生成的初稿这个评价我已经很满意了。5.2 我在测试中遇到的五个典型问题第一次跑通全流程之后我连续测了很多次确实碰到过各种各样的坑挑几个有代表性的列出来。第一个问题是检索式的死循环。有一轮测试我输入的综述主题特别冷门esearch返回的文献数为0。如果不做干预智能体会持续加大检索范围直到把所有相关文献都吞进来生成一个泛得不能再泛的综述。后来我加了分支逻辑当候选文献少于20篇时工作流停下来问用户是要扩大时间范围、放宽主题词还是换一个方向重新检索。第二个问题是摘要长度截断。efetch抓取摘要时有些期刊的摘要特别长超出我的文本切片长度后关键结论正好落在切片尾部被截没了。解决方法是把切片重叠长度加大同时优先保留结论段的句子而不是机械地按字符数切割。第三个问题是短摘要信息量不足。很多生物医学期刊的摘要结构化程度高结论部分只有一两句话Treatment with X significantly reduced Y compared with placebo.这种摘要拿去生成综述支撑不起一段有血有肉的论述。后来我加了一个规则对于摘要字数不足120词的文献工作流会自动尝试抓取该文献在PubMed CentralPMC的全文只要开放获取的就抓前3000词来做补充理解。这个改造对综述质量的提升非常明显。第四个问题是主题聚类过度。有些文献可能同时属于两个主题簇聚类时会被重复归入导致后续综述里同一研究在多个章节反复出场。我在聚类算法里加了归属概率阈值只有当概率超过0.75时才允许跨簇重复归属否则强制归入概率最高的那个簇。第五个问题是平台本身的稳定性。Dify社区版跑长工作流时偶尔会出现节点超时的问题特别是文献数量多的时候一次efetch批量处理上百个请求确实容易触发上游超时。我的解决办法是把批量抓取拆成每批20篇的小批次批次间加1到2秒的缓冲并在工作流的每个节点都配置了失败重试和全局超时退出机制。5.3 排查链路定位引用失效与论据空洞的根因这里单独挑一个我排查过程最有代表性的问题完整还原一下当时的排查链路供大家参考。现象有一版生成的综述正文部分看着还行但抽查引用时发现第12到15条参考文献对应的正文内容读起来总觉得和文献关系不大。当时我怀疑是模型幻觉了于是做了个简单的验证——写了个小程序把这段正文和对应的摘要做了余弦相似度比对结果相似度只有0.42左右明显偏低。于是开始一步步往下查。先看文献本身有没有问题。我打开第12条参考文献的摘要原文发现这篇文献的实验对象是小鼠而正文里写的是临床研究表明……明显是把动物实验的结论当成了临床证据在引用。再看第13条摘要里明明写的是维生素D水平与骨密度的相关性在校正年龄和BMI后不再显著但正文里的引用位置上写的却是多项研究发现维生素D水平与骨密度显著相关——这是典型的结论方向扭曲。到这里我意识到问题可能出在文献读取和生成之间的提示词结构上。我的提示词里要求模型基于文献摘要内容进行总结但摘要里包含的信息太多了包括研究背景、方法、结果、讨论模型在组织语言时容易把作者在引言里提出的假设当成研究结论。总结出来的规律是当提示词没有明确区分研究设计信息和研究结论信息时模型会把整篇摘要混在一起概括导致引用指向的背景而不是真正的发现。修复方式是在文献数据处理环节先把摘要拆成结构化字段——背景、目的、方法、样本、主要结果、结论——每个字段单独成段。这样模型在生成正文引用时看到的是一篇篇结论抽离版的文献摘要而不是一大坨混合文本。修复之后我又做了一次十轮随机抽检正文句子和文献摘要结论字段的语义相似度平均值从0.52提升到0.78引用张冠李戴的问题基本解决了。6. 后续可以怎么扩展给想自建综述智能体的人几条建议6.1 工具与平台选型对比很多人问我想自己搭一个类似的东西该从哪一步开始。我先说结论先想清楚你用的是平台能力还是自研能力这两条路的侧重点完全不同。如果你只是想快速验证想法比如先跑通一个能联网查文献并写摘要的Demo那么直接用Coze或者Dify的公开版本就够了。Coze的优点是插件生态丰富PubMed检索这类常见工具已经有人封装好了拖进来配置一下就能用Dify的优点是工作流编排更自由适合做复杂的条件分支和循环处理而且支持本地部署数据隐私更可控。如果你像我一样需要深度定制文献处理逻辑主题聚类、分层生成、引用校验这些功能平台不会帮你做那我的建议是核心逻辑用Python或者Go自己写平台只做入口和工作流编排把自定义逻辑封装成API节点挂进去。不要试图完全在低代码平台里面硬写复杂逻辑到时候调试成本会高到让你怀疑人生。有一个点值得专门提醒如果你提供给科研团队使用一定要注意生成全过程的可追溯性。综述不同于一般文案读者会问这个结论是哪篇文献支撑的。所以智能体的每一步生成、每一个引用选择都要能回溯到原始文献。这就要求文献库不仅仅存向量还要存原始文本、抓取时间、来源URL甚至是抓取时的PubMed记录版本号。这个设计给你之后应对审稿人质疑会省很多事。6.2 最容易翻车的三个细节及其对策第一个容易翻车的细节是向量数据库的选择。很多教程会推荐你直接用Milvus或者Weaviate但我的体会是对于个人使用的场景用轻量的方案其实就够了。如果你的文献量在几千篇以内SQLite的向量扩展或者单机版的向量库完全顶得住没必要上一套分布式系统给自己增加运维负担。我一开始图新鲜上了分布式方案后来发现每天都要维护一个集群纯粹是在给自己找罪受。第二个容易翻车的是长文本生成会跑题。当你让大模型生成8000字时它写到中间往往会开始重复已经表达过的观点或者突然跳到其他方向侃几句。我的对策是分章节生成时严格限制每个章节的篇幅和内容边界并在全局整合阶段加入一次重复检测——把最终成文按语义向量化后对相邻段落的相似度做扫描超过阈值的段落会被自动精简或标记待人工处理。第三个翻车点让我印象很深是PubMed API的幽灵限制。虽然NCBI官方文档写着API Key情况下每秒10次请求但实际上高并发时段连发大量请求还是会随机触发限流。如果你发现某次运行过程中报429概率比平时高很可能不是你的代码出错了而是遇到了上游服务的流量高峰。这时候最简单的应对是重新跑一遍失败的那批请求别动不动就去改代码逻辑。6.3 我的几点个人体会整个项目做到现在我最大的感受可以总结成一句智能体不是替你思考而是帮你在思考之前少做无意义的体力活。它能把100篇文献的获取、整理、分类、初步归纳这些流程压缩到一个小时以内但真正的学术判断——哪些文献值得重点分析、哪些结论之间存在张力、这个方向下一步该往哪里走——仍然需要研究者自己来做。工具释放出来的时间应该花在这些更有价值的地方。另外还有一个很现实的感受任何自动生成的文本都需要一个负责任的使用者。我的智能体里加了很多约束和校验但它仍然会出错。每次我拿它生成的综述前都会预留至少一个小时的人工审阅时间重点检查引用是否准确、结论是否有夸大、逻辑是否连贯。把智能体当助手而不是代笔这是我从头到尾都在坚持的原则。最后分享一个实用的小建议如果你也打算自建这类工具可以考虑把综述生成和文献管理打通把智能体生成的文献清单直接导出到Zotero的特定分类目录中这样后续写文章、做汇报时所有参考文献都能直接复用。我从这个改动里省下的时间大概比智能体本身帮我省的还多。
1. 先说痛点100篇文献到底有多难啃完1.1 写综述最耗时的不是写作是文献处理做科研的人应该都有这种体会真正动手写综述之前的文献筛选阶段才是最折磨人的。我见过太多人刚下载完100篇PDF兴冲冲打开EndNote或Zotero准备大干一场结果三天后还停在第三篇——每篇Abstract读完读一半就忘读完下一篇又想不起上一篇讲了什么。最后只能打开Excel一行一行记笔记这篇是队列研究、那篇是RCT、哪几篇样本量太小不能用、哪个团队的工作相互矛盾……我算过一笔账。一篇完整的综述如果目标是覆盖某个方向近3到5年的进展核心文献量基本在50到150篇。按每篇完整阅读加笔记需要40分钟算100篇就是4000分钟折合66个小时不吃不喝也要将近3天。再加上文献分类、观点归纳、写作框架搭建、引用格式整理一周时间就这么进去了。这还没算上写作过程中反复回去翻原文确认观点、补查引用信息的碎片时间。1.2 为什么团队里总有人能在deadline前交综述你身边一定有这样的同事同样是写综述人家三天能交初稿你三周还在文献堆里挣扎。以前我总觉得是人家英语好、写法熟后来观察多了才发现真正拉开差距的是文献处理的效率。写综述本质上是个信息蒸馏的过程。你走的路径是全文阅读→形成理解→笔记摘录→知识重组→写出来而效率高的人走的是摘要粗筛→定位关键章节→提取核心结论→按主题组织→写出来。前者是逐篇精读后者是先建立全局地图再定点深入。问题在于即使你有先看摘要再定位全文的意识纯靠人工操作摘要、全文、分类、归纳这些动作还是得一遍遍重复换数据源后又要重来一遍。我当时就在想能不能把这些重复动作全部交给智能体来做我不需要它替我思考但需要它帮我完成文献的获取、初筛、结构化提取和初步归纳。这就是睿思综述智能体的起点。1.3 我从人肉读文献转向智能体辅助的转折点转折点发生在我准备一篇关于绝经后骨质疏松药物治疗进展的综述时。这个方向文献量特别大PubMed上6万多篇光近3年的就有1万多篇。我按关键词筛了两轮还是有大概240篇候选文献。当时我导师和我说你先看摘要筛到80篇再精读。那个周末我在图书馆坐了两天筛完还剩160篇——因为很多摘要写得太模糊光看摘要根本判断不了有没有价值。后来我实在受不了了花了一个晚上搭了一个粗糙的脚本用PubMed的E-utilities把所有候选文献的摘要拉下来按标题和摘要里的核心词分组再用规则把同一主题下的文献聚在一起最后把每个主题下的摘要合并成一段话丢给我看。那一跑下来我大概花了40分钟就摸清了这160篇文献的版图哪些子方向研究密集、哪些方向结论一致、哪些互相矛盾、哪些是明显灌水。虽然这个脚本很简陋但那个下午给我的冲击特别大——过去两天干的事被一个几百行脚本40分钟跑完了。也是从那天起我决定认真做一个完整的综述智能体。2. 睿思综述智能体的整体架构一条流水线解决四件事2.1 四个核心模块拆解睿思综述智能体这个名字听起来很唬人但实际上它的架构并不复杂。我把它拆成了四个模块文献获取模块、理解与索引模块、综述生成模块、质量控制模块。整个链路就是一条流水线各模块各管一段互不干扰。文献获取模块负责和PubMed交互核心逻辑是接收用户输入的检索式调用E-utilities接口获取文献ID列表再逐条抓取标题、摘要、作者、期刊、年份、DOI、PMID等元数据。这个模块的产出是一份规范化的文献清单JSON文件。理解与索引模块负责把抓下来的文献读进去。每篇文献的摘要和MeSH词条先经过文本清洗去掉无效字符然后按固定格式拼接成一条带元数据的文本块写入向量数据库做RAG检索用。同时这个模块还会提取每篇文献的关键发现字段、研究类型、样本量等结构化信息存入一个独立的表格方便后续做统计。综述生成模块是用户能直接感知的部分。它接收主题限定条件目标字数这几个参数先从向量库里检索相关文献片段然后按主题分层生成。这里我用了两次生成第一轮按小主题生成各子章节的综述草稿第二轮把所有子章节合并、去重、润色成完整的综述长文。两轮之间会强制插入参考文献编号标注确保每句话都有文献来源支撑。质量控制模块是容易被忽略但价值最高的一块。它在综述生成后自动做三件事第一检查每个章节的引用密度如果某一段超过三句话没有任何引用就标记为疑似主观堆砌打回重写第二把正文里的引用编号与参考文献列表逐一比对防止出现引了文献1但列表里没有或编号错位的问题第三用规则过滤掉AI常见的空话套话比如近年来随着…这类在综述里毫无信息量的句子并给出替换建议。2.2 我为什么选这个技术组合说实话市面上的智能体平台和框架已经很多了Dify、Coze、AgentScope、Trae这些我都试过。最早我用的是LangChain自建好处是灵活想怎么改就怎么改坏处是维护成本高一个版本升级就可能把之前的调用链打断。后来我把工作流搬到了Dify上主要看重的是它的可视化编排和内置工具节点。这里多说一句平台选型的思路。如果你只是给自己用不想折腾部署Coze或者Dify云端版都够用如果你想做成一个团队内部的科研工具需要对接单位里的统一身份认证或者内网数据库那建议自建Dify社区版至少数据是自己掌控的如果你像我一样后期想接更多自定义的数据源和算法模块可以先用自建代码把核心逻辑跑通再固化成工具节点放到工作流平台里。我的建议是优先选一个成熟平台做编排但核心能力用代码实现这样兼顾效率和可控性。我最终定的方案是Dify工作流自研PubMed工具节点向量库检索。统一入口放在Dify的Agent节点上用户只需要在聊天窗口输入主题和几个参数后面的事情全部由工作流编排完成。这样不需要每个用户都了解代码组里的师妹也能直接在界面上用。2.3 智能体与普通文本生成插件的本质区别很多人一听综述智能体觉得这就是个能生成文字的AI插件无非是把提示词写好一点。但实际上智能体和普通文本生成工具之间最大的区别在于它具备行动能力。普通插件是你把文献喂给它它帮你写一段总结智能体是你说我要这个方向的综述它自己去PubMed检索、自己筛选、自己读取、自己生成、自己校正引用格式。整个过程中它是在多个环节做决策的而不只是生成环节。举个例子普通文本生成工具在写骨密度下降与骨折风险的关系这段时它只能依赖你塞给它的文本智能体在写这段时如果发现向量库里相关的文献证据不够它会自动发起一次补充检索把漏掉的关键文献拉进来再继续写。这就是行动和生成的区别。这也是为什么我说睿思综述智能体本质上是一个会自己查文献的研究助理而不是一个会写字的编辑器。3. 联网PubMed让智能体具备活水检索能力3.1 PubMed E-utilities API的基础用法联网PubMed是整个智能体的地基。没有真实的、可追溯的文献来源生成的综述再流畅也没有意义。PubMed官方提供了E-utilities接口这是最规范、最稳定的接入方式不需要申请复杂的密钥只要设置好API Key并遵守频率限制就行。核心接口有三个esearch用来获取满足检索条件的文献PMID列表esummary用来获取文献的基本信息标题、作者、期刊、年份等efetch用来抓取完整记录包括摘要、MeSH词、DOI等。我的工作流里是这样串起来的先esearch拿ID列表再esummary快速过滤一遍最后efetch抓取精筛后的文献详情。以下是我的工具节点里esearch请求的简化示例import requests from urllib.parse import urlencode base https://eutils.ncbi.nlm.nih.gov/entrez/eutils/ params { db: pubmed, term: (osteoporosis[MeSH]) AND (postmenopause*[Title/Abstract]) AND 2020:2025[dp], retmax: 200, retmode: json, sort: relevance } resp requests.get(base esearch.fcgi, paramsparams, timeout30) data resp.json() pmids data[esearchresult][idlist]这里有个小细节esearch的sort默认是most recent按时间新到旧但对于综述写作按relevance排序往往更实用。因为一个方向上的经典文献不一定是最新的而Relevance排序能在一定程度上把引用高、匹配度高的文献排前面。我实测下来按relevance检索后人工精筛的通过率比按时间排序高出大概20%到30%。3.2 检索词构造与排序策略检索词是整个检索环节里最考验功底的部分。直接用一句osteoporosis treatment去查出来的结果肯定又杂又乱。我的做法是让智能体在检索前先想一想根据用户给的综述主题自动拆解出核心概念、可选同义词、MeSH词、限定条件再组合成完整的检索式。比如输入绝经后骨质疏松的药物干预智能体会构造出这样的检索式(osteoporosis, postmenopausal[MeSH]) AND (drug therapy[Subheading] OR pharmacological treatment[Title/Abstract]) AND (bisphosphonate*[Title/Abstract] OR denosumab[Title/Abstract] OR teriparatide[Title/Abstract]) AND 2015:2025[dp] AND (humans[MeSH Terms])构造检索式的策略其实有个由宽到窄、再由窄到宽的流程先按最核心的主题词检索看数量数量多了就加限定条件时间、研究类型、人群数量少了就替换同义词再试。这个判断逻辑用代码实现不复杂但收益特别大。我把这套逻辑做成了一组条件分支节点放在esearch之前让智能体根据每次检索返回的文献数量自动调整检索式。3.3 速率限制、重试机制与增量更新用E-utilities有个非常现实的坑不设API Key的时候一条请求和三秒钟的间隔规则限制很严厉频繁调用会直接封IP。我一开始没注意结果跑了一次100篇文献的全量efetch大概发了300多个请求中途就被NCBI限流了报HTTP 429。解决方法是两件事。第一注册一个NCBI账号申请API Key这样可以把速率从每秒3次提升到每秒10次对一个小工具来说绰绰有余第二在代码里必须做带退避指数的重试机制。我的实现是这样如果某次请求失败等待2的n次方秒后再试最多试5次连续失败5次就放弃当前文献把它的PMID记录到日志里等整个流程跑完再补抓一次。增量更新这个点也值得提一下。综述写作往往不是一次性的——你写了一个月中间新发表的文献要不要收进来我在智能体里加了一个数据刷新模式它会读取上次运行时保存的PubMed检索时间戳只抓取这个时间点之后新收录的文献然后追加到已有文献库里而不是每次把全部文献重新抓一遍。这样既省时间又能保证综述在投稿前能覆盖到最新研究成果。3.4 引用格式与文献去重处理联网检索还带来一个容易被忽略的问题——文献去重和引用格式匹配。PubMed检索式稍微写得宽一点很容易出现同一篇文献用不同形式重复命中。比如同一篇论文既在drug therapy子标题下又出现在denosumab关键词检索结果里。如果不去重参考文献列表会出现两遍或者正文里同一个研究被当成两个独立研究讨论了。我的处理方案是在文献获取模块的最后加一道归一化操作。按PMID去重是第一层但同一研究可能以预印本和正式发表两个版本存在这时候PMID会不同。所以我额外按DOI第一作者年份做了第二层去重。另外我的工具节点会保留每条文献在检索时的排序位置和命中次数这两个字段在后续精筛时很有用——同一篇文献在多个检索式中命中的次数越多说明它和主题的相关性越强排序时应该适当靠前。引用格式方面PubMed的esummary接口会返回文献的完整题录信息我把它转换成按期刊要求的BibTeX和GB/T 7714两种格式覆盖了国内核心期刊和国际英文期刊的两大场景。生成综述正文时正文内引用编号和文末参考文献条目是同一套数据生成的从源头避免了正文引用了但文末没有的错位问题。4. 万字长文生成如何让AI真正读完100篇文献4.1 上下文窗口不够时RAG不是唯一答案把100篇文献扔给任何一个大模型让它一次性读完并写出综述这在当前的模型能力下都是不现实的。上下文窗口再大也有两个问题一是成本高全量塞进去的Token消耗会让普通科研团队吃不消二是注意力稀释文献一多模型会忘了前面几篇讲了什么生成的后半段质量明显下降。RAG检索增强生成是常规解法把文献切片后存进向量库生成时按语义相似度检索相关片段喂给模型。但我做这个智能体的过程中强烈感受到对综述这种写作场景纯靠RAG是不够的。因为综述的本质是梳理多个研究之间的关系而不是回答某个具体问题。你在写药物A和药物B的对比这段时需要的不是某几段孤立摘要而是所有同时讨论过A和B的文献的全貌。向量检索很容易漏掉这些跨文档的关联信息。所以我在RAG之上加了一个主题预聚合步骤。在生成之前先把100篇文献按MeSH词和标题的共现词自动聚成五到十个主题簇每个簇内部按发表时间排序。生成正文时先以主题簇为粒度检索簇内的文献摘要全部拼接后一次性送给模型做局部总结再进入全局整合。这一步从实际效果看比单纯用向量检索的命中率高了不止一个档次。4.2 分层综述先局部后全局的生成策略这里再展开说下我的两轮生成策略。第一轮生成的单位是主题簇输出的是每个子主题下的分章节综述每一段控制在300到500字附带内部引用的文献编号。第二轮生成的单位是全文我把所有分章节的结果按逻辑顺序拼接再让模型做全局润色和过渡段补充。这种先局部后全局的写法和人写综述的思路其实是一致的。人写综述也不会从头到尾一口气写完一定是先整理归纳好各个子方向再搭框架最后串联成文。用这种方式还有一个额外的好处任一分章节质量不达标时只需要单独重写那一段而不用整篇推倒重来。我在工作流里就加了一个人工抽检节点——各分章节生成后用户可以逐章审阅觉得不行就打回重写不影响其他章节。具体到生成参数我这里有一个实测下来比较稳的设置temperature设为0.2不为了创意而创意综述最怕自由发挥max_tokens按分章节700字、全文总结时按目标字数动态计算重复惩罚系数设为1.2左右防止生成时反复说同一句话。这些参数看起来不起眼但确实直接影响成文质量。4.3 引用标注与防幻觉的强制约束综述生成最大的风险是幻觉引用——模型编造一篇根本不存在的文献或者张冠李戴把文献A的结论安到文献B头上。这个问题在普通对话场景下可能只是尴尬在学术写作场景下就是学术不端是绝对的红线。我在智能体里做了三道约束。第一道是在生成提示词里强制规定每一句涉及具体数据或结论的话末尾必须用方括号标注来源文献编号且编号只能来自本轮提供的文献列表不能自己编。第二道是在输出的后处理环节用代码逐个检查正文中出现的引用编号是否在文献池中存在不在池子里的直接删除整个句子并标记为引用未通过校验。第三道是证据回溯对生成结果里的关键陈述工作流会反向从文献池中提取该编号文献的摘要片段跑一次相似度比对。如果正文句子和原文摘要的语义相似度过低说明模型可能做了过度解读这条内容会被标黄提示。这三道约束执行下来我测试了几十轮幻觉引用的比例从早期的30%以上降到了5%以下。不要小看这个数字对一个需要直接用于论文初稿的工具来说五句话里就有一句可能是编的和二十句话才有一句需要人工核实是完全不同的体验。4.4 结构化输出综述不是摘要叠加初版智能体生成出来的东西说是综述其实更像100篇摘要的拼接。每段开头都是某研究指出某团队发现读起来完全没有逻辑脉络。后来我意识到问题出在提示词上——如果只是告诉模型把这些文献综合一下它很容易按文献逐篇罗列而不是按主题组织观点。正确的做法是让模型先产出综述的大纲框架再往框架里填内容。睿思综述智能体的工作流增加了一个环节在综述生成之前先用文献池里的主题聚类结果生成一份大纲大纲的每个节点都带上这个主题下的关键文献编号然后要求模型严格按照大纲结构来写正文。同时我明确要求每个分节的综述要体现研究进展的时间脉络、不同研究团队的观点异同、尚未解决的一致性问题这样生成的综述就有了议论和评价成分而不是单纯的文献列表。举个例子同样是写双膦酸盐类药物研究进展摘要叠加式的写法是2020年某研究观察了……2021年某研究探讨了……而结构化综述会这样写双膦酸盐类药物在降低椎体骨折风险方面已有大量证据支持但在非椎体骨折与颌骨坏死风险之间仍存在明显争议。支持者们引用……而持保留意见的研究集中在……。近年来的研究方向正逐步转向个体化给药间隔的探索。后者才是综述该有的样子。5. 真实运行记录把100篇文献变成万字综述的完整过程5.1 一次完整的运行流程记录拿我最近一次完整的测试来举例。主题是维生素D补充与绝经后骨质疏松的综述运行环境是8核16G的服务器加一个普通商用大模型的API。整个流程耗时大约26分钟。前三分钟是PubMed检索和文献获取阶段esearch返回了817个候选PMID经过MeSH过滤和关键词精筛后剩172篇esummary快速过了一遍剔除了综述类文章和会议摘要保留118篇原始研究efetch抓取全文摘要和元数据去重后实际入库112篇。接下来大约6分钟是索引阶段文本清洗、分块、向量化存入本地Milvus库。之后是主题聚类分出了7个主题簇比如维生素D与骨密度“血清25(OH)D水平与骨折风险“联合钙剂治疗“不同剂型和给药方式等。然后进入到综述生成阶段7个分章节各生成3到5分钟不等最后全文整合用了4分钟。全程没有人工干预。最终输出了一篇12600多字的综述初稿包含38条参考文献我把112篇按时间范围截取和相关性打分后留了38篇作为核心引用文献结构上有引言、方法说明、按主题划分的正文部分、讨论与展望。我花了大概一个半小时通读一遍补了两段自己觉得需要强调的临床意义调整了几处用词然后作为课程综述作业交上去了。导师给的批注是框架清楚引用扎实个别段落可以再展开——作为一个半自动生成的初稿这个评价我已经很满意了。5.2 我在测试中遇到的五个典型问题第一次跑通全流程之后我连续测了很多次确实碰到过各种各样的坑挑几个有代表性的列出来。第一个问题是检索式的死循环。有一轮测试我输入的综述主题特别冷门esearch返回的文献数为0。如果不做干预智能体会持续加大检索范围直到把所有相关文献都吞进来生成一个泛得不能再泛的综述。后来我加了分支逻辑当候选文献少于20篇时工作流停下来问用户是要扩大时间范围、放宽主题词还是换一个方向重新检索。第二个问题是摘要长度截断。efetch抓取摘要时有些期刊的摘要特别长超出我的文本切片长度后关键结论正好落在切片尾部被截没了。解决方法是把切片重叠长度加大同时优先保留结论段的句子而不是机械地按字符数切割。第三个问题是短摘要信息量不足。很多生物医学期刊的摘要结构化程度高结论部分只有一两句话Treatment with X significantly reduced Y compared with placebo.这种摘要拿去生成综述支撑不起一段有血有肉的论述。后来我加了一个规则对于摘要字数不足120词的文献工作流会自动尝试抓取该文献在PubMed CentralPMC的全文只要开放获取的就抓前3000词来做补充理解。这个改造对综述质量的提升非常明显。第四个问题是主题聚类过度。有些文献可能同时属于两个主题簇聚类时会被重复归入导致后续综述里同一研究在多个章节反复出场。我在聚类算法里加了归属概率阈值只有当概率超过0.75时才允许跨簇重复归属否则强制归入概率最高的那个簇。第五个问题是平台本身的稳定性。Dify社区版跑长工作流时偶尔会出现节点超时的问题特别是文献数量多的时候一次efetch批量处理上百个请求确实容易触发上游超时。我的解决办法是把批量抓取拆成每批20篇的小批次批次间加1到2秒的缓冲并在工作流的每个节点都配置了失败重试和全局超时退出机制。5.3 排查链路定位引用失效与论据空洞的根因这里单独挑一个我排查过程最有代表性的问题完整还原一下当时的排查链路供大家参考。现象有一版生成的综述正文部分看着还行但抽查引用时发现第12到15条参考文献对应的正文内容读起来总觉得和文献关系不大。当时我怀疑是模型幻觉了于是做了个简单的验证——写了个小程序把这段正文和对应的摘要做了余弦相似度比对结果相似度只有0.42左右明显偏低。于是开始一步步往下查。先看文献本身有没有问题。我打开第12条参考文献的摘要原文发现这篇文献的实验对象是小鼠而正文里写的是临床研究表明……明显是把动物实验的结论当成了临床证据在引用。再看第13条摘要里明明写的是维生素D水平与骨密度的相关性在校正年龄和BMI后不再显著但正文里的引用位置上写的却是多项研究发现维生素D水平与骨密度显著相关——这是典型的结论方向扭曲。到这里我意识到问题可能出在文献读取和生成之间的提示词结构上。我的提示词里要求模型基于文献摘要内容进行总结但摘要里包含的信息太多了包括研究背景、方法、结果、讨论模型在组织语言时容易把作者在引言里提出的假设当成研究结论。总结出来的规律是当提示词没有明确区分研究设计信息和研究结论信息时模型会把整篇摘要混在一起概括导致引用指向的背景而不是真正的发现。修复方式是在文献数据处理环节先把摘要拆成结构化字段——背景、目的、方法、样本、主要结果、结论——每个字段单独成段。这样模型在生成正文引用时看到的是一篇篇结论抽离版的文献摘要而不是一大坨混合文本。修复之后我又做了一次十轮随机抽检正文句子和文献摘要结论字段的语义相似度平均值从0.52提升到0.78引用张冠李戴的问题基本解决了。6. 后续可以怎么扩展给想自建综述智能体的人几条建议6.1 工具与平台选型对比很多人问我想自己搭一个类似的东西该从哪一步开始。我先说结论先想清楚你用的是平台能力还是自研能力这两条路的侧重点完全不同。如果你只是想快速验证想法比如先跑通一个能联网查文献并写摘要的Demo那么直接用Coze或者Dify的公开版本就够了。Coze的优点是插件生态丰富PubMed检索这类常见工具已经有人封装好了拖进来配置一下就能用Dify的优点是工作流编排更自由适合做复杂的条件分支和循环处理而且支持本地部署数据隐私更可控。如果你像我一样需要深度定制文献处理逻辑主题聚类、分层生成、引用校验这些功能平台不会帮你做那我的建议是核心逻辑用Python或者Go自己写平台只做入口和工作流编排把自定义逻辑封装成API节点挂进去。不要试图完全在低代码平台里面硬写复杂逻辑到时候调试成本会高到让你怀疑人生。有一个点值得专门提醒如果你提供给科研团队使用一定要注意生成全过程的可追溯性。综述不同于一般文案读者会问这个结论是哪篇文献支撑的。所以智能体的每一步生成、每一个引用选择都要能回溯到原始文献。这就要求文献库不仅仅存向量还要存原始文本、抓取时间、来源URL甚至是抓取时的PubMed记录版本号。这个设计给你之后应对审稿人质疑会省很多事。6.2 最容易翻车的三个细节及其对策第一个容易翻车的细节是向量数据库的选择。很多教程会推荐你直接用Milvus或者Weaviate但我的体会是对于个人使用的场景用轻量的方案其实就够了。如果你的文献量在几千篇以内SQLite的向量扩展或者单机版的向量库完全顶得住没必要上一套分布式系统给自己增加运维负担。我一开始图新鲜上了分布式方案后来发现每天都要维护一个集群纯粹是在给自己找罪受。第二个容易翻车的是长文本生成会跑题。当你让大模型生成8000字时它写到中间往往会开始重复已经表达过的观点或者突然跳到其他方向侃几句。我的对策是分章节生成时严格限制每个章节的篇幅和内容边界并在全局整合阶段加入一次重复检测——把最终成文按语义向量化后对相邻段落的相似度做扫描超过阈值的段落会被自动精简或标记待人工处理。第三个翻车点让我印象很深是PubMed API的幽灵限制。虽然NCBI官方文档写着API Key情况下每秒10次请求但实际上高并发时段连发大量请求还是会随机触发限流。如果你发现某次运行过程中报429概率比平时高很可能不是你的代码出错了而是遇到了上游服务的流量高峰。这时候最简单的应对是重新跑一遍失败的那批请求别动不动就去改代码逻辑。6.3 我的几点个人体会整个项目做到现在我最大的感受可以总结成一句智能体不是替你思考而是帮你在思考之前少做无意义的体力活。它能把100篇文献的获取、整理、分类、初步归纳这些流程压缩到一个小时以内但真正的学术判断——哪些文献值得重点分析、哪些结论之间存在张力、这个方向下一步该往哪里走——仍然需要研究者自己来做。工具释放出来的时间应该花在这些更有价值的地方。另外还有一个很现实的感受任何自动生成的文本都需要一个负责任的使用者。我的智能体里加了很多约束和校验但它仍然会出错。每次我拿它生成的综述前都会预留至少一个小时的人工审阅时间重点检查引用是否准确、结论是否有夸大、逻辑是否连贯。把智能体当助手而不是代笔这是我从头到尾都在坚持的原则。最后分享一个实用的小建议如果你也打算自建这类工具可以考虑把综述生成和文献管理打通把智能体生成的文献清单直接导出到Zotero的特定分类目录中这样后续写文章、做汇报时所有参考文献都能直接复用。我从这个改动里省下的时间大概比智能体本身帮我省的还多。
