什么是 LangChain 和 LangGraph？
LangChain 和 LangGraph 是面向 Python（也支持 JavaScript）的开源框架，用于基于大语言模型构建应用：从简单的 RAG 到带工具、记忆和分支流程的 AI 智能体。LangChain 提供构建块（模型、提示词、链、检索器）；LangGraph 则是状态图，用于需要控制、循环和人工确认的复杂智能体流程。下文说明二者区别、如何选型，以及业务侧要注意什么。
- LangChain - 组件库：LLM、提示词、链、向量嵌入、向量检索、工具
- LangGraph - 通过节点图编排：状态、分支、循环、重试、人在回路
- 链（chain） - 固定流水线「输入 → 步骤 → 回答」
- 智能体 - 由模型决定调用哪个工具、何时停止
- 不能替代模型本身 - 框架不会让 GPT/Claude「更聪明」；它帮忙串起 API、数据与逻辑
- 实践 - 简单 RAG/FAQ 往往够用 LangChain；复杂客服路由和多智能体更适合 LangGraph
用一句话说清 LangChain
一次模型 API 调用是「提问 → 回答」。真实产品通常更宽：从知识库拉取文档、调用 CRM、查订单、保存历史、统计 token，并减少模型 幻觉。
LangChain 是一层覆盖各厂商（OpenAI、Anthropic、Gemini、本地 LLM 等）的抽象，免得手写重复粘合代码：
| 组件 | 用途 |
|---|---|
| Chat model / LLM | 统一对接不同 API |
| Prompt templates | 带变量与角色（system/user）的提示词 |
| Retrievers | 为 RAG 找到相关片段 |
| Tools / functions | 调用外部 API、数据库、计算器等 |
| Memory | 对话历史与短期上下文 |
| Output parsers | 把模型输出解析成 JSON/结构 |
典型 LangChain 流程：用户提问 → 检索器找文档片段 → 提示词拼接问题 + 上下文 → 模型带出处作答。这就是经典 RAG，对很多业务场景已经够用。
什么是 LangGraph，它如何补充 LangChain
LangGraph 是同一 LangChain 生态中的库，用于把智能体应用建成图：节点执行步骤，边定义迁移，共享状态（state）沿途更新。
已有链为何还要图：
- 分支 - 置信度低 → 转人工；客户要求退款 → 另一条路径。
- 循环 - 智能体调用工具、读结果、再思考、再调用。
- 可控 - 明确停点、重试、步数上限；少一点「黑盒」。
- 多智能体 - 多个角色（调研、编辑、审核）彼此传递结果。
- 人在回路 - 发客户邮件或扣款前，先等运营确认。
简单说：LangChain = 积木零件，LangGraph = 复杂机器的装配图。二者常一起用：图中的节点调用 LangChain 生态里的模型、检索器与工具。
LangChain vs LangGraph：如何选择
| 任务 | 通常够用 | 更宜倾向 |
|---|---|---|
| 知识库 FAQ / RAG | LangChain（+ 向量库） | 分支与升级很多时用 LangGraph |
| 固定流水线（摘要 → 翻译） | LangChain | - |
| 带工具与「思考 → 调用 → 校验」循环的智能体 | LangChain Agent 或 LangGraph | 复杂度上升选 LangGraph |
| 带工单路由的客服 | 可从链起步 | 状态与人工审批用 LangGraph |
| 多智能体与长任务 | 纯 chain 很难 | LangGraph |
实践规则：从最简单的流水线开始。逻辑已经像带条件与循环的流程图时，就上图，而不是在一个文件里堆「if 链」。
典型技术栈长什么样
业务最小可用组合：
- 模型 - GPT / Claude / Gemini，或经 Ollama 的本地模型；
- LangChain - 提示词、检索器、工具；
- 向量存储 - 用于 embedding 与知识检索；
- LangGraph（按需） - 智能体与分支编排；
- 可观测性 - 步骤日志、延迟、token 成本、错误追踪；
- 集成 - CRM、工单系统、Telegram 机器人、内部数据库。
重要：框架替代不了干净数据与产品设计。知识库差 + LangGraph 再强，回答仍差。估算 RAG 系统成本 与 定制 AI 智能体 时，瓶颈几乎总是数据、集成与质控，而不只是选哪套库。
项目利弊
优点：
- Python 原型快；
- 与主流 LLM、向量库集成现成；
- 提示词、工具与 RAG 有一致写法；
- LangGraph 让智能体结构显式，便于向客户解释与调试；
- 生态成熟，示例与文档多。
风险：
- 抽象税：新手可能淹没在分层里，其实几十行直连 API 就够；
- 生态 API 会变 - 锁版本并注意 breaking changes；
- 带循环的智能体容易无限制烧 token；
- 没有测试与 eval，产品会悄悄变差；
- 并非每个业务都需要智能体 - 常常确定性脚本 + 一步 LLM 更好。
什么时候该上，什么时候还早
值得上，如果：
- 要在自有数据与 API 上做 RAG、助手或智能体；
- 团队已写 Python/JS，想要标准骨架而非零散脚本；
- 需要分支、人工确认与多步场景（LangGraph）；
- 打算长期维护 - 明确架构会回本。
可以延后，如果：
- 一两次 API 调用加好提示词就能解决；
- 没有稳定知识库与集成 - 框架救不了空数据；
- 团队尚未掌握基础 LLM 调用与 embedding；
- 只需要无代码聊天机器人、无自定义逻辑。
小结
LangChain 用现成积木拼装 LLM 应用：模型、提示词、RAG、工具。LangGraph 用状态图编排复杂智能体逻辑：分支、循环与检查点。FAQ 与文档检索常常 LangChain 就够；客服智能体、多步流程与人在回路，建议一开始就用 LangGraph 设计流程。相对数据质量、指标与 token 预算，选库是次要的 - 但正确骨架能省下数月混乱代码。
常见问题
LangChain 和 LangGraph 是两个产品还是一套？
它们是关联生态：LangChain 提供组件，LangGraph 编排复杂流。可以单独用，但实践中图节点常调用 LangChain 的模型与工具。场景变复杂时，按「积木 + 图纸」来想，而不是非此即彼。
普通 RAG 需要 LangGraph 吗？
不一定。 经典 RAG（提问 → 检索 → 回答）用 LangChain，甚至直连 API + 向量库就行。当 RAG 之上出现分支、追问、多智能体、校验循环或强制人工确认时，再上 LangGraph 更有价值。
LangGraph 智能体和「直接调 ChatGPT」有何不同？
一次 ChatGPT 调用是模型在单个上下文窗口内的回答。LangGraph 智能体可多次调用工具、更新状态、按条件分支，并停下来等人审批。它更接近内置 LLM 的工作流引擎，而不是普通聊天。
用 Python 还是 JavaScript 更好？
后端、数据管道与生态多数示例更常见 Python。若智能体旁就是站点的 Node 技术栈，则 JavaScript/TypeScript 合适。功能相近；选团队语言以及要嵌入 LLM 的服务即可。
上线 LangChain / LangGraph 要花多少钱？
框架本身开源 - 费用在模型 API、基础设施（向量库、托管）与开发/运维。RAG 原型可能几天加不大的 token 预算就能出；带 CRM、监控与 eval 的生产智能体则是数周项目，且有明显的智能体预算。最大隐性成本是无限制循环与膨胀的上下文。