1、框架模块模块核心作用关键组件在架构中的角色1. 模型输入/输出 (Model I/O)标准化与任何大语言模型LLM的交互接口语言模型(LLMs/ChatModels)、提示模板(PromptTemplates)、输出解析器(OutputParsers)应用的门户负责处理模型的输入、调用和输出是整个应用的起点和终点。2. 数据连接 (Data Connection)加载、转换和检索应用所需的私有或外部数据是实现RAG检索增强生成的基础文档加载器(Document Loaders)、文本分割器(Text Splitters)、嵌入模型(Embedding Models)、向量存储(Vector Stores)、检索器(Retrievers)应用的知识库为模型提供训练数据之外的、特定领域的上下文信息解决模型知识滞后问题。3. 链 (Chain)将多个组件如模型、提示模板、检索器按确定性的顺序组合成一个完整的工作流LLMChain基础链、顺序链(SequentialChain)、路由链(RouterChain) 等应用的胶水与流程控制定义和执行复杂的业务逻辑是构建稳定应用的核心模块。4. 记忆 (Memory)在链或智能体的多次调用之间持久化状态管理上下文对话缓冲记忆(ConversationBufferMemory)、对话摘要记忆(ConversationSummaryMemory)、实体记忆(EntityMemory) 等应用的短期与长期记忆让无状态的 LLM 拥有记忆能力是实现多轮对话和上下文理解的关键-。5. 智能体 (Agent)利用 LLM 作为推理引擎动态决策下一步要执行的动作如调用哪个工具代理(Agent)、工具(Tools)、代理执行器(AgentExecutor)应用的大脑与决策者处理非确定性任务能根据用户需求自主规划和调用外部能力。6. 回调 (Callback)提供一套观测和介入系统允许你在应用运行的各个阶段如开始、结束、出错时插入自定义逻辑日志记录、流式传输、Token计数、调试追踪等应用的监控与调试台在不影响主流程的情况下实现全链路的监控、日志和调试。2、模型输入/输出一、 示例选择器 (Example Selectors)在进行 Few-Shot少样本提示时如果我们将所有可用的示例都塞进 Prompt不仅会导致 Token 消耗过大甚至可能超出模型的上下文窗口。示例选择器的作用就是根据当前的用户输入动态、智能地挑选出最合适的示例。1.LengthBasedExampleSelector(基于长度的示例选择器)•核心逻辑它的目标是防止 Prompt 超出模型的上下文长度限制。当用户输入较长时它会选择较少的示例当用户输入较短时它会选择较多的示例。•适用场景纯粹为了控制 Token 数量避免因超出最大长度而报错。通常用于上下文窗口较小的旧版模型或者预算极其有限的场景。•局限性仅考虑长度不考虑示例与输入的语义相关性可能选出的示例对当前任务帮助不大。2.SemanticSimilarityExampleSelector(基于语义相似度的示例选择器)•核心逻辑利用嵌入模型Embedding Models将用户输入和所有候选示例转化为向量并存储在向量数据库Vector Store中。通过计算余弦相似度等指标找出与当前用户输入语义最接近的示例。•适用场景问答系统、客服机器人。当您希望模型参考与当前问题最相似的历史解答时这是最常用的选择器。•局限性可能会选出高度同质化的示例。例如如果库里有三个极其相似的示例它可能把这三个都选出来导致提供给模型的信息存在大量冗余。3.MaxMarginalRelevanceExampleSelector(MMR - 最大边际相关性选择器)•核心逻辑旨在解决“语义相似度”导致的同质化问题。MMR 在选择示例时会进行权衡一方面它要求示例与用户输入有较高的相关性Similarity另一方面它要求被选出的示例之间保持较高的多样性Diversity。•深度解析它会惩罚那些与已经选出的示例高度相似的候选者。•适用场景创意写作、多角度分析、或是需要模型处理各种边界情况Edge Cases的任务。通过提供多样化的示例可以激发模型更全面的思考能力。4.NGramOverlapExampleSelector(基于 N-gram 重叠率的示例选择器)•核心逻辑通过计算用户输入与候选示例在字面上的 N-gram连续的N NN个词或字重叠分数来进行选择。它可以通过设置阈值Threshold来决定包含哪些示例例如重叠率达到 0.5 以上的才会被选中。•适用场景机器翻译、特定的句法转换、或是对特定专业术语和关键词高度敏感的任务。当“字面匹配”比“深层语义”更重要时它非常有效。核心总结选择哪种选择器取决于您的业务痛点。缺 Token 用 LengthBased要精准匹配用 Semantic要举一反三用 MMR要字面精准用 NGram。二、 模型接口 (Models)LangChain 为了兼容不同的模型生态将与大语言模型的交互抽象为两种主要形式1. LLMs (大语言模型)•输入/输出范式String (文本字符串) - String (文本字符串)。•深度说明这是最传统的模型接口例如早期的 OpenAItext-davinci-003。你给它一段前文Prompt它顺着前文继续生成Completion。它没有对话轮次的概念纯粹是文本的续写。2. Chat Models (聊天模型)•输入/输出范式List of Messages (消息列表) - Message (单条消息)。•深度说明这是目前的主流如 GPT-4, Gemini, Claude 等。虽然它们底层依然是大语言模型但 API 被封装成了对话形式。输入不仅是文本而是带有角色的消息体◦SystemMessage (系统消息)设定 AI 的人设、背景和全局规则。◦HumanMessage (人类消息)用户的输入。◦AIMessage (AI 消息)模型之前的回复用于维持对话历史。•优势这种结构极大地增强了模型对复杂指令的遵循能力特别适合角色扮演和多轮复杂对话。三、 输出解析器 (Output Parsers)大模型天生擅长输出自然语言文本但在工程化应用中我们通常需要数据库可读的结构化数据如 JSON、列表、日期对象等。PydanticOutputParser•核心逻辑它是 LangChain 中最强大、最常用的输出解析器之一。它结合了 Python 中强大的数据校验库Pydantic。•工作机制1.定义 Schema开发者使用 Pydantic 的BaseModel定义一个类明确指定需要的字段、类型如整型、字符串、枚举等以及字段描述。2.生成指令解析器会根据这个 Pydantic 类自动生成一段极其详尽的 Prompt 指令Format Instructions告诉大模型“你必须严格按照这个 JSON 格式输出字段说明如下…”。3.解析与校验当模型返回文本后解析器会尝试将其转换为对应的 Pydantic Python 对象。如果格式不完全匹配例如模型返回了非法的键或者类型不对它会触发错误甚至可以通过 LangChain 的RetryOutputParser让模型重新修复输出。•价值深度它使得大模型能够完美接入传统的软件工程管道。你可以放心地调用parsed_output.user_name或parsed_output.age而不必再写复杂的正则表达式去提取文本。3、数据连接一、 Document Loaders文档加载器这是数据管道的第一步。现实世界的数据格式千奇百怪PDF、Word、Notion 页面、数据库、甚至 YouTube 字幕而大模型只认识纯文本。核心功能将各种异构数据源统一转化为 LangChain 标准的Document对象。深度解析Document对象它不仅包含提取出的纯文本page_content更重要的是它包含元数据metadata。为什么元数据至关重要假设您加载了 100 份 PDF 财报。metadata可以记录 {“source”: “2023_Q3_Report.pdf”, “page”: 15, “author”: “Finance Dept”}。在后续检索时您可以利用这些元数据进行精准的硬过滤例如只检索 2023 年的数据这极大地减少了向量搜索的错误率。二、 Document Transformers文档转换器直接把一整本书塞给大模型是不现实的超出上下文窗口且稀释注意力。我们需要将其切分成小块Chunks。您提到的RecursiveCharacterTextSplitter递归字符文本分割器是目前业界公认最好用、最智能的切分策略。它的痛点如果按固定字数生硬地切分文本很容易把一个完整的句子或段落劈成两半导致语义丢失。核心逻辑递归切割它预设了一个分隔符的优先级列表通常是[\n\n (段落), \n (换行), (空格), (字符)]。它首先尝试用最高优先级的\n\n来切分文本。如果切出来的某一段还是超出了您设置的最大长度chunk_size它才会退而求其次针对这一段使用\n进行二次切分。以此类推直到所有数据块都小于指定的长度。优势这种机制最大程度地保证了语义的完整性确保同一个段落、同一个句子的内容被尽量划分在同一个 Chunk 中。关键参数chunk_overlap重叠度切分时必须让相邻的 Chunk 之间有一段重叠的内容比如重叠 50 个字符。这就好比拼图的卡扣它防止了切片边缘的上下文断裂让模型在阅读局部时依然能感知到前后的关联。三、 Text Embedding Models文本嵌入模型这是 RAG 的灵魂。嵌入模型将人类的自然语言文本压缩成一个高维的浮点数数组向量空间通常是几百到上千维如768 768768维或1536 15361536维。在向量空间中语义越接近的两段文本它们对应的向量坐标在空间里的距离就越近。您特别提到了“一个用于文档嵌入另一个用于查询嵌入”这是一个非常专业且深刻的观察非对称语义搜索Asymmetric Semantic Searchembed_documents()(文档嵌入)处理的是知识库中的长文本段落。它需要捕获丰富的、描述性的背景信息。embed_query()(查询嵌入)处理的是用户输入的通常很短、带有疑问性质的句子。为什么要在接口上分开像 OpenAI 的text-embedding-3系列或 BGE 模型底层虽然可能是同一个神经网络但在面对“查询”和“文档”时其内部的最优表示方式是不同的。通过在 LangChain API 层面对embed_query和embed_documents进行区分模型可以在底层运用不同的前缀指令Instructions或注意力机制从而大幅提升短问题匹配长文档的召回率。四、 Vector Stores向量数据库当我们将成千上万的文档切片Chunks全部转换成向量后普通的 MySQL 数据库是无法高效搜索它们的。我们需要专用的向量数据库如 Chroma、FAISS、Pinecone、Milvus。核心逻辑它不仅存储原始的 Chunk 文本和元数据更重要的是它会对高维向量建立索引通常使用 HNSW 等近似最近邻居算法。作用当一个用户的查询被转化为向量输入后向量数据库可以在极短的时间内毫秒级从海量向量中计算出距离如余弦相似度C o s i n e S i m i l a r i t y Cosine\ SimilarityCosineSimilarity或欧氏距离L 2 L_2L2最近的几个点。五、 Retrievers检索器Retriever 是 LangChain 中的一个接口它定义了如何从 Vector Store 中把最相关的 Chunk 抓取出来并交付给大模型去生成答案。1. 相似性搜索 (Similarity Search)逻辑纯粹基于向量之间的距离如余弦相似度。距离越近相关度得分越高。它会简单粗暴地返回得分最高的 Top-K 个结果。痛点信息冗余假设用户搜“苹果公司2023年利润”如果您的文档里有三段几乎一模一样的关于这部分利润的描述Similarity Search 会把这三段全部召回。这就浪费了大模型宝贵的上下文空间且没有提供增量信息。2. 最大边际相关性 (MMR - Maximal Marginal Relevance)逻辑它是对相似性搜索的完美升级。MMR 引入了一个“惩罚机制”。首先它像相似性搜索一样选出与查询最相关的候选集比如 Top-20。然后它从中挑选第一个放入最终结果。在挑选第二个时MMR 会进行计算这个候选块不仅要和“用户查询”相关Relevance还要和“已经挑选出的结果”不相似Diversity多样性。深度价值MMR 完美解决了“信息同质化”问题。它确保喂给大模型的上下文既切题又涵盖了不同的角度和信息面极大提升了大模型最终回答的丰富度和全面性。4、链一、LLMChainLLMChain是 LangChain 中最基础、最核心的构建块。任何复杂的应用最终都会拆解为一个个单独的LLMChain去执行。核心构成它将三个元素绑定在一起PromptTemplate提示词模板 LLM / ChatModel大语言模型 OutputParser输出解析器可选。深度机制1. 接收用户的字典格式输入例如{topic: 量子力学}。将变量注入到 Prompt 模板中。调用底层的 LLM 生成回复。如果配置了通过 Parser 将回复转化为结构化数据。认知定位不要把它看作一个复杂的系统把它看作程序设计中的一个纯函数。它的职责单一且明确输入特定的变量输出大模型的思考结果。二、RouterChain在真实的业务中用户的意图是多样的。如果您把所有类型的问题比如数学计算、创意写作、IT 运维都塞给同一个 Prompt 去处理大模型的表现会非常平庸。RouterChain解决了**“让专业的人做专业的事”**的问题。核心逻辑它通常结合MultiPromptChain一起使用。它包含一个“主控大模型Router”和多个“下游子链Destination Chains”。深度工作流意图识别用户输入问题后首先交给 Router 模型。Router 的 Prompt 里通常写着“你是一个意图识别专家这里有几个处理中心A是数学中心B是物理中心。请判断用户的输入该发给谁。”动态路由Router 输出一个结构化指令比如{destination: 物理中心, next_inputs: ...}。分发执行框架根据这个指令将用户的原始问题无缝转发给特定的“物理学专业 Prompt 子链”进行处理。默认兜底如果用户的输入不属于任何既定分类会发给一个DefaultChain默认通用链进行兜底回应。业务价值极大地提升了系统的准确率和专业度。您可以为每个细分领域精调特定的 Prompt而对用户来说他们只面对一个统一的入口。三、SimpleSequentialChainvsSequentialChain当您的任务无法通过一次对话完成需要多步推理和处理时就需要用到串联链。1.SimpleSequentialChain简单顺序链核心逻辑严格的单输入、单输出线性流水线。工作机制链 A 的输出直接作为链 B 的输入链 B 的输出直接作为链 C 的输入。适用场景剧本生成Step 1: 生成故事大纲 - Step 2: 根据大纲写第一章 - Step 3: 翻译成英文。局限性数据流转太死板后面的步骤无法获取第一步的原始数据。2.SequentialChain高级顺序链核心逻辑支持多输入、多输出的复杂流水线网络。工作机制这是企业级应用的主力。它通过指定input_variables和output_variables在上下文中进行“字典级的键值匹配”。比如Chain 1 接收[文章]输出[摘要, 核心观点]。Chain 2 接收[核心观点]输出[反驳意见]。Chain 3 接收第一步的[文章]和第二步的[反驳意见]输出最终的[辩论稿]。业务价值允许数据在整个执行周期内“穿透”传递各个子链可以根据需要订阅前面任意步骤产出的变量构建复杂的思维树Tree of Thoughts逻辑。四、TransformChain这是一个常常被忽视但对控制成本极其重要的组件。核心逻辑它不调用任何 LLM而是直接运行您自定义的纯 Python 函数。它在流水线中专门负责数据的预处理或后处理。为什么需要它使用大模型是非常昂贵且缓慢的。如果您仅仅是想把一段文本变成大写、利用正则表达式清洗掉 HTML 标签、截取字符串的前 1000 个字符、或者去数据库里查询一个简单的用户 ID用大模型做这些事简直是用大炮打蚊子。深度工作流您可以编写一个 Python 函数比如clean_text(inputs)将其封装为TransformChain。然后把它无缝安插在SequentialChain的各个 LLMChain 之间。业务价值降低 Token 消耗减少延迟保证业务逻辑中确定性部分Deterministic的绝对可靠性。5、记忆一、ConversationBufferMemory1. 核心工作机制它的逻辑非常简单粗暴原封不动地记录所有的对话历史Human 消息和 AI 消息并在下一次交互时将整个历史记录全量注入到 Prompt 中。2. 深度剖析优缺点绝对优势Perfect Recall因为它保留了对话的逐字原貌模型可以精准地提取之前的任何细节不会产生信息丢失。致命缺陷Token 爆炸与上下文溢出*成本高昂大模型的 API 是按 Token 计费的。随着对话轮次的增加每一次请求携带的上下文都会越来越长导致成本呈线性甚至指数级增长。长度限制每个大模型都有最大上下文窗口Context Window如 8K、128K。一旦完整对话历史超出了这个窗口程序就会直接报错崩溃。业务定位ConversationBufferMemory仅适用于极短的、临时性的任务型多轮对话。在严肃的企业级长对话场景中它是不可用的。二、ConversationBufferWindowMemory基于轮次的滑动窗口核心逻辑只保留最近的k kk轮对话。比如设置k3那么当进行第 4 轮对话时第 1 轮的记录就会被永久丢弃。深度价值它极其轻量。在很多客服场景中用户通常只关心最近几个问题的上下文早期的寒暄完全可以被丢弃。它完美控制了 Token 的上限。三、ConversationTokenBufferMemory基于 Token 的精准截断核心逻辑与WindowMemory类似但它不是按“轮次”截断而是按“Token 数量”截断例如max_token_limit1000。深度价值更加精确的成本控制。因为一轮对话可能只有几个字也可能长达几千字。按 Token 截断能最精准地防止超出模型的上下文窗口。四、ConversationSummaryMemory利用 LLM 进行记忆压缩核心逻辑当对话发生时它会在后台悄悄调用一次大模型让模型把之前的对话总结成一段摘要。之后每次提问传递给主模型的不再是逐字记录而是这份“摘要”。深度价值极大地压缩了信息体积理论上可以支持无限轮次的对话。代价总结的过程本身会丢失细节比如具体的代码片段、精确的数字可能被忽略且每次更新记忆都需要额外消耗一次 LLM 调用的时间和金钱。五、ConversationSummaryBufferMemory终极形态混合记忆核心逻辑结合了 Buffer缓存和 Summary摘要的最强方案。它设定了一个max_token_limit。当最近的聊天记录没有超过这个 Token 限制时它表现得就像ConversationBufferMemory原封不动地保留对话。一旦即将超出限制它不会直接丢弃老旧对话而是把最老的那部分对话拿去生成“摘要”同时保留最近的对话原貌。业务定位这是目前最推荐的单点长对话解决方案。它既保留了近期对话的绝对细节又通过摘要记住了早期对话的宏观背景。六、VectorStoreRetrieverMemory基于向量库的语义记忆核心逻辑打破了“时间线”的限制。它将每一轮的对话切片并转化为向量存入向量数据库Vector Store。当用户提出新问题时它通过相似度检索找出与当前问题最相关的历史对话片段注入到 Prompt 中。深度价值适用于“漫长且主题跳跃”的对话。比如用户在一个月前跟 AI 聊了“苹果的财报”一个月后突然又问“你上次说苹果的利润是多少”基于时间窗口的记忆早就把它忘了但向量记忆可以精准把它捞回来。6、智能体一、 Agent智能体大脑在传统的 Chain 中执行顺序是被代码硬编码写死的先做 A再做 B。而 Agent 完全打破了这种限制由大模型自己决定接下来该做什么。核心驱动力Prompt 策略如 ReActAgent 的核心是一个极其复杂的 Prompt 模板。目前业界最主流的策略是ReAct (Reason Act)。Agent 会被要求以特定的格式输出它的思考过程Thought思考我现在需要解决什么问题我应该用哪个工具Action行动我决定调用“计算器”工具。Action Input行动输入输入参数是123 * 456。深度剖析Agent 本身不执行任何操作。它只负责“想”。它就像一个发号施令的将军输出的是结构化的指令文本比如一段要求调用某个函数的 JSON等待外部系统去实际执行。二、 Tools工具大模型的知识停留在训练日且无法与物理世界交互。Tools 就是赋予大模型联网、查数据库、执行代码、发送邮件能力的 API。深度考虑一工具的描述Description比代码更重要这是很多开发者最容易踩坑的地方。Agent 是如何知道该用哪个工具的完全依赖于您提供给它的description字符串。反面教材description用于搜索大模型会感到困惑不知道搜什么。优秀示范description当你需要获取关于当前天气、实时新闻或未知的客观事实时请使用此工具。输入应该是一个具体的搜索关键词。如果您发现 Agent 频繁调用错误的工具或者陷入死循环90% 的原因是您的工具描述写得不够清晰、边界不够明确。深度考虑二强类型与参数校验现代 LangChain 工具深度集成了Pydantic。您可以严格规定工具需要哪些输入参数如不仅需要搜索词还需要指定日期范围这能极大降低大模型“幻觉”导致的工具调用失败。三、 Toolkits工具箱既然工具这么好为什么不把 100 个工具全塞给 Agent因为大模型的上下文窗口是有限的且注意力会被稀释。如果工具描述占用了 4000 个 Token模型就很难专注于解决用户的问题了。核心价值按领域打包降低认知负载。Toolkits 是一种业务上的聚合。例如SQL Database Toolkit。当您想让 Agent 分析数据库时您只需要加载这个 Toolkit。它通常包含ListTablesTool看看库里有哪些表。InfoSQLDatabaseTool查看某张表的 Schema字段名、类型。QuerySQLDataBaseTool实际执行 SQL 语句。深度剖析Toolkit 实际上教给了 Agent 一套解决特定领域问题的标准SOP标准作业程序。Agent 会很自然地先查表名再查字段最后写 SQL而不是像无头苍蝇一样乱撞。四、 AgentExecutor运行引擎AgentExecutor 是把 Agent大脑和 Tools手脚结合在一起的运行时环境。它本质上是一个高级的while循环。深度执行逻辑The Agent Loop把用户输入交给 Agent。Agent 思考后决定调用 Tool A并生成参数。AgentExecutor 拦截这个指令实际去执行 Tool A。Tool A 返回结果我们称为Observation观察结果。AgentExecutor 将 Observation 喂回给 Agent问它“这是工具的结果你接下来怎么办”循环重复直到 Agent 输出一个特殊的指令Final Answer最终答案循环终止将结果返回给用户。健壮性处理AgentExecutor 的强大之处在于它的容错能力。如果大模型输出的 JSON 格式坏了或者工具执行超时报错AgentExecutor 不会直接崩溃而是会把错误信息变成一段 Observation 传回给 Agent“你刚才的调用报错了原因是参数类型不对请修正后重试。”它赋予了系统自我纠错的能力。1、Plan-and-execute Agent计划与执行智能体核心逻辑将大脑一分为二。先让一个“规划者Planner”模型统揽全局将复杂的大目标拆解为 5 个明确的子任务。然后交由“执行者Executor”一步一步去完成。优势极大地增强了处理长线任务的稳定性不会像普通 Agent 那样做着做着就跑偏了。2、BabyAGI AutoGPT自主智能体先驱核心逻辑引入了任务队列Task Queue和长期记忆Vector Store。深度剖析它们不仅仅是完成一次问答而是可以设定一个宏大的目标如“帮我调研市场上所有的竞品并写一份报告”。它们会自动生成任务列表执行任务根据执行结果自我反思Self-Reflection动态向队列中添加新任务并把有用的信息存入向量数据库以便后续查阅。这已经是非常接近“自动化数字员工”的雏形了。7、回调一、BaseCallbackHandlerBaseCallbackHandler通常简称为CallbackHandler是所有回调处理器的基类接口。它定义了一套极其详尽的“钩子Hooks”方法贯穿了 LangChain 组件运行的整个生命周期。核心逻辑它就像是在流水线的各个关键节点安装了监控探头。当事件发生时LangChain 底层会自动触发对应的方法。深度剖析关键生命周期事件LLM 层面on_llm_start: 模型开始生成前触发可获取输入的 Prompt。on_llm_new_token:极其重要当模型流式Streaming输出时每生成一个新字Token就会触发一次。这是实现前端打字机效果的核心。on_llm_end/on_llm_error: 模型生成结束或报错时触发可获取完整的输出文本或 Token 消耗统计。Chain 层面on_chain_start/on_chain_end/on_chain_error: 监听链路的输入输出流转。Tool Agent 层面on_tool_start: 工具开始执行前触发可看到 Agent 决定传给工具的具体参数。on_agent_action: Agent 决定采取某个动作时触发捕获 Agent 的“内心戏” Thought。on_agent_finish: Agent 最终完成任务时触发。二、StdOutCallbackHandler如果说BaseCallbackHandler是图纸那么StdOutCallbackHandler就是 LangChain 官方提供的一个最基础的实体实现类。核心功能顾名思义Standard Output它的作用就是拦截上述生命周期中的关键事件并把它们以不同颜色的格式化文本打印到控制台Terminal / Console上。深度应用场景在开发 Agent 或复杂的 SequentialChain 时它是不可或缺的调试神器。只要将其注入到 AgentExecutor 中您就能在控制台上清晰地看到绿色的字是用户的输入蓝色的字是 Agent 的思考过程黄色的字是工具的返回结果。这就好比把 Agent 的大脑思维过程直接投影在了屏幕上。局限性它只适合本地开发调试。在生产环境线上服务器中您通常不需要也不应该把大量中间过程打印到标准输出中。三、CallbackManager在实际业务中我们往往需要同时触发多个回调。比如同一个 Agent 运行期间既要在本地控制台打印日志使用StdOutCallbackHandler又要将 Token 消耗发送到监控系统使用DataDogCallbackHandler或自定义 Handler还要把生成的字逐个推送到 Web 前端。核心功能CallbackManager就是用来管理和调度这些 Handler 的。它是一个分发器Dispatcher。工作机制您将多个不同的 CallbackHandler 注册添加到CallbackManager中。当 LangChain 组件如 LLM触发on_llm_start事件时它并不会直接去找 Handler而是把事件报告给CallbackManager。CallbackManager会遍历它内部维护的 Handler 列表依次调用它们的on_llm_start方法。现代 LangChain 的演进重要提示在较新的 LangChain 版本中开发者通常不需要手动实例化CallbackManager。您只需要在调用组件如chain.invoke()时通过callbacks[handler1, handler2]参数传入一个 Handler 列表LangChain 底层会自动为您构建并管理这个 Manager。
Langchain原理综述
1、框架模块模块核心作用关键组件在架构中的角色1. 模型输入/输出 (Model I/O)标准化与任何大语言模型LLM的交互接口语言模型(LLMs/ChatModels)、提示模板(PromptTemplates)、输出解析器(OutputParsers)应用的门户负责处理模型的输入、调用和输出是整个应用的起点和终点。2. 数据连接 (Data Connection)加载、转换和检索应用所需的私有或外部数据是实现RAG检索增强生成的基础文档加载器(Document Loaders)、文本分割器(Text Splitters)、嵌入模型(Embedding Models)、向量存储(Vector Stores)、检索器(Retrievers)应用的知识库为模型提供训练数据之外的、特定领域的上下文信息解决模型知识滞后问题。3. 链 (Chain)将多个组件如模型、提示模板、检索器按确定性的顺序组合成一个完整的工作流LLMChain基础链、顺序链(SequentialChain)、路由链(RouterChain) 等应用的胶水与流程控制定义和执行复杂的业务逻辑是构建稳定应用的核心模块。4. 记忆 (Memory)在链或智能体的多次调用之间持久化状态管理上下文对话缓冲记忆(ConversationBufferMemory)、对话摘要记忆(ConversationSummaryMemory)、实体记忆(EntityMemory) 等应用的短期与长期记忆让无状态的 LLM 拥有记忆能力是实现多轮对话和上下文理解的关键-。5. 智能体 (Agent)利用 LLM 作为推理引擎动态决策下一步要执行的动作如调用哪个工具代理(Agent)、工具(Tools)、代理执行器(AgentExecutor)应用的大脑与决策者处理非确定性任务能根据用户需求自主规划和调用外部能力。6. 回调 (Callback)提供一套观测和介入系统允许你在应用运行的各个阶段如开始、结束、出错时插入自定义逻辑日志记录、流式传输、Token计数、调试追踪等应用的监控与调试台在不影响主流程的情况下实现全链路的监控、日志和调试。2、模型输入/输出一、 示例选择器 (Example Selectors)在进行 Few-Shot少样本提示时如果我们将所有可用的示例都塞进 Prompt不仅会导致 Token 消耗过大甚至可能超出模型的上下文窗口。示例选择器的作用就是根据当前的用户输入动态、智能地挑选出最合适的示例。1.LengthBasedExampleSelector(基于长度的示例选择器)•核心逻辑它的目标是防止 Prompt 超出模型的上下文长度限制。当用户输入较长时它会选择较少的示例当用户输入较短时它会选择较多的示例。•适用场景纯粹为了控制 Token 数量避免因超出最大长度而报错。通常用于上下文窗口较小的旧版模型或者预算极其有限的场景。•局限性仅考虑长度不考虑示例与输入的语义相关性可能选出的示例对当前任务帮助不大。2.SemanticSimilarityExampleSelector(基于语义相似度的示例选择器)•核心逻辑利用嵌入模型Embedding Models将用户输入和所有候选示例转化为向量并存储在向量数据库Vector Store中。通过计算余弦相似度等指标找出与当前用户输入语义最接近的示例。•适用场景问答系统、客服机器人。当您希望模型参考与当前问题最相似的历史解答时这是最常用的选择器。•局限性可能会选出高度同质化的示例。例如如果库里有三个极其相似的示例它可能把这三个都选出来导致提供给模型的信息存在大量冗余。3.MaxMarginalRelevanceExampleSelector(MMR - 最大边际相关性选择器)•核心逻辑旨在解决“语义相似度”导致的同质化问题。MMR 在选择示例时会进行权衡一方面它要求示例与用户输入有较高的相关性Similarity另一方面它要求被选出的示例之间保持较高的多样性Diversity。•深度解析它会惩罚那些与已经选出的示例高度相似的候选者。•适用场景创意写作、多角度分析、或是需要模型处理各种边界情况Edge Cases的任务。通过提供多样化的示例可以激发模型更全面的思考能力。4.NGramOverlapExampleSelector(基于 N-gram 重叠率的示例选择器)•核心逻辑通过计算用户输入与候选示例在字面上的 N-gram连续的N NN个词或字重叠分数来进行选择。它可以通过设置阈值Threshold来决定包含哪些示例例如重叠率达到 0.5 以上的才会被选中。•适用场景机器翻译、特定的句法转换、或是对特定专业术语和关键词高度敏感的任务。当“字面匹配”比“深层语义”更重要时它非常有效。核心总结选择哪种选择器取决于您的业务痛点。缺 Token 用 LengthBased要精准匹配用 Semantic要举一反三用 MMR要字面精准用 NGram。二、 模型接口 (Models)LangChain 为了兼容不同的模型生态将与大语言模型的交互抽象为两种主要形式1. LLMs (大语言模型)•输入/输出范式String (文本字符串) - String (文本字符串)。•深度说明这是最传统的模型接口例如早期的 OpenAItext-davinci-003。你给它一段前文Prompt它顺着前文继续生成Completion。它没有对话轮次的概念纯粹是文本的续写。2. Chat Models (聊天模型)•输入/输出范式List of Messages (消息列表) - Message (单条消息)。•深度说明这是目前的主流如 GPT-4, Gemini, Claude 等。虽然它们底层依然是大语言模型但 API 被封装成了对话形式。输入不仅是文本而是带有角色的消息体◦SystemMessage (系统消息)设定 AI 的人设、背景和全局规则。◦HumanMessage (人类消息)用户的输入。◦AIMessage (AI 消息)模型之前的回复用于维持对话历史。•优势这种结构极大地增强了模型对复杂指令的遵循能力特别适合角色扮演和多轮复杂对话。三、 输出解析器 (Output Parsers)大模型天生擅长输出自然语言文本但在工程化应用中我们通常需要数据库可读的结构化数据如 JSON、列表、日期对象等。PydanticOutputParser•核心逻辑它是 LangChain 中最强大、最常用的输出解析器之一。它结合了 Python 中强大的数据校验库Pydantic。•工作机制1.定义 Schema开发者使用 Pydantic 的BaseModel定义一个类明确指定需要的字段、类型如整型、字符串、枚举等以及字段描述。2.生成指令解析器会根据这个 Pydantic 类自动生成一段极其详尽的 Prompt 指令Format Instructions告诉大模型“你必须严格按照这个 JSON 格式输出字段说明如下…”。3.解析与校验当模型返回文本后解析器会尝试将其转换为对应的 Pydantic Python 对象。如果格式不完全匹配例如模型返回了非法的键或者类型不对它会触发错误甚至可以通过 LangChain 的RetryOutputParser让模型重新修复输出。•价值深度它使得大模型能够完美接入传统的软件工程管道。你可以放心地调用parsed_output.user_name或parsed_output.age而不必再写复杂的正则表达式去提取文本。3、数据连接一、 Document Loaders文档加载器这是数据管道的第一步。现实世界的数据格式千奇百怪PDF、Word、Notion 页面、数据库、甚至 YouTube 字幕而大模型只认识纯文本。核心功能将各种异构数据源统一转化为 LangChain 标准的Document对象。深度解析Document对象它不仅包含提取出的纯文本page_content更重要的是它包含元数据metadata。为什么元数据至关重要假设您加载了 100 份 PDF 财报。metadata可以记录 {“source”: “2023_Q3_Report.pdf”, “page”: 15, “author”: “Finance Dept”}。在后续检索时您可以利用这些元数据进行精准的硬过滤例如只检索 2023 年的数据这极大地减少了向量搜索的错误率。二、 Document Transformers文档转换器直接把一整本书塞给大模型是不现实的超出上下文窗口且稀释注意力。我们需要将其切分成小块Chunks。您提到的RecursiveCharacterTextSplitter递归字符文本分割器是目前业界公认最好用、最智能的切分策略。它的痛点如果按固定字数生硬地切分文本很容易把一个完整的句子或段落劈成两半导致语义丢失。核心逻辑递归切割它预设了一个分隔符的优先级列表通常是[\n\n (段落), \n (换行), (空格), (字符)]。它首先尝试用最高优先级的\n\n来切分文本。如果切出来的某一段还是超出了您设置的最大长度chunk_size它才会退而求其次针对这一段使用\n进行二次切分。以此类推直到所有数据块都小于指定的长度。优势这种机制最大程度地保证了语义的完整性确保同一个段落、同一个句子的内容被尽量划分在同一个 Chunk 中。关键参数chunk_overlap重叠度切分时必须让相邻的 Chunk 之间有一段重叠的内容比如重叠 50 个字符。这就好比拼图的卡扣它防止了切片边缘的上下文断裂让模型在阅读局部时依然能感知到前后的关联。三、 Text Embedding Models文本嵌入模型这是 RAG 的灵魂。嵌入模型将人类的自然语言文本压缩成一个高维的浮点数数组向量空间通常是几百到上千维如768 768768维或1536 15361536维。在向量空间中语义越接近的两段文本它们对应的向量坐标在空间里的距离就越近。您特别提到了“一个用于文档嵌入另一个用于查询嵌入”这是一个非常专业且深刻的观察非对称语义搜索Asymmetric Semantic Searchembed_documents()(文档嵌入)处理的是知识库中的长文本段落。它需要捕获丰富的、描述性的背景信息。embed_query()(查询嵌入)处理的是用户输入的通常很短、带有疑问性质的句子。为什么要在接口上分开像 OpenAI 的text-embedding-3系列或 BGE 模型底层虽然可能是同一个神经网络但在面对“查询”和“文档”时其内部的最优表示方式是不同的。通过在 LangChain API 层面对embed_query和embed_documents进行区分模型可以在底层运用不同的前缀指令Instructions或注意力机制从而大幅提升短问题匹配长文档的召回率。四、 Vector Stores向量数据库当我们将成千上万的文档切片Chunks全部转换成向量后普通的 MySQL 数据库是无法高效搜索它们的。我们需要专用的向量数据库如 Chroma、FAISS、Pinecone、Milvus。核心逻辑它不仅存储原始的 Chunk 文本和元数据更重要的是它会对高维向量建立索引通常使用 HNSW 等近似最近邻居算法。作用当一个用户的查询被转化为向量输入后向量数据库可以在极短的时间内毫秒级从海量向量中计算出距离如余弦相似度C o s i n e S i m i l a r i t y Cosine\ SimilarityCosineSimilarity或欧氏距离L 2 L_2L2最近的几个点。五、 Retrievers检索器Retriever 是 LangChain 中的一个接口它定义了如何从 Vector Store 中把最相关的 Chunk 抓取出来并交付给大模型去生成答案。1. 相似性搜索 (Similarity Search)逻辑纯粹基于向量之间的距离如余弦相似度。距离越近相关度得分越高。它会简单粗暴地返回得分最高的 Top-K 个结果。痛点信息冗余假设用户搜“苹果公司2023年利润”如果您的文档里有三段几乎一模一样的关于这部分利润的描述Similarity Search 会把这三段全部召回。这就浪费了大模型宝贵的上下文空间且没有提供增量信息。2. 最大边际相关性 (MMR - Maximal Marginal Relevance)逻辑它是对相似性搜索的完美升级。MMR 引入了一个“惩罚机制”。首先它像相似性搜索一样选出与查询最相关的候选集比如 Top-20。然后它从中挑选第一个放入最终结果。在挑选第二个时MMR 会进行计算这个候选块不仅要和“用户查询”相关Relevance还要和“已经挑选出的结果”不相似Diversity多样性。深度价值MMR 完美解决了“信息同质化”问题。它确保喂给大模型的上下文既切题又涵盖了不同的角度和信息面极大提升了大模型最终回答的丰富度和全面性。4、链一、LLMChainLLMChain是 LangChain 中最基础、最核心的构建块。任何复杂的应用最终都会拆解为一个个单独的LLMChain去执行。核心构成它将三个元素绑定在一起PromptTemplate提示词模板 LLM / ChatModel大语言模型 OutputParser输出解析器可选。深度机制1. 接收用户的字典格式输入例如{topic: 量子力学}。将变量注入到 Prompt 模板中。调用底层的 LLM 生成回复。如果配置了通过 Parser 将回复转化为结构化数据。认知定位不要把它看作一个复杂的系统把它看作程序设计中的一个纯函数。它的职责单一且明确输入特定的变量输出大模型的思考结果。二、RouterChain在真实的业务中用户的意图是多样的。如果您把所有类型的问题比如数学计算、创意写作、IT 运维都塞给同一个 Prompt 去处理大模型的表现会非常平庸。RouterChain解决了**“让专业的人做专业的事”**的问题。核心逻辑它通常结合MultiPromptChain一起使用。它包含一个“主控大模型Router”和多个“下游子链Destination Chains”。深度工作流意图识别用户输入问题后首先交给 Router 模型。Router 的 Prompt 里通常写着“你是一个意图识别专家这里有几个处理中心A是数学中心B是物理中心。请判断用户的输入该发给谁。”动态路由Router 输出一个结构化指令比如{destination: 物理中心, next_inputs: ...}。分发执行框架根据这个指令将用户的原始问题无缝转发给特定的“物理学专业 Prompt 子链”进行处理。默认兜底如果用户的输入不属于任何既定分类会发给一个DefaultChain默认通用链进行兜底回应。业务价值极大地提升了系统的准确率和专业度。您可以为每个细分领域精调特定的 Prompt而对用户来说他们只面对一个统一的入口。三、SimpleSequentialChainvsSequentialChain当您的任务无法通过一次对话完成需要多步推理和处理时就需要用到串联链。1.SimpleSequentialChain简单顺序链核心逻辑严格的单输入、单输出线性流水线。工作机制链 A 的输出直接作为链 B 的输入链 B 的输出直接作为链 C 的输入。适用场景剧本生成Step 1: 生成故事大纲 - Step 2: 根据大纲写第一章 - Step 3: 翻译成英文。局限性数据流转太死板后面的步骤无法获取第一步的原始数据。2.SequentialChain高级顺序链核心逻辑支持多输入、多输出的复杂流水线网络。工作机制这是企业级应用的主力。它通过指定input_variables和output_variables在上下文中进行“字典级的键值匹配”。比如Chain 1 接收[文章]输出[摘要, 核心观点]。Chain 2 接收[核心观点]输出[反驳意见]。Chain 3 接收第一步的[文章]和第二步的[反驳意见]输出最终的[辩论稿]。业务价值允许数据在整个执行周期内“穿透”传递各个子链可以根据需要订阅前面任意步骤产出的变量构建复杂的思维树Tree of Thoughts逻辑。四、TransformChain这是一个常常被忽视但对控制成本极其重要的组件。核心逻辑它不调用任何 LLM而是直接运行您自定义的纯 Python 函数。它在流水线中专门负责数据的预处理或后处理。为什么需要它使用大模型是非常昂贵且缓慢的。如果您仅仅是想把一段文本变成大写、利用正则表达式清洗掉 HTML 标签、截取字符串的前 1000 个字符、或者去数据库里查询一个简单的用户 ID用大模型做这些事简直是用大炮打蚊子。深度工作流您可以编写一个 Python 函数比如clean_text(inputs)将其封装为TransformChain。然后把它无缝安插在SequentialChain的各个 LLMChain 之间。业务价值降低 Token 消耗减少延迟保证业务逻辑中确定性部分Deterministic的绝对可靠性。5、记忆一、ConversationBufferMemory1. 核心工作机制它的逻辑非常简单粗暴原封不动地记录所有的对话历史Human 消息和 AI 消息并在下一次交互时将整个历史记录全量注入到 Prompt 中。2. 深度剖析优缺点绝对优势Perfect Recall因为它保留了对话的逐字原貌模型可以精准地提取之前的任何细节不会产生信息丢失。致命缺陷Token 爆炸与上下文溢出*成本高昂大模型的 API 是按 Token 计费的。随着对话轮次的增加每一次请求携带的上下文都会越来越长导致成本呈线性甚至指数级增长。长度限制每个大模型都有最大上下文窗口Context Window如 8K、128K。一旦完整对话历史超出了这个窗口程序就会直接报错崩溃。业务定位ConversationBufferMemory仅适用于极短的、临时性的任务型多轮对话。在严肃的企业级长对话场景中它是不可用的。二、ConversationBufferWindowMemory基于轮次的滑动窗口核心逻辑只保留最近的k kk轮对话。比如设置k3那么当进行第 4 轮对话时第 1 轮的记录就会被永久丢弃。深度价值它极其轻量。在很多客服场景中用户通常只关心最近几个问题的上下文早期的寒暄完全可以被丢弃。它完美控制了 Token 的上限。三、ConversationTokenBufferMemory基于 Token 的精准截断核心逻辑与WindowMemory类似但它不是按“轮次”截断而是按“Token 数量”截断例如max_token_limit1000。深度价值更加精确的成本控制。因为一轮对话可能只有几个字也可能长达几千字。按 Token 截断能最精准地防止超出模型的上下文窗口。四、ConversationSummaryMemory利用 LLM 进行记忆压缩核心逻辑当对话发生时它会在后台悄悄调用一次大模型让模型把之前的对话总结成一段摘要。之后每次提问传递给主模型的不再是逐字记录而是这份“摘要”。深度价值极大地压缩了信息体积理论上可以支持无限轮次的对话。代价总结的过程本身会丢失细节比如具体的代码片段、精确的数字可能被忽略且每次更新记忆都需要额外消耗一次 LLM 调用的时间和金钱。五、ConversationSummaryBufferMemory终极形态混合记忆核心逻辑结合了 Buffer缓存和 Summary摘要的最强方案。它设定了一个max_token_limit。当最近的聊天记录没有超过这个 Token 限制时它表现得就像ConversationBufferMemory原封不动地保留对话。一旦即将超出限制它不会直接丢弃老旧对话而是把最老的那部分对话拿去生成“摘要”同时保留最近的对话原貌。业务定位这是目前最推荐的单点长对话解决方案。它既保留了近期对话的绝对细节又通过摘要记住了早期对话的宏观背景。六、VectorStoreRetrieverMemory基于向量库的语义记忆核心逻辑打破了“时间线”的限制。它将每一轮的对话切片并转化为向量存入向量数据库Vector Store。当用户提出新问题时它通过相似度检索找出与当前问题最相关的历史对话片段注入到 Prompt 中。深度价值适用于“漫长且主题跳跃”的对话。比如用户在一个月前跟 AI 聊了“苹果的财报”一个月后突然又问“你上次说苹果的利润是多少”基于时间窗口的记忆早就把它忘了但向量记忆可以精准把它捞回来。6、智能体一、 Agent智能体大脑在传统的 Chain 中执行顺序是被代码硬编码写死的先做 A再做 B。而 Agent 完全打破了这种限制由大模型自己决定接下来该做什么。核心驱动力Prompt 策略如 ReActAgent 的核心是一个极其复杂的 Prompt 模板。目前业界最主流的策略是ReAct (Reason Act)。Agent 会被要求以特定的格式输出它的思考过程Thought思考我现在需要解决什么问题我应该用哪个工具Action行动我决定调用“计算器”工具。Action Input行动输入输入参数是123 * 456。深度剖析Agent 本身不执行任何操作。它只负责“想”。它就像一个发号施令的将军输出的是结构化的指令文本比如一段要求调用某个函数的 JSON等待外部系统去实际执行。二、 Tools工具大模型的知识停留在训练日且无法与物理世界交互。Tools 就是赋予大模型联网、查数据库、执行代码、发送邮件能力的 API。深度考虑一工具的描述Description比代码更重要这是很多开发者最容易踩坑的地方。Agent 是如何知道该用哪个工具的完全依赖于您提供给它的description字符串。反面教材description用于搜索大模型会感到困惑不知道搜什么。优秀示范description当你需要获取关于当前天气、实时新闻或未知的客观事实时请使用此工具。输入应该是一个具体的搜索关键词。如果您发现 Agent 频繁调用错误的工具或者陷入死循环90% 的原因是您的工具描述写得不够清晰、边界不够明确。深度考虑二强类型与参数校验现代 LangChain 工具深度集成了Pydantic。您可以严格规定工具需要哪些输入参数如不仅需要搜索词还需要指定日期范围这能极大降低大模型“幻觉”导致的工具调用失败。三、 Toolkits工具箱既然工具这么好为什么不把 100 个工具全塞给 Agent因为大模型的上下文窗口是有限的且注意力会被稀释。如果工具描述占用了 4000 个 Token模型就很难专注于解决用户的问题了。核心价值按领域打包降低认知负载。Toolkits 是一种业务上的聚合。例如SQL Database Toolkit。当您想让 Agent 分析数据库时您只需要加载这个 Toolkit。它通常包含ListTablesTool看看库里有哪些表。InfoSQLDatabaseTool查看某张表的 Schema字段名、类型。QuerySQLDataBaseTool实际执行 SQL 语句。深度剖析Toolkit 实际上教给了 Agent 一套解决特定领域问题的标准SOP标准作业程序。Agent 会很自然地先查表名再查字段最后写 SQL而不是像无头苍蝇一样乱撞。四、 AgentExecutor运行引擎AgentExecutor 是把 Agent大脑和 Tools手脚结合在一起的运行时环境。它本质上是一个高级的while循环。深度执行逻辑The Agent Loop把用户输入交给 Agent。Agent 思考后决定调用 Tool A并生成参数。AgentExecutor 拦截这个指令实际去执行 Tool A。Tool A 返回结果我们称为Observation观察结果。AgentExecutor 将 Observation 喂回给 Agent问它“这是工具的结果你接下来怎么办”循环重复直到 Agent 输出一个特殊的指令Final Answer最终答案循环终止将结果返回给用户。健壮性处理AgentExecutor 的强大之处在于它的容错能力。如果大模型输出的 JSON 格式坏了或者工具执行超时报错AgentExecutor 不会直接崩溃而是会把错误信息变成一段 Observation 传回给 Agent“你刚才的调用报错了原因是参数类型不对请修正后重试。”它赋予了系统自我纠错的能力。1、Plan-and-execute Agent计划与执行智能体核心逻辑将大脑一分为二。先让一个“规划者Planner”模型统揽全局将复杂的大目标拆解为 5 个明确的子任务。然后交由“执行者Executor”一步一步去完成。优势极大地增强了处理长线任务的稳定性不会像普通 Agent 那样做着做着就跑偏了。2、BabyAGI AutoGPT自主智能体先驱核心逻辑引入了任务队列Task Queue和长期记忆Vector Store。深度剖析它们不仅仅是完成一次问答而是可以设定一个宏大的目标如“帮我调研市场上所有的竞品并写一份报告”。它们会自动生成任务列表执行任务根据执行结果自我反思Self-Reflection动态向队列中添加新任务并把有用的信息存入向量数据库以便后续查阅。这已经是非常接近“自动化数字员工”的雏形了。7、回调一、BaseCallbackHandlerBaseCallbackHandler通常简称为CallbackHandler是所有回调处理器的基类接口。它定义了一套极其详尽的“钩子Hooks”方法贯穿了 LangChain 组件运行的整个生命周期。核心逻辑它就像是在流水线的各个关键节点安装了监控探头。当事件发生时LangChain 底层会自动触发对应的方法。深度剖析关键生命周期事件LLM 层面on_llm_start: 模型开始生成前触发可获取输入的 Prompt。on_llm_new_token:极其重要当模型流式Streaming输出时每生成一个新字Token就会触发一次。这是实现前端打字机效果的核心。on_llm_end/on_llm_error: 模型生成结束或报错时触发可获取完整的输出文本或 Token 消耗统计。Chain 层面on_chain_start/on_chain_end/on_chain_error: 监听链路的输入输出流转。Tool Agent 层面on_tool_start: 工具开始执行前触发可看到 Agent 决定传给工具的具体参数。on_agent_action: Agent 决定采取某个动作时触发捕获 Agent 的“内心戏” Thought。on_agent_finish: Agent 最终完成任务时触发。二、StdOutCallbackHandler如果说BaseCallbackHandler是图纸那么StdOutCallbackHandler就是 LangChain 官方提供的一个最基础的实体实现类。核心功能顾名思义Standard Output它的作用就是拦截上述生命周期中的关键事件并把它们以不同颜色的格式化文本打印到控制台Terminal / Console上。深度应用场景在开发 Agent 或复杂的 SequentialChain 时它是不可或缺的调试神器。只要将其注入到 AgentExecutor 中您就能在控制台上清晰地看到绿色的字是用户的输入蓝色的字是 Agent 的思考过程黄色的字是工具的返回结果。这就好比把 Agent 的大脑思维过程直接投影在了屏幕上。局限性它只适合本地开发调试。在生产环境线上服务器中您通常不需要也不应该把大量中间过程打印到标准输出中。三、CallbackManager在实际业务中我们往往需要同时触发多个回调。比如同一个 Agent 运行期间既要在本地控制台打印日志使用StdOutCallbackHandler又要将 Token 消耗发送到监控系统使用DataDogCallbackHandler或自定义 Handler还要把生成的字逐个推送到 Web 前端。核心功能CallbackManager就是用来管理和调度这些 Handler 的。它是一个分发器Dispatcher。工作机制您将多个不同的 CallbackHandler 注册添加到CallbackManager中。当 LangChain 组件如 LLM触发on_llm_start事件时它并不会直接去找 Handler而是把事件报告给CallbackManager。CallbackManager会遍历它内部维护的 Handler 列表依次调用它们的on_llm_start方法。现代 LangChain 的演进重要提示在较新的 LangChain 版本中开发者通常不需要手动实例化CallbackManager。您只需要在调用组件如chain.invoke()时通过callbacks[handler1, handler2]参数传入一个 Handler 列表LangChain 底层会自动为您构建并管理这个 Manager。
