企业官网建设流程全解析

LangGraph 1.2 实战连载（一）：从状态机到 Agent——重新理解"图式编排"

本文基于langgraph 1.2.x（2026-10 稳定版）。如果你还在看 0.1/0.2 的老教程，建议直接重学——API 已经换了几轮。

前言：为什么又要写一篇 LangGraph 教程

说实话，LangChain 生态的教程过期速度比牛奶还快。你搜到的"LangGraph 入门"十篇里有八篇跑不起来：set_entry_point变成了START/END、invoke和ainvoke傻傻分不清、interrupt连个返回 schema 都没有。

所以这一篇（以及下一篇）的目标很明确：用 2026 年还能跑通的 API，把 LangGraph 的核心心智模型讲透，并顺手串一遍 1.2 这一年新增的生产级特性。两篇是连载，这一篇打地基（状态机模型 + 第一个图 + 新特性速览），下一篇上生产（持久化、时间旅行、人工审核、多 Agent）。

一、为什么需要 LangGraph

先泼盆冷水：不是所有 LLM 应用都需要 LangGraph。

• 单次调用 / 简单线性链 → 用LCEL或干脆一个函数就完事，别上图。

• 多步、有分支、要循环重试、要暂停等人确认 → 这才是 LangGraph 的舒适区。

LangGraph 解决的本质问题是：把"Agent 的运行时"显式化成一张状态机图。节点是函数，边是流转规则，状态（State）在节点间流转并被修改。相比手写while True+if/else调 LLM 的"意大利面条"，它给你三样免费的东西：

1. 可审计：每一步状态都能看、能回放。

1. 可持久化：崩溃了能从断点续跑（checkpointer，下篇讲）。

1. 可控：分支、循环、人工介入都是一等公民，不是 hack。

一句话——LangGraph 让你把 Agent 当成状态机来设计，而不是当成聊天机器人来祈祷。

二、核心心智模型：图 = 状态机

LangGraph 的世界由四个东西组成：

2.1 State：用MessagesState偷懒

聊天类应用 90% 的 State 只有一个键messages。LangGraph 已经给你预制好了：

add_messages这个 reducer 是关键——它决定新消息是追加进列表，而不是覆盖整个列表。很多人初学踩的坑就是：自己手写State忘了加 reducer，结果多轮对话直接被覆盖成最后一条。

如果你要自定义状态，正确写法是：

2.2 建图四步（1.2 现行写法）

注意导入START/END（不是大写字符串"__start__"，那是旧写法）：

三、第一个能跑的 LangGraph：智能客服分类器

一个带条件路由的例子——根据用户问题分类，决定走"自动回复"还是"人工升级"。完整可运行：

关键点：add_conditional_edges的第三个参数是路由字典，把route()的返回值映射到目标节点。这是实现"重试逻辑""Agent 分支"的核心套路，务必吃透。

四、LangGraph 1.2 这一年都更新了啥（新特性速览）

光会建图可不够，2026 年 LangGraph 悄悄补齐了一堆"从能跑到敢上生产"的能力。下面这些是 1.2.x 已经落地的：

• Node Caching（节点缓存）：重跑时跳过冗余计算，同样的输入直接命中缓存。长流程调试省时间。

• Deferred Nodes（延迟节点）：把一个节点扇出成多个并行子任务，等全部完成后再用 barrier 汇合给下游——天然的 Map-Reduce。

• Pre/Post Model Hooks（模型前后置钩子）：在模型调用边界做上下文裁剪、护栏（guardrails）、PII 脱敏。以前要自己在节点里硬塞，现在框架管。

• Content-block Streaming（内容块流式 API）：统一的StreamPart输出，前端逐块渲染体验更顺。

• Per-node Timeout（节点级超时）：单个节点卡死不再拖垮整个图。

• Typed Error Handlers（带类型的错误处理器）：错误能路由到指定的"恢复节点"，而不是整图崩。

• DeltaChannel 类型：只存增量 delta，长列表/大状态省内存。

• interrupt()支持response_schema（1.2.12）：人工审核时能对"人回传的值"做结构校验，详见下篇。

提醒：上述部分特性（缓存、延迟节点、钩子、流式）的精确参数随小版本微调，落地前请以pip show langgraph的版本号对照官方 changelog 为准。但"它们已经存在、且是生产必备"这件事，你可以放心写进方案里。