企业官网建设流程全解析

1. 项目概述：构建一个本地的深度研究智能体

最近在折腾一个挺有意思的项目，我把它叫做“本地RAG深度研究员”。简单来说，这是一个能帮你做深度资料调研和分析的AI助手，但它最大的特点是完全运行在你的本地电脑上。想象一下，你有一个私人研究助理，它不仅能理解你的复杂问题，还能自动从你本地的文档库、甚至互联网上查找、筛选、分析信息，最后给你生成一份结构清晰的报告，而且整个过程不依赖任何云端API，数据隐私完全由你掌控。

这个项目的核心，是把几个当下很火的技术栈组合在了一起：用LangGraph来编排整个智能体的工作流，用Ollama在本地运行强大的DeepSeek R1推理模型，用ChromaDB作为本地的向量数据库来存储和检索你的知识库。最终，通过一个简单的Streamlit网页界面，你就能和这个“研究员”对话了。我之所以花时间搭建它，是因为在实际工作和学习中，我们常常需要处理大量的信息。无论是写技术报告、做竞品分析，还是研究一个新领域，手动收集、阅读、总结资料的过程既耗时又容易遗漏重点。一个能自主执行多步骤研究任务的智能体，能显著提升信息处理的效率和质量。

这个项目适合谁呢？如果你是对AI应用开发感兴趣的开发者，想学习如何用LangGraph构建多智能体工作流，或者想实践本地化大模型部署与RAG（检索增强生成）技术，那么这个项目会是一个很好的练手案例。即使你只是终端用户，希望有一个安全、私密的个人研究工具，按照本文的步骤，你也能在自己的机器上把它跑起来。接下来，我会拆解整个系统的设计思路、详细实现步骤，并分享我在搭建过程中踩过的坑和总结的经验。

2. 核心架构与工作流设计解析

2.1 为什么选择“自适应RAG”架构？

传统的RAG系统流程相对固定：用户提问 -> 检索相关文档 -> 将文档和问题一起扔给大模型生成答案。这种模式有个明显的问题：如果第一次检索到的文档质量很差或者完全不相关，系统就会基于垃圾信息生成一个垃圾答案，没有补救机制。

因此，在这个项目中，我采用了“自适应RAG”的设计思路。它的核心思想是让系统具备“判断”和“调整”的能力。整个工作流被设计成一个有状态的图（State Graph），由LangGraph驱动，智能体在不同的节点间流转，每个节点负责一项专门任务，并且会根据当前结果决定下一步走向。这模拟了人类研究员的思考过程：先尝试从已知资料库（本地知识库）找答案；如果找不到或不够好，就去扩展搜索（联网搜索）；对找到的资料要进行评估，过滤掉无关内容；最后才进行归纳总结。

这种架构的优势在于健壮性和效率的平衡。它不会盲目地进行昂贵的联网搜索（尤其是使用付费API时），而是优先利用免费的本地资源。只有当本地知识无法满足需求时，才会启动备用方案，确保最终结果的质量。同时，通过“评估”环节，也避免了将不相关的噪音信息传递给总结环节，提升了最终报告的准确性和相关性。

2.2 技术栈选型背后的考量

选对工具是项目成功的一半。下面我详细解释每个核心组件的选型原因：

1. Ollama + DeepSeek R1：本地推理引擎

   • Ollama：几乎是本地运行大模型的事实标准。它封装了模型加载、GPU内存管理、对话接口等复杂细节，通过一个简单的命令行工具就能拉取和运行上百种模型，极大地降低了入门门槛。
   • DeepSeek R1：这是我选择的核心模型。在众多开源模型中，DeepSeek R1系列（特别是经过深度对齐的版本）在推理能力和指令遵循上表现突出。研究任务不仅仅是续写文本，更需要模型理解复杂指令、进行逻辑推理和综合判断。DeepSeek R1在这方面的能力足以胜任研究助理的角色。选择7B参数版本是基于消费级硬件（如配备16GB内存的笔记本电脑）的可行性考量，它能在保证功能的同时实现流畅运行。

2. LangGraph：智能体工作流编排器

   • 为什么不用简单的脚本？因为研究流程包含条件分支和循环（比如“判断是否需要进一步搜索”）。LangGraph允许你以“图”的形式直观地定义智能体的状态和节点（函数），并指定节点之间的流转路径。它管理着整个对话状态，让构建复杂、有状态的智能体变得像搭积木一样清晰。相比于直接使用LangChain的Chain，LangGraph对多步骤、有条件的工作流支持更原生、更强大。

