LangChain

3 秒看懂

LangChain 是连接大语言模型（LLM）与外部世界的应用开发框架。 它把“调用模型、检索文档、调用工具、管理上下文记忆、串联多步骤推理”等通用能力抽象成可组合的模块，让开发者用声明式/图式的方式搭建 LLM 应用。可类比为“LLM 时代的应用中间件”。

3 分钟产业解释

为什么需要 LangChain？

一个原始 LLM API 调用只能做到“给一段文本，返回一段文本”。但真实应用往往需要：

LangChain 就是把这些“胶水逻辑”标准化、模块化，降低从“有一个 LLM”到“有一个 LLM 应用”之间的工程门槛。

产业位置

终端用户/企业
    │
    ▼
┌──────────────────────────┐
│   LLM 应用（ChatBot/Agent/自动化）│
└──────────┬───────────────┘
           │
     ┌─────▼─────┐
     │ LangChain  │  ◄── 应用编排框架层
     │ (LangGraph)│
     │ (LangSmith)│
     └─────┬─────┘
           │
    ┌──────▼──────┐
    │ LLM 提供商   │  OpenAI / Anthropic / Meta / 本地模型
    │ 向量数据库    │  Pinecone / Weaviate / Chroma / Milvus
    │ 工具/数据源   │  搜索引擎 / SQL / API
    └─────────────┘

商业化路径

LangChain 于 2023 年成立公司 LangChain Inc.，核心开源框架免费，商业化产品包括：

• LangSmith：LLM 应用的可观测性/评估/调试平台（SaaS 按用量计费）
• LangGraph Platform：Agent 工作流的部署与托管服务
• 这是典型的 “开源核心 + 商业化 SaaS” 模式

15 分钟专家深入

核心架构演进（v0.1 → v0.2 → v0.3）

LangChain 经历了剧烈的架构重构，理解其演变是理解当前代码库的关键：

第一阶段（2022.10 – 2023）：单体库

• 所有功能（模型调用、Chain、Agent、Memory、Retrieval）集中在一个 langchain 包中
• Chain 采用 LLMChain、SequentialChain 等线性链式抽象
• 问题：依赖过重、抽象层级混乱、调试困难

第二阶段（2023 下半年 – 2024）：模块化拆分

• langchain-core：核心抽象（Runnables 接口、LCEL 表达式语言）
• langchain：认知架构组件（Agents、Chains 的高级实现）
• langchain-community：第三方集成（所有外部 LLM/工具/向量库的适配器）
• 独立伙伴包：langchain-openai、langchain-anthropic、langchain-google-genai 等
• 引入 LCEL（LangChain Expression Language）：用 | 管道运算符声明式组合 Runnables

第三阶段（2024 – 至今）：Graph 优先

• LangGraph 成为核心 Agent 编排层，取代传统 AgentExecutor
• 用有状态有向图（StateGraph）替代线性链，支持循环、分支、人机交互节点
• LangChain 本身更多退化为“集成层 + 工具定义 + 检索抽象”

关键抽象：Runnable 协议

LangChain v0.2+ 的基石是 Runnable 接口，所有组件统一实现以下方法：

invoke(input)        → 同步单次调用
batch(inputs)        → 批量调用（含自动并行与重试）
stream(input)        → 流式输出
ainvoke / abatch / astream  → 异步版本

所有 Runnable 支持 | 管道组合：

chain = prompt | llm | output_parser
result = chain.invoke({"question": "什么是RAG?"})

这是 LCEL 的核心设计——把数据处理管道变成可声明、可序列化、可流式传输的表达式。

LangGraph：Agent 编排的核心

传统 LangChain Agent 的问题是线性且难以中断/恢复。LangGraph 的设计：

        ┌──────────┐
        │  START   │
        └────┬─────┘
             ▼
    ┌────────────────┐
    │  call_model    │  ◄── 节点：执行 LLM 推理
    └────────┬───────┘
             ▼
    ┌────────────────┐
    │  should_continue│ ◄── 条件边：模型是否要调用工具？
    └───┬────────┬───┘
        │        │
   Yes  ▼        ▼  No
┌────────────┐  ┌──────┐
│ call_tools │  │ END  │
└─────┬──────┘  └──────┘
      │
      └──→ 返回 call_model（循环）

关键特性：

