LangGraph系列：从入门到精通，掌控大模型工作流与智能体开发

在大模型应用开发的浪潮中，越来越多开发者不再满足于简单调用API实现对话功能，而是渴望构建更复杂、更可控的智能系统，列如能自主查资料的AI研究员、能多步骤处理任务的智能助手。但传统开发框架要么过度封装导致灵活性不足，要么缺乏流程管理能力难以实现复杂逻辑。这时，LangGraph的出现恰好填补了这一空白。作为专门为工作流程和智能体打造的基础设施框架，它以“透明可控”为核心设计理念，让开发者能像搭积木一样编排大模型的执行逻辑，同时兼顾持久化、测试与部署能力。本文将从基础概念到实战代码，全方位拆解LangGraph，带你真正实现从入门到精通的跨越。

一、什么是LangGraph？打破“黑盒”的智能体开发框架

在接触具体技术前，我们先搞清楚一个核心问题：LangGraph到底是什么，它和市面上其他大模型开发框架有何不同？简单来说，LangGraph是一个专注于“流程编排”的基础设施，专门用于构建任意复杂度的工作流程（Workflow）和智能体（Agent）。但它的独特之处在于，它没有走“简化操作”的No-code/Low-code路线，而是选择了“透明可控”的技术路径——不对提示词或架构做过度抽象封装，把每一个环节的控制权都交还给开发者。

这种设计理念带来了三项无可替代的核心优势：

1. 极致的控制能力：流程细节尽在掌握

传统框架可能会预设固定的工作流模板，列如“提问→搜索→回答”的单一流程，但实际开发中，我们往往需要更灵活的逻辑，列如根据搜索结果判断是否需要补充查询，或者多轮反思后再调整策略。LangGraph允许你直接定义每个处理节点，以及节点之间的跳转规则：你可以给流程加循环（列如“反思不足就继续搜索”）、加分支（列如“简单问题直接回答，复杂问题启动多步研究”），甚至支持并行处理（列如多个搜索词同时查资料）。每个节点的输入输出、执行顺序都由你决定，没有任何“暗箱操作”。

举个例子：如果要做一个AI学术助手，你可以用LangGraph设计这样的流程：“接收问题→判断是否需要文献支持→生成关键词→并行搜索多篇文献→提取核心观点→反思是否覆盖所有论点→补充搜索遗漏文献→整合观点生成回答”。整个过程中，每一步的触发条件、处理逻辑都可以准确调整，完全贴合实际需求。

2. 强劲的持久化能力：让智能体拥有“记忆”

智能体要实现复杂任务，“记忆”是必不可少的能力，列如记住之前的搜索结果、反思过的知识盲区、用户的历史提问等。LangGraph框架原生支持图状态（Graph State）的持久化存储，这意味着流程执行过程中的所有状态数据（如搜索关键词、网页摘要、反思结论等）都可以被保存下来。这种能力不仅让“记忆功能”的开发变得简单，还为“人类干预”提供了可能：列如当AI遇到无法解决的问题时，开发者可以暂停流程，手动修改状态数据后再继续执行，极大提升了系统的容错性和灵活性。

3. 完善的开发支持：测试、调试、部署一条龙

复杂流程的开发最怕什么？怕出了问题找不到缘由，怕调试完上线又出bug。LangGraph针对这些痛点提供了完整的解决方案：测试阶段，你可以单步执行流程，查看每个节点的输入输出；调试阶段，框架会记录详细的执行日志，让你清晰看到流程的跳转路径和状态变化；部署阶段，它可以无缝对接FastAPI、Docker等工具，轻松实现线上服务。这种“全链路支持”让开发者不用在不同工具间切换，大大提升了开发效率。

核心总结：LangGraph不是一个“傻瓜式”的工具，而是一个“专业级”的基础设施。它适合那些追求流程可控性、需要构建复杂智能体的开发者，当你不想被框架的预设逻辑束缚，想真正掌控大模型的执行细节时，LangGraph就是最佳选择。

二、项目组成与架构：看懂LangGraph的“骨架”

要真正用好LangGraph，光理解概念还不够，我们需要深入它的项目结构和技术选型，搞清楚每个模块的作用。下面以一个典型的LangGraph实战项目为例，拆解它的组成部分和核心架构。

1. 目录结构：清晰的模块划分

一个标准的LangGraph项目一般会按“前后端分离”的思路组织目录，每个目录各司其职，便于团队协作和后期维护：

