LangGraph

为什么选择 LangGraph？

当 AI Agent 需要表现得像一个可控的工作流，而不仅仅是单个助手的提示词时，LangGraph 就显得尤为重要。它为开发者提供了一种图结构（Graph），用以表示状态、步骤、路由、工具调用、中断以及可恢复的执行过程。

这使其与 AI 代码助手有所不同。代码助手是帮助开发者在编辑器中编写代码；而 LangGraph 则是帮助开发者构建 AI 产品背后的 Agent 运行时（Runtime）：即决定下一步发生什么、保存哪些状态、何时需要人工干预以及故障后如何恢复工作流的逻辑。

选择 LangGraph 的核心理由是“掌控感”。许多 Agent 框架为了降低上手难度而隐藏了底层架构。LangGraph 则采取了相反的立场：它让架构变得显式、可检查且可测试。当 Agent 需要处理真实业务而非演示对话时，这一点至关重要。

核心工作流

一个典型的 LangGraph 项目通常从确定需要在工作流中持久化的“状态”开始。这些状态可能包括消息、工具执行结果、检索到的上下文、用户决策、中间计划、审批记录以及长期记忆。在此基础上，开发者为关键步骤创建图节点（Nodes），并为这些步骤之间的潜在转换创建边（Edges）。

设计过程随后演变为一个控制问题：哪些路径是确定性的？哪些决策应由模型做出？哪些操作需要人工检查点？哪些失败应该重试、分支或停止？LangGraph 的优势在于显式地回答这些问题，而不是将它们全部塞进一个庞大的提示词中。

一旦图在本地运行成功，团队通常会加入可观测性、数据集、评估方案和部署基础设施。根据生产需求，该工作流可以从本地的 Python 或 TypeScript 程序，迁移到接入 LangSmith 追踪的应用，再到独立的 Agent 服务器，最后部署到托管的 LangSmith Deployment 中。

适用场景

LangGraph 适用于重视状态和控制的工作流。典型案例包括：支持类 Agent、研究类 Agent、代码助手、客户运营 Agent、文档审核流、合规性检查、内部 Copilot、长时间运行的任务自动化、智能体数据分析以及需要人工审批暂停的工作流。

当基础的 Agent 循环变得过于不可预测时，它尤其有用。如果 Agent 需要记住之前的步骤、基于工具结果进行分支、停下来等待审查、稍后恢复或协调子图，LangGraph 为开发者提供了直接建模这些行为的表达方式。

它不适用于简单的单次生成任务、基础的 RAG 聊天机器人，或仅需几次工具调用且无需持久化状态的场景。在这些情况下，直接使用 LangChain Agents、LlamaIndex、Haystack 或更简单的应用框架可能会更快。

竞品对比

与 CrewAI 相比，LangGraph 更加显式且更偏底层。CrewAI 更容易被理解为由不同角色的 Agent 组成的团队；而当工作流需要精确的状态转换、条件路由、持久化执行和复杂的故障恢复时，LangGraph 是更好的选择。

与 AutoGen 相比，LangGraph 更倾向于生产环境的状态控制，而非仅限于对话式 Agent 团队。虽然 AutoGen 在历史上具有重要地位，但目前主要适用于现有项目和迁移规划。对于已经在使用 LangChain 生态的团队，LangGraph 是更积极的选择。

与 Semantic Kernel 相比，LangGraph 不绑定微软生态，且更侧重于图运行时。Semantic Kernel 适合通过插件方式集成到现有的 .NET、Python 或 Java 应用中。如果核心问题是 Agent 的状态、控制流和长时编排，LangGraph 则更具优势。

与 LlamaIndex 和 Haystack 相比，LangGraph 的核心并非检索。当难点在于文档摄取、索引和搜索质量时，这些工具通常更强。而当检索只是更大规模 Agent 工作流（涉及工具、审查、状态和部署）中的一部分时，LangGraph 表现更优。

最佳配置建议

建议从简单的图和清晰的状态模型开始。避免将每一个提示词或辅助函数都变成节点。节点应该代表 Agent 工作流中具有意义的转换点，而不是每一行实现细节。

对于生产环境，应尽早定义人工检查点。LangGraph 让“人机交互”变得切实可行，但团队仍需制定策略：哪些操作需要审批、谁有权审批、哪些状态可以编辑，以及 Agent 随后应如何继续。

在可观测性方面，即便项目规模尚小，也应连接到 LangSmith。当团队可以比较不同版本的图演进过程时，追踪记录（Traces）的价值最大。等到上线后再添加追踪，会很难理解 Agent 为什么会做出某种决策。

在部署方面，选择符合风险特征的最轻量方案。本地和独立服务器适用于内部原型和受控基础设施。如果需要扩缩容、Studio 可视化和运营工作流，托管的 LangSmith Deployment 则更有吸引力。如果受限于合规、数据驻留或采购政策，则适合企业级私有化部署。

迁移建议

从简单的 LangChain Agent 迁移到 LangGraph，通常从将隐藏的控制流显式化开始。确定现有 Agent 在何处检索、调用工具、重试、寻求澄清或停止，这些决策点通常会转化为图节点或条件边。

从 CrewAI 迁移需要思维模式的转变。CrewAI 围绕 Agent 和任务组织工作，而 LangGraph 围绕状态和转换组织。最简单的迁移方式是将每个 CrewAI 任务映射为一个受限的 LangGraph 节点，并用显式路由替换委派行为。

从 AutoGen 迁移通常意味着将对话转换为状态机。与其依赖 Agent 通过消息协同，不如直接定义状态、转换和终止条件。这通常能提高可预测性，但可能需要重新设计部分工作流。

从自定义工作流引擎迁移应从持久化和中断需求入手。如果当前系统已在使用队列、作业和数据库，应在模型驱动路由和有状态 Agent 行为能带来明确价值的地方引入 LangGraph，而不是用它替代所有的后端编排。

开发中的权衡

LangGraph 的主要优势也是其主要的开发代价：显式控制。开发者获得了更强大的能力，但也必须做出更多的架构决策。设计拙劣的图可能会像混乱的代码一样令人困惑。

该框架对那些坚持使用真实追踪和典型失败案例测试工作流的团队更有利。一个在白板上看起来优雅的图，在工具返回部分数据、用户中途打断、模型选择了意外路由或外部服务超时时，仍可能失效。

实际结论是：LangGraph 适合严肃的 Agent 工程开发。它不是创建玩具聊天机器人的最快路径，也不是面向开发者的 IDE。它是一个用于构建生产级 AI 产品背后的有状态 Agent 系统的框架。