什么是 LangGraph？为什么它能让 AI 从一问一答进化成智能体

什么是 LangGraph

LangGraph 是一个用于构建、管理和运行长时间运行、有状态 AI Agent 的低层编排框架。它把复杂任务表达成一张由状态、节点和边组成的图，让应用能够保存中间结果、调用工具、动态选择路径、形成循环，并在需要时暂停或恢复。

一句话概括：LangGraph 专门解决“怎样让大模型可靠地连续完成多步骤任务”，而不是“怎样让大模型生成一次回答”。

LangGraph 本身不是大模型，也不会训练模型。它更像智能体的运行骨架：模型负责理解、推理和生成，工具负责查询或执行，LangGraph 负责保存任务状态，并决定各步骤按照什么顺序运行。

为什么普通的一问一答还不够

普通大模型 API 通常是无状态的。一次请求结束后，模型不会自动保存上一步的任务进度；下一次调用能否看到历史信息，取决于应用是否重新提供这些内容。

一次问答适合翻译、改写、摘要和简单知识问答，但现实任务通常还要求 AI：

• 记住用户目标、约束条件和已经完成的步骤。
• 调用搜索、数据库、代码执行器或业务 API。
• 根据工具结果决定下一步，而不是始终走固定路径。
• 遇到错误后重试、改用备用方案或请求人工确认。
• 在长任务中暂停，之后从原来的进度继续执行。

因此，从聊天机器人到智能体的关键变化，不只是多调用几次模型，而是为模型增加状态管理、任务编排、工具调用和反馈循环。

多步骤任务为什么需要状态和决策

假设用户提出这个需求：

帮我查一下下周五北京飞上海的机票，选最便宜的那班，然后根据航班时间，推荐机场附近评分高的咖啡馆。

这个任务至少包含四个相互依赖的步骤：

1. 查询指定日期的北京到上海航班。
2. 比较价格，筛选最便宜的有效航班。
3. 从航班结果中读取到达机场和到达时间。
4. 查询附近营业中的高评分咖啡馆并生成推荐。

如果没有航班，智能体不能继续搜索咖啡馆，而应询问用户是否更换日期；如果最便宜的航班到达虹桥机场，后续搜索地点就不能写成浦东机场；如果咖啡馆已经打烊，还需要换一个结果。

每一步都会产生新信息，新信息又会改变下一步决策。LangGraph 用状态保存这些信息，用图控制任务如何向前推进。

LangGraph 和传统链式调用有什么区别

传统链式调用更像一根水管：数据按照预设顺序从输入流向输出。LangGraph 更像一张流程地图：节点负责执行动作，边负责连接路径，条件边根据当前状态选择下一站。

图结构并不意味着每个流程都必须复杂。固定步骤仍然可以画成一条直线；只有真正存在不确定性的部分，才需要条件分支或循环。

为什么图结构能支持循环和自我修正

真实任务很少永远沿一条直线执行。工具可能超时，搜索结果可能不足，模型输出可能不符合格式，用户也可能需要在中途补充信息。

LangGraph 允许执行路径回到之前的节点。例如：

1. 智能体先生成一个方案。
2. 校验节点检查事实、格式或业务约束。
3. 如果通过，流程进入最终输出节点。
4. 如果失败，流程进入修正节点。
5. 修正后的结果再次送回校验节点。
6. 达到质量要求或重试上限后结束。

这种“执行一个动作、观察结果、再决定下一步”的循环，是 Agent 能够持续行动的基础。LangGraph 的价值在于把循环显式地写进程序，而不是只依赖一段提示词要求模型“自己反思”。

LangGraph 的三个核心概念是什么

LangGraph 的 Graph API 围绕三个核心概念展开：状态、节点和边。状态保存任务上下文，节点执行具体工作，边控制执行路径。

三者组合后，一个大任务就能被拆成职责单一、可测试、可替换的小模块。

状态为什么是智能体的共享记忆

状态是一次图执行中的共享数据结构。任何节点都可以读取它需要的字段，并返回本节点产生的更新。

旅行助手的状态可能包含：

class TravelState(TypedDict):
    origin: str
    destination: str
    travel_date: str
    budget: int
    flights: list[dict]
    selected_flight: dict | None
    cafes: list[dict]
    current_step: str

这里需要区分“状态”和“持久化记忆”：