frontend/：前端交互层：采用React框架开发，主要负责UI展示和与用户的交互。列如用户输入问题的界面、展示AI回答和引用来源的页面、流程执行状态的实时显示等。这里还会通过API调用后端的LangGraph服务，把用户的输入传递给后端，再把后端返回的结果渲染到页面上。
backend/：后端核心层：这是LangGraph的“主战场”，用Python编写。所有的流程定义、节点逻辑、工具调用都在这里实现。后端不仅包含LangGraph的代理（Agent）代码，还会集成大模型API（如Google Gemini）和第三方工具（如Google Search），是整个系统的“大脑”。
src/agent/：代理核心模块：后端的核心中的核心，包含三个关键部分：一是“流程定义”（graph.py），负责编排整个工作流；二是“工具定义”（tools_and_schemas.py），定义大模型可以调用的工具（如搜索工具）和数据结构（如搜索关键词列表、反思结果等）；三是“状态定义”，规定流程执行过程中需要保存的状态数据（如搜索结果、知识盲区等）。
examples/：示例代码：提供最小化的调用示例，方便开发者快速上手。列如cli_research.py就是一个命令行调用示例，不用启动前端，直接在终端输入问题就能看到效果，超级适合刚开始学习时测试代码。

2. 技术栈：主流工具的高效组合

LangGraph项目的技术栈选择都围绕“高效开发”和“稳定运行”展开，都是行业内成熟且易用的工具：

前端技术

React：构建交互式UI的主流框架，组件化开发模式便于复用和维护。
Vite：比Webpack更快的构建工具，启动速度快、热更新及时，提升前端开发效率。
Tailwind CSS：实用优先的CSS框架，不用写复杂的CSS代码就能快速实现美观的界面。

后端技术

Python 3.11+：保证能使用最新的语言特性和库。
LangGraph：核心流程编排框架。
Google Gemini：提供大模型能力，负责生成搜索词、反思、总结答案等。
FastAPI：高性能的Python Web框架，用于构建后端API，处理前端的请求。

3. 核心流程：AI研究员的“工作日常”

理解了目录和技术栈后，我们来看整个系统的核心运行流程。实则你可以把这个流程想象成一个“AI研究员”的工作过程，每一步都对应着研究员处理问题的逻辑：

用户输入问题：用户通过前端网页或命令行输入一个问题，列如“2025年全球人工智能发展趋势是什么？”。
生成搜索词：AI研究员第一会把问题拆解成适合搜索的关键词，列如“2025人工智能发展趋势报告”“AI技术突破 2025”“全球AI政策 2025”等，这一步对应LangGraph中的generate_query节点。
网页搜索与总结：AI研究员用生成的关键词进行Google搜索，找到相关的权威报告、新闻文章，然后提取核心信息并加上引用标记，这一步对应web_research节点。
反思知识盲区：AI研究员会检查已有的搜索结果是否足够回答问题，有没有遗漏的重大信息（列如某个关键技术领域的趋势没覆盖），如果有就生成补充搜索词——这一步对应reflection节点。
迭代补充搜索：如果反思发现信息不足，就用补充搜索词继续搜索，重复“搜索→反思”的过程，直到信息足够或达到最大迭代次数，这一步由evaluate_research节点控制流程跳转。
合成带引用的答案：当信息足够后，AI研究员把所有搜索到的信息整合起来，生成一篇逻辑连贯、带有引用来源的最终回答，这一步对应finalize_answer节点。

整个流程环环相扣，既有自动化的高效，又有类似人类的反思和迭代能力，这正是LangGraph流程编排的魅力所在。

三、动手实践：启动和体验LangGraph项目

“纸上得来终觉浅”，看完了理论知识，我们来亲手启动一个LangGraph项目，感受它的实际效果。整个过程分为环境准备、安装依赖、运行开发环境和命令行体验四个步骤，超级简单，即使是新手也能快速完成。

1. 环境准备：提前安装必要工具

在开始前，你需要确保电脑上安装了以下工具：

Node.js 16+和npm：用于运行前端项目。你可以在终端输入“node -v”和“npm -v”查看版本，如果没安装，去Node.js官网下载最新版即可（安装时会自动附带npm）。
Python 3.11+：用于运行后端项目。同样在终端输入“python -V”（注意是大写V）查看版本，推荐通过Anaconda或Python官网安装，避免版本过低导致兼容性问题。
Google Gemini API Key：这是必需的，由于项目用Gemini作为大模型。你需要去Google AI Studio官网注册账号，创建项目后生成API Key，保存好备用，注意不要泄露你的API Key，否则可能被他人滥用。

