基于 LangChain 官方最新架构与工程实践，结合之前掌握的 "组合电路 / 时序电路"、"DAG / 有环图" 认知框架，从核心本质、架构理念、开发体验、能力边界、工程化等维度进行系统性对比，帮助你在实际项目中做出正确选型。

一、核心本质差异

这是所有区别的根源，决定了两者的设计哲学和能力上限：

表格

维度	传统预定义 Chain	LCEL（LangChain Expression Language）
设计定位	预封装的黑盒组件库：提供开箱即用的固定功能模块	声明式的组合语言：提供原子化的可组合单元，让开发者自由构建任意拓扑
核心思想	组件即应用：一个 Chain 就是一个完整的应用，用户只能配置参数，不能修改内部流程	组合即应用：所有能力拆分为标准 Runnable 接口，通过管道符和并行原语自由拼接
对应电路范式	固定功能的集成电路芯片（如加法器、编码器）	通用的可编程逻辑门阵列（FPGA）
拓扑结构	预定义的固定 DAG，流程硬编码在类内部	开发者自定义的任意 DAG，支持所有串并联组合

二、核心能力对比

1. 灵活性与可定制性

这是 LCEL 相比传统 Chain 最显著的优势：

传统预定义 Chain

• 流程固定：所有执行步骤和顺序都硬编码在 Chain 类的 _call 方法中，用户无法修改
• 扩展困难：只能通过继承重写方法来扩展，代码复杂且容易出错
• 黑盒特性：内部逻辑不透明，无法插入自定义步骤
• 示例限制：RetrievalQA 只能是 "检索→生成" 两步，无法在中间插入重排序、上下文压缩或结果过滤步骤

LCEL

• 完全可编程：可以自由组合串行、并行、分支、嵌套等任意拓扑结构
• 流程自定义：可以在任意位置插入自定义逻辑，修改执行顺序
• 白盒特性：所有步骤都是显式的，开发者完全掌控执行流程
• 示例优势：实现 RAG 可以是 "并行多检索→结果合并→重排序→上下文压缩→提示词→LLM→结果格式化" 的复杂流程

2. 可组合性

传统预定义 Chain

• 组合繁琐：需要使用 SequentialChain、TransformChain 等专门的组合类
• 变量映射复杂：必须手动指定每个子链的输入输出变量映射，容易出错
• 类型不统一：不同 Chain 的输入输出格式不一致，需要大量转换代码
• 嵌套困难：多层嵌套需要层层包装，代码可读性差

LCEL

• 统一接口：所有组件（LLM、提示词、检索器、工具、子链）都实现了 Runnable 接口
• 极简语法：用 | 管道符实现串行，用 RunnableMap 实现并行，语法直观
• 自动变量对齐：输入输出自动传递，无需手动映射
• 无限嵌套：子链和原子节点没有区别，可以任意嵌套组合

3. 调试与可观测性

传统预定义 Chain

• 黑盒调试：只能通过设置 verbose=True 查看简单日志，无法定位具体步骤的错误
• 无法分步执行：不能单独执行某个中间步骤，查看中间结果
• LangSmith 集成有限：只能看到整个 Chain 的输入输出，看不到内部每个步骤的详细信息

LCEL

• 分步调试：可以单独调用任意一个 Runnable 节点，查看其输入输出
• 可视化追踪：与 LangSmith 深度集成，每个步骤的输入输出、耗时、错误、token 用量都能可视化
• 断点支持：可以在任意节点设置断点，暂停执行查看状态
• 错误定位精准：异常信息会明确指出是哪个节点出错，以及出错时的输入数据

4. 性能与并发

传统预定义 Chain

• 串行执行：所有步骤默认串行执行，并行需要自己用多线程 / 多进程实现
• 流式支持差：很多传统 Chain 不支持流式输出，或者支持得很有限
• 批处理能力弱：没有原生的批处理支持，需要自己实现

LCEL

• 原生并行：RunnableMap 中的多个分支会自动并发执行，无需手动管理线程
• 全链路流式：支持从 LLM 到最终输出的全链路流式传输
• 原生批处理：所有 Runnable 都支持 batch() 方法，可以批量处理多个输入
• 异步支持：原生支持异步调用，性能更高

5. 状态管理与记忆

传统预定义 Chain

• 记忆注入式：通过 memory 参数将记忆对象注入 Chain 中
• 记忆类型固定：只能使用预定义的记忆类型（如 ConversationBufferMemory）
• 记忆管理不灵活：无法自定义记忆的过滤、截断、持久化逻辑
• 全局记忆：整个 Chain 共享一个记忆对象，无法实现局部记忆

LCEL

• 记忆包装式：使用 RunnableWithMessageHistory 包装任意 Runnable 来添加记忆
• 完全自定义：可以自定义记忆的存储、加载、过滤、序列化逻辑
• 局部记忆：可以为不同的子链添加不同的记忆对象
• 多会话支持：原生支持多会话隔离，通过 session_id 区分不同用户的记忆

6. 工具调用能力

传统预定义 Chain

• 工具与 Chain 绑定：每个工具对应一个专门的 Chain（如 LLMMathChain、SQLDatabaseChain）
• 多工具组合困难：很难将多个工具组合在一起使用
• 工具调用逻辑固定：工具调用的流程是预定义的，无法修改
• 不支持并行工具调用：只能串行调用多个工具

LCEL

• 通用工具绑定：使用 bind_tools() 方法将任意工具绑定到 LLM 上
• 自由组合工具：可以任意组合多个工具，实现复杂的工具调用流程
• 自定义工具调用逻辑：可以完全控制工具调用的解析、执行、结果处理流程
• 原生支持并行工具调用：可以同时调用多个工具，提高效率

