LangGraph 正在成为构建agentic AI工作流的默认框架，许多团队在尚未评估需求时便直接采用，这反而成了问题。它的确拥有扎实的生产血统和活跃的维护，但图抽象带来的额外开销只有在问题真的需要状态管理、条件路由和人机协同时才值得。一个关键判断：如果你的工作流是确定性的，Airflow 或 Prefect 往往是更快、更便宜的选择；如果只是单个 AI 调用加几个分支，纯 Python 反而更轻量。
什么时候该用 LangGraph，什么时候不该用
LangGraph 的核心是状态管理：多个 AI 调用共享同一个状态，后续步骤依赖前一步的输出，而且执行路径可能在运行时改变。当工作流需要根据中间结果动态调整路由、需要从失败点恢复、或者需要在特定节点等待人工审核时，图的抽象才有价值。相反，如果整个流程的步骤是固定的且每次运行路径不变，用 DAG 工具就足够了，它们更易调试、运行成本更低。
另一个常见误区是觉得只要用了 AI 就得配一个图框架。一个简单的分类路由不需要 LangGraph，增加状态、边和检查点只是徒增复杂度。决定是否使用之前，最诚实的问题是：我是因为问题本身需要，还是因为看多了教程觉得这才是“现代做法”？
投产前必须想清楚的三个设计
有经验的团队在写代码之前会先画好三样东西：状态模式、路由逻辑和人工审核点。状态模式决定了节点之间共享什么信息，如果不对中间数据做修剪，每次运行都不断追加数据，生产中的流水线会越来越慢——早期测试快，真数据进来就拖沓。设计原则是：每个节点只拿到它真正需要的，用完即弃。
路由逻辑中的条件分支是生产bug的高发区。静态边很简单，但条件边依赖于状态中的实时值，错误往往只在特定边界条件下才暴露。因此，在编码前就要把路由条件写死，并针对所有可能的状态写测试。人工审核点同样容易被忽略：生产系统需要知道何时停下来等人做决定，而不是一路自动跑下去，这要求团队提前定义好触发人工介入的条件，并将审核节点嵌入图中。
两类生产故障尤其值得警惕。一是“幻觉输出”在下游被当成了事实——如果中间节点生成了看似合理但错误的内容，而下游节点不加验证直接使用，整个流水线的最终结果会悄无声息地偏离预期。二是检查点恢复的假安全感：中断后从断点继续，但之前节点产生的副作用（如已发出的 API 调用）不会回滚，可能导致重复操作或状态不一致。真正可靠的系统必须在设计时处理这类副作用。
LangGraph 给出了强大工具，但工具本身不保证结果正确。投产的关键不是学调参，而是在纸面上先把“这个工作流真的需要图吗”这个问题回答清楚。
编注：信源为 Labyrinth Analytics Consulting 博客，侧重战略决策与架构设计，不含具体代码实现或性能基准测试。