2. 安装依赖：一键脚本或手动操作

第一把项目代码克隆到本地（如果是自己新建项目，可以参考官方示例结构），然后进入项目根目录，安装前后端依赖。项目一般会提供一键安装脚本，操作超级方便：

在Windows系统下，直接双击运行setup.bat文件，然后输入“install”并回车，脚本会自动安装前后端所有依赖：


setup.bat install

如果你想分别安装后端和前端依赖，也可以执行以下命令：


setup.bat install-backend  # 安装后端依赖
setup.bat install-frontend # 安装前端依赖

如果是Mac或Linux系统，需要把.bat脚本改成.sh脚本（或直接执行对应的pip和npm命令），核心就是安装后端的Python库（如langgraph、fastapi、google-generativeai等）和前端的npm包（如react、vite、tailwindcss等）。

注意事项：如果安装过程中出现“权限不足”的错误，Windows系统可以用管理员身份打开终端，Mac/Linux系统在命令前加“sudo”；如果出现依赖冲突，提议创建Python虚拟环境（用venv或conda），在虚拟环境中安装依赖，避免影响全局环境。

3. 运行开发环境：启动前后端服务

依赖安装完成后，执行以下命令启动开发环境：


setup.bat dev

执行后，脚本会自动弹出两个命令行窗口：一个是前端服务（一般运行在http://localhost:5173），一个是后端服务（一般运行在http://localhost:8000）。同时，浏览器会自动打开前端页面，地址是http://localhost:5173/app。

此时你可以在前端页面的输入框中输入问题，列如“今天北京的天气怎么样？”，然后点击提交。页面会显示“processing…”，表明LangGraph正在执行流程：生成搜索词→搜索→反思→生成答案。等待几秒钟后，你就能看到带有引用来源的回答了，超级直观。

4. 命令行体验：快速测试后端功能

如果你不想启动前端，只想快速测试后端的核心功能，可以用命令行示例脚本。在项目根目录执行以下命令，把引号里的问题换成你想问的内容：


setup.bat cli-example "2025年中国新能源汽车销量预测是多少？"

执行后，终端会逐步输出流程的执行状态，列如“生成搜索词：['2025中国新能源汽车销量预测', '新能源汽车行业报告2025']”“正在进行网页搜索…”“反思：现有信息已覆盖主要机构预测，无需补充搜索”，最后输出完整的回答和引用来源。这种方式适合快速调试后端代码，不用关注前端界面。

通过这两个体验方式，你应该能直观感受到LangGraph的强劲，它不像简单的大模型对话，而是能像一个真正的研究员一样，主动查资料、反思不足、迭代优化，最后给出有理有据的答案。

四、深度剖析：端到端代码导读

体验完项目后，我们来深入代码层面，拆解LangGraph项目的核心实现。这部分我们会从“入口→流程定义→节点实现”一步步展开，带你看懂每个环节的代码逻辑，真正做到“知其然并知其所以然”。

1. 入口：命令行调用的起点

我们先从最简单的命令行入口开始，由于它没有前端的干扰，能直接看到后端核心代码的调用逻辑。打开文件
backend/examples/cli_research.py，这是一个最小化的调用示例。

代码的入口在第42行左右：


if __name__ == "__main__":
    main()

当你执行这个脚本时，会调用main()函数（第5行左右）。main()函数的核心逻辑超级简单，就是构造初始状态，然后调用LangGraph的graph.invoke()方法启动流程：


from agent.graph import graph  # 从核心模块导入定义好的graph

def main():
    # 解析命令行输入的问题
    question = sys.argv[2]
    # 构造初始状态：包含用户问题、空的搜索结果等
    state = {
        "messages": [HumanMessage(content=question)],
        "sources_gathered": [],
        "research_loop_count": 0,
    }
    # 启动LangGraph流程，获取结果
    result = graph.invoke(state)
    # 输出最终答案
    print("最终回答：")
    print(result["messages"][0].content)

这里的关键是graph.invoke(state)，graph是我们在agent/graph.py中定义好的工作流，state是初始状态数据。这一行代码就是整个“AI研究员”流程的“启动按钮”，输入初始状态后，LangGraph会自动按照定义好的流程执行，最后返回包含最终答案的状态。