• 状态描述当前任务正在使用的数据。
• checkpointer 可以在每个步骤保存状态检查点，让任务在中断或失败后恢复。
• store 可以保存跨线程、跨会话使用的长期信息，例如用户偏好。
• 模型本身并没有被重新训练，应用只是在后续调用时把相关状态重新提供给模型。

所以，“有状态”不是让模型突然拥有永久记忆，而是让应用以可控、可检查的方式管理上下文和进度。

节点和边分别负责什么

节点是干活的地方，边是安排路径的地方。一个节点通常是 Python 或 JavaScript/TypeScript 函数，可以调用大模型、搜索服务、数据库、自定义 API，也可以只做普通的数据处理。

普通边表示确定的顺序，例如“制定计划完成后进入路由节点”。条件边会读取当前状态，再决定去哪个节点，例如：

def choose_next(state: ResearchState) -> str:
    if state["all_tasks_done"]:
        return "write_report"
    if state["next_task"] == "search_news":
        return "search_web"
    return "search_papers"

清晰的职责边界很重要：节点应专注完成一个动作，路由函数应专注选择路径。把所有逻辑塞进一个超大节点，会失去图结构带来的可观察性和可测试性。

研究助手如何用 LangGraph 制定计划

以“研究量子计算的最新进展，并写一份简短报告”为例，应用启动时会把用户问题写入状态，然后进入“制定计划”节点。

制定计划节点可以调用大模型，把任务拆成三个子任务：

1. 搜索近期新闻和公司动态。
2. 查询论文数据库或可信研究机构资料。
3. 汇总证据并生成报告。

计划会写回状态，而不是只保留在某一次模型输出里。后续节点因此能知道哪些任务已经完成、哪些任务仍在等待执行。

智能路由和循环如何推进任务

计划完成后，条件边读取状态中的待办项。如果第一个未完成任务是“搜索新闻”，流程就进入网络搜索节点；搜索结果写回状态后，执行路径再次回到路由节点。

整个循环可以概括为：

1. 路由节点检查计划和当前状态。
2. 选择一个尚未完成的子任务。
3. 对应节点调用工具并保存结果。
4. 执行路径返回路由节点。
5. 如果仍有待办项，进入下一轮。
6. 如果任务全部完成，进入报告节点。

为了避免智能体无限循环，生产系统必须设置最大步数、超时、重试上限和明确的结束条件。灵活路由解决的是路径选择问题，不代表系统可以无限制地自主运行。

任务完成后如何生成报告

当条件边判断所有子任务都已完成，流程会进入“生成报告”节点。这个节点读取状态中的搜索结果、论文摘要和来源信息，再调用大模型生成最终报告。

可靠的报告节点不应只负责“写得通顺”，还应执行这些约束：

• 只使用状态中已有的研究材料。
• 为关键事实保留来源和发布日期。
• 区分论文结论、公司公告和媒体报道。
• 资料不足时明确说明限制，不编造缺失信息。
• 输出结构化字段，便于后续校验或页面展示。

报告写回状态后，图到达终点。此时应用既有最终答案，也保留了计划、工具调用结果和执行轨迹，便于调试与审计。

LangGraph 为什么能让 AI 从问答进化成智能体

LangGraph 让 AI 从问答进化成智能体，是因为它补上了单次模型调用缺少的四类运行能力：持续状态、行动工具、动态决策和反馈循环。

真正的跨越不是让模型“更会聊天”，而是让它能在受控流程里持续观察、决策和行动，直到完成目标或触发明确的停止条件。

LangGraph 还提供哪些生产能力

除了状态、节点和边，LangGraph 还围绕长时间运行的 Agent 提供多项基础能力：

1. 持久化执行：通过检查点保存图状态，让任务在进程中断后继续。
2. Human-in-the-loop：在付款、发送邮件、修改数据等敏感动作前暂停，等待人工审批或修改状态。
3. 流式输出：把节点更新、工具消息或模型 token 实时发送给界面。
4. 时间旅行：从历史检查点检查、修改或重新执行某个分支，适合调试和人工纠错。
5. 子图：把复杂工作流拆成可复用模块，也可用于多智能体协作。
6. 可观察性集成：结合 LangSmith 追踪运行轨迹、延迟、错误和质量评估。

这些能力不会自动让答案变正确，但能让智能体的执行过程更容易恢复、检查和控制。

LangGraph、LangChain 和 LangSmith 有什么区别

三者属于同一生态，但解决的问题不同。LangChain 提供模型与工具等应用组件，LangGraph 负责有状态编排和运行，LangSmith 负责追踪、评估与监控。

