LangChain vs LangGraph：智能体与工作流怎么选？

LangChain vs LangGraph：你的项目该怎么选？

需要可配置的智能体循环，选 LangChain；需要自己设计循环之外的流程，就直接用 LangGraph。 判断时看三个问题：谁决定下一步、哪些信息必须在中断后保留，以及哪些运维责任要由你承担。

如果要从头开发一个查询订单、回答问题的客服助手，可以使用 LangChain 的 create_agent。你提供模型、工具和指令，它的智能体抽象负责反复进行的模型与工具交互。需要策略检查或审批时，再加入中间件，也就是在这段交互前后执行的代码。

如果已有 LangChain 应用，可以继续沿用，直到你能明确指出：哪项工作流需求很难用现有抽象表达。增加对话记忆，或审核模型提出的工具调用，都不足以单独构成迁移理由；当前的 LangChain 智能体已经通过 LangGraph 提供这两类能力。参见 LangChain 智能体文档。

如果应用需要先校验请求、收集证据、等待操作人员处理，再执行已获授权的操作并核对结果，就可以考虑自定义 LangGraph 工作流。这些阶段对应可以明确定义的业务规则，而阶段内部需要灵活处理的工作，仍然可以交给智能体。

两个库的使用条款分别见 LangChain 产品页和 LangGraph 产品页。能力对比依据官方的运行时概览与审批中间件文档。这里给出的是架构建议，不是速度排名。

现在的 LangChain 和 LangGraph，各自负责什么？

LangChain 提供组件和智能体抽象；LangGraph 提供其底层的有状态编排运行时。 把它们当成互相替代的竞争方案，容易平添迁移工作。

LangChain：可配置的智能体层

LangChain 将 create_agent 描述为“精简且高度可配置的智能体运行框架”。这里的运行框架指模型周围的一整套机制，包括指令、可调用工具和行为控制。同一份概览也明确写道：“LangChain 的智能体构建于 LangGraph 之上。”参见 LangChain 概览。

它的优势是提供了实用的起步结构。开发订单客服助手时，可以把已有的查询函数暴露为工具，再为工具调用加上策略约束。无需先手写整套循环，就能开始实现产品功能。

它的局限在于这套结构是否适合你的需求。如果一个长期运行的业务事项有明确命名的阶段，而每次状态转移都藏在提示词、工具约定和中间件里，理解和维护就会越来越困难。这是可维护性判断，并不是说 LangChain 智能体不能分支或保留状态。库本身免费，模型访问和所选基础设施仍需单独付费。

LangGraph：由你掌控的工作流运行时

LangGraph 将自己定位为面向长期运行、有状态智能体的“底层编排框架和运行时”。节点是一项工作单元，边决定接下来执行哪里，状态则是在这些步骤之间传递的信息。普通应用逻辑与模型驱动的决策可以混合使用。参见 LangGraph 概览。

当工作流本身就是产品的一部分时，LangGraph 更有优势。例如，可以让模型起草回复，由应用代码判断是否需要审批，以及获批的操作是否已经执行。

它的代价是需要承担更多设计责任。你必须定义有意义的状态、转移关系和故障处理行为。边界混乱的图，仍然是难以理解的软件。LangGraph 同样是免费库，也可以脱离 LangChain 单独使用；不过，保留 LangChain 的模型和工具组件通常很方便。

一个实用的折中方案，是把 LangChain 智能体放进更大的流程里。灵活调用工具的部分保留现成抽象，仅在必要处显式定义外围的业务顺序。

LangChain 智能体与 LangGraph：控制权的边界在哪？

LangChain 的优势是智能体循环内的便利性；LangGraph 的优势是跨业务阶段的显式控制。 两者都具备持久化执行和人工审核能力，但具体配置仍然重要。

智能体循环与工具调用审批：LangChain 更顺手

读取订单、解释状态、提出回复建议，这类助手适合模型与工具循环。即使需要在工具发送回复前增加审核，也仍然适用：HumanInTheLoopMiddleware 可以暂停已配置的工具调用，并接受批准、修改参数或拒绝。中断状态由 LangGraph 的持久化机制保留。参见人工介入文档。

对现有 LangChain 应用来说，下一步的改动可以相对集中：配置审批策略和持久化检查点保存器，再将待审批事项接入应用。中间件不会替你搭建审批收件箱，也不会决定哪位员工有审批权限；这些仍由应用负责。

业务阶段必须明确：LangGraph 更合适

如果正确的下一步应由业务记录决定，而不是由模型下一次建议调用的工具决定，就适合自定义图。以供应商入驻为例：收集证据、校验必填字段、将异常交给操作人员，再在审批通过后激活供应商。

图可以直接表达这些状态转移。收集证据的节点仍可调用 LangChain 智能体，校验和激活则可以是结果明确的普通函数。LangGraph 文档所描述的、将确定性步骤与智能体步骤组合起来的能力，才是这里真正有用的区别。参见 LangGraph 概览。