小贴士：如果你想快速测试后端代码，不用执行setup.bat，直接在终端运行python
backend/examples/cli_research.py “你的问题”即可，这样能更快定位问题。

2. 核心：LangGraph的流程定义

顺着from agent.graph import graph，我们打开
backend/src/agent/graph.py，这是整个项目的“流程大脑”。在这里，我们用LangGraph的StateGraph构建器来定义工作流。

第一，代码会定义流程的状态结构（OverallState），规定哪些数据需要在流程中传递和保存，列如用户消息、搜索到的来源、研究循环次数等。然后，从第269行开始，用builder来构建流程：


from langgraph.graph import StateGraph, START, END

# 初始化StateGraph，指定状态类型
builder = StateGraph(OverallState)

# 1. 添加节点：每个节点对应一个处理函数
builder.add_node("generate_query", generate_query)      # 生成搜索词节点
builder.add_node("web_research", web_research)          # 网页研究节点
builder.add_node("reflection", reflection)              # 反思节点
builder.add_node("finalize_answer", finalize_answer)    # 最终答案节点

# 2. 定义流程跳转规则
builder.add_edge(START, "generate_query")               # 流程开始→生成搜索词
# 生成搜索词后→分发到web_research节点（支持并行）
builder.add_conditional_edges("generate_query", continue_to_web_research, ["web_research"])
builder.add_edge("web_research", "reflection")          # 网页研究后→反思
# 反思后→根据结果跳转到web_research（继续搜索）或finalize_answer（生成答案）
builder.add_conditional_edges("reflection", evaluate_research, ["web_research", "finalize_answer"])
builder.add_edge("finalize_answer", END)                # 生成答案后→流程结束

# 3. 编译生成graph
graph = builder.compile(name="pro-search-agent")

这段代码超级直观，就像在画一张“流程图”：

添加节点：用add_node()方法添加每个处理节点，第一个参数是节点名称，第二个参数是节点对应的处理函数（列如generate_query函数负责生成搜索词）。
定义跳转：用add_edge()定义“无条件跳转”（列如流程开始后必定先到generate_query节点），用add_conditional_edges()定义“条件跳转”（列如反思后根据信息是否足够，决定跳转到继续搜索还是生成答案）。
编译graph：用builder.compile()生成最终的graph对象，这个对象就是我们在cli_research.py中导入并调用的graph。

这里的关键是“条件跳转”和“并行处理”，列如continue_to_web_research函数会把每个搜索词都分发到web_research节点，实现多搜索词的并行搜索；evaluate_research函数会判断是否需要继续迭代，实现流程的循环。这正是LangGraph比其他框架灵活的核心缘由。

3. 细节：逐个拆解核心节点实现

流程定义好了，接下来我们看每个节点的具体实现，也就是每个处理函数到底做了什么。我们以“AI研究员”的工作流程为顺序，逐个剖析核心节点。

3.1 generate_query节点：让AI学会“怎么搜”

这个节点的作用是把用户的自然语言问题转换成适合搜索的关键词列表。对应的函数定义在第44行左右：


def generate_query(state: OverallState, config: RunnableConfig) -> QueryGenerationState:
    # 1. 初始化Gemini大模型
    llm = ChatGoogleGenerativeAI(
        model="gemini-pro",
        api_key=os.getenv("GOOGLE_API_KEY"),  # 从环境变量获取API Key
        temperature=0.7,
    )
    # 2. 配置结构化输出：让LLM返回指定格式的结果（搜索词列表+理由）
    structured_llm = llm.with_structured_output(SearchQueryList)
    # 3. 构造提示词：告知LLM如何生成搜索词
    query_writer_instructions = """
    你是一个专业的搜索词生成助手。请根据用户的问题，生成3-5个最相关的搜索词，每个搜索词要具体、精准，便于获取权威信息。同时说明每个搜索词的生成理由。
    用户问题：{question}
    """
    formatted_prompt = query_writer_instructions.format(question=state["messages"][-1].content)
    # 4. 调用LLM生成搜索词
    result = structured_llm.invoke(formatted_prompt)
    # 5. 返回结果：符合QueryGenerationState的格式
    return {"search_query": result.query}

这个函数的核心有两点：

