LangChain 的核心组件有哪些？
- 标签：大模型、AI、Agent、LangChain
🏛 业务架构师
LangChain 核心组件我按一条 RAG 应用的组装顺序来讲：
- Model I/O：ChatModel（模型统一接口，一行代码换供应商）、Prompt Template（提示模板化管理）、Output Parser（把输出解析成结构化数据）。
- Retrieval / Loader：DocumentLoader（加载 PDF、网页、Confluence 等）、TextSplitter（文档切分）、Embeddings + VectorStore（向量化与向量库接入，支持 Milvus、Chroma 等）。
- Memory：对话记忆（会话历史、摘要记忆），支撑多轮对话。
- Tools / Agents：Tool 封装外部能力（查库存、调 API），Agent + AgentExecutor 让模型自主决定调用哪个工具、循环执行直至完成任务。
- LCEL（LangChain 表达式语言）：用管道式声明组合链路（如
retriever | prompt | model | parser），天然支持流式、并行、重试。 - LangSmith：配套的可观测与评测平台，追踪每步的输入输出和延迟成本。
业务视角：这套组件清单其实就是 LLM 应用的"能力采购单"——评估团队要不要用 LangChain，本质是评估自研这些抽象层值不值。我的答案：除非有特殊合规或性能要求，先用它换速度，等业务跑起来再决定哪些环节替换为自研。
🏗 系统架构师
LangChain 核心组件我按数据流分层讲，这比背清单好记：
- I/O 层：
ChatModel（模型抽象）/PromptTemplate（模板）/OutputParser（输出解析）——负责"进 Prompt、出结构"； - 检索层：
DocumentLoader（加载）、TextSplitter（分块）、Embeddings+VectorStore（向量化与存储）、Retriever（检索抽象）——RAG 的四件套； - 记忆层：Memory / ChatMessageHistory（多轮上下文，1.0 后向 LangGraph 持久化收敛）；
- 编排层：LCEL 表达式（
|管道组合 Runnable），LangGraph（状态图，复杂 Agent 的事实标准）； - Agent 层：Tool（工具抽象）、AgentExecutor / LangGraph 的 agent loop（决策循环）；
- 观测层：Callback（回调钩子，接 LangSmith 等 tracing）。
架构解读：这套组件本质是"管道-过滤器"架构风格——每个组件实现 Runnable 接口，串成数据流水线，好处是可组合、可替换、可插桩（Callback 统一埋点）。生产上我重点审计三处：OutputParser 的失败重试策略、Retriever 的权限过滤位置、Callback 的 tracing 采样率（全量 trace 成本不低）。
💻 全栈开发专家
按 0.3 之后的包结构说，核心组件分四块：
- 模型 I/O：ChatModel/LLM（对话与补全）、EmbeddingModel、PromptTemplate（模板渲染）、OutputParser（结构化解析）。
- 检索（RAG 三件套）：DocumentLoader（PDF/HTML/Notion 等）、TextSplitter（分块）、VectorStore（Milvus/PGVector/Redis…）+ Retriever 抽象（可插拔检索策略）。
- 编排：LCEL（Runnable 管道，
|串联、RunnableParallel并行、内置流式/重试/回退）；复杂流程交给 LangGraph（状态图、循环、checkpoint）。 - Agent 体系：Tool（
@tool定义）、AgentExecutor（循环执行）、Memory（0.3 已弱化，改为RunnableWithMessageHistory+ LangGraph checkpointer 做持久化）。
结构认知：langchain-core 是地基（抽象+LCEL），langchain-community 放第三方集成，partner 包（langchain-openai 等）官方维护，LangGraph 独立演进。写代码时依赖越少越稳，我生产项目只引 core + 具体 partner 包。
排坑提醒：网上老教程里 LLMChain、ConversationBufferMemory 都是废弃 API，新项目直接 LCEL + LangGraph，别抄旧代码。