19-大模型智能体开发：LangChainLangGraph是如何诞生的

系列文章导航：AI系列文章导航目录-持续更新中

第19课：Agent开发框架——LangChain & LangGraph 完全指南（一）

前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站，麻烦大家帮点贡献下点击量支持一下，您的支持是我更新的动力。

📝 本文定位：这不是一篇普通的技术培训文章。它试图回答两类问题：

• 为什么：LangChain 为什么被创造？LangGraph 为什么从中分离？每一个设计决策背后的行业痛点是什么？
• 怎么做：如何用 LangChain + LangGraph 构建生产级 Agent 应用？

理解"为什么"，你才能真正用好"怎么做"。

零、前因后果：一个框架的诞生与进化

在学任何技术之前，先搞清楚它从哪里来、为什么存在、解决了什么问题。这比背 API 文档重要得多。

0.1 时代背景：2022年的那个秋天

要理解 LangChain，必须先回到 2022 年秋天。

那时候，GPT-3 已经发布两年，但它只是一个"聊天玩具"——你问它问题，它回答，仅此而已。真正的变化发生在 2022 年 3 月：OpenAI 悄悄在 API 里加了一个功能，叫text-davinci-003，它的指令跟随能力突然变得异常强大。

开发者们开始疯狂实验：

"如果我让 LLM 先思考，再行动，再观察结果，再思考……会怎样？"

2022 年 10 月，一篇论文横空出世：ReAct: Synergizing Reasoning and Acting in Language Models。它证明了一件事：LLM 不只能聊天，它能"推理+行动"，能成为一个真正的 Agent。

ReAct 的核心思想极其简单：

Thought: 我需要查一下今天的天气 Action: search("北京今天天气") Observation: 北京今天晴，25°C Thought: 已经知道天气了，可以回答用户了 Answer: 北京今天晴天，25°C，适合出行

这个循环，就是 Agent 的本质。

但问题来了：每个开发者都在自己手写这个循环。

0.2 LangChain 的诞生：一个人的周末项目

2022 年 10 月，一个叫Harrison Chase的工程师，在旧金山的一个周末，写了一个小工具，把 LLM 调用、工具调用、提示词管理这些重复工作封装了起来。

他把它叫做LangChain，推到了 GitHub 上。

没有任何宣传，没有任何融资，就是一个工程师解决自己痛点的周末项目。

然后，它爆了。

2022.10 → GitHub 上线，第一周 1000 stars 2022.12 → ChatGPT 发布，AI 开发者数量爆炸式增长 2023.01 → LangChain 成为 GitHub 增长最快的项目之一 2023.02 → 融资 1000 万美元（种子轮） 2023.04 → 融资 2500 万美元（A 轮） 2023.06 → 融资 2500 万美元（B 轮），估值 2 亿美元 2023.08 → GitHub stars 突破 50,000

为什么爆？因为它解决了一个所有 AI 开发者都在面对的真实痛点：

没有 LangChain 之前，每个开发者都在重复写这些代码： 1. 消息格式管理 messages = [{"role": "system", "content": "..."}, ...] → 每个项目都要手写，格式不统一 2. 工具调用循环 while True: response = llm.call(messages) if response.has_tool_call: result = execute_tool(response.tool_call) messages.append(result) else: break → 每个项目都要手写，逻辑重复 3. 提示词管理 prompt = f"你是一个助手，用户问：{user_input}，上下文：{context}" → 字符串拼接，难以维护 4. 模型切换 # 从 OpenAI 换到 Anthropic，要改很多地方 → 没有统一接口 LangChain 把这些全部封装了，给了开发者一套统一的抽象。

这就是 LangChain 最初的愿景：做 AI 开发的"标准库"，让开发者专注业务逻辑，而不是重复造轮子。

0.3 LangChain 的第一个设计哲学：Chain（链）

Harrison Chase 给这个框架起名 “LangChain”，“Chain” 这个词不是随便选的。

他的核心设计思想是：AI 应用 = 一系列步骤的组合。

用户输入 → 提示词模板（格式化输入） → LLM 调用（生成回复） → 输出解析器（提取结构化数据） → 返回结果 这就是一条"链"（Chain）。

早期的 LangChain 充满了各种 Chain：

• LLMChain：最基础的链，提示词 → LLM → 输出
• ConversationChain：带记忆的对话链
• RetrievalQAChain：RAG 链，检索 + 问答
• SequentialChain：顺序执行多个链
• RouterChain：根据输入路由到不同链