结构化输出：SearchQueryList是在tools_and_schemas.py中定义的Pydantic模型，规定了LLM必须返回“query: List[SearchQuery]”的格式，其中每个SearchQuery包含“term（搜索词）”和“reason（理由）”。这样能确保LLM的输出是结构化的，方便后续代码处理，避免解析非结构化文本的麻烦。
提示词工程：提示词明确告知LLM要生成3-5个精准的搜索词，并说明理由，这能引导LLM生成高质量的搜索词，避免生成太宽泛或不相关的关键词。

3.2 continue_to_web_research节点：分发搜索词实现并行

这个节点不是一个“处理节点”，而是一个“路由节点”，负责把generate_query生成的多个搜索词分发到web_research节点，实现并行处理。函数定义在第84行左右：


def continue_to_web_research(state: QueryGenerationState):
    # 遍历每个搜索词，生成发送到web_research节点的消息
    return [
        Send("web_research", {"search_query": search_query.term, "id": int(idx)})
        for idx, search_query in enumerate(state["search_query"])
    ]

这里用到了LangGraph的Send对象，它表明“把指定的状态数据发送到某个节点”。通过列表推导式，我们为每个搜索词生成一个Send消息，LangGraph会自动把这些消息分发到web_research节点，并行执行搜索，这大大提升了多搜索词的处理效率，不用等待一个搜索完成再执行下一个。

3.3 web_research节点：查资料+提取引用

这个节点是“AI研究员”的核心工作环节，负责用搜索词进行网页搜索，提取信息并加上引用标记。函数定义在第95行左右：


def web_research(state: WebSearchState, config: RunnableConfig) -> OverallState:
    # 1. 获取搜索词
    search_query = state["search_query"]
    # 2. 调用Gemini的搜索工具能力（Gemini原生支持Google搜索）
    genai_client = genai.GenerativeModel("gemini-pro")
    response = genai_client.generate_content(
        f"请搜索以下内容并总结核心信息：{search_query}",
        tools=[{"name": "search", "parameters": {"query": search_query}}],
    )
    # 3. 解析搜索结果，获取原始URL（解决短链问题）
    resolved_urls = resolve_urls(response)
    # 4. 提取引用信息：把搜索结果中的片段和对应的URL关联起来
    citations = get_citations(response, resolved_urls)
    # 5. 在总结文本中插入引用标记（如[1]、[2]）
    modified_text = insert_citation_markers(response.text, citations)
    # 6. 整理来源信息，便于后续使用
    sources_gathered = [item for citation in citations for item in citation["segments"]]
    # 7. 返回结果：更新状态中的搜索结果和来源
    return {
        "sources_gathered": sources_gathered,
        "search_query": [search_query],
        "web_research_result": [modified_text],
    }

这个节点的逻辑比较复杂，但核心是“调用搜索工具+处理引用”：

工具调用：Gemini原生支持Google搜索工具，我们通过tools参数指定搜索词，LLM会自动调用搜索工具获取结果并总结。
引用处理：resolve_urls函数把搜索结果中的短链转换成原始URL，get_citations函数提取每个信息片段对应的来源，insert_citation_markers函数在总结文本中插入引用标记，这三步确保了最终答案的引用是准确、可追溯的，避免了“编造来源”的问题。

3.4 reflection节点：让AI学会“反思不足”

这个节点是“AI研究员”的“思考环节”，负责检查现有搜索结果是否足够回答问题，生成知识盲区和补充搜索词。函数定义在第139行左右：


def reflection(state: OverallState, config: RunnableConfig) -> ReflectionState:
    # 1. 收集已有的搜索结果
    research_results = "
".join(state["web_research_result"])
    # 2. 构造反思提示词
    reflection_instructions = """
    你是一个专业的研究反思助手。请根据用户的问题和已有的搜索结果，回答以下问题：
    1. 现有信息是否足够全面回答用户问题？（是/否）
    2. 如果不足，知识盲区是什么？
    3. 需要补充哪些搜索词来填补知识盲区？
    用户问题：{question}
    已有搜索结果：{research_results}
    """
    formatted_prompt = reflection_instructions.format(
        question=state["messages"][-1].content,
        research_results=research_results,
    )
    # 3. 调用LLM进行反思，结构化输出结果
    llm = ChatGoogleGenerativeAI(model="gemini-pro", api_key=os.getenv("GOOGLE_API_KEY"))
    result = llm.with_structured_output(Reflection).invoke(formatted_prompt)
    # 4. 返回反思结果：是否足够、知识盲区、补充搜索词
    return {
        "is_sufficient": result.is_sufficient,
        "knowledge_gap": result.knowledge_gap,
        "follow_up_queries": result.follow_up_queries,
        "research_loop_count": state["research_loop_count"] + 1,  # 增加循环计数
    }

