系列文章导航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 充满了各种 ChainLLMChain最基础的链提示词 → LLM → 输出ConversationChain带记忆的对话链RetrievalQAChainRAG 链检索 问答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 的演进 LangChainAI 工具→ LangGraph编排工具→ LangGraph Platform生产级平台这不是巧合。每一个新技术范式都会经历工具 → 编排 → 平台的三阶段演进。0.7 为什么其他框架会出现生态的分化LangChain 爆火之后大量竞争者涌现。这不是偶然而是因为 LangChain 的设计哲学本身存在争议批评 LangChain 的声音LangChain 抽象层太多了我只是想调用一个 LLM为什么要引入这么多概念 → 催生了直接用 OpenAI SDK / Anthropic SDK LangChain 的 Chain 概念太复杂我只想做多 Agent 协作有没有更简单的 → 催生了CrewAI角色驱动更直觉化 LangChain 太通用了我只做 RAG有没有专精 RAG 的框架 → 催生了LlamaIndexRAG 专精 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趋势, agentagent) 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 → 生产系统、复杂流程 → 命令式LangGraph0.9 现在的格局2025-2026 年的 Agent 生态当前 Agent 框架生态的几个关键趋势 趋势一标准化 MCPModel Context Protocol和 A2AAgent-to-Agent协议的出现 让不同框架的 Agent 可以互相通信。 → 框架之间的壁垒在降低 趋势二平台化 LangGraph Platform、OpenAI Agents SDK 的 Sessions 功能…… 框架都在往托管平台方向走不只是库而是服务。 → 开发者不需要自己管理基础设施 趋势三多模态 Agent 不只处理文字还能处理图片、音频、视频、代码执行…… 框架需要支持更复杂的工具类型。 趋势四长时运行 Agent 不再是一次性调用而是可以运行几小时、几天的长任务。 这对持久化、错误恢复、人机协作提出了更高要求。 → LangGraph 的 Checkpointer 设计正是为此而生 趋势五可观测性成为标配 生产级 Agent 必须知道Agent 在做什么。 LangSmith、Langfuse、Arize 等可观测性工具成为标配。小结现在你知道了——LangChain 是一个工程师解决自己痛点的周末项目LangGraph 是为了解决 Chain 无法表达复杂流程而生的整个生态的演进是由真实的开发者痛点驱动的。带着这个理解我们开始学技术。