【LangChain】传统Chain与LCEL链对比：从langchain.chains到langchain_core的迁移指南

1. 传统Chain与LCEL链：从设计哲学到实战差异

第一次接触LangChain时，我像大多数人一样从langchain.chains模块开始。那些预置的LLMChain、RetrievalQA确实解决了燃眉之急，但真正投入生产环境后，我发现这些传统Chain就像乐高说明书里的固定模型——能快速拼出示例造型，却难以应对千变万化的业务需求。直到LCEL（LangChain Expression Language）出现，才真正体会到什么叫"自由拼搭"的快乐。

传统Chain的核心问题在于强耦合性。以最常见的LLMChain为例，要修改一个输出处理逻辑，往往需要继承父类重写方法。去年我们团队维护的客服系统就遇到过这种尴尬：当需要给AI回复添加审核步骤时，不得不为每个Chain子类添加重复代码。而LCEL采用|操作符的管道风格，让每个处理步骤变成可插拔的模块，就像下面的对比：

# 传统LLMChain改造前
class CustomChain(LLMChain):
    def _call(self, inputs):
        result = super()._call(inputs)
        return audit_filter(result)  # 硬编码的审核逻辑

# LCEL实现方式
chain = prompt | llm | audit_filter  # 审核步骤可动态替换

灵活性差异在异步处理场景更为明显。传统Chain要实现流式响应需要重写整个调用链路，而LCEL原生支持：

# 传统方式需自定义异步逻辑
async def stream_response():
    # 复杂的手动异步控制...

# LCEL直接使用
async for chunk in chain.astream(input_d