3. ChromaDB：本地向量数据库

   • 我们需要一个地方来存储和管理本地文档的“记忆”（即向量嵌入）。ChromaDB的优点是轻量、易用，且完全本地化。它不需要像PgVector或Weaviate那样依赖外部数据库服务，开箱即用，特别适合个人或小规模项目。它将我们的PDF、TXT、Word等文档转换成向量，并高效地进行语义相似度检索。

4. Streamlit：快速构建交互界面

   • 目标是让工具可用，而不是只停留在命令行。Streamlit允许用纯Python脚本快速创建数据应用界面。对于这个项目，我们只需要一个输入框、一个按钮和一个结果显示区域，Streamlit在几分钟内就能搞定，让整个项目变成一个真正的Web应用。

5. Tavily API：高质量的联网搜索备用方案

   • 当本地知识库无能为力时，我们需要向外部世界求助。Tavily是一个专为AI智能体优化的搜索API，它返回的结果已经是结构化的、简洁的摘要，减少了大量网页爬取和清洗的工作。虽然它是云端API且付费，但作为本地检索的补充和兜底方案，其成本和效率是合理的。

注意：Tavily API需要注册并获取密钥，有免费额度。如果你追求极致的本地化，可以将其替换为其他开源爬虫方案，但这会显著增加复杂度和不稳定性。

整个系统的数据流如下图所示：用户问题进入后，依次经过查询生成 -> 本地检索 -> 相关性评估 -> 条件判断（是否需要联网）-> 汇总与报告生成。这个流程被固化在LangGraph图中，确保了每次执行的一致性和可靠性。

3. 环境搭建与详细配置指南

纸上得来终觉浅，绝知此事要躬行。下面我们一步步把这个系统搭建起来。我会假设你使用的是macOS或Linux系统（Windows用户请在WSL2环境下操作，体验更佳）。

3.1 基础环境准备

首先确保你的系统满足最低要求：Python 3.9或以上版本，以及至少16GB的物理内存（运行7B模型较流畅）。建议使用conda或venv创建独立的Python环境，避免包冲突。

# 1. 克隆项目代码仓库 git clone https://github.com/kaymen99/local-rag-researcher-deepseek cd local-rag-researcher-deepseek # 2. 创建并激活虚拟环境（以venv为例） python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 3. 安装项目依赖 pip install -r requirements.txt

requirements.txt文件通常包含以下核心库（版本可能更新，以仓库为准）：

langchain>=0.1.0 langchain-community langgraph>=0.0.50 chromadb streamlit ollama python-dotenv tavily-python

安装过程中如果遇到某些包编译错误，通常是因为缺少系统依赖。例如在Ubuntu上，你可能需要运行sudo apt-get install build-essential python3-dev。

3.2 核心服务部署：Ollama与DeepSeek R1

这是项目的“大脑”安装步骤。

1. 安装Ollama： 访问 Ollama官网 下载对应系统的安装包，或者使用命令行安装脚本。安装完成后，在终端输入ollama --version验证。

2. 拉取DeepSeek R1模型： Ollama安装好后，拉取模型就像下载软件包一样简单。这里我们选择7B参数的版本，它在效果和资源消耗上比较平衡。

   ollama pull deepseek-r1:7b

   这个命令会下载约4-5GB的模型文件。下载速度取决于你的网络。完成后，你可以测试一下模型是否正常工作：

   ollama run deepseek-r1:7b

   在出现的提示符后输入“Hello”，看模型是否能正常回复。按Ctrl+D退出。

   实操心得：第一次运行ollama run时，它会将模型加载到内存，可能会比较慢。后续通过LangChain调用时，Ollama服务会在后台常驻，响应就快多了。另外，如果你的GPU显存足够（例如8GB以上），Ollama会自动利用GPU加速。你可以通过ollama ps查看运行中的模型。

3.3 配置向量数据库与知识库

系统需要一个“长期记忆”来存储你的本地文档。我们使用ChromaDB，它默认将数据存储在本地的一个目录中。

