这篇解决什么

LangGraph 解决的是「循环、分支、暂停和恢复」。LangChain 把组件串成链；一旦要 ReAct 多步、失败重试、人工确认，就要把状态放到图上，而不是在 while 里堆 if。

核心三要素：State、Node、Edge

  • State：这一轮图上所有节点共享的数据，通常是 TypedDict 或 reducer 合并的字段（消息列表、检索结果、预算）。
  • Node：一个可执行步骤，调模型、调工具或改 State。
  • Edge：固定边或条件边。条件边才是 Agent 的「下一步由模型或规则决定」。

先把 State 字段写清楚，再画边。字段含糊时，节点会互相覆盖，日志也无法回放。

Graph API 和 Functional API

Graph API 显式 add_node / add_edge，适合把控制流画给同事看。Functional API 用检查点装饰普通函数，适合已有业务函数、只想加上持久化和中断。两条 API 共用一套 State 和 HITL 语义，不要混用两套检查点后端。

HITL

人机协同不是弹一个 confirm 对话框。图要在工具执行前 interrupt，把待确认的调用写进 State，恢复时从同一检查点继续，而不是重跑整张图。权限和沙箱仍按本系列「沙箱与多租户」那篇做，LangGraph 只负责停在正确的边上。

流式执行

生产要同时流式输出 token 和节点级事件（进入节点、工具开始、中断）。只推最终字符串，排障时看不见卡在哪条边。检查点选 Postgres / Redis，不要默认内存，进程一重启会话就丢。

怎么选型

控制流必须可见、要暂停恢复：选 LangGraph。只要提示词和检索拼装：回到 LangChain。角色制小队、任务分发更自然：看 CrewAI。要完整 Runtime、权限和 Sandbox：对照已发布的 AgentScope。