如果你动手开发过 AI 应用，几乎一定会遇到 LangChain 这个名字。它是 AI 应用开发领域最流行的开源框架之一，从 2022 年诞生到现在，几乎成了”LLM 应用开发”的代名词。而它的”同门兄弟” LangGraph，则把 AI 开发推向了更复杂、更可控的 Agent 场景。2025 年 10 月，这两个框架双双发布了 1.0 版本。
先搞清楚：LangChain 和 LangGraph 是什么关系
很多人分不清这两个名字，甚至以为它们是竞争关系。其实它们出自同一个团队（LangChain Inc），定位互补，常常一起用。
LangChain 的定位是”构建 AI 应用的最快方式”。它提供了一整套搭积木式的组件——模型集成、提示词模板、工具、记忆、检索器——让开发者能快速拼出一个 LLM 应用。它的核心抽象是”链”（Chain）和 LCEL（LangChain Expression Language），用管道式的写法把多个步骤串起来。
LangGraph 的定位则更低层、更偏”运行时”。它把应用建模成一张”图”——有节点（node，代表动作）、有边（edge，代表跳转关系），还有一个贯穿始终的状态对象。这种图结构天然适合表达循环、分支、重试、暂停等待人工等复杂逻辑，而这些正是”真正能上生产的 Agent”所需要的。
一个形象的比喻：LangChain 是”零件箱”，让你快速搭出东西；LangGraph 是”装配流水线”，负责让复杂流程稳定、可控、可恢复地跑起来。官方自己也说得很清楚——LangChain 的 Agent 是构建在 LangGraph 运行时之上的。
为什么会走到 1.0
LangChain 的早期版本以”抽象丰富”著称，但也因此招来不少批评：抽象层太厚、包体积臃肿、想跳出预置模式做定制时反而处处受限。经过三年多迭代和社区反馈，1.0 做了一次大的收敛。
这次 1.0 的核心变化，是把 LangChain 重新聚焦到”核心 Agent 循环”上，引入了 create_agent 这个新抽象，并通过 middleware（中间件） 机制提供可插拔的定制能力。官方承诺：1.0 是稳定版本，直到 2.0 之前不会有破坏性变更。这标志着框架从”快速试错”阶段进入了”生产可用”阶段。
create_agent：一行代码跑起一个 Agent
LangChain 1.0 引入的 create_agent，把构建 Agent 的门槛降到了极低。它的核心是一个标准的 Agent 循环：
- 设置：选定模型，给它一些工具和提示词。
- 执行：把请求发给模型。
- 模型返回两种结果之一：要么是要调用的工具（tool call），要么是最终答案。
- 如果是工具调用，就执行工具、把结果加回对话，回到第 2 步循环；如果是最终答案，就返回。
这个循环，本质上就是我们前面聊过的 ReAct 范式的工程化实现。用代码表达大概是这样：
from langchain.agents import create_agent
agent = create_agent(
model="openai:gpt-5",
tools=[get_weather],
system_prompt="帮助用户查询所在城市的天气。",
)
result = agent.invoke({"role": "user", "content": "旧金山天气怎么样？"})
很多 Agent 框架的问题是”只能在这个核心循环内定制”，超出循环就无能为力。create_agent 用 middleware 解决了这个痛点。
middleware：在 Agent 循环的每一步插桩
中间件（middleware）定义了一组”钩子”，让你能在 Agent 循环的每一步做细粒度的定制。官方内置了几个常用的中间件：
- Human-in-the-loop（人在回路）：在工具执行前暂停，让用户批准、修改或拒绝。这对要和外部系统交互、发消息、做敏感交易的 Agent 至关重要。
- Summarization（摘要）：当对话历史逼近上下文上限时，自动压缩旧内容，保留最近的消息。避免 token 溢出，让长会话保持可用。
- PII redaction（隐私脱敏）：在内容发给模型前，用模式匹配识别并脱敏邮箱、电话、证件号等敏感信息，帮助满足隐私合规要求。
除了内置的，你也可以写自定义中间件，挂到 Agent 循环的不同环节上。这给了开发者”既享受预置的省事，又保留精细控制”的平衡。
LangGraph：为什么复杂 Agent 需要一张”图”
如果说 LangChain 解决的是”快速搭出来”，那 LangGraph 解决的是”复杂、长时、有状态”的场景。它的设计灵感来自 Pregel 和 Apache Beam（都是大规模图计算/流处理的经典系统）。
LangGraph 把一个 Agent 应用建模为节点 + 边 + 状态。节点是具体的动作（调用模型、调用工具、做判断），边是节点之间的跳转关系，状态对象则在整张图里流转。这种设计带来几个关键能力：
- 持久执行（durable execution）：通过 checkpoint（检查点），应用能在任意节点暂停、保存状态，出错后从断点恢复，而不是从头再来。这让”长时间运行的 Agent”成为可能。
- 循环与分支：传统线性”链”很难表达”问不清楚就再问一次””根据结果走不同分支”这类逻辑，图结构天然支持。
- 人在回路：在任意时刻检查、修改 Agent 状态，无缝引入人工监督。
- 全面记忆：既有短期工作记忆，也有跨会话的长期持久记忆。
简单说：当你需要的是一个”能跑很久、能自我纠错、能在关键节点停下来等人”的 Agent，而不是一个”一把梭”的线性流程时，就该上 LangGraph。
生态里的其他成员
LangChain 生态不止这两个框架，还有几个经常被一起提及的组件：
- LangSmith：可观测性和评估平台。用来追踪 LLM 应用的执行轨迹、评估 Agent 表现、在生产环境里定位问题。对应”调试”和”质量”。
- LangGraph Platform / Studio：部署和可视化原型平台，用来把有状态的 Agent 部署、扩展到生产，并在 Studio 里可视化调试。
- LangFlow：可视化拖拽式构建器，适合不写代码的人快速搭流程原型，再导出成代码。
一个常见的上手路径是：先用 LangChain 快速搭原型，流程变复杂后迁到 LangGraph，同时用 LangSmith 做观测和评估，需要快速迭代或非开发者协作时再用 LangFlow。
一段简史：从 2022 到 2025
理解 LangChain 的现状，回头看它的演进会更清楚。
2022 年 10 月：Harrison Chase 等人开源了 LangChain，定位是”组合 LLM 应用的框架”。当时 ChatGPT 刚火，开发者迫切需要一套工具来把”模型调用、提示词、记忆、工具”这些散件组装起来，LangChain 正好踩中了这个需求，迅速成为最流行的 LLM 应用框架。
2023 年：LangChain 形式化了核心抽象，引入了 LCEL（LangChain Expression Language），用管道式的写法组合组件，并推出了 LangServe 用于把链部署成 API。这一年它也拿到了融资，团队和社区都快速膨胀。
2023-2024 年：LangSmith 上线并逐步成熟，提供了统一的追踪、评估、监控能力，让团队能调试和测试链与 Agent。同期，LangGraph 于 2024 年推出，用图运行时解决了”长时运行、多步、有状态”的 Agent 需求。
2025 年：LangChain 和 LangGraph 双双发布 1.0，标志着一个稳定期的开始。官方承诺 1.0 到 2.0 之间无破坏性变更，这对企业采用是个重要信号。
这条线背后是一个趋势：LLM 应用开发从”能不能跑通”走向”能不能稳定上生产”，框架也随之从”包罗万象”收敛到”职责清晰”。
LCEL：用管道的方式组合组件
LangChain 里有个绕不开的概念叫 LCEL（LangChain Expression Language）。它的核心是用 | 管道符，把一个个组件”串”起来，让数据像流水线一样从左流到右。
比如一个最简单的”提示词 → 模型 → 输出解析”的链，用 LCEL 可以写成：
chain = prompt | model | output_parser
result = chain.invoke({"question": "..."})
这段代码里，prompt、model、output_parser 都是 Runnable 对象，| 把它们连成一个新的 Runnable。LCEL 的优雅之处在于：它天然支持流式输出、异步调用、批处理和自动重试——你不需要为这些能力写额外的胶水代码。
LCEL 也澄清了一个常见的误解：LangChain 的”链”并不是什么魔法，它本质就是”把多个可运行组件按顺序组合起来”。理解了 Runnable 和 | 管道，LangChain 的核心用法就掌握了七成。
LangChain 的经典用例：RAG
LangChain 最经典、也最能体现其价值的一个用例，是 RAG（检索增强生成）。RAG 解决的是大模型”知识过时、私有数据不掌握”的问题——先从你自己的文档库里检索相关内容，再把检索结果拼进提示词，让模型基于这些内容作答。
用 LangChain 搭一个 RAG 流程，大致是这几步：加载文档（load）→ 切块（chunk）→ 向量化（embed）→ 存入向量库（store）→ 检索（retrieve）→ 拼提示词生成答案。每一步都有对应的组件，用 LCEL 或链把它们串起来即可。
RAG 这个例子很好地说明了 LangChain 的定位：它不发明新算法，而是把”文档处理、向量检索、模型调用”这些已有的能力，用统一的接口组织起来，让开发者不用自己写一堆胶水代码。这也是为什么在”快速搭一个 AI 应用”的场景里，LangChain 至今仍然很顺手。
Agent 循环的工程细节
Agent 是 LangChain/LangGraph 最核心的场景，值得把它的工程细节拆开看看。
一个 Agent 循环，本质上是这样的：模型接收对话历史，输出”要调用哪个工具 + 什么参数”或”最终答案”；如果是工具调用，程序执行工具，把结果追加回历史，再次调用模型；如此往复，直到模型给出最终答案。
这里有几个关键的工程点：
- 工具描述：每个工具要有一段清晰的描述，告诉模型”这个工具是干什么的、参数是什么”，否则模型不知道该什么时候用、怎么用。
- 循环终止：必须有明确的终止条件（最大步数、或模型输出最终答案），否则可能死循环。
- 错误处理：工具执行失败、超时、返回异常，都要能优雅地反馈给模型，让它重试或换策略。
- 状态管理：多轮对话、多步行动之间，状态要正确维护。这正是 LangGraph 的强项——用显式的状态对象和图结构，让状态流转清晰可控。
理解了这些细节，你就明白为什么”能跑通一个 demo”和”能上生产一个 Agent”之间，隔着相当多的工程工作。框架帮你消化了其中很大一部分。
怎么选：LangChain、LangGraph，还是都不选
框架选择一直是个有争议的话题。有人觉得框架抽象太重、隐藏了太多细节，宁可直接用模型的原生 API 或工具调用。这里给几个判断维度：
- 快速原型、线性流程、想省事 → LangChain 很合适，组件丰富、生态大、文档全。
- 复杂多步、有循环分支、要长时运行、要可恢复 → 用 LangGraph，或者直接基于它的运行时构建。
- 追求极致可控、不想被抽象绑架、团队能力强 → 直接用底层 LLM API + 自己写编排，也未尝不可。框架不是必需的，它只是帮你少写胶水代码。
关键在于认清自己的需求：框架的价值是”少写重复代码、少踩常见坑”，代价是”多一层抽象、多一份学习成本”。对小项目，直接用原生 API 可能更清爽；对要长期维护、多人协作、功能复杂的 Agent 应用，框架带来的工程化收益会越来越明显。
一个具体的 LangGraph 图长什么样
说再多抽象，不如看一段真实的 LangGraph 代码。下面是一个简化的”检索问答 + 人在回路”流程，用 StateGraph 定义节点和边：
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class State(TypedDict):
question: str
context: str
answer: str
def retrieve(state):
# 从知识库检索相关文档
return {"context": "...检索结果..."}
def generate(state):
# 基于 context 生成答案
return {"answer": "...生成的答案..."}
graph = StateGraph(State)
graph.add_node("retrieve", retrieve)
graph.add_node("generate", generate)
graph.add_edge(START, "retrieve")
graph.add_edge("retrieve", "generate")
graph.add_edge("generate", END)
app = graph.compile()
result = app.invoke({"question": "..."})
这段代码展示了 LangGraph 的核心思想：状态类型 State 定义了贯穿全程的数据结构，节点 retrieve、generate 是动作，边定义了”先检索、再生成”的顺序。当流程变复杂时，你只需要在图上加节点、改边的指向，就能表达循环（比如”答案不满足要求就回到 retrieve 再查”）和分支（比如”根据问题类型走不同节点”），而不需要重写整套逻辑。
配合 checkpoint 机制，你还可以在任意节点处 interrupt（中断）暂停，把控制权交给人——比如在生成答案前让人工确认检索结果是否准确。人在回路的实现，在 LangGraph 里就是这么自然。
Agent 开发的几个常见误区
用框架开发 Agent 的人多了，也沉淀出了一些反复出现的坑，值得提前避开。
- 误以为框架越大越好：很多人一上来就把 LangChain + LangGraph + LangSmith + 各种组件全堆上，结果被抽象层绕晕。正确做法是从最小可用开始，需要什么再加什么。
- 忽视工具描述的质量：模型靠工具描述来决策”用不用、怎么用”。描述含糊，Agent 就频繁调错工具。工具描述要像写 API 文档一样认真。
- 没有设终止条件：Agent 循环没有步数上限或明确的结束信号，很容易陷入”查了又查”的死循环，白白烧 token。
- 把框架当银弹：框架帮你少写胶水代码，但不会替你解决”提示词设计、工具选型、数据质量”这些根本问题。核心还是模型能力和你的业务设计。
- 过早优化状态管理：简单流程用链（LCEL）就够了，不要一上来就上 LangGraph 的图。等真的遇到循环、分支、长时运行的需求，再迁也不迟。
说到底，框架是工具，不是目的。理解它解决了什么问题、又引入了什么代价，才能用得恰到好处，而不是被它牵着走。
小结
LangChain 和 LangGraph 走到 1.0，是一个信号：AI Agent 开发正在从”能跑就行”走向”要稳定、可控、可上生产”。理解这两个框架的分工——一个偏应用层组件，一个偏运行时编排——能帮你在面对”搭一个 AI 应用”的需求时，做出更清醒的技术选型，而不是盲目跟风套框架。
