LangGraph 构建 Agent 有几种方式?

30 秒回答

1. 掌握LangGraph的三种核心构建方式（StateGraph、MessageGraph、Pregel底层）
2. 理解状态机驱动 vs 消息驱动的设计差异
3. 能说明各方式的适用场景和选型依据
4. 了解LangGraph相比LangChain原生Agent的优势（循环、持久化、人机协同）

回答与解析

答案要点

• 掌握LangGraph的三种核心构建方式（StateGraph、MessageGraph、Pregel底层）
• 理解状态机驱动 vs 消息驱动的设计差异
• 能说明各方式的适用场景和选型依据
• 了解LangGraph相比LangChain原生Agent的优势（循环、持久化、人机协同）

LangGraph是LangChain团队推出的用于构建复杂Agent的框架，核心是将Agent建模为状态图（StateGraph）。主要构建方式有三种：

1. StateGraph（状态图）——最常用

原理：定义状态Schema + 节点函数 + 边条件，形成有向图。每个节点接收当前状态，返回状态更新，通过边路由到下一节点。

from langgraph.graph import StateGraph, END

class State(TypedDict):
    messages: Annotated[list, add_messages]
    next: str

builder = StateGraph(State)
builder.add_node("agent", call_model)
builder.add_node("tools", execute_tools)
builder.add_conditional_edges("agent", should_continue, {"continue": "tools", "end": END})

适用：多步骤决策、需要显式控制流的复杂Agent，如ReAct循环、多Agent协作。

2. MessageGraph（消息图）——简化版

原理：状态简化为消息列表，节点直接操作消息，自动处理消息传递。本质是StateGraph的特化。

from langgraph.graph import MessageGraph

builder = MessageGraph()
builder.add_node("oracle", model)
builder.add_edge("oracle", "tools")

适用：简单链式或循环对话场景，快速原型，不需要复杂状态管理。

3. Pregel底层API——极致灵活

原理：直接操作图计算引擎，自定义channel、reducer、并行执行策略。类似Apache Beam的编程模型。

适用：超大规模并行、需要自定义同步机制的场景，如MapReduce风格的批量处理。

选型建议

LangGraph相比原生LangChain Agent的核心优势：显式状态管理支持断点续传、人机介入，图结构打破DAG限制允许循环，更适合生产级复杂Agent。

口语版讲法(约4分钟)

• 一句话定位：LangGraph本质是状态图，三种方式对应不同抽象层次
• StateGraph最常用，适合复杂Agent流程
• MessageGraph是简化版，适合快速原型
• Pregel底层API适合特殊场景
• 选型建议与业务场景结合，风险点

这道题其实是在问，用LangGraph搭Agent时，怎么在可控性和灵活性之间做取舍。LangGraph的核心是把Agent建模成状态图，而三种构建方式，说白了就是不同抽象层次的工具。

先说最常用的 StateGraph，也就是状态图。它的原理是，你定义好状态的数据结构，比如一个包含消息列表和下一步动作的字典，然后每个节点函数接收当前状态，返回状态更新，再通过条件边决定下一步跳到哪个节点。这样一来，整个Agent的决策流就变成了一个有向图，你可以清晰地看到每一步怎么走。举个例子，做客服退款场景的Agent，需要先判断用户意图，再查订单状态，然后执行退款，最后确认结果。用StateGraph，你可以把这些步骤拆成节点，中间加条件判断，比如如果退款失败就回到人工节点。这种方式特别适合多步骤决策，比如ReAct循环或者多Agent协作，因为状态是显式管理的，支持断点续传和人机介入。

再一个是 MessageGraph，它是StateGraph的简化版。状态就简化为消息列表，节点直接操作消息，框架自动处理消息传递。说白了，就是快速搭一个链式或简单循环的对话Agent，不用操心复杂的状态管理。比如你想验证一个简单的LLM调用工具链，MessageGraph几行代码就能跑起来。但它有个局限，就是状态太薄，一旦流程复杂，比如需要持久化或者多分支，就不好用了。所以它的适用场景就是快速原型和简单循环。

最后是 Pregel底层API，这个用得少，但特别灵活。它让你直接操作图计算引擎，自定义channel和reducer，甚至控制并行执行策略。有点像Apache Beam那种编程模型。什么场景用呢？比如你要做MapReduce风格的批量处理，或者超大规模并行计算，需要自定义同步机制。但说实话，绝大多数业务场景用不到这个，因为复杂度和收益不成正比。

所以选型上，我一般这么看：标准Agent流程，比如ReAct或者Plan-and-Execute，直接上StateGraph；快速验证一个想法，用MessageGraph；多Agent并行投票或者复杂编排，StateGraph加子图就够了；只有当你对性能有极致要求，或者要做非常规的并行逻辑，才考虑Pregel。

这里有个坑，很多人一上来就用StateGraph，觉得功能全，但其实小场景下MessageGraph更轻量，开发效率更高。反过来，MessageGraph用着用着发现状态不够用，再重构到StateGraph，成本也不低。所以我会先评估流程复杂度，再选。

还有一个点值得提，就是LangGraph的优势其实在于它的图结构打破了DAG限制，允许循环，这点在实现自我反思或者纠错逻辑时特别有用。比如Agent执行工具调用后，如果结果不对，可以自动回到推理节点重试，而不是简单报错。

总的来说，我更倾向把StateGraph当作默认选项，因为它平衡了可控性和灵活性，适合生产级落地。而MessageGraph和Pregel更像是针对特定场景的补充工具，知道它们存在就够了。

关键一句:LangGraph的循环能力在自我反思或纠错逻辑中特别有用，比如Agent执行工具后结果不对可自动重试。

面试官还可能这样问

1. 问法 1 · 场景切入

   我看你简历里用过LangChain做Agent。假设现在要做一个多步检索+推理的客服Agent，用户问题需要调用API查库存、比价格再回答，流程有分支有循环，你用LangGraph会怎么搭这个结构？

2. 问法 2 · 层层追问

   用LangChain写Agent你一般怎么定义步骤？……那如果流程里需要根据中间结果决定下一步是调用工具还是直接回答，循环怎么实现？……LangGraph里有没有现成的模式能处理这种带状态的路由？

3. 问法 3 · 直球架构

   LangGraph构建Agent有几种主要方式？StateGraph、MessageGraph和底层Pregel各适用于什么场景？你分别说一下它们的实现原理和选型依据。