• 持久化状态：每个节点共享一个 State 对象，支持 checkpoint 存储
• 人机交互（Human-in-the-loop）：可在任意节点中断，等待人类审批后恢复
• 子图嵌套：复杂 Agent 可由子图组合
• 多 Agent 拓扑：支持 supervisor、hierarchical、swarm 等多 Agent 协作模式
• 流式 token 输出：支持节点级别的 streaming

RAG（检索增强生成）在 LangChain 中的实现层次

用户问题
   │
   ▼
┌─────────────────┐
│ Query 转换/扩展  │  MultiQuery / HyDE / Decomposition
└────────┬────────┘
         ▼
┌─────────────────┐
│ 检索 Retrieval   │  VectorStore.similarity_search / BM25 / Hybrid
└────────┬────────┘
         ▼
┌─────────────────┐
│ 重排序 Reranking │  Cross-encoder / Cohere Rerank
└────────┬────────┘
         ▼
┌─────────────────┐
│ 压缩上下文       │  ContextualCompression / 逐文档链
└────────┬────────┘
         ▼
┌─────────────────┐
│ 生成回答         │  LLM + 构造好的 Prompt
└─────────────────┘

LangChain 提供了上述每一层的抽象和内置实现，但不是所有场景都需要全部层级。这是新手常见的过度工程化问题。

技术原理

1. 核心运行时机制

┌─────────────────────────────────────────────────┐
│                   LCEL Runtime                    │
│                                                   │
│  RunnableA  ──(pipe)──▶  RunnableB ──▶ RunnableC │
│                                                   │
│  统一接口: invoke / batch / stream / ainvoke      │
│                                                   │
│  ┌─────────────────────────────────────────┐     │
│  │           RunnableConfig                 │     │
│  │  - callbacks (tracing/logging)           │     │
│  │  - tags / metadata                       │     │
│  │  - max_concurrency                       │     │
│  │  - run_name                              │     │
│  └─────────────────────────────────────────┘     │
│                                                   │
│  序列化: 所有管道可通过 JSON 描述→部署到 LangServe  │
└─────────────────────────────────────────────────┘

流式传输的实现： LCEL 管道的 stream 不是简单地等待整个输出——它实现了逐 chunk 透传。当管道末端的 LLM 产出一个 token 时，如果下游的 OutputParser 能处理 partial input（如 JsonOutputParser 支持部分 JSON 解析），用户就能在 LLM 仍在生成时看到部分结果。

2. Agent 执行循环（LangGraph）

# 简化的 LangGraph Agent 状态图伪代码
class AgentState(TypedDict):
    messages: Annotated[list, add_messages]  # 消息列表，自动追加

graph = StateGraph(AgentState)

# 节点定义
graph.add_node("agent", call_model)
graph.add_node("tools", tool_node)

# 边定义
graph.add_edge(START, "agent")
graph.add_conditional_edges(
    "agent",
    should_continue,       # 函数：检查最后一条消息是否包含 tool_calls
    {"continue": "tools", "end": END}
)
graph.add_edge("tools", "agent")  # 工具结果回传给 agent

app = graph.compile(checkpointer=MemorySaver())

与传统 AgentExecutor 的关键区别：

3. 工具定义与调用协议

@tool
def search_web(query: str) -> str:
    """Search the web for current information."""
    return tavily_search(query)

# 工具会被自动转换为 JSON Schema，注入到 LLM 的 system prompt
# 当 LLM 返回 tool_calls 时，LangGraph 的 ToolNode 会：
#   1. 解析 function name 和 arguments
#   2. 路由到对应的 Python 函数执行
#   3. 将结果封装为 ToolMessage 返回给状态

4. 内存管理机制

LangChain 的“Memory”概念在 LangGraph 中被重新定义：

旧方案: ConversationBufferMemory（维护 messages 列表，自动注入 prompt）
                ↓ 演化
新方案: LangGraph 的 State.messages（显式管理，通过 reducer 函数控制行为）

- short-term memory = 单次会话的 messages（在 State 中）
- long-term memory = 跨会话持久化的存储（通过 LangGraph Store API）
- 外部记忆 = 向量数据库中的历史摘要

5. LangSmith 可观测性架构

应用代码（启用 LangSmith tracing）
    │
    │  [POST] /runs   (每个 Runnable 调用自动上报)
    ▼
