在 LangChain 系列的最后一篇里，我们用 create_agent 几行代码就搭出了一个能调工具、有记忆、能人工审核的智能体。它好用，但也是个黑盒：循环怎么转、在哪一步停、出了错从哪里重来，都由框架替你决定。当流程本身就是业务的核心时，你需要自己把这张图画出来。这个系列就从 create_agent 往下走一层，学习它的底座 LangGraph。本篇先建立思维方式：为什么是"图"、图由什么组成、图是怎么一步步跑起来的，最后亲手搭出第一张工作流。

一、create_agent 的内部，其实是一张图#

先回忆一下 Agent 是怎么工作的：模型读完问题，决定要不要调用工具；如果要，就执行工具，把结果交回给模型；模型再判断下一步……直到它不再调用工具，给出最终回答。

把这个过程画出来，就是这样：

flowchart LR
  S([开始]) --> M[调用模型]
  M -->|回复里有工具调用| T[执行工具]
  T --> M
  M -->|没有工具调用| E([结束])

图里只有两个步骤——"调用模型"和"执行工具"；一条固定的线——工具执行完总是回到模型；还有一条有条件的线——看模型的回复里有没有工具调用，决定是去执行工具还是结束。

这不只是一个比喻。create_agent 返回的对象，本身就是一张由 LangGraph 编译好的图，可以直接打印出它的结构：

Python
agent = create_agent(model, tools=[get_weather])
print(type(agent).__name__)              # CompiledStateGraph
print(agent.get_graph().draw_mermaid())  # 输出图结构：节点 model、tools，以及它们之间的连线

打印出来的节点正好叫 model 和 tools，连线也和上面手画的一模一样。换句话说，上一个系列里用过的每一个 Agent，都是一张 LangGraph 图。

这张"模型 ⇄ 工具"的循环图非常适合开放式任务：要走几步事先不知道，由模型自己判断什么时候结束。但很多真实业务并不是这样的：

  • 流程有固定步骤。比如客服工单必须先识别意图、再查订单、最后生成回复，任何一步都不允许被模型"跳过"；
  • 有可以同时做的事。同时查内部知识库和网络搜索，两边谁也不依赖谁，没必要排队；
  • 需要在固定位置停下来。转账前必须人工确认，确认后要从停下的地方接着走，而不是从头再来；
  • 分支由业务规则决定。金额大于一万走审批，否则直接执行——这种判断不该交给模型去"猜"。

在 create_agent 上，这些需求只能靠中间件去打补丁。当流程本身就是业务的骨架时，更自然的做法是把流程直接画成图，每一步做什么、走哪条线，都由你来定。这正是 LangGraph 要解决的问题。

二、LangGraph 是什么，和 LangChain 怎么分工#

官方对 LangGraph 的定位是底层的编排框架与运行时。它不提供提示词模板，也不封装模型，只关心一件事：把多个步骤组织成一张图，并把这张图可靠地执行完。在此之上，它还提供了几项单靠写函数很难做好的能力：

  • 持久化：图每走一步都可以把进度存下来，进程崩溃后能从断点继续；
  • 人机协作：在任意一步暂停，等人确认或修改后再继续；
  • 流式输出：一边执行一边把中间结果推给前端；
  • 记忆：短期记住一次会话，长期记住用户偏好。

这些能力后面会一篇一篇展开。现在只需要记住两个框架的分工：