这里的核心是Reflection结构体（同样定义在tools_and_schemas.py中），它规定了LLM必须返回“is_sufficient（是否足够）”“knowledge_gap（知识盲区）”“follow_up_queries（补充搜索词）”三个字段。通过这种方式，AI能像人类一样主动检查自己的工作成果，发现不足并提出改善方案，而不是简单地“有什么资料就输出什么”。

3.5 evaluate_research节点：控制流程的“决策环节”

这个节点是流程的“决策中枢”，根据reflection节点的结果，决定是继续补充搜索还是进入最终答案生成环节。函数定义在第183行左右：


max_research_loops = 3  # 最大研究循环次数，避免无限循环

def evaluate_research(state: ReflectionState, config: RunnableConfig) -> OverallState:
    # 1. 判断条件：信息足够 或 达到最大循环次数
    if state["is_sufficient"] or state["research_loop_count"] >= max_research_loops:
        # 条件满足，跳转到finalize_answer节点
        return "finalize_answer"
    else:
        # 条件不满足，用补充搜索词继续调用web_research节点
        return [
            Send("web_research", {
                "search_query": follow_up_query,
                "id": int(idx) + len(state["search_query"])
            })
            for idx, follow_up_query in enumerate(state["follow_up_queries"])
        ]

这个函数的逻辑很清晰，但有两个关键点需要注意：

终止条件：设置max_research_loops（列如3次）是为了避免流程陷入无限循环。如果AI一直认为信息不足，就会不断补充搜索，设置最大次数能确保流程最终会结束。
状态传递：返回Send消息时，给补充搜索词的id加上了已有搜索词的长度，避免id重复，确保每个搜索任务的标识唯一。

3.6 finalize_answer节点：合成最终答案

这是流程的最后一个节点，负责把所有搜索结果整合起来，生成一篇逻辑连贯、引用规范的最终回答。函数定义在第220行左右：


def finalize_answer(state: OverallState, config: RunnableConfig):
    # 1. 收集所有搜索结果和来源
    research_results = "
".join(state["web_research_result"])
    sources = state["sources_gathered"]
    # 2. 构造最终回答提示词
    answer_instructions = """
    你是一个专业的答案合成助手。请根据用户的问题和已有的搜索结果，生成一篇逻辑清晰、语言流畅的最终回答。要求：
    1. 回答要全面覆盖用户问题，基于已有的搜索结果。
    2. 在引用信息的地方标注引用标记（如[1]、[2]），引用标记要和来源对应。
    3. 结尾列出所有引用来源的完整URL。
    用户问题：{question}
    搜索结果：{research_results}
    """
    formatted_prompt = answer_instructions.format(
        question=state["messages"][-1].content,
        research_results=research_results,
    )
    # 3. 调用LLM生成最终回答
    llm = ChatGoogleGenerativeAI(model="gemini-pro", api_key=os.getenv("GOOGLE_API_KEY"))
    result = llm.invoke(formatted_prompt)
    # 4. 处理引用：把短链替换成原始URL，去重来源
    unique_sources = []
    for source in sources:
        if source["short_url"] in result.content:
            result.content = result.content.replace(source["short_url"], source["value"])
        if source not in unique_sources:
            unique_sources.append(source)
    # 5. 返回最终结果：更新消息和来源
    return {
        "messages": [AIMessage(content=result.content)],
        "sources_gathered": unique_sources,
    }

这个节点的核心是“整合与规范”：把多个搜索结果的信息融合成一篇连贯的回答，确保引用标记和来源对应，并且对来源进行去重，避免重复列出一样的URL。最终返回的AIMessage会包含完整的回答内容，这就是我们在前端或命令行看到的最终结果。

五、总结与展望：LangGraph的无限可能

通过本文的解析，信任你已经对LangGraph有了全面的认识：它不是一个简单的大模型调用工具，而是一个专注于流程编排的基础设施框架，以“透明可控、持久化、易开发”为核心优势，让开发者能轻松构建复杂的智能体系统。从概念到架构，从实践到代码，我们一步步拆解了LangGraph的核心内容，你会发现它的设计理念超级贴近实际开发需求，不做过度封装，把控制权交给开发者，同时提供完善的工具链支持。