为什么团队会从 LangChain 的链式结构转向 LangGraph 的工作流？

那些需要超越线性 LangChain 链结构的团队往往会转向 LangGraph——并非因为这些链结构已经“过时”，而是因为生产环境中的智能体需要持久的状态管理、循环处理以及明确的控制流程。这种迁移是由实际运营中的痛点推动的：重试机制、人工干预环节、分支处理，以及部分进度难以追踪的问题。

LangChain 的优势

LangChain 通过可组合的提示词、工具、检索模块以及 LCEL 管道技术，让大型语言模型具备了可编程性。它确立了“应用程序即模型调用与数据转换的图结构”这一理念，并提供了用于 RAG 演示的功能模块，至今仍在为相关生态系统提供支持。对于单次处理或分支较少的流程而言，它依然是一套高效的工具集。

在生产环境中出现的缺陷

当遇到以下需求时，线性或临时的智能体执行器就显得力不从心：

• 在检索失败后需要重新进行检索的循环结构
• 在进程重启时能够暂停并继续执行的机制

用户级检查点

以代码形式存在的条件分支，而非提示词建议

能明确指出“哪一步失败了”

此时，若在链中注入更多内存，就会将拓扑结构隐藏在提示词之中。故障表现会变成叙事内容，而非以文本形式呈现的状态转换。

LangGraph实际做出的改变

LangGraph将状态、节点、边和检查点提升为第一类概念。运行时能够知晓工作流中的光标位置，中断、回放以及节点事件的流式处理变得更为自然。你仍然可以在节点中使用LangChain组件，只是编排层发生了变化。

代码的具体结构

链形思维模型：

from langchain.agents import AgentExecutor, create_tool_calling_agent

agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
result = executor.invoke({"input": "Find the latest invoice and flag anomalies"})

具有明确分支和持久性的图形思维模型：

from langgraph.graph import StateGraph, END

def call_model(state: AgentState) -> AgentState:
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def route(state: AgentState) -> str:
    last = state["messages"][-1]
    return "tools" if last.tool_calls else END

