LangChain核心概念#

核心组件（经典六件套）：

• Model：LLM 调用封装（1.x 用 content_blocks 统一各家的推理过程、引用、工具调用等内容）
• Prompt Template：提示词模板
• Chain：多步骤流水线（1.x 中旧版 Chain 实现移到 langchain-classic，组合逻辑用 LCEL 或 LangGraph）
• Agent：基于 LLM 决策的工具调用（1.x 标准入口是 create_agent）
• Memory：对话历史管理（1.x 的 Agent 靠 LangGraph checkpointer 按线程保存历史）
• Retriever：RAG 检索器

LCEL（LangChain Expression Language）： 声明式链构建 prompt | llm | parser，统一 invoke/stream/batch/async 接口，仍在 langchain-core 中。

LangChain 1.x 的变化：

LangChain是目前最主流的LLM应用开发框架，它把构建LLM应用的常见模式抽象成六大组件。Model是对各种LLM的统一封装，屏蔽不同API的差异。Prompt Template是提示词模板，支持变量替换，避免硬编码Prompt。Chain把多个步骤串成流水线，比如先检索再生成。Agent是最核心的概念——让LLM自己决定调用哪个工具，实现了从”被动回答”到”主动执行”的跨越。Memory管理对话历史，支持滑动窗口、摘要等策略控制上下文长度。Retriever是RAG的检索接口，对接向量数据库做相似度搜索。LCEL是声明式的链构建语法，用管道符连接组件：prompt | llm | parser，代码简洁直观。到了1.x，LangChain把重心收到Agent上：用create_agent建Agent，它底层跑在LangGraph上，自带持久化和人工介入；横切逻辑比如脱敏、历史压缩、审批用middleware插进循环；旧的Chain实现挪进了langchain-classic。不过LangChain的抽象层有时过重，简单场景直接调SDK可能更合适。

追问方向：

• LangChain 的 LCEL 和传统 Chain 有什么区别？解决了什么问题？ → LCEL 用管道符 | 声明式组合组件，支持流式/批量/异步统一接口。解决了传统 Chain 类爆炸（每种组合写一个类）的问题
• LangChain 和 LangGraph 什么时候用哪个？ → 线性流程用 LangChain（检索→生成），需要条件分支/循环/人工审批用 LangGraph（显式状态图）；1.x 的 create_agent 已经跑在 LangGraph 上，预置 Agent 不够用时再手写图
• 为什么选/不选 LangChain？ → 看技术栈和定制深度：Python 栈、要快速搭原型选它；Java 栈可选 Spring AI（Function Calling 与 MCP 原生支持）；需要精细控制每一步时，LangChain 的抽象层可能成为障碍，可下沉到 LangGraph 或自研。结合项目时可以讲：选型时比较了哪几个方案、在哪一层做了取舍
• LangChain 调试困难时怎么排查？ → 开启 verbose/debug 看每步输入输出，用 LangSmith 做链路追踪，关键是理解底层 ReAct 原理才能定位是 Prompt 问题还是工具问题
• 1.x 的 middleware 解决什么问题？ → 把脱敏、历史压缩、人工审批这类横切逻辑挂到 Agent 循环上，不用改 Agent 主体或手写图节点

易错点：

• ❌ 过度依赖框架封装不理解底层 → 出问题时需要看框架源码排查，不理解 ReAct 原理就无法 debug Agent 行为
• ❌ 所有场景都用 LangChain → 简单的 API 调用直接用 SDK 更清晰，框架适合复杂编排场景
• ❌ 认为 Python 框架是唯一选择 → Java 生态有 Spring AI，Go 有 LangChainGo，选型要看团队技术栈
• ❌ 还在新代码里用 AgentExecutor / 旧版 Chain 类 → 1.x 新代码用 create_agent，旧实现在 langchain-classic 里只为兼容保留