1.2 相较于LangChain的演进与优势

1.2 相较于LangChain的演进与优势

从链到图的路径

本节在全册位置：解释 LangGraph 与 LangChain 的关系。LangChain 提供组件与链，擅长把若干步骤串成线性管道；但当步骤需要循环、分支或人工介入，链的表达力就见顶。LangGraph 不是替代 LangChain，而是在它之上补一层「编排」能力。我们见过不少团队因为误解这点，把 LangChain 组件又包一层链，结果控制流比直接用图还绕。

演进：链解决顺序，图解决控制流

下表按工程维度对比两者。需要强调：LangGraph 复用 LangChain 的模型、工具、检索器，差异在执行模型。链是「写死的下一步」，图是「由状态决定的下一步」。这点在多步推理任务上差异明显——链的回退要重写整条链，图的回退只需改一条边。类比建筑：链像预制管廊，图像带阀门与旁通的管网，运维时能在节点间切换流向。我们的判断是，只要任务出现「要不要再来一次」的判定，就该认真考虑图。

#    1.2 相较于LangChain的演进与优势
from langchain_core.tools import tool

@tool
def search(q: str) -> str:
    """检索知识库"""
    return f"关于 {q} 的片段..."

# 在 LangGraph 中作为节点接入
from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class S(TypedDict):
    q: str
    ans: str

def run_tool(s: S):
    return {"ans": search.invoke(s["q"])}

b = StateGraph(S)
b.add_node("search", run_tool)
b.add_edge(START, "search")
b.add_edge("search", END)
g = b.compile()
print(g.invoke({"q": "检查点", "ans": ""}))
​

# 对比：链的写法（线性、无回路）
from langchain_core.runnables import RunnableLambda
chain = RunnableLambda(lambda x: x["q"]) | RunnableLambda(search.invoke)
# 我们更推荐把这类控制流交给图，链只负责单步转换
​

案例：多轮检索的取舍

背景：研究助手常需「检索-阅读-发现缺口-再检索」，轮数不固定，无法在编码期写死。

操作：链方案用递归 Runnable 模拟，图方案用条件边判断是否充分。

结果：图方案代码量更小，且每轮查询可见、可中断、可观测。

解读：当控制流由数据决定时，图的边际成本远低于链，这是两者最实质的分野。

变式：把「是否充分」交给模型打分时，图的断点更容易插入人工确认（见第四章），链的递归里插断点要改调用栈。

工程清单

• 链与图不是替代关系，而是执行模型的差异：链写死下一步，图由状态决定下一步，重构控制流只改边。

• 同一批 LangChain 工具在链和图里都能用，迁移成本主要在控制流，不必为图重写已验证的组件。

• 多轮决策一旦出现，优先评估是否能用条件边表达，而非嵌套 Runnable，后者调试时完全不可视。

常见误区

误以为上了 LangGraph 就一定要把全部逻辑搬进图；其实清洗、格式化这类固定步骤用链更轻，把图留给真正有分支与循环的部分，整体可读性更好。

迁移成本拆解

把已有链迁入图，最划算的是「节点最小化改动」：原有 Runnable 直接包成节点，控制流改写边，业务函数一行不动。下面量化三条路径的代价。

# 路径 A：整条链当单个节点塞进图（最快但黑盒）
def run_chain(s):
    return {"text": old_chain.invoke(s["text"])}
b = StateGraph(S); b.add_node("legacy", run_chain)
b.add_edge(START, "legacy"); b.add_edge("legacy", END)

# 路径 B：把有分支的步拆成节点（可观测）
def branch_step(s):
    return {"text": refine(s["text"])}
# 至少拆出分支步，才能用条件边做回流
​

⚠️ 常见坑：把旧链整条塞进单个节点，就只借到图的外壳，享受不到可中断、可观测红利；要拿红利至少把有分支的步拆出来。

💡 关键直觉：迁移不是重写业务，而是把「下一步去哪」从业务函数抽出来交给边；业务函数越纯（只算不改流向），迁移越便宜。

生态位置：LangGraph 不是孤岛

LangGraph 复用 LangChain 的模型接口、工具协议与检索抽象，把执行层从「管道」升级为「图」。这带来两个实际收益：其一，积累的 LangChain 组件（自定义工具、retriever、memory）不必重写；其二，LangChain 生态的观测工具（LangSmith）能直接追踪图内每一步的状态变化，排查「卡在哪一轮」比链式日志直观得多。

与其他多智能体框架的分工

AutoGen 强调「对话驱动」的智能体协作，CrewAI 强调角色化的任务拆解，LangGraph 则把「控制流」本身当作一等公民。选型不是比谁先进，而是看你的痛点在不在它的射程内：核心诉求若是「流程可显式建模、回退、审计」，LangGraph 最合适；只是想让几个角色互相聊天出结果，对话式框架上手更快。把控制流交给图、把对话交给框架，是常见的互补组合。

什么时候不该用图

承认边界也是工程素养。固定顺序、无分支、无循环的步骤，用链写三行就够了，上图反而多一层概念开销。图的价值在「下一步由状态决定」，如果任务从头到尾只有一条直线，图的收益接近零。建议先画一遍流程图：图上只有一条直线就继续用链；一旦出现回边或菱形分支，再迁到 LangGraph。这条取舍线，比记住任何 API 都更能帮你少走弯路。