一、为什么要从 RAG 升级到 AgentPaperPilot 是一个基于 RAG检索增强生成架构的 AI 文献助手核心功能是帮用户检索文献、管理引用、生成开题报告。在之前的版本中我已经实现并优化了三种检索策略向量检索、混合检索、重排序回答质量有了明显提升。但在实际使用中我发现传统 RAG 有一个绕不过去的瓶颈它只会”检索—生成”这一条固定流水线。举个真实场景用户问”帮我对比一下近三年 Transformer 在医学影像方向的研究进展并给出值得投稿的方向建议”。传统 RAG 的做法是——把整句话拿去检索一次召回几篇文献然后让大模型基于这些文献生成回答。问题显而易见1.不会拆解任务这个问题其实包含”检索文献→筛选近三年→按方法分类→对比分析→给出建议”多个步骤单次检索根本覆盖不了2.不会自我修正检索结果不理想时它不会换关键词重试而是”将错就错”地硬答3.不会使用工具查不到的信息不会调用外部搜索算不了的引用格式不会调用格式化工具。于是我把 PaperPilot 升级到了 Agentic RAG——在 RAG 之上引入 Agent智能体让系统具备规划、工具调用、反思的能力。这篇文章记录完整的改造思路与实现过程。二、Agentic RAG 是什么和普通 RAG 有什么区别先用一句话区分•传统 RAG一条直线。Query → 检索 → 拼接 Prompt → LLM 生成 → 输出。•Agentic RAG一个循环。LLM 作为”大脑”自主决定什么时候检索、检索什么、用哪个工具、结果够不够好、要不要再查一轮。核心差异在于 Agent 引入了三个能力模块能力 说明 在 PaperPilot 中的作用Planning规划 把复杂问题拆解为子任务 把”对比研究进展”拆成多次定向检索Tool Use工具调用 自主调用外部工具 文献检索、网页搜索、引用格式化、笔记读写Reflection反思 评估中间结果质量并自我修正 召回文献不相关时自动改写查询重试业界常见的实现框架有 ReActReasoning Acting、Plan-and-Execute 等。PaperPilot 采用的是 ReAct 模式模型在每一轮输出”思考Thought→ 动作Action→ 观察Observation“循环直到得出最终答案。这个模式实现最简单、可控性强适合文献助手这种工具链明确的场景。三、PaperPilot 的 Agent 架构设计整体架构分为四层用户提问│▼┌─────────────────────────────┐│ Agent 核心LLM ReAct 循环│ ← 大脑推理与决策├─────────────────────────────┤│ 规划模块 │ 记忆模块 │ 反思模块 │ ← 能力组件├─────────────────────────────┤│ 工具层 Tools ││ · 文献向量检索原有 RAG ││ · 混合检索 Rerank ││ · 联网搜索 ││ · 引用格式生成器GB/T 7714 ││ · 用户文献库读写 │├─────────────────────────────┤│ 数据层向量数据库 文献元数据库 │└─────────────────────────────┘几个关键设计决策原有 RAG 检索不废弃而是降级为”工具”。 之前优化的三种检索策略向量、混合、Rerank全部封装成 Tool由 Agent 按需调用。这保证了检索质量的投资不浪费Agent 只是在其上做调度。引入短期记忆 长期记忆。 短期记忆保存当前会话的 ReAct 循环历史Thought/Action/Observation长期记忆记录用户的文献库、研究方向偏好让 Agent 的回答越来越”懂”这个用户。反思机制兜底质量。 每轮工具返回后Agent 会先自评“这些文献和问题的相关度够吗覆盖了几个子问题”不够就改写查询再来一轮设置最大循环次数防止死循环。四、核心代码实现精简版以下是 Agent 主循环的伪代码级实现实际开发中基于云函数/后端服务运行TOOLS {“literature_search”: vector_hybrid_search, # 文献混合检索Rerank“web_search”: web_search_api, # 联网搜索“format_citation”: gbt7714_formatter, # 引用格式化“library_read”: read_user_library, # 读用户文献库}REACT_PROMPT “”你是文献研究助手。可用工具{tool_desc}按如下格式循环作答Thought: 当前需要做什么Action: 工具名Action Input: 工具参数系统返回 Observation 后继续当信息足够时输出Final Answer: 最终答案问题{question}“”def agent_run(question, max_steps8):context REACT_PROMPT.format(…)for step in range(max_steps):output llm.generate(context)thought, action, action_input parse(output)if action “Final Answer”:return action_inputobservation TOOLSaction# 反思让模型评估观察结果质量context f\nThought: {thought}\nAction: {action}\ncontext fAction Input: {action_input}\ncontext fObservation: {observation}\nreturn “达到最大步数基于现有信息给出答案…”关键点就三个1.工具描述写清楚模型才知道什么时候该调哪个工具2.解析要鲁棒LLM 输出格式偶尔会跑偏需要正则兜底和格式纠正重试3.限制最大步数成本控制的第一道闸门Agent 的 Token 消耗通常是普通 RAG 的 3~5 倍。五、实测效果对比以”对比近三年 Transformer 在医学影像分割方向的研究进展并给出投稿方向建议”为例维度传统 RAGAgentic RAG检索次数1 次平均 3~5 次按子问题拆分召回文献相关性一般常混入无关年份/方向高每轮检索针对性强回答结构单段综述分方向对比 趋势分析 方向建议错误自我修正无检索结果差时自动换词重试响应耗时~3s10~15sToken 成本1x3~5x结论很现实Agent 换来的是质的提升付出的是时延和成本。所以 PaperPilot 里做了路由策略——简单问题“帮我格式化这篇引用”走单工具直调复杂问题综述、对比、规划类才走完整 Agent 循环。六、踩坑记录1.死循环问题模型会在”反思不通过→重试→又不通过”里打转。解法是最大步数 反思判定阈值放宽比如相关度评分 ≥0.7 就放行。2.工具选择混乱工具一多超过 5~6 个模型容易选错。解法是给每个工具写清楚”什么时候用我”并在 Prompt 里给出 1~2 个 few-shot 示例。3.成本失控初期每轮都把全部历史塞进 PromptToken 爆炸。解法是对 Observation 做摘要压缩只保留结论性内容。4.解析失败LLM 不严格按格式输出。解法是用 JSON mode / function calling如果模型支持替代纯文本 ReAct稳定性大幅提升——这也是我下一步的优化方向。七、总结与下一步引入 Agent 后PaperPilot 从”一个会查文献的问答机器人”进化成了”一个会拆解任务、自我修正的研究助理”。整个改造的核心收益在于•复杂问题的回答质量显著提升•原有 RAG 检索能力被完整复用改造成本可控•架构具备良好的扩展性——后续加新工具翻译、图表解析、开题报告生成只需要注册一个 Tool。下一步计划1.将 ReAct 文本协议迁移到 Function Calling提升稳定性2.引入 多 Agent 协作检索 Agent、写作 Agent、审校 Agent 分工3.针对文献场景微调路由模型进一步压低成本。