LangGraph 入门：把工作流画成图是什么意思
数据截至 2026-07，价格与限额以各官网为准。
“把工作流画成图”不是一句比喻，它是 LangGraph 的字面设计：节点是函数或 LLM 调用，边定义控制流，一份带类型的状态字典在这些节点之间传递并被不断改写。理解了这三样东西，你就理解了这个框架八成的心智模型；剩下的两成是持久化和人工介入，那才是它区别于”随手写个 while 循环”的地方。
先承认一个很常见的误解：不少人以为 LangGraph 是”给 agent 加了个可视化流程图编辑器”，像那些拖拽式的低代码平台一样。不是的。这里的”图”是代码里的数据结构，不是画布上的图形。你依然在写 Python，只是不再把流程写成一条从上到下的函数调用链，而是先把流程拆成一个个节点，再显式声明”这个节点跑完之后去哪儿”。它更接近状态机的写法，而不是画图工具。
一、“画成图”到底画的是什么
拿一个具体场景来说：做一个能查资料、能自我校对的写作 agent。传统写法大概是一个主函数，里面顺着往下调：先调检索，再调模型生成，再调一次模型做审阅，如果审阅不过就回头重新生成。
用图的方式重新表达，你要做的是把它拆成这样几块（数一下是四个节点、一个判断）：
- 节点 A：检索资料
- 节点 B：生成草稿
- 节点 C：审阅打分
- 节点 D：定稿输出
- 判断：C 之后，分数够就去 D，不够就回 B
画出来就是：
[A 检索] → [B 生成] → [C 审阅] ──不合格──→ 回到 [B]
└──合格────→ [D 定稿]
在 LangGraph 的模型里，A/B/C/D 就是节点（node），箭头就是边（edge），“合格还是不合格”那个岔路口是一条条件边——由一个函数在运行时返回下一步该去哪个节点。你不再是在一个大函数里靠嵌套 if 和 while 把流程”藏”在控制流里，而是把流程本身作为一份显式的结构声明出来。
这个区别听上去像风格偏好，实际影响很大：流程一旦是显式的数据结构，框架就能对它做事情——记录每一步的状态、在任意一步中断和恢复、把中间过程流式吐给前端、允许人在某个节点插一脚。这些能力在”藏在函数里的控制流”上是做不到的，因为框架根本不知道你的程序走到哪一步了。
二、状态：图里流动的那份字典
节点和边只是骨架，真正让图跑起来的是状态。LangGraph 的做法是让状态以一份带类型的字典在节点之间传递：每个节点接收当前状态，返回它想要更新的部分，框架把更新合并回去，再交给下一个节点。
为什么强调”带类型”？因为多节点协作最容易出的问题就是字段对不上——B 节点往里塞了个 draft，C 节点却去读 content，跑到一半才炸。把状态的结构提前声明出来，字段名、字段类型都是明确的，写第二个节点的时候就有据可依，而不是靠翻上一个节点的代码猜。
几条实践上的建议：
- 状态里只放流程需要的东西，不要把整个数据库查询结果原样塞进去。状态会被完整地存快照、在节点间反复搬运，塞太多东西既费内存也难排查。
- 想清楚每个字段是”覆盖”还是”追加”。比如”当前草稿”是每次覆盖的，“审阅意见历史”是要一条条累积的。这两种语义混在一起是新手最常见的坑，写状态定义的时候就要区分开。
- 给状态里的字段起长一点的名字。节点多了以后
data、result、output这种名字会互相打架。
真正上手写代码时的具体类型声明写法、状态合并的具体机制，请以 LangGraph 官方文档当前版本为准——各家框架的 API 这两年都在快速变，任何教程里抄来的具体签名都有过期的可能，本文只讲不会过期的那层心智模型。
三、循环和分支：图模型真正值钱的地方
如果你的流程是”第一步→第二步→第三步”这种一条道走到黑的线性管线，说实话上不上 LangGraph 差别不大，甚至用更轻的东西更省事。图模型的价值集中在有循环、有分支的场景。
带反馈环的循环任务上，LangGraph 是有明显优势的一类——第三方对比的实测口径是它在这类任务上胜出，而 CrewAI 虽然技术上也支持循环，但调试起来相当痛苦。这不难理解：循环意味着同一个节点会被跑很多遍，每一遍的输入都不一样，出问题的时候你需要知道的是”第几轮、当时状态里是什么、为什么这一轮判断成了继续循环”。图模型把每一轮的状态快照都留下来了，你能一轮一轮翻；藏在 while 里的循环则只留下最后崩掉的那一刻。
常见的循环形态有这么几种（数一下，三种）：
- 自我修正循环：生成 → 检查 → 不过则重生成。上面那个写作例子就是。
- 工具调用循环：模型决定调工具 → 执行 → 把结果喂回模型 → 模型决定还要不要继续调。这其实就是 ReAct 的思考-行动-观察循环在框架里的落地形态。
- 多轮澄清循环：信息不够就回头问用户，问到够了再往下走。
写循环有一个必须现在就记住的纪律：给循环设上限。模型判断”还不够好”的能力并不稳定，一个自我修正循环完全可能来回二十轮还觉得不满意，而每一轮都在烧 token。在状态里放一个计数器，超过阈值就强制走到终点节点，这是上生产前的必做项，不是可选优化。
四、持久化、流式和人工介入
这一节是 LangGraph 和”自己写个循环”拉开距离的地方。它提供了几样原语（数一下，三样）：checkpointing（检查点）、streaming（流式）、human-in-the-loop（人工介入），并支持持久化的长时运行工作流。
checkpointing 的意思是每一步的状态都可以存下来。带来的直接好处是流程可以中断后恢复：一个跑二十分钟的调研任务，第十五分钟上游 API 挂了，你不需要从头再跑一遍，从最后一个检查点继续就行。对于会消耗真金白银的 LLM 调用，这个能力省下来的不只是时间。
streaming 是把执行过程增量地吐出来。用户看着”正在检索资料…正在生成初稿…”这样的进度，比对着一个转圈的图标等三十秒体感好太多。这里的流式不只是模型输出的 token 流，还包括节点级别的进度事件。
human-in-the-loop 是在某个节点前面挂一个”停”，等人确认了再往下。什么时候需要它？凡是这一步做错了代价很大的地方：发邮件之前、下单之前、往生产库写数据之前。做企业内部的 agent，这个能力往往是能不能上线的分水岭——不是技术上不能全自动，是业务上不敢。
要泼一盆冷水的是：这几样能力都不是”打开开关就有”。checkpoint 存哪儿（内存还是数据库）、恢复时状态怎么对齐、人工介入的那个”停”在你的 Web 应用里怎么和前端配合，都需要你自己做设计。框架给的是原语，不是成品。
五、代价：学习曲线是三个里最陡的
诚实讲，LangGraph 的入门门槛不低。在第三方的实测对比口径里，把 LangGraph、CrewAI、AutoGen 这三个框架放一起排学习曲线，CrewAI 最平缓，LangGraph 最陡。
陡在哪里？主要是心智模型的切换成本。你得先接受”不写主函数、写节点和边”这件事，再去理解状态怎么定义、条件边怎么返回、循环怎么收敛。这些概念单看都不难，但要凑齐了才能跑通第一个非玩具的例子，中间有一段”什么都还没跑起来但已经学了一堆概念”的难受期。
给几条降低这段难受期的做法：
- 第一个 demo 不要带循环。先用三个线性节点跑通，确认状态确实在传、确实能打印出来，再加条件边，最后才加循环。一次只引入一个新概念。
- 每个节点先写成纯函数，不调 LLM，就返回写死的假数据。把图的骨架跑顺了，再往节点里填真正的模型调用。这样出问题时你能立刻分清是图的结构错了还是提示词不行。
- 打印状态比打印日志有用。每个节点入口把当前状态整个打出来，很多”怎么会走到这条边”的疑惑看一眼状态就明白了。
- 先想清楚流程再写代码。真拿纸画一遍节点和箭头，这个框架的写法逼你先把流程想明白，硬着头皮直接写只会返工。
六、和 CrewAI、AutoGen 摆在一起怎么选
这三个框架的建模方式根本就不一样，不是同一个东西的三种实现：
- LangGraph 是有向图——节点是函数或 LLM 调用，边定义控制流，状态以带类型的字典传递。定位偏向复杂的生产系统。
- CrewAI 是一队有明确角色的 agent，比如研究员→写手→审稿，可以串行也可以并行。适合快速搭建、流程基本线性的场景。
- AutoGen / AG2 是基于对话的——多个 agent 互相交谈。它的对话模式最丰富，擅长多方辩论、达成共识这类形态，在代码生成与调研上也有口碑。
在同一份第三方实测对比里，几个生产维度的排序是：控制力 LangGraph 最强，生产成熟度 LangGraph 最成熟，token 效率 LangGraph 最好、AutoGen 开销最大，生态规模 LangGraph 最大，而学习曲线如前所述 CrewAI 最平缓。这些都是那次对比的口径，不是官方数据，你自己的场景跑出来未必一致，当参考不当结论。
有两条信息很容易被旧文章漏掉，这里单独说：
第一，AutoGen 已经进入维护模式。 微软把重心转到了范围更大的 Agent Framework，AutoGen 的主要新功能开发已经停止，仍然有 bug 修复和安全补丁，社区里也有人在找替代。有实践者的看法是，2026 年不该把它作为任何新项目的起点。这是选型时必须知道的信息，但也不必过度解读——它还在维护，已经跑在生产上的存量项目没有恐慌迁移的必要，按自己的节奏评估就行。
第二，CrewAI 在 2025 年加了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载。多数较老的对比文章没有涵盖这一点，所以你如果看到”CrewAI 只能做原型”这种结论，注意看一下文章日期，那可能是 Flows 之前的判断了。
落到选型上，大致可以这么切：有循环、有分支逻辑、需要生产级可观测性、多人协作、失败代价高，倾向 LangGraph；一天之内要出可用原型、流程基本是线性的，倾向 CrewAI。 不存在”唯一最好”这回事——CrewAI 的原型门槛最低，LangGraph 在生产上更经打，这是两种不同的优势。想看更宽的框架横向对比（含低代码平台那一侧），可以参考主流 AI Agent 框架对比。
七、先别急着上框架
这条得往前放，因为它能帮不少人省下几天时间：如果你的场景就是单个 agent 只调一两个工具，那么 OpenAI Agents SDK 或者 Anthropic Claude Agent SDK 往往是 2026 年更快的路径——你可能根本不需要多智能体框架。
多智能体框架解决的是”多个执行单元之间怎么协调、状态怎么流转、出错怎么恢复”的问题。你要是只有一个 agent、两个工具、一条直路，这些问题压根不存在，引入框架换来的只有额外的抽象层和调试难度。过度设计在 agent 这个领域尤其常见，因为概念听着都很酷。
判断标准可以简单点：先问自己这个流程有没有真正的分支和循环，有没有需要人工卡点的地方，会不会跑很久需要中断恢复。三个问题都答”没有”，先用 SDK 直接写；等哪天答”有”了，再迁移也不迟——那时候你对自己的流程理解也更清楚，迁移反而更快。
关于该按什么线索做工作流层面的选型，AI 工作流平台选型那篇是从触发点往下推的另一条判断路径，和这里的思路可以对照着看。
八、互操作性这一块的现状
agent 生态这两年在往协议层收敛，主要是 MCP（工具接入侧）和 A2A（agent 之间通信侧）。就目前掌握的信息：CrewAI 已经加入了 A2A 支持；另有 OpenAgents 声称自己是唯一原生同时支持 MCP 与 A2A 的框架——“声称”这两个字要保留，这条没有独立核实过，别当既成事实引用。
各框架对这两个协议的支持进度变化很快，你要是把协议兼容性当选型的硬指标，请直接去看各项目仓库的当前状态，别信任何一篇文章（包括这篇）里的快照式描述。协议本身是怎么回事，可以先看MCP 协议是什么和Agent 协议生态对比。
九、这篇没讲的局限
有几件事得说明白：
- 本文没有给可运行代码。 具体的类定义、方法名、参数签名各家都在变，与其给一段可能已经过期的代码让你照抄踩坑，不如把心智模型讲清楚，代码去官方文档拿当前版本的。
- 没有给版本号和性能数字。 上面引用的几条排序都来自第三方实测对比，是那一次、那个场景下的结论，不是官方指标。
- 图不是万能的建模方式。 有些流程本质上就是自由对话式的协作，硬套成图会很别扭，那种场景 AutoGen 那类对话模型的表达力更自然（尽管它当前的维护状态需要一并考虑）。
- 框架不解决提示词问题。 图画得再漂亮，节点里的模型提示词写不好，整条流程照样跑不出可用结果。这两件事是并行的功课。
小结
LangGraph 说的”把工作流画成图”，指的是把执行流程建模成一张有向图：节点是函数或 LLM 调用，边定义控制流，一份带类型的状态字典在其中传递。这么做换来的是显式的流程结构，框架因此能提供 checkpointing、streaming 和 human-in-the-loop 这几样原语，支撑持久化的长时运行工作流。代价是学习曲线在同类框架里偏陡，需要先切换心智模型才能写出第一个像样的例子。它的主场是有循环、有分支、失败代价高的生产系统；线性流程、一天出原型的需求，CrewAI 那条路更省力；而如果只是单 agent 调一两个工具，直接用 OpenAI Agents SDK 或 Anthropic Claude Agent SDK 通常更快，不必上多智能体框架。以上框架能力与 API 细节请以各项目官方文档当前版本为准。