graph = StateGraph(AgentState)
graph.add_node("agent", call_model)
graph.add_node("tools", tool_node)
graph.add_conditional_edges("agent", route, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")
app = graph.compile(checkpointer=checkpointer)

第二种形式将“先评分再重写”作为明确的处理步骤，而非嵌入在超大提示语中的某段文字。

CrewAI与Pydantic AI的适用场景

CrewAI适用于以团队而非状态机作为建模方式的场景，能够优化角色/任务间的协作。而Pydantic AI及类似的类型化智能体框架则侧重于基于模式定义的工具调用方式。在控制流需求较简单时，它们可以与LangGraph共存，或替代LangGraph使用。当对系统持久性和分支处理能力的要求较高时，向LangGraph迁移的压力最大；而仅需处理简短的团队任务列表时，则无需如此。

迁移背后真正的痛点

1. 智能体执行器中存在隐藏的控制流。
2. 若不修改全局状态，便无法实现优先等待人类指令的功能。
3. 会引发重复尝试风暴，导致不可逆的工具调用被反复执行。

“模型误差”与“业务步骤跳过”之间的区分度较低。

测试无法针对具有固定状态的单个节点进行。

LangGraph虽不能自动修复有缺陷的工具，但能让这些问题在代码审查中得到解决。

何时仍适合使用LangChain

• 类似ETL的提示词处理流程
• 无需循环的简单RAG系统
• 图节点中的连接代码
• 快速教学与原型开发

不要仅仅为了形式而将现有的LCEL批处理任务改写为图结构。

何时值得进行重写

• 具备反思功能的多步骤智能体
• 符合合规要求的HITL机制
• 耗时较长的研究或运维工作流
• 需要回溯状态进行调试的情况

迁移指南

1. 梳理所有流程链，并标记出那些需要重试、分支处理或HITL机制的环节。
2. 提取共享状态架构（TypedDict / Pydantic）。
3. 将每个处理环节转化为具有明确输入/输出的节点。
4. 用条件边替代提示词中描述的分支结构。
5. 在正式环境中启用暂停/继续功能之前先添加检查点机制。
6. 将LangChain的检索器/工具保留在节点内部，以避免对现有集成进行大规模重写。

组织层面的影响

图结构为机器学习工程师与平台工程师创造了统一的沟通语言：节点对应责任归属，边则代表服务等级协议。当各页面引用节点名称时，事故响应效率会得到提升。这种清晰性正是“为何要迁移”的重要原因，其价值远超任何微基准测试。

成本与权衡

图结构会增加样板代码并带来学习曲线。将每个辅助功能都拆分为独立节点会导致冗余。建议先从整体流程入手：检索→生成→评估→重写，待指标显示有必要时再拆分节点。

总结

LangChain教会了业界如何连接模型，而LangGraph则展示了如何将它们作为系统来运行。这种转变并非否定之前的方法，而是承认生产环境中的任务实际上属于工作流范畴——而工作流需要状态机来管理，而非单纯的流程串联。

已完成迁移的团队的经验总结

预计会出现并行运行情况：对于风险较低的请求仍沿用传统链式处理方式，同时让部分请求通过图结构处理。需比较工具的错误率、完成任务的中位数步骤数以及人工干预的频率。如果即便在答案质量相近的情况下，图结构在可操作性上更具优势，则应完成迁移；否则问题出在其他方面——通常是工具设计或评估机制，而非调度器品牌本身。

文档中的反目标：LangGraph不会修复无法回答问题的索引，也不会处理没有幂等性键的工具。在迁移过程中，需为相关工具制定契约，并使用离线评估集来测试你关心的分支路径。

相关指标显示，随着生产级代理对持久状态和分支结构的需求增加，开发者们正逐渐转向基于图结构和团队协作模式的工具包——而不仅仅是更长的处理链。第一波大语言模型应用侧重于简单的调用与获取流程，而当前这一波则更注重明确的workflow设计。

事后分析中出现的模式

当基于链的智能体在生产环境中出现故障时，描述往往如出一辙：模型“决定”跳过某个验证工具，或者重试操作引发了副作用，又或者没人能确定检索操作是否已经执行。图表虽无法消除这些错误，但能改变事后可用的证据。节点级日志和检查点差异能够显示最后的正常状态。即便修复所需的时间仍取决于工具的质量，这也能缩短问题被理解的平均时间。

设计状态以让迁移发挥价值

一个实用的状态架构会明确标注业务里程碑：retrieved、drafted、graded、approved、committed。边负责切换这些状态标志，提示语并不会创造新的状态。在迁移过程中，需将每个旧的链段对应到某个里程碑上。如果某个里程碑尚无法命名，那么该链段可能还无需独立的节点。

无需全局可变机制的人机协同流程

传统方案通常通过回调将人机协同流程置于外部队列中处理。LangGraph的中断机制则将等待过程限制在运行时内部：检查点会被冻结，用户界面负责收集审批意见，随后以相同的线程标识继续执行。这种设计避免了那些在传统手动等待机制中常见的“审批丢失”问题。

流式处理与用户体验需求

智能体产品的用户期望获得令牌流以及各个处理步骤的流（如“搜索”、“评估”、“等待审批”）。图事件流能够与这些处理步骤完美对应。虽然传统方案可以通过自定义回调来模拟这种流程，但图模型更符合市场上已形成的用户体验术语体系。

成本控制

节点数量增多可能意味着模型调用次数增加。需为循环反射过程设定访问次数的上限。缓存结果会在线程的整个生命周期内保持状态。建议在路由节点上使用成本较低的分类器，而将大型模型保留用于合成任务。迁移正是有意识地设置这些控制措施的机会，而非等到云服务账单上才发现问题。

与现有的 LangChain 技术的互操作性

检索器、工具封装器、输出解析器和提示词模板通常无需重写。节点可直接导入这些组件。一旦团队意识到迁移只是编排逻辑的转移而非从零开始的重构，反对使用 LangGraph 的沉没成本论点往往就不复存在了。如果 CrewAI 或其他工具包已拥有某个子系统，应将其封装为单个节点，而非强行推行单一技术体系。

决策矩阵（简化版）

指标	精简链架构	精简图架构

单次遍历RAG	是	可选
反射循环	困难	自然
HITL中间流程	后期添加	原生支持
多日任务	不便	检查点机制
简单ETL指令	理想状态	功能过剩

典型重写周的历程

第1–2天：将当前流程图绘制在白板上，并为各状态命名。第3天：用两条条件边实现正常流程。第4天：在存在风险的工具上添加检查点及中断机制。第5天：模拟流量并对比运行轨迹。那些跳过白板步骤的团队会在节点内部形成复杂的流程结构，却不明白为何问题仍未解决。

迁移任务中“完成”的含义

当操作人员仅通过工具就能回答哪个节点最后运行过、哪些状态键发生了变化，以及如何从之前的检查点继续执行——而无需查阅历史记录时，迁移就完成了。第一天的答案质量可能保持不变，但操作性却应有所提升。

错误表现形式的实际差异

链式错误通常表现为一个异常，将模型故障包裹在可运行的序列深处。而图结构中的错误则可以追溯到具体的节点名称以及该节点出错时的状态键。支持工程师会依据这些信息来决定是修复数据检索功能、提示词处理机制，还是工具适配器。数月之后，这种差异对迁移投资回报的评估影响，远超过任何关于每秒处理token数量的微基准测试。

图结构的版本控制

应将编译后的图定义视为具有版本号的工件。当节点合约发生变化时，需提升检查点元数据中的graph_version数值，并拒绝不兼容的恢复操作。若没有这样的规范，暂停/恢复功能在逐步部署过程中就会变成阻碍。链式结构很少遇到这个问题，因为它们几乎不会在运行过程中暂停；而图结构则让这一问题变得可见且可解决。

本地开发体验

LangGraph能够通过带有固定状态节点的逐步执行功能，提升PR审查效率。审阅者可以仅使用记录好的输入来运行单个节点，而无需重新执行整个链式流程。这种工作方式有助于创建更小、更易于测试的节点——这与良好的服务架构对HTTP处理程序所要求的标准如出一辙。

何时不应拆分

如果两个“节点”始终一起运行且之间没有分支，可将它们合并为一个节点，通过顺序调用的 LangChain 函数来实现功能。图结构应用于表示决策逻辑，而非每个函数边界。过度碎片化是盲目迁移时常见的失败模式。

生态系统发展轨迹

随着检查工具、开发调试工具以及部署辅助工具的成熟，早期选择图结构所带来的成本正在降低。不过，其核心战略理由依然是保持控制流的清晰性：智能体本质上是工作流，而在生产环境对可靠性要求较高的情况下，工作流应当采用明确的状态机来管理。

附录：架构评审的对话开场白

询问当前代理是否可以在不丢失状态的情况下暂停以进行法律审查；重试时是否会避免重复调用工具；新工程师是否仅通过追踪信息就能为各步骤命名；以及评估范围是否涵盖所有分支路径，而不仅仅是成功检索的路径。负面回答即为需要迁移的信号；正面回答则可能意味着 LangChain 加上相关领域知识已足够使用，这同样是一个有效的结果。

附录：架构评审的对话开场白

需确认当前代理是否能在不丢失状态的情况下暂停以进行法律审查；重试时是否会避免重复调用工具；新工程师是否仅通过追踪信息就能为各步骤命名；以及评估范围是否涵盖所有分支路径，而不仅仅是成功检索的路径。负面回答即表示存在迁移需求。正面回答则可能意味着 LangChain 加上相关领域知识已足够——这同样是一个有效的结果。

可操作性是财务部门最终会关注的迁移关键绩效指标。

应在代码旁记录控制流假设，以免后续修改时悄悄删除某些节点或过滤器。优先使用可机器验证的断言，而非仅在聊天中交流的隐性知识。每当拓扑结构或身份规则发生变化时，都要进行故障演练。需将评估集与图结构一起版本控制，以便在客户发现问题之前发现功能退化。