这个设计在 2023 年初非常成功，因为大多数 AI 应用确实是线性的：输入 → 处理 → 输出。

但随着开发者开始构建更复杂的 Agent，问题出现了。

0.4 第一个危机：Chain 的局限性

2023 年中，开发者们开始抱怨：

“我的 Agent 需要根据工具调用的结果，决定下一步做什么。但 Chain 是线性的，它不支持条件分支！”

“我的 Agent 需要循环执行，直到满足某个条件。但 Chain 不支持循环！”

“我有多个 Agent 需要协作，但 Chain 没法表达 Agent 之间的通信！”

LangChain 团队的应对方案是AgentExecutor——一个专门为 Agent 设计的执行器，内置了 ReAct 循环。

但AgentExecutor很快也暴露了问题：

AgentExecutor 的问题： 1. 黑盒 → 你不知道 Agent 在每一步做了什么 → 调试极其困难 2. 不可控 → 无法在 Agent 执行中途插入人工审核 → 无法在某个步骤暂停、修改、继续 3. 状态管理混乱 → 没有清晰的"状态"概念 → 多个 Agent 之间共享数据很麻烦 4. 不支持复杂流程 → 无法表达"如果 A 失败，走 B 路径，否则走 C 路径" → 无法表达"先并行执行 A 和 B，再汇总结果"

这时候，LangChain 团队意识到：他们需要一个全新的抽象来解决这些问题。

0.5 LangGraph 的诞生：用图论解决 Agent 编排问题

2023 年 8 月，LangChain 团队发布了LangGraph。

这个名字里的 “Graph”（图）不是随便起的。它来自计算机科学中的有向图概念：

传统 Chain 的思维模型： A → B → C → D （线性，只能前进） LangGraph 的思维模型： A → B → C ↓ ↑ D → E ──┘ （图，可以有分支、循环、并行）

LangGraph 的核心洞察是：Agent 的执行流程，本质上是一个有状态的有向图。

• 每个节点（Node）是一个处理步骤
• 每条边（Edge）是步骤之间的跳转规则
• 整个图共享一个状态（State）

这个抽象解决了AgentExecutor的所有问题：

LangGraph 如何解决 AgentExecutor 的问题： 1. 黑盒 → 透明 每个节点都是显式定义的函数，你知道每一步在做什么 2. 不可控 → 精细控制 可以在任意节点插入 interrupt()，暂停等待人工审核 3. 状态管理混乱 → 清晰的 State 所有节点共享同一个 TypedDict 定义的 State，类型安全 4. 不支持复杂流程 → 任意图结构 条件边、并行节点、子图……任何流程都能表达

但 LangGraph 为什么不直接替代 LangChain，而是作为独立包存在？

这是一个重要的架构决策：

LangChain 和 LangGraph 的分工： LangChain（基础设施层）： - 提供统一的模型接口（ChatOpenAI, ChatAnthropic...） - 提供消息类型（HumanMessage, AIMessage...） - 提供工具定义规范（@tool 装饰器） - 提供提示词模板 → 这些是"积木" LangGraph（编排层）： - 定义 Agent 的执行流程（图结构） - 管理状态（State） - 控制流程（条件边、循环） - 持久化（Checkpointer） → 这是"搭积木的规则" 分开的好处： - 你可以用 LangGraph 编排，但用 OpenAI SDK 直接调用模型 - 你可以用 LangChain 的工具，但用自己的编排逻辑 - 关注点分离，各自演进

0.6 生态的演进：从工具到平台

LangChain 的发展不是线性的，它经历了几次重要的战略转型：

阶段一（2022.10 - 2023.06）：工具期 核心产品：LangChain 库 核心用户：AI 开发者 核心价值：减少重复代码 问题：生态太大太杂，抽象层太多，"过度工程化"的批评开始出现 阶段二（2023.06 - 2024.06）：平台期 核心产品：LangSmith（可观测性平台） 核心洞察：开发者不只需要框架，还需要"看到 Agent 在做什么" LangSmith 解决了： - Agent 执行的全链路追踪 - 提示词版本管理 - 评估和测试 这是 LangChain 从"开源工具"转向"商业平台"的关键一步 阶段三（2024.06 - 至今）：Agent 基础设施期 核心产品：LangGraph Platform（部署平台） 核心洞察：Agent 不只需要开发，还需要部署、运维、扩展 LangGraph Platform 解决了： - 一键部署 Agent 为 API 服务 - 内置持久化（不需要自己搭数据库） - 内置队列（处理并发请求） - 内置监控 这是 LangChain 从"框架"转向"Agent 基础设施"的关键一步

