面经策

LangChain 核心架构是什么样的 ​

  • 标签：大模型、AI、Agent、LangChain

🏛 业务架构师 ​

LangChain 的核心架构是"分层抽象+可组合"：

底层是 Model I/O——统一封装各厂商模型的调用接口，向上屏蔽差异；中间是能力层——Retrieval（文档加载/切分/向量化/检索）、Memory（对话记忆）、Tools（外部工具封装）；再往上是编排层——先是 Chain（固定流水线，LCEL 声明式组合），后演进为 LangGraph（把应用建模为状态图/状态机，支持循环、分支、多 Agent 协作，是当前官方主推）；最外是运行时层——AgentExecutor 驱动"模型决策→调工具→观察→再决策"的循环。配套 LangSmith 做链路追踪与评测，LangServe 做服务化部署。

业务视角解读：这个架构演进史就是 LLM 应用复杂度升级史——Chain 解决"流水线式"应用（RAG 问答），Graph 解决"有状态、会循环"的应用（Agent、工作流审批）。对企业来说启示很明确：业务流程越复杂、越多分支回退，越应该直接上 LangGraph 而不是用 Chain 硬拼。同时要认识到框架只是脚手架，架构上真正要自己守住的是模型路由层和数据资产层——这两层决定了换框架、换模型时的迁移成本。

🏗 系统架构师 ​

LangChain 的核心架构可以用一句话概括：一切皆 Runnable 的管道-过滤器体系，外层用 Callback 体系横向切观测。

纵向（执行模型）：PromptTemplate、ChatModel、Retriever、OutputParser、Tool 都实现 Runnable 接口（invoke/stream/batch 三方法），因此任意组件可以用 | 管道符组合，LCEL 把链式调用编译成一个可统一调度的执行单元——支持流式透传（streaming 从模型一路透到前端）、并行（fan-out/fan-in）、异步批量。这是它的架构精髓：接口统一带来组合自由。

横向（横切关注点）：Callback 体系在每步执行前后发事件，tracing、打点、审计都挂在这层，不需要侵入业务链。

Agent 执行模型：AgentExecutor 是"LLM 决策 + 工具执行"的循环（ReAct 类），复杂场景迁到 LangGraph——显式状态机图，节点是步骤、边是转移，支持循环、分支、中断恢复、人工介入，还内置 checkpoint 持久化。

架构师评价：统一抽象是双刃剑——组合性强、切换成本低；但间接层多、栈深难调试、性能热点不透明。我的生产策略：核心链路薄封装自持，LangChain 用在集成层和 PoC，LangGraph 用在需要状态机语义的 Agent 编排。

💻 全栈开发专家 ​

LangChain 现在的架构是分层包结构，这点搞清楚后看代码就不迷路了：

  • langchain-core：地基。定义 BaseChatModel、BaseRetriever、Runnable 等抽象和 LCEL 表达式。Runnable 是灵魂——所有组件（prompt、模型、解析器、检索器）都实现 Runnable 接口，所以能任意 | 拼接，并自动获得 stream/batch/async/重试能力。
  • langchain-community：社区集成大杂烩（几百个 loader、向量库 wrapper）。
  • partner packages：官方与厂商共建（langchain-openai、langchain-milvus），版本独立发布。
  • langgraph：图编排引擎，节点+边+共享 State，支持循环/分支/持久化/human-in-the-loop，Agent 场景的事实标准。
  • langsmith：观测评估（tracing、数据集、评测），生产必备。
LangGraph(复杂编排/Agent)
   └─ langchain-core: Runnable + LCEL(管道) + 抽象接口
        └─ partner/community: 模型、向量库、loader 集成

架构特点：一切皆 Runnable、组合优于继承、流式是一等公民。选型建议：简单链 LCEL 够用；有循环决策（Agent、自适应 RAG）上 LangGraph；依赖只引 core+partner，少踩 community 的质量参差。