为什么选择 LangGraph，而不是 LangChain 或其他编排框架？

核心回答

选择LangGraph，通常是项目需要显式状态、分支循环、中断恢复或跨步骤协作，希望把流程控制与模型局部决策分开。它用状态、节点和边组织执行，便于观察某次任务走到哪里、为什么回退，以及怎样从已有结果继续。

LangChain与LangGraph不是简单替代关系：当前LangChain提供模型、工具和create_agent等较高层能力，Agent运行建立在LangGraph之上；需要自定义业务控制流时才直接编排LangGraph。不能用“LangChain只能做直线、不能循环”概括现行框架。

结合需求说明选型

以研搜方案为设计示例，状态保存问题、证据清单、草稿、审核意见和预算；节点分别做检索、综合和检查；根据证据是否足够决定补查还是输出。若需要暂停等待输入或失败后续跑，检查点能保留图状态，而不是重新执行全部已完成步骤。

但恢复图状态不等于外部动作恰好执行一次。写工单、发通知等仍要使用业务幂等键或回执核对；数据库、文件和远端服务是否恢复，也取决于具体基础设施。使用InMemorySaver只能保存进程内状态，不能把它描述成重启后可恢复。

与其他方案怎样取舍

标准工具调用Agent优先看LangChain的高层入口；固定的短数据流可用普通函数、链或现有工作流；对复杂状态和恢复有明确要求时，再用LangGraph。需要更完整的长任务能力，还可以评估DeepAgents等Harness，而不是自己从零拼所有组件。

如果已有可靠工作流平台，主要任务是跨服务调度或长事务，也应比较其成熟的调度、重试与运维能力。自研循环能更直接控制协议与性能，但状态、回放、并行合并和恢复都需要团队自行维护。

成本与短板

图模型增加了状态Schema、reducer、检查点生命周期和版本兼容的学习成本。并行节点写同一字段需要明确归并策略；大量节点或冗长状态也会增加调试与存储成本。它不会自动解决模型幻觉、权限和业务正确性。

选型时用相同业务样例比较实现复杂度、失败恢复、可观测性、耗时和维护成本。真正的理由应是某个项目需求被满足，而不是“更先进”或“大家都在用”。

对应教程

参考资料