LangChain

LangChain 的痛点：为什么需要 LangGraph LangChain 最初设计目标是链式调用 LLM——prompt → model → output parser 串成一条链。这在简单的 Q&A 和 RAG 场景下足够用，但当你要构建真正的 Agent时，问题就来了： 痛点 具体表现 链是线性的 Agent 需要循环、条件分支、回退，Chain 只能直线走 状态管理粗糙 Memory 机制简陋，复杂状态需手动管理，多步推理容易丢上下文 没有检查点 长流程中途失败，无法从断点恢复，只能从头来 Human-in-the-loop 困难 链执行中无法暂停等待人类输入 AgentExecutor 黑盒 封装太重，调试困难，自定义控制流代价高 LangChain 的 AgentExecutor 本质上是一个 while 循环 + tool 调用，你无法精确控制每一步的行为。当你需要"如果工具返回 X 则走分支 A，否则走分支 B"这种逻辑时，AgentExecutor 就力不从心了。 LangGraph 的核心思路：把 Agent 当图来建模 LangGraph 的设计哲学很简单：Agent 的执行流程是一张有向图。 节点（Node）：每个节点是一个函数，接收状态，返回更新后的状态 边（Edge）：连接节点的有向边，可以是固定的或条件性的 状态（State）：一个共享的 TypedDict 或 dataclass，在节点间流转 from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] tool_results: list def call_model(state: AgentState): response = llm.invoke(state["messages"]) return {"messages": [response]} def should_use_tool(state: AgentState) -> str: last_msg = state["messages"][-1] if last_msg.tool_calls: return "tools" return END # 构建图 graph = StateGraph(AgentState) graph.add_node("agent", call_model) graph.add_node("tools", tool_node) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_use_tool) graph.add_edge("tools", "agent") # 工具执行完回到 agent app = graph.compile() 这段代码实现了一个标准的 ReAct Agent，但控制流完全透明。你能看到每一步在做什么，为什么走这个分支。 ...

LangChain 生态版图 LangChain（工具库） ├── LangGraph（图式 Agent 编排） ├── LangSmith（可观测性） └── LangServe（API 部署） LangChain：工具库时代 定位 LangChain 是最早也是最流行的 LLM 应用框架，核心是"把 LLM 当作可组合的积木"。 核心概念 from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_openai import ChatOpenAI # Chain = Prompt + LLM + Parser prompt = ChatPromptTemplate.from_template("解释 {topic} 给 5 岁小孩听") llm = ChatOpenAI(model="gpt-4o") parser = StrOutputParser() chain = prompt | llm | parser # 管道语法 result = chain.invoke({"topic": "量子计算"}) LangChain 的问题 # 问题 1：过度抽象 # 简单的 API 调用被包装了 5 层 chain = ( RunnablePassthrough.assign( context=lambda x: retriever.invoke(x["question"]) ) | prompt | llm.bind_tools(tools) | RunnableLambda(parse_tool_calls) | RunnableLambda(execute_tools) | llm | parser ) # 调试困难：报错信息深埋在调用栈中 # 问题 2：版本碎片化 # langchain / langchain-core / langchain-community 版本不同步 # 升级一个包可能破坏其他包 # 问题 3：性能开销 # 每层抽象都有 Python 对象创建开销 # 简单任务直接用 OpenAI SDK 更快 LangGraph：图式编排时代 定位 LangGraph 是 LangChain 团队的"自我革命"——从链式调用转向图式编排，专门为 Agent 设计。 ...

为什么需要 LangGraph 传统 Agent 框架（如 LangChain Agent）采用线性的 ReAct 循环：思考 → 行动 → 观察 → 重复。这种模式简单但局限明显： 无法表达复杂控制流：条件分支、并行执行、人工审批等场景难以优雅实现 状态管理粗糙：所有上下文堆在对话历史里，难以精细控制 不可暂停/恢复：长流程任务无法中间暂停等待外部输入 LangGraph 用有状态图解决了这些问题。 核心概念 State Graph（状态图） LangGraph 的核心是 StateGraph，每个节点接收状态、修改状态、返回新状态： from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from operator import add class AgentState(TypedDict): messages: Annotated[list, add] # 消息列表自动追加 tool_results: list iteration: int def call_model(state: AgentState): response = llm.invoke(state["messages"]) return {"messages": [response], "iteration": state["iteration"] + 1} def should_continue(state: AgentState): if state["iteration"] > 5: return END return "tools" # 构建图 graph = StateGraph(AgentState) graph.add_node("agent", call_model) graph.add_node("tools", tool_node) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") app = graph.compile() 关键设计决策 设计点 LangChain LangGraph 控制流 线性循环 DAG + 条件边 状态管理 隐式（对话历史） 显式（TypedDict） 可暂停 ❌ ✅ 人工介入 难 内置 interrupt 流式输出 部分 全面支持 实战：多步骤研究 Agent 以下是一个实际的研究 Agent 示例，展示 LangGraph 的核心能力： ...