一个关键的行业观察：

LangChain 的演进路径，和 10 年前 Docker 的演进路径惊人地相似：

Docker 的演进： Docker（容器工具）→ Docker Compose（编排工具）→ Kubernetes（生产级平台） LangChain 的演进： LangChain（AI 工具）→ LangGraph（编排工具）→ LangGraph Platform（生产级平台）

这不是巧合。每一个新技术范式，都会经历"工具 → 编排 → 平台"的三阶段演进。

0.7 为什么其他框架会出现：生态的分化

LangChain 爆火之后，大量竞争者涌现。这不是偶然，而是因为 LangChain 的设计哲学本身存在争议：

批评 LangChain 的声音：

"LangChain 抽象层太多了，我只是想调用一个 LLM，为什么要引入这么多概念？" → 催生了：直接用 OpenAI SDK / Anthropic SDK "LangChain 的 Chain 概念太复杂，我只想做多 Agent 协作，有没有更简单的？" → 催生了：CrewAI（角色驱动，更直觉化） "LangChain 太通用了，我只做 RAG，有没有专精 RAG 的框架？" → 催生了：LlamaIndex（RAG 专精） "LangChain 没有类型安全，我的生产系统需要严格的类型约束" → 催生了：PydanticAI（类型安全） "我是微软/Google/OpenAI，我要做自己的 Agent 框架" → 催生了：AutoGen / Google ADK / OpenAI Agents SDK

这就是为什么今天有这么多 Agent 框架：不是因为 LangChain 失败了，而是因为 AI Agent 这个领域足够大，不同的场景需要不同的工具。

0.8 设计哲学的碰撞：两种 Agent 开发观

理解了历史，你会发现今天的 Agent 框架，本质上代表了两种截然不同的设计哲学：

哲学一：声明式（Declarative） 代表：CrewAI、AutoGen 核心思想：你告诉框架"你想要什么"，框架决定"怎么做" 例（CrewAI）： agent = Agent(role="研究员", goal="收集信息", backstory="...") task = Task(description="研究AI趋势", agent=agent) crew = Crew(agents=[agent], tasks=[task]) crew.kickoff() 优点：上手快，代码简洁 缺点：黑盒，难以精细控制 哲学二：命令式（Imperative） 代表：LangGraph 核心思想：你精确定义"每一步怎么做"，框架负责执行 例（LangGraph）： def agent_node(state): ... def tools_node(state): ... graph.add_node("agent", agent_node) graph.add_node("tools", tools_node) graph.add_conditional_edges("agent", should_continue) 优点：完全可控，透明，适合生产 缺点：代码量大，需要理解图的概念 没有哪种哲学是绝对正确的。 → 快速原型、内容创作 → 声明式（CrewAI） → 生产系统、复杂流程 → 命令式（LangGraph）

0.9 现在的格局：2025-2026 年的 Agent 生态

当前 Agent 框架生态的几个关键趋势： 趋势一：标准化 MCP（Model Context Protocol）和 A2A（Agent-to-Agent）协议的出现， 让不同框架的 Agent 可以互相通信。 → 框架之间的壁垒在降低 趋势二：平台化 LangGraph Platform、OpenAI Agents SDK 的 Sessions 功能…… 框架都在往"托管平台"方向走，不只是库，而是服务。 → 开发者不需要自己管理基础设施 趋势三：多模态 Agent 不只处理文字，还能处理图片、音频、视频、代码执行…… 框架需要支持更复杂的工具类型。 趋势四：长时运行 Agent 不再是"一次性调用"，而是可以运行几小时、几天的长任务。 这对持久化、错误恢复、人机协作提出了更高要求。 → LangGraph 的 Checkpointer 设计正是为此而生 趋势五：可观测性成为标配 生产级 Agent 必须知道"Agent 在做什么"。 LangSmith、Langfuse、Arize 等可观测性工具成为标配。

小结：现在你知道了——LangChain 是一个工程师解决自己痛点的周末项目，LangGraph 是为了解决 Chain 无法表达复杂流程而生的，整个生态的演进是由真实的开发者痛点驱动的。带着这个理解，我们开始学技术。