┌───────────────┐
│  LangSmith    │
│  SaaS 后端    │
├───────────────┤
│ - Trace 树    │  完整的调用链路可视化
│ - 评估        │  自动/人工评估 LLM 输出质量
│ - 数据集      │  管理测试用例
│ - 监控        │  延迟/成本/错误率 dashboard
│ - Prompt Hub  │  Prompt 版本管理
└───────────────┘

技术实现上，LangSmith 通过 Callback 机制在每个 Runnable 的 start/end/error 钩子点上报 telemetry 数据，对应用逻辑零侵入。

技术演进史

技术路线对比

LangChain vs. 竞品框架

选型决策树

你的核心需求是什么？
│
├── “需要高质量 RAG”  ──────▶ LlamaIndex（首选）或 LangChain
│
├── “需要复杂 Agent 工作流” ──▶ LangGraph（首选）或 AutoGen
│
├── “需要快速搭建多 Agent demo” ──▶ CrewAI 或 AutoGen
│
├── “已在微软/Azure 生态” ──▶ Semantic Kernel
│
└── “需要通用框架 + 企业支持” ──▶ LangChain + LangSmith

上下游

上游依赖（LangChain 依赖谁）

┌─────────────────────────────────────────────┐
│                  LangChain                    │
│                                               │
│  依赖层：                                     │
│  ├─ LLM API: OpenAI / Anthropic / Google /   │
│  │           Cohere / 本地模型(vLLM/Ollama)   │
│  ├─ 向量数据库: Pinecone / Weaviate / Chroma  │
│  │             Milvus / Qdrant / FAISS        │
│  ├─ 嵌入模型: OpenAI Embeddings / Cohere /    │
│  │            Sentence Transformers           │
│  ├─ 工具/API: Tavily / SerpAPI / 各类 SaaS    │
│  ├─ 文档加载: Unstructured / PDF/HTML/代码解析 │
│  └─ 云基础设施: LangSmith 后端 / 托管计算      │
└─────────────────────────────────────────────┘

下游用户（谁在用 LangChain）

┌─────────────────────────────────────────────┐
│              LangChain 使用者                  │
│                                               │
│  ├─ 初创公司: 用 LangChain 快速构建 AI 产品    │
│  ├─ 企业 IT: 构建内部知识问答/自动化系统        │
│  ├─ 独立开发者: 搭建 ChatBot / AI 工具        │
│  ├─ AI 平台: 在产品中嵌入 LangChain 作为引擎   │
│  └─ 教育/研究: 快速原型验证 LLM 应用想法       │
└─────────────────────────────────────────────┘

关键指标

供需与市场数据

LLM 应用开发框架市场

需求侧驱动力：

• 企业对 LLM 应用的需求从“demo 验证”转向“生产部署”
• RAG、Agent、自动化工作流成为企业 AI 投入的主要形态
• 2024-2025 年全球企业 AI 应用支出快速增长 [据 Gartner/IDC 等机构估算，具体数据请查最新报告]

供给侧竞争格局：

市场份额心智 [定性估算]

LangChain/LangGraph  ████████████████████░░░░  最高知名度，社区最大
LlamaIndex           ████████████░░░░░░░░░░░░  RAG 领域强劲
CrewAI               ████████░░░░░░░░░░░░░░░░  多 Agent 热度上升
AutoGen              ████████░░░░░░░░░░░░░░░░  微软支持，企业探索
Semantic Kernel      ██████░░░░░░░░░░░░░░░░░░  Azure 用户首选
自研框架/直接调 API   ████████████████░░░░░░░░  大厂多自建，中小厂用框架

关键趋势：

1. 框架趋向统一收敛：开发者不希望学太多框架，头部 2-3 个将吃掉大部分市场
2. 编排层向上竞争：从“帮你调 LLM”到“帮你编排整个工作流”
3. 可观测性成为刚需：LangSmith 的商业化验证了这一判断
4. 直接调 API vs 框架之争：部分高级用户认为框架增加了抽象复杂度，选择直接用 LLM SDK

代表公司与资本映射

对投资者的意义

LangChain 生态的投资映射：

