面经策

什么是 LangChain？ ​

  • 标签：AI、大模型、LangChain

🏛 业务架构师 ​

LangChain 是最流行的 LLM 应用开发框架，一句话定位：大模型时代的"胶水层"集成框架——把模型调用、提示模板、检索、记忆、工具调用、Agent 编排这些通用模式抽象成可组合的组件，让团队不必每个项目从零造轮子。

它解决什么业务问题：企业做 AI 应用，真正的工作量不在调模型 API，而在周边——对接各种数据源、管理提示词、维护对话记忆、做 RAG 流水线、换模型时的适配。LangChain 把这些"脏活"标准化了，一个 5 人团队可以两周出 MVP，而不是两个月。对业务方而言，这就是交付周期的缩短和试错成本的降低。

2026 年现状：LangChain 生态最全（社区组件最多、资料最丰富），但也因为抽象层多被诟病"黑盒重、排错难"。我的使用建议分阶段：POC 期用 LangChain 快速验证价值——它的价值在"快"；生产期则控制依赖面，核心链路可以只用它最底层的模型抽象甚至直连 SDK，避免框架升级带来的连锁返工。框架是租来的，业务资产（提示词、评测集、数据管道）才是自己的。

🏗 系统架构师 ​

LangChain 是当前生态最完整的 LLM 应用编排框架：把模型调用、Prompt 模板、检索、记忆、工具、Agent 逻辑抽象成可组合组件，用统一接口屏蔽上百个模型/向量库/API 的差异。

我按架构视角拆它的价值：

  • 适配层价值（最大）：Model I/O、VectorStore、DocumentLoader 的统一抽象 = 依赖倒置，换模型/换向量库只改配置——在没有标准的领域这一点极其务实；
  • 编排层价值：LCEL（声明式管道表达式）和 LangGraph（图状态机）提供从简单 chain 到复杂 Agent 的编排能力；
  • 生态价值：集成数量决定 PoC 速度，一天能搭出 RAG 原型。

清醒的部分（生产权衡）：抽象是有代价的——层数多导致调试栈深、某些版本迭代快接口不稳、默认实现未必性能最优。所以我的实践是PoC 用 LangChain 抢速度，生产核心链路做减法：稳定路径抽成自己的薄封装，关键性能点（检索、流式、并发）绕过框架直接写。

一句话：LangChain 解决的是"LLM 应用没有统一编程模型时期的碎片化问题"，2026 年它和 LangGraph 的组合仍是默认起点，但生产化要主动控制它带来的间接层。

💻 全栈开发专家 ​

LangChain 是最主流的 LLM 应用开发框架，一句话：把「调模型 + 接数据 + 编排流程 + 记忆管理 + 工具调用」这些通用脏活抽象成统一接口，让你专注业务而不是胶水代码。

它解决的核心痛点：

  1. 模型可替换：ChatOpenAI 换 QwenChatModel 业务代码不动，避免厂商锁定；
  2. 组件齐全：文档加载、切分、Embedding、几十种向量库、检索器、输出解析、Agent 工具，全是现成集成；
  3. 编排能力：LCEL（管道表达式）和 LangGraph（状态机）把 prompt→检索→生成串成可流式、可重试、可观测的流水线。

一个最小 RAG 就是三行核心：

python
retriever = vectorstore.as_retriever()
chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt | model | StrOutputParser())
chain.invoke("退货政策是什么")

我的态度：原型期 LangChain 极快，生产期建议只用 langchain-core 的轻抽象 + 自研关键链路——它的抽象层多、版本迭代快（0.1→0.3 破坏性变更不少），全盘依赖升级时很痛苦。Java 团队可以直接看 LangChain4j 或 Spring AI，设计更克制。