1. 准备你的文档： 在项目根目录下创建一个documents文件夹，将你想要让智能体学习的文件放进去。支持格式包括.txt,.md,.pdf,.docx等。LangChain有相应的文档加载器（UnstructuredFileLoader,PyPDFLoader等）来处理它们。

2. 生成向量库（知识库）： 原项目可能提供了脚本，或者需要在首次运行时初始化。核心过程是：

   • 加载文档：使用LangChain的文档加载器读取documents文件夹下的所有文件，并分割成大小适中的文本块（例如500字符一段，重叠50字符）。
   • 生成嵌入：使用一个嵌入模型（Embedding Model）将每个文本块转换成向量。这里有一个关键点：为了完全本地化，我们需要一个本地运行的嵌入模型。通常可以选择nomic-embed-text或all-minilm等小型高效模型，同样通过Ollama运行。
   • 存储向量：将这些向量及其对应的原文块，存入ChromaDB的一个集合（Collection）中。

   一个简化的初始化脚本可能如下所示（你需要根据项目实际结构调整）：

   from langchain_community.document_loaders import DirectoryLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader = DirectoryLoader('./documents', glob="**/*.txt") # 也可以支持多种格式 documents = loader.load() # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) splits = text_splitter.split_documents(documents) # 3. 创建本地嵌入函数和向量库 embeddings = OllamaEmbeddings(model="nomic-embed-text") # 使用Ollama运行嵌入模型 vectorstore = Chroma.from_documents(documents=splits, embedding=embeddings, persist_directory="./chroma_db")

   运行后，会在当前目录生成一个chroma_db文件夹，里面就是你的本地知识库。

3.4 获取并配置API密钥（可选）

如果你希望启用联网搜索功能，需要配置Tavily API。

1. 访问 Tavily官网 注册账号。
2. 在控制台找到你的API Key。
3. 在项目根目录创建.env文件，并填入密钥：

   TAVILY_API_KEY="your_tavily_api_key_here"

   如果你的研究完全基于本地文档，可以不配置此项，并在代码中关闭联网搜索功能。

4. 核心代码与智能体工作流拆解

理解了环境搭建，我们深入到代码内部，看看这个“研究员”的大脑是如何工作的。核心逻辑集中在assistant/graph.py文件中。

4.1 状态定义：研究员的“记忆白板”

LangGraph的核心是状态管理。我们首先定义一个状态字典，记录研究过程中的所有信息。这就像研究员手边的白板，随时记录和更新。

from typing import TypedDict, List, Annotated import operator class GraphState(TypedDict): """ 定义图的状态，所有节点都会读写这个状态。 """ question: str # 用户原始问题 queries: List[str] # 根据问题生成的多个搜索查询 documents: List[str] # 检索到的文档内容列表 evaluated_docs: List[str] # 经过相关性评估后的文档 search_needed: bool # 是否需要联网搜索的标志 web_results: List[str] # 联网搜索的结果 final_context: str # 最终用于生成报告的综合上下文 report: str # 生成的最终报告

Annotated和operator用于LangGraph内部的状态合并操作，例如将多个节点生成的文档列表合并到一起。

4.2 节点函数：研究员的各项技能

智能体的每个步骤都对应一个节点函数。我们重点看几个关键节点：

节点1：生成搜索查询 (generate_queries)这个节点的任务是把用户的一个复杂问题，拆解成3-5个更具体、更容易被检索到的子问题。例如，用户问“如何在Python中实现高效的数据清洗？”，它可能生成：

1. “Python pandas 数据清洗常用方法”
2. “处理缺失值的最佳实践 Python”
3. “Python 数据去重和类型转换技巧”

def generate_queries(state: GraphState): prompt = f""" 你是一个专业的搜索专家。针对以下问题，生成3到5个用于网络或文档检索的搜索查询词。 问题：{state['question']} 请直接输出查询词，每行一个。 """ # 调用本地DeepSeek R1模型 response = ollama.chat(model='deepseek-r1:7b', messages=[{'role': 'user', 'content': prompt}]) queries = [q.strip() for q in response['message']['content'].split('\n') if q.strip()] return {"queries": queries}

这里直接通过Ollama的Python库调用模型。你也可以使用LangChain的ChatOllama封装，它提供了更统一的接口。

节点2：检索相关文档 (retrieve_documents)利用上一步生成的查询词，从ChromaDB向量库中并行检索相关文档。