框架层:   LangChain Inc. (私有) ── 关注商业化指标（LangSmith ARR）
向量库:   Pinecone (私有) / Weaviate (私有) / Zilliz (Milvus, 私有)
LLM层:   OpenAI (私有) / Anthropic (私有) / 各上市公司 (MSFT, GOOG, AMZN)
可观测性: LangSmith / Langfuse (开源替代) / Helicone
基础设施: 各云厂商（AWS Bedrock, Azure AI, GCP Vertex）

投资逻辑

看多逻辑

1. 开发框架的网络效应：700+ 集成 → 开发者生态 → 更多集成 → 更多开发者。先发优势+社区规模构成护城河。
2. 开源核心+商业 SaaS 是验证过的模式：类比 MongoDB（开源→Atlas SaaS）、Elastic（开源→Cloud）、Databricks（Spark→平台）。
3. LangSmith 切中生产级痛点：LLM 应用的调试/评估/监控是刚需，一旦被嵌入企业工作流，迁移成本高。
4. LangGraph 差异化：有状态、可中断、多 Agent 编排能力在竞品中相对领先。
5. AI Agent 赛道爆发：如果 2025-2026 年 Agent 应用大规模落地，编排框架是核心受益层。

看空/风险逻辑

1. LLM 供应商可能内置编排能力：OpenAI 的 Assistants API、Anthropic 的 Tool Use、Google 的 Vertex AI Agent Builder 都在蚕食框架层。
2. API 变动频繁，开发者信任成本：LangChain 早期的“破坏性变更”频发导致部分开发者流失。
3. “太多抽象”的批评：部分资深开发者认为直接调 LLM API + 轻量封装（如 Instructor、Pydantic AI）更高效。
4. 收入规模未公开：LangSmith 的 ARR 是否足以支撑估值？企业付费意愿待验证。
5. 框架层的可替代性：编排逻辑并不构成深技术壁垒，开源替代（Langfuse + 自研编排）始终存在。

关键验证指标

• LangSmith 付费客户数与 ARR 增速
• LangGraph Platform 的企业采纳率
• GitHub 活跃贡献者/issue 解决速度
• 与头部 LLM 供应商的深度集成（是否会成为“默认选择”）

常见误读纠偏

误读 1：“LangChain 是一个 Agent 框架”

纠偏： LangChain 是一个通用 LLM 应用开发框架，Agent 只是其中一种应用模式。大量用户用 LangChain 做的是纯 RAG 流程（检索+生成），根本不用 Agent 功能。更准确地说，LangGraph 是 Agent 编排框架，而 LangChain 本身更偏“集成层 + 工具定义 + 检索抽象”。

误读 2：“用 LangChain 就能轻松搭建生产级 AI 应用”

纠偏： LangChain 降低了“从 0 到 1 Demo”的门槛，但从 Demo 到生产仍需要大量工程投入：Prompt 工程调优、评估体系搭建、成本控制、延迟优化、安全防护、错误处理。LangSmith 的存在本身就说明——生产级应用需要远超框架本身的工具链。框架是“脚手架”，不是“成品房”。

误读 3：“LangChain 和 LlamaIndex 是竞品，二选一即可”

纠偏： 两者有重叠但定位不同。LlamaIndex 专精于数据索引和检索，在 RAG 场景下能力更强更深入；LangChain/LangGraph 更关注应用编排和 Agent 逻辑。实际上很多生产项目同时使用两者：用 LlamaIndex 做高质量检索，用 LangGraph 做 Agent 编排。它们不是互斥关系。

误读 4：“LangChain 的抽象层只会增加复杂度，不如直接调 API”

纠偏： 这取决于应用场景的复杂度。如果你的用例是“调一次 LLM 获取回答”，确实不需要框架。但当你需要：对接多个模型供应商、实现复杂的 RAG pipeline、编排多步骤 Agent 工作流、集成多种工具、需要可观测性时，框架的标准化抽象降低的是长期维护成本而非短期开发成本。“框架 vs 直接调用”是一个权衡，不是绝对判断。

学习路径

入门（1-2 天）

1. 通读 LangChain 官方文档的 Quickstart
   → 理解 Chat Models / Prompts / Output Parsers / Chains
2. 跑一个简单的 RAG demo
   → 加载文档 → 分块 → 嵌入 → 检索 → 生成
3. 理解 LCEL（管道运算符 |）
   → prompt | model | parser

参考资料

• LangChain 官方文档：https://docs.langchain.com/oss/python
• LangChain 官方产品页：https://www.langchain.com/langchain