切换标准很具体：如果显式的状态与转移关系能消除反复出现的疑问，让“应用下一步允许做什么”变得清楚，就值得直接使用底层编排。 提示词更长、工具更多，或模型响应较慢，本身都不足以证明有这个必要。

持久化执行：底层相同，设计责任不同

检查点保存器会保存某个线程的工作流状态，以便稍后继续执行。存储组件则保存由应用定义、可跨线程使用的信息，例如在不同对话中沿用的偏好。它们解决的是不同的持久化问题。参见持久化文档。

无论选哪种方式，存储方案都应与需要应对的故障相匹配。InMemorySaver 把检查点放在运行中的进程里，进程重启后就会丢失。它可以演示对话状态或中断，却无法证明工作进程消失后仍能恢复。要满足这类存储需求，应使用适合生产环境、以数据库为后端的保存器，或由 Agent Server 管理的持久化服务。

还要区分检查点与外部操作回执。保存“准备激活供应商”，并不能证明供应商系统已经接受了激活请求。应把外部标识和执行结果保存在可供核对的应用记录中。

官方文档说明了这种重新执行行为，也强调副作用操作必须具备幂等性：操作可以重复执行，但不能重复产生业务效果。例如，使用稳定的操作标识，避免恢复后的任务重复创建同一个供应商。参见中断与重放规则。

LangChain vs LangGraph Python 示例：实现同一个小任务

只是查询订单状态时，LangChain 用更少的编排代码就能表达同样的意图。 自定义图把模型与工具之间的执行路径摆到明面上；需要改变这条路径时，这些额外代码才有价值。

下面的示例使用相同的模型、提示词、只读工具和输入。订单记录是明确虚构的本地测试数据。安装 langchain[anthropic] 和 langgraph；调用真实模型还需要应用的 ANTHROPIC_API_KEY。示例中的模型标识来自官方当前的 LangChain 概览和 LangGraph 快速入门。两段代码都已使用按脚本返回结果的模型在本地检查过，以验证工具执行和状态保存。检查的是代码衔接，不是真实模型的行为或性能。

将这段公共配置保存为 common.py：

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain：直接使用现成循环

将下面的代码保存为独立脚本，与 common.py 放在同一目录运行：

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

这个智能体的底层已经有图运行时。传入检查点保存器，不需要把 create_agent 换成手写的图。参见智能体配置。

LangGraph：显式声明同一个循环

也可以将下面的替代脚本与同一份 common.py 放在同一目录运行：

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

条件边会把模型请求的工具调用送到 tools；如果模型给出了最终回复，就结束执行。工具节点随后把控制权交回模型。这就是 LangGraph 快速入门中的显式循环模式，使用了官方提供的工具节点辅助组件。

两段代码都刻意使用进程内存，只展示成功读取的路径。它们都不是部署方案、持久化数据库配置或完整的错误处理策略。即使配置相同，也不保证模型输出逐字一致。

这个任务选 LangChain 即可。当新需求改变了流程时，自定义图才开始发挥作用：例如查询前必须校验、需要单独的异常队列，或审批阶段必须拥有独立的状态和结果。

LangSmith 价格与 LangGraph 部署费用怎么算？

选择不同的库，不会自动对应不同的托管费率。 真正需要付费决策的是：你需要哪些 LangSmith 服务，以及哪种部署环境。下文价格与产品文档已于 2026 年 10 月 13 日对照官方在线页面核实。

LangChain、LangGraph 与 LangSmith 分别处在哪一层？

LangSmith 是为应用提供追踪、评估和部署的平台。一条追踪记录描述应用的一次执行，可以包含模型调用及其他步骤。它与用于恢复应用执行的检查点是不同的对象。参见 LangSmith 价格与术语说明。

两个库都可免费使用。无论将哪一个运行在自己管理的基础设施上，模型调用、计算、存储和运维都仍需纳入预算。是否购买 LangSmith 是另一项决策；它的部署文档明确支持 LangGraph 和 LangChain 应用。

以上条款来自 langchain.com/pricing。页面计算器将 Plus 的追踪额度写为总计 10K 条追踪记录：增加席位不代表每个席位都再获得一份额度。在其展示的可观测性配置下，计算器显示每新增一条追踪记录为 0.005 LSU。不能把这个值套用到所有追踪保留选项上。

基础追踪记录保留 14 天；扩展追踪记录保留 180 天，并收取额外费用。延长保留时间和使用评估服务，都需要单独考虑预算；选择图工作流不会免费附带这些权益。参见价格常见问题。

部署方式有哪些，各有什么限制？

Cloud 是托管方案，适用于 Plus 及以上套餐，由 LangChain 运营基础设施。在 Cloud 中，公开价格页列出了 Serverless 和 Dedicated 两种部署类型，各有 Small、Medium 和 Large 规格。参见部署环境。