LangGraph 可以独立使用，也可以调用 LangChain 组件。当前 LangChain 的高层 Agent 运行时本身也建立在 LangGraph 之上。想快速构建常见 Agent，可以先用 LangChain；需要精细控制执行路径时，再直接使用 LangGraph。

哪些场景适合使用 LangGraph

LangGraph 适合下一步会受到中间结果影响，并且需要保存状态、循环执行或人工介入的任务：

• 多源研究助手和深度搜索。
• 能搜索、运行代码并读取报错的编程 Agent。
• 包含分类、检索、生成、校验和重写的 RAG 系统。
• 需要审批的客服、财务或企业自动化流程。
• 可以暂停数小时或数天再恢复的长任务。
• 多个专业 Agent 共享状态并协作的系统。

如果任务只是一次摘要、固定格式转换或三步确定性 API 调用，直接写函数、使用普通链或工作流通常更简单。是否使用 LangGraph，应由状态复杂度和路径不确定性决定，而不是由“是否用了大模型”决定。

LangGraph 有哪些局限和风险

LangGraph 提供的是编排基础设施，不会自动解决模型幻觉、数据质量、工具权限和业务正确性问题。

常见限制包括：

• 学习成本：开发者需要理解状态合并、条件路由、检查点和并发更新。
• 调试复杂：循环和动态分支越多，可达路径越多，测试成本越高。
• 成本与延迟：多轮模型调用和工具调用会显著增加 token 消耗与等待时间。
• 无限循环：缺少结束条件和步数上限时，Agent 可能重复执行。
• 状态膨胀：把所有历史信息都放进状态，会增加存储和上下文成本。
• 副作用重放：恢复任务时，发邮件、扣款或写数据库等节点必须考虑幂等性，避免重复执行。
• 安全风险：提示注入可能诱导 Agent 误用工具，高风险动作仍需最小权限和人工确认。

生产环境至少应加入结构化状态、节点级测试、最大步数、超时、重试策略、幂等设计、调用日志和敏感操作审批。

常见问题

LangGraph 是大模型吗？

不是。LangGraph 是 Agent 编排框架和运行时。它可以调用 OpenAI、Anthropic 或其他模型，也可以运行完全不包含大模型的状态图。

LangGraph 一定要和 LangChain 一起使用吗？

不一定。LangGraph 可以直接配合普通 Python 或 JavaScript/TypeScript 函数、模型 SDK 和自定义工具使用。使用 LangChain 组件通常能减少模型与工具集成工作，但不是硬性要求。

LangGraph 的状态等于长期记忆吗？

不等于。状态主要保存当前线程和当前任务的数据；checkpointer 用于保存执行检查点；跨会话长期记忆通常通过 store 或外部数据库实现。模型本身不会因为状态存在而自动更新参数。

LangGraph 和工作流有什么区别？

LangGraph 本身就是一种图工作流框架，但它特别面向有状态、长时间运行和动态决策的 Agent。普通工作流通常更强调预先确定的业务步骤，LangGraph 则更适合包含模型路由、循环、工具反馈和人工介入的流程。

LangGraph 能保证 Agent 不出错吗？

不能。LangGraph 能让错误处理、状态恢复和人工审批更容易实现，但模型仍可能判断错误，工具也可能返回错误数据。可靠性来自框架能力、业务校验、权限控制、测试和监控的共同作用。

小项目需要使用 LangGraph 吗？

通常不需要。如果应用只有一次模型调用或少量固定步骤，直接使用模型 SDK 更清楚。只有当流程出现共享状态、条件分支、循环、暂停恢复或多 Agent 协作时，LangGraph 的价值才会明显。

总结

LangGraph 是为长时间运行、有状态 AI Agent 设计的低层编排框架。它用状态保存任务上下文，用节点执行模型或工具动作，用边定义顺序、分支和循环。

它让 AI 从一问一答进化成智能体的原因，不是让基础模型本身发生了变化，而是为模型补上了可持续运行的工程结构：记住进度、制定计划、调用工具、检查结果、修正错误，并在明确边界内继续行动。

最值得记住的一句话是：大模型提供智能，LangGraph 负责把这份智能组织成一个可执行、可恢复、可控制的过程。

参考资料

• LangGraph 官方概览
• LangGraph Graph API
• LangGraph 持久化文档
• LangGraph Durable Execution
• LangGraph Interrupts 与 Human-in-the-loop