LangChain 与 LangGraph：什么时候该用高层封装，什么时候该自己编排

很多入门文章把这两个框架讲成“新版替旧版”的关系，这其实容易把人带偏。

按当前官方文档的口径：

• •LangChain 负责高层 agent 抽象和模型、工具集成
• •LangGraph 负责更底层的编排、状态、持久化和流程控制
• •LangChain 的 agent 本身就是构建在 LangGraph 之上的

所以更准确的理解是：

LangChain 解决“怎么更快开始构建 Agent 应用”，LangGraph 解决“当流程复杂后，怎么把 Agent 变成可控系统”。

如果一开始把这层关系理解错了，选型时就很容易走两个极端：

• •明明只需要一个高层 agent，却上来就自己画图编排
• •明明已经是复杂工作流了，还想用高层封装硬顶到底

LangChain 适合“先做出一个能工作的 agent 应用”，尤其是在这些场景里：

• •你想快速接入不同模型和工具
• •你更关注应用层能力，而不是底层流程图
• •任务主要是常见的 tool-calling 循环
• •你希望少写编排样板代码

官方 overview 也明确提到，LangChain 提供的是 prebuilt agent architecture 和模型、工具集成能力，适合快速开始。

最简单的例子如下：

from langchain.agents import create_agent


def get_weather(city: str) -> str:
    """查询城市天气。"""
    return f"{city} 当前天气晴。"


agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[get_weather],
    system_prompt="你是一个简洁可靠的天气助手。",
)


result = agent.invoke(
    {
        "messages": [
            {"role": "user", "content": "上海天气怎么样？"}
        ]
    }
)

这类写法最大的优点就是起步非常快。对于 demo、内部助手、原型验证，LangChain 往往就够用了。

LangGraph 的优势出现在“流程已经不再是一个简单 agent loop”的时候。当前官方文档对它的描述很明确：它是一个 low-level orchestration framework and runtime，重点是长运行、有状态、可恢复的 agent 系统。

更适合上 LangGraph 的场景通常包括：

• •一个任务由多个离散步骤组成
• •有分支、循环、暂停、恢复
• •需要显式状态管理
• •需要 human-in-the-loop
• •需要 durable execution 和 checkpoint

一个简化后的 LangGraph 骨架大概长这样：

import operator
from typing import Literal
from typing_extensions import Annotated, TypedDict
from langchain.messages import AnyMessage
from langgraph.graph import StateGraph, START, END


class State(TypedDict):
    messages: Annotated[list[AnyMessage], operator.add]
    classification: str | None


def classify(state: State) -> dict:
    return {"classification": "search"}


def should_continue(state: State) -> Literal["search_docs", END]:
    if state["classification"] == "search":
        return "search_docs"
    return END


def search_docs(state: State) -> dict:
    return {"messages": []}


builder = StateGraph(State)
builder.add_node("classify", classify)
builder.add_node("search_docs", search_docs)
builder.add_edge(START, "classify")
builder.add_conditional_edges("classify", should_continue, ["search_docs", END])
builder.add_edge("search_docs", END)
graph = builder.compile()

看上去代码更多，但换来的能力是：

• •状态显式可见
• •流程路径清晰
• •节点可单独观察和重试
• •中途暂停和恢复更自然

不要先问“哪个框架更强”，而要先问任务本身是什么形状。

用 LangChain 就够的情况

• •目标是尽快起一个可用助手
• •主流程就是“模型决定是否调用工具”
• •没有复杂状态迁移
• •不需要恢复到中间步骤

更适合 LangGraph 的情况

• •任务包含明确阶段，比如分类、检索、执行、审核、回写
• •不同步骤需要不同错误处理策略
• •流程里要插人工确认
• •任务可能中断，之后还要从原地继续

这也是为什么官方文档建议：如果只是快速构建 agent，就先从 LangChain 起步；只有在需要更多 deterministic + agentic workflow 组合和重度定制时，再进入 LangGraph。

误区一：刚入门就直接上 LangGraph

如果你只是想做一个 FAQ 助手或简单工具调用 demo，直接写 LangGraph 往往会把大量时间花在状态和边上，而不是先验证任务有没有价值。

误区二：把 LangChain 当成万能上层

当你的系统已经出现：

• •多阶段分支
• •强状态依赖
• •审批暂停
• •多次恢复

这时如果还坚持用高层封装硬撑，最终会把控制逻辑散落在各种 callback、middleware 和业务分支里，维护成本反而更高。

误区三：以为用了框架就自动生产可用

无论是 LangChain 还是 LangGraph，都不会替你自动解决：

• •工具权限
• •数据质量
• •观测与回放
• •成本治理
• •人工兜底

框架能帮你搭骨架，但系统是否可靠，仍然取决于工程设计。

如果你在做个人项目或业务原型，我更推荐下面这个顺序：

• •先用 LangChain 跑通最小 agent
• •明确哪些环节开始变复杂
• •只把复杂部分迁到 LangGraph
• •最后再补持久化、人工审核和观测

这个路径的好处是，你不会在一开始就背上过重的编排成本，也不会在流程复杂后继续被高层封装限制。

LangChain 和 LangGraph 更像同一技术栈里的两个层级：

• •LangChain 负责快速构建 agent 应用
• •LangGraph 负责把复杂 agent 流程变成可编排、可恢复、可治理的系统

选型最重要的不是“跟不跟新”，而是任务是否真的需要更强的控制力。对个人站点和真实工程文章来说，这个判断比背 API 名字重要得多。

• •LangChain Overview
• •LangGraph Overview
• •Thinking in LangGraph