7. 智能体构建能力

传统预定义 Chain

• 预定义智能体类型：只能使用官方提供的几种智能体类型（如 ZeroShotAgent、ReActAgent）
• 智能体流程固定：思考→行动→观察→思考的循环是硬编码的，无法修改
• 无法添加自定义步骤：不能在智能体循环中插入反思、错误处理、规划等步骤
• 能力上限低：只能实现简单的单轮工具调用，无法构建复杂的多智能体系统

LCEL

• 完全自定义智能体：可以自由定义智能体的循环流程和逻辑
• 灵活的步骤组合：可以添加规划、反思、错误处理、人类介入等任意步骤
• 多智能体支持：可以轻松构建多智能体协作系统
• 与 LangGraph 无缝集成：LCEL 节点可以直接作为 LangGraph 的节点，实现有循环、有状态的复杂智能体

三、工程化支持对比

表格

特性	传统预定义 Chain	LCEL
重试机制	需要自己实现装饰器	原生支持 with_retry() 方法
超时控制	需要自己实现	原生支持 with_timeout() 方法
回调系统	支持，但不够灵活	支持更丰富的回调类型，可在任意节点添加
输入输出验证	无原生支持	原生支持 Pydantic 模型验证
序列化与持久化	支持有限，很多 Chain 无法序列化	所有 Runnable 都支持序列化
部署支持	部署复杂，需要专门的包装	可以直接部署为 LangServe 端点
官方维护状态	逐步弃用，不再添加新功能	官方核心，所有新功能优先支持

四、代码示例对比

示例：实现一个简单的 RAG 应用

传统预定义 Chain 写法

python

运行

from langchain.chains import RetrievalQA
from langchain_openai import ChatOpenAI
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

# 初始化组件
llm = ChatOpenAI(temperature=0)
embeddings = OpenAIEmbeddings()
db = FAISS.load_local("faiss_index", embeddings, allow_dangerous_deserialization=True)
retriever = db.as_retriever()

# 构建 RAG 链（流程固定：检索→生成）
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 调用
result = qa_chain.invoke({"query": "什么是 LCEL？"})

LCEL 写法（可自定义流程）

python

运行

from langchain_core.runnables import RunnablePassthrough, RunnableLambda
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

# 初始化组件
llm = ChatOpenAI(temperature=0)
embeddings = OpenAIEmbeddings()
db = FAISS.load_local("faiss_index", embeddings, allow_dangerous_deserialization=True)
retriever = db.as_retriever()

# 自定义提示词
prompt = ChatPromptTemplate.from_template("""
根据以下上下文回答问题：
上下文：{context}
问题：{question}
""")

# 自定义 RAG 流程（可任意扩展）
def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
)

# 调用
result = rag_chain.invoke("什么是 LCEL？")

扩展：在 LCEL 中添加重排序步骤

python

运行

from langchain_community.document_compressors import LLMChainExtractor

# 添加上下文压缩步骤
compressor = LLMChainExtractor.from_llm(llm)

rag_chain_with_compression = (
    {"context": retriever | compressor | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
)

这在传统 RetrievalQA 中需要重写整个 _call 方法才能实现。

五、选型建议

优先使用传统预定义 Chain 的情况

• 快速原型开发，需要在几分钟内搭建一个简单的应用
• 需求非常简单，完全匹配某个预定义 Chain 的功能
• 不需要自定义流程，只需要修改参数
• 维护旧项目，暂时不需要迁移

强烈推荐使用 LCEL 的情况

• 所有新开发的项目
• 需要自定义流程或扩展功能的应用
• 对性能、并发、流式输出有要求的应用
• 需要良好调试和可观测性的生产级应用
• 需要组合多个工具或多个链的复杂应用

需要使用 LangGraph 的情况

• 需要循环、迭代、重试的任务
• 需要状态记忆和反馈回路的智能体
• 需要自主回退和纠错的复杂任务
• 多智能体协作系统

六、迁移指南

官方提供了完整的从传统 Chain 迁移到 LCEL 的指南，以下是常见传统 Chain 的 LCEL 等价写法：

表格

传统 Chain	LCEL 等价写法
LLMChain	`prompt	llm`
SimpleSequentialChain	`chain1	chain2`
SequentialChain	手动映射变量后用 `	` 串联
RetrievalQA	`{"context": retriever, "question": RunnablePassthrough()}	prompt	llm`
ConversationChain	`RunnableWithMessageHistory(prompt	llm)`

七、最终总结

传统预定义 Chain 是 LangChain 早期为了降低入门门槛而设计的黑盒组件，它们提供了开箱即用的功能，但灵活性和可扩展性非常有限。而 LCEL 是 LangChain 架构的一次根本性重构，它将所有能力拆分为标准的 Runnable 接口，通过极简的语法让开发者可以自由组合出任意复杂的拓扑结构。

从本质上讲，传统 Chain 是 "给你一个做好的蛋糕，你只能选择口味"，而 LCEL 是 "给你面粉、鸡蛋、奶油和烤箱，你可以做出任何你想要的甜点"。

对于现在的开发者来说，LCEL 应该是构建所有 LangChain 应用的首选，传统预定义 Chain 只应该用于快速原型和旧项目维护。而当你的应用需要循环、状态和自主决策能力时，再在 LCEL 的基础上引入 LangGraph，形成 "LCEL 做节点，LangGraph 做编排" 的最佳实践。