def retrieve_documents(state: GraphState): all_docs = [] for query in state['queries']: # 对每个查询，从向量库中获取最相关的3个文档块 docs = vectorstore.similarity_search(query, k=3) all_docs.extend([doc.page_content for doc in docs]) # 简单去重 unique_docs = list(set(all_docs)) return {"documents": unique_docs}

节点3：评估文档相关性 (evaluate_documents)这是实现“自适应”的关键。不是所有检索到的文档都有用。这个节点让模型对每个文档打分，判断其与原始问题的相关性。

def evaluate_documents(state: GraphState): relevant_docs = [] for doc in state['documents']: prompt = f""" 请评估以下文档片段是否与回答这个问题相关： 问题：{state['question']} 文档：{doc[:500]}... # 截取部分进行评估 请只回答“相关”或“不相关”。 """ response = ollama.chat(model='deepseek-r1:7b', messages=[{'role': 'user', 'content': prompt}]) if "相关" in response['message']['content']: relevant_docs.append(doc) # 判断是否需要进一步搜索：如果相关文档太少（例如少于2条），则触发联网搜索 search_needed = len(relevant_docs) < 2 return {"evaluated_docs": relevant_docs, "search_needed": search_needed}

节点4：执行联网搜索 (web_search)这是一个条件节点，只有当search_needed为True时才被调用。它使用Tavily API进行搜索。

def web_search(state: GraphState): if not state['search_needed']: return {"web_results": []} from tavily import TavilyClient client = TavilyClient(api_key=os.environ["TAVILY_API_KEY"]) web_results = [] for query in state['queries']: response = client.search(query, max_results=2) # 每个查询取前2条结果 for result in response['results']: web_results.append(result['content']) # 获取结果的摘要内容 return {"web_results": web_results}

节点5：生成最终报告 (generate_report)这是最后一步，将评估后的本地文档和联网搜索结果合并，交给模型进行综合分析和撰写。

def generate_report(state: GraphState): all_context = state['evaluated_docs'] + state['web_results'] combined_context = "\n\n---\n\n".join(all_context) # 这里可以引入更复杂的提示词模板，定义报告格式（如引言、要点、总结） report_prompt = f""" 基于以下上下文信息，撰写一份关于“{state['question']}”的详细报告。 要求：报告结构清晰，分点论述，重点突出，并注明信息出处（如果上下文中有暗示）。 上下文信息： {combined_context} """ response = ollama.chat(model='deepseek-r1:7b', messages=[{'role': 'user', 'content': report_prompt}]) return {"final_context": combined_context, "report": response['message']['content']}

4.3 构建与编译工作流图

将上述节点用LangGraph连接起来，定义流转逻辑。

from langgraph.graph import StateGraph, END # 创建图 workflow = StateGraph(GraphState) # 添加节点 workflow.add_node("generate_queries", generate_queries) workflow.add_node("retrieve", retrieve_documents) workflow.add_node("evaluate", evaluate_documents) workflow.add_node("search_web", web_search) workflow.add_node("generate_report", generate_report) # 设置边的流转关系 workflow.set_entry_point("generate_queries") workflow.add_edge("generate_queries", "retrieve") workflow.add_edge("retrieve", "evaluate") # 条件边：根据评估结果决定是否联网搜索 workflow.add_conditional_edges( "evaluate", # 这是一个判断函数，返回下一个节点的名称 lambda state: "search_web" if state['search_needed'] else "generate_report", { "search_web": "search_web", "generate_report": "generate_report" } ) workflow.add_edge("search_web", "generate_report") workflow.add_edge("generate_report", END) # 编译图，得到一个可执行的应用 app = workflow.compile()

现在，这个app就是我们的智能体。我们可以通过app.invoke({"question": "你的问题"})来启动一次完整的研究流程。

4.4 前端交互界面集成

为了让非开发者也能使用，我们用Streamlit包装一个简单的Web界面。代码通常在app.py中。

import streamlit as st from assistant.graph import app as research_agent # 导入上面编译好的智能体 st.title("🔍 本地深度研究助理") st.markdown("基于DeepSeek R1与LangGraph构建，完全在您本地运行。") question = st.text_area("请输入您的研究问题：", height=100) if st.button("开始研究"): if question: with st.spinner("研究员正在思考，请稍候..."): # 调用智能体 result = research_agent.invoke({"question": question}) # 显示结果 st.subheader("📄 生成的研究报告") st.markdown(result['report']) # 可选：显示检索到的上下文 with st.expander("查看检索到的参考资料"): st.text(result['final_context']) else: st.warning("请输入问题。")

