链式调用为什么不够用

早期 Agent 框架（包括 LangChain 最初的 Chain）本质是一条线性管道：输入进，输出出，中间串几个步骤。但真实的智能体任务充满了循环、分支与回退——写完代码要跑测试，测试挂了得回头改，改完再跑；查资料发现方向错了，要退回去换检索词。线性管道表达不了这种「根据中间结果动态决定下一步去哪」的控制流，于是很快就撞上了天花板。LangGraph 由 LangChain 团队推出，把 Agent 的运行时建模成一张有状态的图：节点是计算步骤，边是转移条件，状态在节点间流动。这一步抽象转换，让 Agent 从「脚本」变成了「可循环的程序」。

节点、边与共享状态

LangGraph 的核心三件套。**节点（node）**是一个普通 Python 函数，接收当前状态、返回要更新的状态片段。**边（edge）**决定下一个节点是谁：固定边写死转移，条件边根据状态里的字段动态路由，比如 if error: go to fix_node else: go to review_node。**状态（state）**是一张被所有节点读写的共享字典，通常用 TypedDict 或 Pydantic 定义，还能配 reducer 决定多个节点写同一字段时是覆盖还是追加（比如消息列表用 add_messages 累加而非替换）。

这套抽象的好处是可控：你能在图里画出循环，能加人在环（human-in-the-loop）的断点，能让某个节点失败后走兜底分支。相比「一个大 prompt 让模型自己决定调什么工具」的黑盒 Agent，LangGraph 把控制流交还给开发者——模型负责推理，图负责流程。

检查点与持久化是它的护城河

真正让 LangGraph 区别于玩具框架的，是 checkpointer。图在每一步执行完都会把状态持久化（可以落 SQLite、Postgres），于是 Agent 可以随时中断、第二天恢复、甚至把状态序列化后在另一个进程里接着跑。这对长周期任务（比如要跑几小时的代码修复 agent、跨多轮对话的客服）至关重要：进程崩了不丢进度，用户随时能插入一条指令让它从当前节点继续。这也是生产级 Agent 系统和 demo 的分水岭。

与其他框架的分工

AutoGen 偏多智能体对话，CrewAI 偏角色分工的角色扮演式协作，LangGraph 偏底层的可控状态图。如果你要的是「快速搭一个多角色剧本」，CrewAI 更顺手；如果你要的是「能调试、能持久化、能上生产的确定性流程」，LangGraph 更可靠。很多团队的做法是用 LangGraph 做编排内核，把工具层通过 MCP 接进来——协议管工具互联，图管流程控制，各司其职。

收束

Agent 编排的演进方向很清楚：从不可控的单 prompt 黑盒，走向有状态、可观测、可恢复的图。LangGraph 抓住了「状态」这个要害。对开发者而言，理解节点、条件边、reducer、checkpointer 这四个概念，比盲目堆工具调用更重要——因为 Agent 的可靠性，从来不是某个模型多聪明，而是流程有没有被好好地组织起来。

去论坛讨论

关于「LangGraph」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。