很多人第一次打开 LangChain 的文档都会被那一大堆 Module 名字吓到——模型、提示词、链、记忆、检索、代理、回调好像每个都能单独写一本书。但如果你退一步看LangChain 其实只做了一件事把大模型和各类外部能力串联起来。而实现这个价值的核心就是标题里那六个核心组件。它们各司其职像搭积木一样能帮你快速拼出复杂的 LLM 应用。这篇文章我就打算把这六块积木一块一块摆开讲清楚它们各自管什么、怎么用、以及拼在一起时接口是怎么咬合的。适合刚接触 LangChain 不久、想系统理解组件逻辑的人也适合已经跑过一些 Demo 但总觉得“差点意思”的开发者。我在这里把六大组件按自己的理解做了一个拆分Model、Prompt、Chain、Memory、Retrieval、Agent含 Tool。官方的文档有时候会把 Callback 也算进来但站在应用串联的角度上面这六个才是每天真正在打交道的东西。下面正式开始。1. 为什么 LangChain 把“串联”当成头等大事1.1 LLM 应用的根本矛盾模型是“单次思考的”业务是“多步协作的”大部分 LLM 产品不是你输入一句话、它回复一句话那么简单。一个稍微像样的应用往往要经历这样的流程先检索知识库把相关上下文找出来拼进提示词接着让模型做判断然后可能需要查一个外部接口拿到实时数据最后再组织语言回复用户。这一整套流程里模型本身只参与其中某一步前后都要靠外部代码来协调。这就引出了 LLM 应用的根本矛盾模型调用本质上是一个无状态的、单次的输入输出过程而真实业务天然是多步、有状态、需要外部协作的。你当然可以用最原始的 requests 或者原生 SDK 把每一步都手写出来但一旦场景复杂起来比如要给同一个模型包装多套提示词、要在多个模型之间切换、要记录几十轮对话、要动态决定下一步调用哪个工具纯手写的代码就会迅速长成一团乱麻。LangChain 的出现正是为了解决这个矛盾。它不生产模型也不替代模型它做的是在模型和你之间的业务逻辑之间铺一层标准的“管线层”。这层管线定义了消息格式、调用接口、数据流转方式让不同的模型、不同的工具、不同的记忆策略可以被纳入同一套串联体系。1.2 组件化的本质定义接口而不是定义实现我见过不少人初学 LangChain 时会有一个误解觉得它是某种“超级框架”什么功能都内置好了。其实 LangChain 更准确的定位是一套组件协议加一堆参考实现。每个组件都对外暴露标准接口至于底层是调哪家模型、存哪个向量库、用哪种切分算法都是可替换的实现细节。这种设计的最大好处是让“串联”本身变得标准化。无论你后面是把底层模型从 A 换到 B还是把向量库从云端换成本地上层业务代码基本不用改。这也是为什么很多人说 LangChain 的价值不在某一个组件而在于组件之间那些已经定义好的接口和编排方式。理解这一点之后你再去看六大组件心里就会有一张地图每个组件解决一类问题组件之间靠“输入输出契约”衔接而 Chain 和 Agent 就是两种不同粒度的编排器。2. 六大组件逐个拆解各自管什么、怎么用2.1 Models统一模型接入层让换模型像换插头Models 组件解决的是最底层的接入问题。大模型不是一个而是一群。各家有各家的接口风格有的传字符串返回字符串有的传消息数组返回消息对象有的支持流式输出有的支持工具调用token 计算方式也各不相同。如果你的业务代码直接依赖某一家 SDK后面每一次模型升级或者换供应商都是一次伤筋动骨的改动。LangChain 通过 Model 层把这种差异屏蔽掉了。你写业务逻辑的时候面向的是一个统一的“模型接口”只需要在初始化的时候指定具体用的是哪家模型、哪个版本。下面是一段很典型的用法from langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o-mini, temperature0.2, api_keyos.environ.get(OPENAI_API_KEY), )这里有几个实际使用中容易忽略的点。第一temperature不是每个任务都适合调高。如果是做检索问答、工具调用这类偏确定性的场景我会习惯把它控制在 0 到 0.3 之间如果是做头脑风暴、文案生成才会放到 0.7 以上。第二不是所有模型都支持“工具调用”能力。如果你后面要接 Agent选模型时务必确认它支持 function calling否则 Agent 的决策循环会变得很不稳定。第三模型层的抽象虽然能统一接口但不能完全抹平各家模型的能力差异换模型之后必须重新跑一遍关键链路做验证不要默认“能跑就等于效果一致”。2.2 Prompts提示词工程从“硬编码”升级为“模板化管理”模型接进来之后紧接着的问题就是每次调用时提示词从哪来最原始的做法是在代码里拼字符串比如f你是客服用户的问题是{question}。这在 Demo 阶段没毛病但项目一旦复杂你会发现提示词散落在各个文件里想统一调个语气、加个限定规则得全局搜索替换而且每次改动都可能引入格式错误。Prompts 组件把提示词变成了可声明、可复用、可组合的模板。它的核心抽象是ChatPromptTemplate用来管理不同角色的消息序列。常用的写法长这样from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是一个严谨的金融分析助手只能基于给定的资料回答不能编造数据。), (human, 用户的问题是{question}), (ai, 好的请稍等我正在分析。), (human, 请给出最终答案并标注数据来源。), ])这里你可能注意到了消息序列里可以有 System、Human、AI 三种角色甚至可以在中间插入一段“AI 的预设回复”用来引导模型的行为模式。模板里的{question}是变量槽真正调用时再传入具体值。这样做的好处是提示词和代码解耦了你可以把模板单独维护甚至放到配置文件里让非开发人员一起参与调整。实操上我还有一个建议不要在 Prompt 模板里堆砌太长的规则。模型对超长提示词的遵循度并不是线性的规则写太多反而容易互相干扰。更合理的做法是把必须遵守的硬性约束放 System把当前任务的具体背景放 Human把需要模型逐步思考的引导放 Assistant 的历史消息里各司其职。2.3 Chains最小执行单元与管道式编排Chains 是 LangChain 里最核心的编排工具。它的设计目标特别朴素把“提示词模板 模型 输出解析”这样一组固定操作封装成一个可复用的执行单元然后再把这些单元像管道一样串起来。旧版的写法是通过LLMChain类来包装新版本我强烈建议直接用 LCELLangChain Expression Language也就是管道符|的写法。它的表达能力更强代码也更短from langchain_core.output_parsers import StrOutputParser chain prompt | llm | StrOutputParser() result chain.invoke({question: 去年第四季度的营收趋势如何})这条管道的含义是把question传给prompt生成消息列表再把消息列表交给llm得到模型原始输出最后用StrOutputParser把输出里的文本内容提取出来。整个过程一气呵成而且每一步的输入输出都是明确定义的方便单独调试。在实际项目中我不会一上来就写一条很长的管道。我的习惯是先分别构建小的 Runnable比如retriever、prompt、llm、parser各自验证没问题之后再用管道符拼装。拼装的时候可以借助RunnablePassthrough做数据透传也可以借助RunnableBranch做条件分支这样链条再长也不会乱。需要提醒的是Chain 非常适合“流程固定”的场景。如果你的应用里每一步要做什么是明确的、不需要模型自己决定那就应该用 Chain而不是用 Agent。控制越少的方案越稳定也越省钱。2.4 Memory让应用从“金鱼记忆”变成“连续对话”模型本身不保存任何历史信息。你每次调用它它都在“失忆”状态下重新开始。对于多轮对话类应用这就很致命用户上一轮刚说了自己的情况下一轮模型就忘了体验非常割裂。Memory 组件就是在这里补位的。Memory 的职责可以概括为一句话在调用模型之前把应该被“记住”的历史信息取出来塞进提示词里。LangChain 提供了多种记忆策略我整理了一个对比表方便你按场景选择记忆类型核心思路适合场景主要缺点ConversationBufferMemory把全部历史对话原样保存并注入对话轮数少、历史短很快会撑爆上下文窗口ConversationBufferWindowMemory只保留最近 N 轮对话大多数客服、助手类场景更早的关键信息会丢失ConversationSummaryMemory用模型把历史摘要成短文本长会话、需要长期记忆摘要本身有信息损耗、多一次模型调用VectorStoreRetrieverMemory按相关性召回历史片段知识库型助手、跨很多轮找关键信息实现较重需要向量检索我实际用下来最简单的多轮对话场景用BufferWindowMemory就足够了窗口设在 6 到 10 轮比较合适。窗口太大提示词被历史对话占满模型回答质量反而下降窗口太小用户会觉得你没记住他说的话。如果你的应用是那种“用户聊了几十轮之后再反问早期信息”的类型那就要考虑用向量检索式记忆把“历史”当成一个可以被检索的知识库来对待。还要提醒一点记忆不是越多越好。上下文窗口是有限的宝贵资源每一轮对话都把全部历史原样塞进去是最懒也是最贵的做法。对长会话做摘要或者只保留关键决策信息往往比“全量保存”效果更好成本更低。2.5 Retrieval把外部知识变成模型能“查”的上下文Retrieval 组件解决的问题是怎么让模型知道它训练数据之外的信息。无论是企业内部知识库、产品文档、还是随时都在更新的网页资料模型都不知道。Retrieval 的流程就是一套“外部知识进水管”加载文档、切分成块、向量化、存入向量库、按相似度召回。标准链路大致是这样from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs splitter.split_documents(raw_docs) vectorstore FAISS.from_documents(docs, OpenAIEmbeddings()) retriever vectorstore.as_retriever(search_kwargs{k: 4}) relevant_docs retriever.invoke(季度营收下降的原因是什么)这里面的两个参数非常关键。chunk_size是每一块切多大chunk_overlap是相邻两块重叠多少字符。很多初学者喜欢把块切得很小以为这样检索更精确但实际上块太小会导致语义不完整模型拿到的是一段缺头缺尾的碎片块太大则容易混入无关内容降低召回精准度。我的经验是按文档结构切而不是死板地按字符数切。有标题的按标题分有段落的按段落分代码按函数分纯文本再用递归切分器兜底。检索之后的“后处理”也很重要。直接把 Top k 个结果全部拼进提示词经常会让模型被不相关片段带偏。更稳妥的做法是加一步相关性过滤比如设置 score 阈值或者再套一层 Rerank 模型对召回的候选做二次排序。这一步对问答质量的提升往往比换一个更强的大模型还要明显。2.6 Agents 与 Tools让模型从“只能聊天”变成“能动手干活”如果说 Chain 是“固定流程的执行者”那么 Agent 就是“临场决策的执行者”。它会根据当前任务自己决定先做什么、后做什么、要不要调用某个外部工具、以及如何根据工具返回结果继续推进。这一层把 LLM 应用从“问答”推向了“行动”。举个例子用户问“帮我查一下北京明天的天气然后根据天气建议一下出行穿衣”。如果模型没有天气数据光靠它自己的知识是答不准的。正确的做法是定义好一个天气查询工具然后把“查天气”这件事交给 Agent 去调度。工具的定义可以用tool装饰器标注from langchain_core.tools import tool tool def get_weather(city: str, date: str) - str: 查询指定城市在指定日期的天气情况返回格式为文本描述。 # 这里接入真实的天气服务 return 北京明天晴气温 -2℃ ~ 8℃北风3级。工具定义里最重要的不是函数内部怎么实现而是那段文档字符串。Agent 选不选这个工具、传什么参数进来主要靠读描述来判断。描述写得模糊Agent 就会瞎猜参数描述写得清楚Agent 的调用准确率会明显上升。我见过太多次因为工具描述写得敷衍导致 Agent 反复传错参数、来回折腾的情况。有了工具之后再用 Agent 把它们组合起来。LangChain 新版推荐用create_tool_calling_agent配合AgentExecutor来跑from langchain.agents import create_tool_calling_agent, AgentExecutor agent create_tool_calling_agent(llm, tools, prompt_with_scratchpad) executor AgentExecutor(agentagent, toolstools, verboseTrue) executor.invoke({input: 北京明天天气怎么样适合穿什么出门})这一步跑通之后你会真正感受到“串联”的威力模型负责推理和决策工具负责获取外部信息AgentExecutor 负责循环调度直到得出最终答案。不过威力越大越要控制好边界。Agent 的循环是有代价的每一步都在消耗 token也都有可能出现推理偏差。务必要设置max_iterations上限并且在关键操作上保留人工确认的入口。3. 把六块积木拼成一个可用的智能助手3.1 一个综合场景带记忆、能检索、能动手的问答助手前面讲了很多组件它们单独拿出来都不复杂真正的价值在于组合。我拿一个亲身搭过的模拟项目举例一个“企业知识库 实时工具”的问答助手。用户可以向它询问内部制度文档内容也可以让它帮忙查外部信息、做简单计算。整个系统用到的组件如下Models统一接入一个支持工具调用的对话模型Prompts定义一套包含 System 约束、人工问题、工具结果、模型中间推理的完整消息模板Retrieval把企业内部文档切分、向量化、建立检索器Memory把最近几轮对话摘要注入上下文保证连续性Chains用 LCEL 编排“检索 → 拼接资料”的前置流程Agent 与 Tools把检索器本身封装成一个工具再挂一个天气查询工具交给 Agent 统一调度。这个组合里最值得玩味的是“检索器也能当工具”。当任务是“查资料”时Agent 会主动选择调用检索工具拿回的文档片段再交给模型做总结。这样做的好处是Agent 可以自己判断什么时候需要检索、什么时候不需要比每次提问都强行检索一遍要智能很多。3.2 各组件之间的接口是怎么咬合的组件的拼接并不是随便塞在一起就行它们之间有明确的“数据协议”。Retrieval 的输出是一组 Document 对象要喂给 Prompt得先把page_content拼接成文本。Prompt 的输出是消息列表模型吃进去、吐出来一个AIMessage。如果后面还要接 Agent 的工具调度模型输出的AIMessage里会携带tool_calls字段里面写着“我要调用哪个工具、传什么参数”。AgentExecutor 正是解析了这个字段才去执行对应的工具函数再把工具返回的文本继续追加到消息序列里形成下一轮推理的输入。这套循环本质上就是一个消息列表的不断增长System 指令不变Human 的问题是原始输入Agent 的中间推理作为 Assistant 消息工具返回结果作为 Tool 消息一路追加直到模型不再要求调用工具、直接给出最终答案。理解了这个循环你再看 Agent 相关的源码就不会觉得它有多玄乎了。3.3 一次多步交互的完整过程我把上面那个助手的实际运行过程简化为几个步骤。假设用户输入“帮我查一下明天北京天气顺便看下我们公司的请假制度里病假需要什么材料”。第一步AgentExecutor 接收输入把历史记忆摘要、用户问题一起拼进 Prompt然后调用模型。第二步模型分析后认为需要两个外部信息于是输出两个tool_calls一个调用天气工具传参 city“北京”另一个调用检索工具搜索关键词“病假 所需材料”。第三步AgentExecutor 依次执行这两个工具把各自的返回文本追加为 Tool 消息。第四步再次调用模型模型拿到天气结果和检索到的制度片段整合成一段自然语言回答。第五步回答返回给用户同时这段问答被写入记忆模块供后续对话使用。整个过程里“串联”的痕迹非常清晰。模型是大脑工具是手脚检索是眼睛记忆是前额叶LangChain 就是把这些器官连接到同一套神经系统上的那层组织。4. 实际跑过之后组件边界、选型与最常见的坑4.1 明确组件之间的责任边界别让 Agent 干 Chain 的活我见过不少项目上来就把所有逻辑都塞给 Agent似乎什么功能都能让模型“自主决策”。但自主决策是有代价的每一次决策都是一次模型调用都有失败概率都会增加时延和成本。如果你的业务流程是固定的比如“先检索、再总结、最后格式化输出”那就老老实实用 Chain 串起来又快又稳。反过来如果业务里确实存在“根据用户意图选择不同工具”的情况才值得引入 Agent。这里我给自己定的判断标准很简单分支少于三条、流程固定走 Chain工具多、意图不可预判、需要动态编排时走 Agent。把 Agent 用在它该用的地方它才是好工具滥用 Agent它只会变成你账单上的黑洞。还有一点是关于工具内部的实现。工具函数应该只做“获取信息”或“执行动作”这一件事不要在里面堆砌业务判断逻辑。业务逻辑应该放在 Prompt 的规则里或者放在 Agent 外围的控制层里。工具保持单一职责Agent 才不会乱套。4.2 上下文窗口是硬约束记忆和检索都要“精打细算”上下文窗口是有限的而记忆、检索结果、中间推理都会抢占这部分空间。我踩过最典型的坑是记忆里存了太多历史结果用户当前问题的关键信息反而挤不进上下文模型表现断崖式下跌。现在我给自己定了一条预算规则System 指令占 20% 以内历史记忆压缩后占不超过 30%检索到的资料最多占 40%剩下的留给模型输出和工具调用结果。如果某个环节超了就先压缩它而不是盲目升级更长上下文的模型。检索结果的长度同样要控制。只取最相关的几条还不够还要对每一条做截断。我的习惯是每个召回的 Document 截取到 800 到 1200 字以内宁可信息少而精不可多而杂。对结果做一次 “压缩成要点” 的 LLM 调用通常在长文档场景下比直接堆原文效果好得多。4.3 版本变化快调试排查时先确认 API 基线LangChain 的迭代速度很快网上教程满天飞但很多帖子已经过时了。拿调用链路的接口来说旧版本你可能见过chain.run()、executor.run()新版本几乎所有组件统一收敛到了invoke()。如果不先确认你安装版本的 API 风格照着一个老教程抄代码大概率会撞一鼻子灰。排查问题时我习惯按三层来定位先确认组件本身的输入输出是否符合预期再确认组件拼接处的数据格式有没有对齐最后才怀疑模型能力或提示词策略。官方提供的 trace 工具我非常推荐它能把一次请求的完整链路展示出来——每个组件在哪个环节、吃进了什么、吐出了什么一目了然。遇到 Agent 行为诡异翻 trace 记录往往比盯着控制台日志猜要高效得多。4.4 我汇总的常见坑检查清单现象根因处理方式Agent 反复调用同一个工具不结束工具返回信息不足以支持决策或 max_iterations 未设置设置迭代上限检查工具返回内容是否包含足够信息检索答案答非所问chunk 切分过碎或过大召回相关性不够按文档结构调整切分加入 score 阈值或 Rerank多轮对话上下文爆炸全量保存所有历史改用窗口记忆、摘要记忆或向量检索式记忆换了个模型后工具调用失灵新模型不支持 function calling 或工具格式兼容差先确认模型支持工具调用必要时走 ReAct 文本格式提示词规则明明写了却不生效规则太长太杂模型注意力被稀释精简规则把最关键约束放到离问题最近的位置最后我踩过几次坑之后的一些习惯现在做 LLM 应用我不会一上来就写代码。我会先画一张非常粗糙的数据流图明确“外部信息从哪里进来”“记忆放在哪个环节注入”“哪些步骤由固定逻辑完成哪些交给模型决策”。这个习惯帮我省下了大量返工时间。你是真的需要把每一块组件都吃透才能开始做应用吗我的感受是不需要。你只需要把 Model、Prompt、Chain 这三种最基础的关系摸熟能拼出一个跑得通的问答链路后面再加 Memory、Retrieval、Agent 的时候自然会有一种“原来这块积木是这样咬合”的顺畅感。LangChain 最值钱的地方从来不是某一个具体组件而是“把它们串联起来”的那套思路。把这个思路练熟了无论后面技术栈怎么变你都能很快迁移过去。