运行streamlit run app.py，一个简洁的研究工具界面就在浏览器中打开了。

5. 高级定制与优化技巧

基础版本跑通后，你可以根据需求进行深度定制，让它更强大、更贴合你的使用场景。

5.1 定制报告格式与模板

默认的报告生成提示词比较简单。你可以在report_structures文件夹下创建不同的模板。例如，创建一个technical_analysis.md：

# 技术分析报告：{{ question }} ## 执行摘要 请用一段话概括核心发现。 ## 关键技术与方法 请列出从资料中识别出的主要技术或方法，并简要说明其原理和适用场景。 ## 对比与评估 如果资料中包含多种方案，请对它们进行对比分析，指出各自的优缺点。 ## 实施建议 基于以上分析，给出具体的实施步骤或选型建议。 ## 参考资料摘要 - [来源1摘要] - [来源2摘要] ...

然后在generate_report节点中，根据用户选择加载不同的模板文件，并将模板内容与上下文一起填充到提示词中，从而控制输出格式。

5.2 切换为云端大模型

虽然本地运行隐私性好，但DeepSeek R1 7B的能力上限可能无法应对极其复杂的研究任务。你可以轻松切换到更强大的云端模型，如GPT-4o或DeepSeek-V3。

1. 修改模型调用：在assistant/graph.py中，将ollama.chat调用替换为对应云服务的SDK调用。例如，使用OpenAI：

   from openai import OpenAI client = OpenAI(api_key=os.environ["OPENAI_API_KEY"]) def call_openai(prompt): response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}] ) return response.choices[0].message.content

   然后将所有节点函数中的ollama.chat调用替换为call_openai。

2. 使用OpenRouter统一接口：原项目提到了OpenRouter，这是一个聚合了众多云端模型的服务。使用它的好处是，你只需一个API Key，就可以在代码中灵活切换不同厂商的模型，便于对比测试。你需要安装openai库（OpenRouter兼容OpenAI API协议），并将base_url指向OpenRouter。

   from openai import OpenAI client = OpenAI( api_key=os.environ["OPENROUTER_API_KEY"], base_url="https://openrouter.ai/api/v1" ) # 调用时，在model参数中指定你想用的模型，如'deepseek/deepseek-chat'

5.3 优化检索质量

检索是RAG的基石，这里有几个优化方向：

• 调整文本分块策略：RecursiveCharacterTextSplitter的chunk_size和chunk_overlap参数至关重要。对于技术文档，500-1000字符的块可能合适；对于对话或小说，可能需要按段落或句子分割。重叠部分可以避免上下文被割裂。
• 尝试不同的嵌入模型：Ollama支持的嵌入模型不止nomic-embed-text。你可以尝试mxbai-embed-large（效果更好但更慢）或all-minilm（更快但效果稍逊）。通过ollama pull拉取新模型，并在代码中更改OllamaEmbeddings的model参数。
• 使用重排序器：简单的向量相似度检索可能会漏掉一些语义相关但措辞不同的文档。可以加入一个“重排序”步骤，即先用向量检索出较多的候选文档（如20个），再用一个更精细的交叉编码器模型对它们进行相关性重排，只保留Top-K个最相关的。虽然这会增加计算量，但能显著提升精度。

5.4 添加对话记忆与多轮交互

目前的系统是单次问答，没有记忆。你可以利用LangGraph的状态持久化能力，实现多轮对话。基本思路是：将历史对话（包括问题和之前的报告摘要）也作为状态的一部分，在生成搜索查询和最终报告时，将历史上下文考虑进去。这需要更精细的状态设计和提示词工程，避免上下文过长导致模型性能下降。

6. 常见问题与故障排除实录

在搭建和运行过程中，你几乎一定会遇到下面这些问题。这里是我踩过坑后的解决方案。

6.1 Ollama相关问题

问题1：运行ollama pull或ollama run速度极慢或失败。

