【LangChain】新架构概览：从Chain到Agent的演进
想象一下，你正在经营一家餐厅。刚开始时，你只有一条简单的流水线：顾客点餐 → 厨师做菜 → 服务员上菜。这就是LangChain时代的"链式思维"——输入进，输出出，一步接一步，像传送带一样顺畅。
但随着生意越来越好，你发现简单的流水线不够用了。有的顾客要改订单，有的菜需要等食材补货，还有VIP客人需要特殊照顾。你需要一个更智能的系统：能循环、能分支、能记住状态、能在关键时刻停下来询问。这就是LangGraph诞生的原因——把流水线升级为智能调度中心。
让我们来看看这场从"链"到"图"的架构革命到底是怎么回事。
一、核心概念：流水线 vs 调度中心
什么是LangChain？
LangChain就像乐高积木的套装。它提供了一堆标准化的组件：提示词模板、模型接口、工具集成、记忆模块。你可以把它们像拼积木一样串起来，快速搭建一个LLM应用。
# 经典的LangChain风格：像拼水管一样串联组件
chain = prompt | model | output_parser
result = chain.invoke({"question": "今天天气如何？"})
核心特点：
- 线性执行：数据从A点流向B点，像工厂流水线
- 简单直接：适合"输入→处理→输出"的标准流程
- 组件丰富：700+集成，从OpenAI到本地数据库应有尽有
什么是LangGraph？
LangGraph则是把这套乐高积木放进了一个智能棋盘游戏。棋子（节点）可以按照规则在棋盘（图）上移动，可以前进、可以回头、可以分叉，甚至可以在关键位置"暂停"等待人工决策。
# LangGraph风格：定义状态和转移规则
builder = StateGraph(State)
builder.add_node("agent", call_model)
builder.add_node("tools", tool_node)
builder.add_edge("agent", "tools") # 可以循环、可以分支
核心特点：
- 状态驱动：每个步骤都能读取和修改共享"记忆"
- 循环支持：Agent可以反思、重试、迭代优化
- 原生持久化：对话可以暂停，下次接着聊
二、新架构的核心：create_agent设计理念
2025年10月，LangChain和LangGraph双双发布了1.0正式版，标志着生态系统的成熟。其中最值得关注的变化是：旧的AgentExecutor已经被标记为弃用，取而代之的是全新的create_agent API（在LangGraph中对应create_react_agent）。
为什么需要新API？
想象你在用旧式电话亭（AgentExecutor）打电话：投币、拨号、通话、挂断——流程是固定的，如果你想中途查个号码再拨，电话已经断了。
create_agent则像是智能手机：你可以随时暂停去查地图，可以切到计算器算个数，甚至可以同时和多人视频通话——状态始终在线。
新架构的三层设计
| 层级 | 作用 | 类比 |
|---|---|---|
| LangChain Core | 提供基础组件（模型、工具、提示词） | 乐高积木 |
| LangChain Agent API | 快速搭建标准Agent（create_agent） | 积木说明书（预置模型） |
| LangGraph | 完全自定义控制流 | 自由搭建+电路设计图 |
关键洞察：LangChain的新API实际上是在LangGraph之上的一层封装。当你调用create_agent时，底层已经在使用LangGraph的状态管理机制了。
三、何时用LangChain？何时用LangGraph？
这是每个开发者都会问的问题。让我们用几个真实场景来说明：
🟢 选择LangChain（简单预置模式）的场景
场景1：智能客服机器人
- 用户问问题 → 查知识库 → 生成答案
- 流程固定，不需要循环思考
- 代码示例：
from langchain import create_agent
# 10行代码搞定标准ReAct Agent
agent = create_agent(
model="gpt-4",
tools=[search_tool, calculator],
system_prompt="你是一个 helpful 的助手"
)
场景2：文档摘要生成
- 读取PDF → 分段处理 → 合并摘要
- 线性管道，无分支逻辑
判断标准：如果你的流程可以画成一条从左到右的直线，没有回头箭头和分支，用LangChain就够了。
🔵 选择LangGraph（图编排模式）的场景
场景1：研究型Agent
- 搜索资料 → 发现信息不足 → 重新设计查询 → 再次搜索 → 综合分析
- 需要循环、需要反思、需要状态记忆
场景2：多Agent协作系统
- 写作Agent生成草稿 → 编辑Agent审核 → 发现质量问题 → 退回重写
- 需要条件分支、需要人工介入点
场景3：复杂审批工作流
- 提交申请 → AI初审 → 需要人工确认 → 暂停等待 → 收到确认后继续
- 需要持久化状态、需要人机协作
判断标准：如果你的流程图里有循环箭头、菱形判断框、或者暂停等待的时钟图标，你需要LangGraph。
四、架构演进背后的哲学
LangChain的这次架构升级，本质上是在回答一个问题：LLM应用到底需要什么？
从"函数调用"到"状态机"
早期的Chain思维把LLM当成纯函数：输入确定，输出确定。但现实世界的Agent需要状态机：
- 记忆之前的尝试（状态）
- 根据结果决定下一步（转移）
- 在异常时优雅降级（错误处理）
- 长时间运行不丢数据（持久化）
LangGraph的图结构天然支持这些需求。
生态位清晰化
2026年的LangChain生态已经形成了清晰的分工：
┌─────────────────────────────────────────┐
│ LangSmith（观测层） │
│ （监控、调试、评估、A/B测试） │
├─────────────────────────────────────────┤
│ LangGraph（编排层） │
│ （循环、分支、状态、持久化、多Agent） │
├─────────────────────────────────────────┤
│ LangChain（组件层） │
│ （模型、工具、提示词、向量存储...） │
└─────────────────────────────────────────┘
LangSmith是观测塔，盯着整个系统的运行状况； LangGraph是调度中心，决定任务怎么流转； LangChain是工具箱，提供执行具体任务的能力。
五、实战建议：迁移与选型
如果你在用旧版LangChain...
AgentExecutor将在2026年12月停止维护。迁移路径很清晰：
- 简单Agent → 改用
langchain.create_agent（高层API，几乎无迁移成本） - 复杂Agent → 迁移到
langgraph.create_react_agent（需要学习图思维，但收益巨大）
新项目选型决策树
1. 你的应用需要"思考-行动-观察"循环吗？
└─ 是 → LangGraph
└─ 否 → 继续问
2. 需要多Agent协作或人工介入点吗？
└─ 是 → LangGraph
└─ 否 → 继续问
3. 需要状态持久化（断线续聊）吗？
└─ 是 → LangGraph
└─ 否 → LangChain简单模式
4. 只是简单问答/摘要/翻译？
└─ 是 → LangChain（最快上手）
六、最佳实践（Dos & Don'ts）
✅ Do
- 从简单开始：先用LangChain验证想法，复杂了再迁到LangGraph
- 状态设计先行：用LangGraph前先画好状态转移图，明确每个节点的输入输出
- 利用生态协同：LangChain组件 + LangGraph编排 + LangSmith监控，三剑合璧
❌ Don't
- 不要过度设计：简单的RAG管道用LangGraph就是杀鸡用牛刀
- 不要忽视状态管理：LangGraph的强大来自显式状态，别把所有东西塞到prompt里
- 不要在LangChain里硬造循环：用错工具会导致代码像意大利面条
七、延伸阅读
- 官方文档：LangChain Overview - 本文的核心参考来源
- LangGraph入门：LangGraph Concepts - 理解StateGraph的必读材料
- 迁移指南：本系列附录A1《从旧版LangChain迁移指南》
- 调试技巧：本系列附录A2《常见陷阱与调试技巧》
小结：LangChain的新架构不是推翻重来，而是分层进化。底层LangGraph提供强大的状态机和图编排能力，上层LangChain提供简洁的预置模式。理解这层关系，你就能在简单性和灵活性之间找到最佳平衡点——就像既会玩乐高说明书，也能自由发挥搭建自己的城堡。
关注公众号【dev派】，发送 "agent" 获取全部源码和模板
