先这样答
LangChain 的核心组件可以分为模型交互、数据处理和代理增强三个层次。模型交互层包含统一的模型接口（ChatModel）、提示模板以及将模型输出转化为结构化数据的输出解析器（OutputParser）。数据处理层主要围绕检索增强生成场景，提供文档加载、文本切分和检索器（Retriever）。代理增强层则包含用于扩展模型能力的工具（Tool）以及用于多轮对话状态管理的记忆（Memory）。
LCEL 全称是 LangChain Expression Language，是 LangChain 推出的一种声明式语法。它的核心机制是通过管道操作符将不同的组件按数据流向连接起来，例如将提示模板、模型和输出解析器组合成一条执行链。这种设计的目的是替代过去繁杂的旧 Chain 类子类，让开发者用更直观的方式完成组件编排。更重要的是，LCEL 在底层统一了执行接口。开发者定义好一条链后，可以直接调用同步、异步、批量处理或流式输出的方法，而不需要为每种执行方式单独编写底层逻辑。
在实际的生产环境中，LangChain 的核心价值体现在其庞大的第三方集成层和开箱即用的组件。对于简单的线性任务，使用 LCEL 快速串联组件效率很高。但如果遇到需要编排复杂状态、多分支或循环逻辑的场景，直接使用基础组件会显得受限，通常需要引入 LangGraph 来处理。如果项目有深度定制的需求，完全可以只抽取需要的特定组件，避免被整个框架绑定。
面试官会怎么追问
-
「处理复杂的多步 Agent 逻辑时，使用 LCEL 有什么局限性？」 LCEL 主要适用于线性的管道组合，当需要处理带有循环、复杂条件分支和全局状态维护的逻辑时，管道式声明的表现力不足。这种情况下代码的可读性和调试难度会增加，因此需要使用 LangGraph 以图结构来定义复杂的状态机。
-
「如果业务只需要做简单的文档检索和问答，一定要引入完整的 LangChain 吗？」 不需要。过度引入重型框架会增加依赖管理和代码排错的成本。在简单场景下，可以只使用 LangChain 的文档加载器或文本切分器等独立数据组件，而模型调用和提示词拼接完全可以使用原生 SDK 手写，以保持系统的轻量与可控。
-
「LCEL 是如何实现端到端的流式输出的？」 LCEL 通过统一定义的 Runnable 接口规范了各个组件的输入输出标准。当调用流式接口时，底层组件会以生成器的方式逐块产生数据，并通过管道实时传递给下一个组件，从而实现从大模型端到解析端的数据流转。
回答的坑
- 认为开发大模型应用必须重度依赖 LangChain，实际上很多生产环境为了稳定性和可调试性，会选择手写核心控制流，仅把 LangChain 当作工具箱使用。
- 解释 LCEL 时只提到了通过管道符拼接代码，没有指出其在统一同步、异步和流式执行接口方面的核心设计优势。
同系列的题