• 原因：网络连接Ollama官方服务器不畅。
• 解决：
  1. 配置镜像源。对于国内用户，可以设置环境变量：export OLLAMA_HOST=114.116.19.131:8080（这是一个国内镜像，请确认其可用性和安全性）。或者修改Ollama配置。
  2. 使用代理。如果已有科学上网环境，可以为Ollama配置代理：export ALL_PROXY=http://your_proxy_ip:port。
  3. 手动下载模型文件。从社区（如Hugging Face）下载模型的Modelfile和权重文件，然后使用ollama create命令本地创建模型。

问题2：运行模型时提示“CUDA out of memory”或进程被系统杀死。

• 原因：模型所需内存超过可用显存或内存。
• 解决：
  1. 使用量化版本：尝试更小的量化版本，例如deepseek-r1:7b-q4_K_M（4位量化），它所需内存更少。使用ollama pull deepseek-r1:7b:q4_K_M拉取。
  2. 调整Ollama运行参数：通过ollama run的--num-gpu或--num-thread参数限制资源使用。更有效的是在拉取模型时指定参数，或修改已拉取模型的配置。
  3. 关闭其他占用内存的应用程序。
  4. 升级硬件：如果长期使用，考虑增加内存或使用带更大显存的GPU。

6.2 依赖包安装与版本冲突

问题：pip install -r requirements.txt时报错，提示某些包版本不兼容。

• 原因：LangChain生态更新非常快，依赖关系复杂。
• 解决：
  1. 优先使用项目锁定的版本：如果项目提供了requirements.txt，严格按照里面的版本安装。
  2. 创建全新的虚拟环境：确保环境干净，没有旧版本残留。
  3. 分步安装：如果整体安装失败，尝试注释掉requirements.txt里的大部分包，先安装langchain-core,langchain-community,langgraph等核心包，再逐个安装其他依赖，看是哪个包出了问题。
  4. 查看项目Issue：去GitHub仓库的Issues页面搜索错误信息，很可能别人已经遇到并解决了。

6.3 向量数据库检索结果不相关

问题：系统检索到的文档与问题完全无关。

• 原因与排查：
  1. 嵌入模型不匹配：确保生成向量库（索引）时使用的嵌入模型，与检索时使用的嵌入模型是同一个。如果中途更换了模型，必须重新生成向量库。
  2. 文本分块不合理：块太大（包含多个不相关主题）或太小（语义不完整）都会影响检索。尝试调整chunk_size和chunk_overlap。
  3. 查询词质量差：观察generate_queries节点生成的查询词是否准确。如果不准，需要优化这个节点的提示词。
  4. 相似度阈值：ChromaDB的similarity_search默认返回前k个，可能包含低分结果。可以改用similarity_search_with_score获取分数，并设置一个最低分数阈值进行过滤。

6.4 Streamlit界面运行报错或无响应

问题：运行streamlit run app.py后，页面空白或提示错误。

• 排查：
  1. 检查端口占用：Streamlit默认使用8501端口。确保该端口未被其他程序占用。
  2. 查看终端日志：Streamlit会在终端输出详细的错误信息，这是排查问题的第一手资料。
  3. 检查导入路径：确保在app.py中导入智能体app的路径正确。如果项目结构不同，可能需要使用相对导入（如from .assistant.graph import app）或修改sys.path。
  4. 模型未加载：首次在Streamlit中调用Ollama时，如果Ollama服务未启动或模型未加载，会超时。确保先通过命令行测试Ollama模型可以正常运行。

6.5 性能优化建议

当知识库文档很多时，系统可能会变慢。

• 索引优化：ChromaDB支持持久化到磁盘，首次加载后后续查询会快很多。确保persist_directory参数设置正确。
• 异步处理：对于retrieve_documents和web_search这类I/O密集型操作，可以考虑使用异步（asyncio）来并行执行多个查询，减少总体等待时间。
• 缓存：对于相同的用户问题，可以使用functools.lru_cache对最终报告进行缓存，避免重复计算。但要注意，如果知识库更新了，缓存需要失效。

搭建这样一个系统就像组装一台精密仪器，每个环节都可能出问题。但一旦调通，看到它能够自动完成从问题分析、资料搜集到报告成文的整个流程，那种成就感是非常棒的。这个项目不仅是一个工具，更是一个学习LangGraph、大模型应用和RAG技术的绝佳平台。你可以从修改提示词开始，逐步尝试更复杂的工作流，比如加入多智能体辩论、迭代式研究等，不断探索AI自主智能的边界。