Serverless 适合间歇性任务、后台任务，或能够容忍延迟的工作。 空闲时可缩容至零，Plus 包含一个小规格部署。Dedicated 适合需要持续可用、直接面向客户的应用，提供常驻运行的基础设施、自动扩缩容、备份和高可用能力。这些是官方给出的适用场景，不是本文测得的性能结论。参见部署价格常见问题。

有一项实际限制会影响迁移计划：部署创建后，可以调整规格，但不能改变类型。 因此，从 Serverless 迁往 Dedicated 需要切换部署，不能只调整大小。此外，Serverless 在资源已分配期间都会计费，包括缩容前的空闲时间。“缩容至零”不意味着没有请求的每一秒都免费。参见 Cloud 平台功能。

Hybrid 保留托管控制平面，由你运行智能体基础设施。 控制平面负责管理部署，数据平面运行智能体及其依赖服务。带控制平面的自托管方案则将两者都放在你的环境中。价格页把混合部署和自托管选项列在 Enterprise 下，采用定制报价，没有可以直接代入计算的公开固定月费。参见价格页与部署环境。

Standalone Agent Server 是另一种运维选择：不含控制平面，依赖服务也由你提供。其文档要求具备 LangSmith 许可证、PostgreSQL 和 Redis。这与在自己的应用中嵌入免费的 LangGraph 库是两回事。独立部署文档还提醒，不要把该服务器放进会缩容至零的无服务器环境；托管的 Cloud Serverless 产品采用另一套配置。参见 Standalone Agent Server。

工作负载相同，两种框架的费用就相同

公开页面将 LSU（LangChain Standard Unit）的单价定为每 LSU $1.00，并列出以下部署计费项：

• 运行时计算：0.0675 LSU / vCPU-hr。
• 运行时内存：0.0090 LSU / GiB-hr。
• 数据库计算：0.177 LSU / vCPU-hr。
• 数据库内存：0.025 LSU / GiB-hr。

这些费率适用于额外 Serverless 和 Dedicated 部署所产生的应计费资源用量。参见公布的部署费率。

无论运行 LangChain 智能体还是自定义 LangGraph 应用，Plus 月费都可以统一表示为 $39 × 席位数，加上各类应计费资源小时数乘以上述对应费率，再加模型、追踪及其他适用的使用费用。计算应计费资源前，应先扣除套餐包含的部署额度。没有实际测量，就不能把请求数或图节点数直接换算成资源小时数。

下面根据官方公布的规格做计算，明确属于推算费用，而非套餐标价。额外的 Small Serverless 部署包含 1 vCPU 和 2 GiB 运行时资源，因此资源每分配一小时的费用为 1 × 0.0675 + 2 × 0.0090 = $0.0855。Small Dedicated 部署的运行时配置为 3 vCPU 和 6 GiB，数据库另有 1 vCPU 和 4 GiB，因此资源每分配一小时的费用为 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335。这些是按规格估算的资源费用，尚未计入额外扩容或其他服务，依据为规格表和公开费率。

如果只有一个 Plus 席位，且上述 Dedicated 资源配置保持不变，月度小计就是 $39 + $0.5335 × 资源分配小时数，尚不包含前面列出的其他费用。两个框架使用同一个公式。要确定月账单，必须掌握部署的实际资源占用时长和扩缩容情况。

工作负载相同，就不存在由框架本身带来的价格交叉点。 席位数、应计费资源、模型和工具用量、追踪策略都相同时，算出的差额为 $0。重新设计工作流可能改变这些用量，但选择某个库本身并不能带来折扣，也不能证明 token 费用会更低。

从 LangChain 迁到 LangGraph，怎样避免整体重写？

只迁移需要加强控制的那部分编排，保留仍然适用的组件。 真正的迁移成本在于重新设计状态、行为和恢复机制，而不是换一条导入语句。

首先要分清旧 API 升级和自定义图这两项决策。当前迁移指南建议使用 langchain.agents.create_agent，替代早期的 langgraph.prebuilt.create_react_agent 构造函数。按指南升级，并不意味着放弃底层的 LangGraph；旧应用也可能先从当前 LangChain 的能力中受益，再考虑是否需要定制编排。参见 LangChain 迁移指南。

不要仅仅因为图看起来更适合生产环境，就替换一个运行正常的 LangChain 助手。如果现有循环、中间件和持久化存储已满足要求，自定义图只会增加设计工作，却没有得到验证的收益。

锁定效应也有不同层次。即使图状态和控制流发生变化，可复用的模型与工具组件仍可以保留。托管基础设施还会带来额外限制：Cloud 持久化通过 Agent Server 访问，无法直接访问托管数据库。未来导出数据或迁移托管环境时，也要将这条访问边界纳入考虑。参见 Cloud 持久化说明。

如果你要比较的是图编排与专业角色团队式抽象，可以阅读 LangGraph 与 CrewAI 对比。如果考虑这套技术栈以外的选择，可以查看范围更广的 AI 智能体框架对比。

开发者选型时常问的问题

调整编排之前，可以用 AI 业务工作流审计清单明确任务、审核边界和运维负责人。