1. 从协议到适配器各家的 API 在 URL、鉴权、消息表示、工具调用、错误类型、流式协议上都可能不同。LangChain 的分工是Core 定义基类与消息合同provider 包继承这些抽象并负责把数据翻译到服务商 API。可以把适配器想成旅行插头它不改变电器的用途也不能保证目的地每项服务完全相同但把物理接口差异集中到适配器一侧。2.init_chat_model的用户用法先看一段不请求模型的创建示例需要安装 provider 包但这里只构造对象、不调用invoke因此不需要 API Key也不会联网。选择一种包管理方式不要混用使用 uv 的独立项目可执行# uv 项目uvaddlangchain langchain-openai# macOS / Linuxpython-mvenv .venvsource.venv/bin/activate python-mpipinstalllangchain langchain-openai# Windows PowerShellpython-m venv.venv.venv\Scripts\Activate.ps1 python-m pip install langchain langchain-openaifromlangchain.chat_modelsimportinit_chat_model modelinit_chat_model(openai:替换为当前服务商支持的模型标识,temperature0)print(type(model).__name__)创建阶段解析 provider、按需导入适配类并构造对象这一步不请求模型因此不需要 API Key 或联网。真正调用.invoke(...)才会访问在线 API 并可能产生费用执行前设置有效的OPENAI_API_KEY确认模型 ID 属于你的账号/区域可用型号。密钥只放环境变量不要写进源码# macOS / LinuxexportOPENAI_API_KEY你的密钥# Windows PowerShell$env:OPENAI_API_KEY你的密钥replymodel.invoke(用一句话解释模型适配器。)print(reply.content)3. 你写集成时实现的是哪一层新 provider 通常需要提供自己的集成包、客户端和鉴权参数实现BaseChatModel的核心生成方法_generate接收标准化消息并返回ChatResult在生成结果中提供AIMessage并负责把通用消息转换为 provider 请求、把响应转换回来。如果它支持原生异步、流式或结构化输出也可以实现或覆盖相应能力。下面是刻意简化的伪适配器只展示“覆盖通用生成入口”的形状client和转换函数均为占位未展示消息转换的具体 API也省略构造器、类型标注、错误映射、streaming 和参数验证因此它不是可运行实现# 伪代码不要直接用于生产也不会执行真实 API 请求。classExampleChatModel(BaseChatModel):model:strpropertydef_llm_type(self)-str:returnexample-providerdef_generate(self,messages,stopNone,run_managerNone,**kwargs):provider_payloadconvert_messages_for_example_api(messages)provider_responseself.client.generate(provider_payload)returnconvert_response_to_chat_result(provider_response)真正集成不能只实现 happy path需考虑异常映射、流式 chunks、usage metadata、工具调用、token计数与共同测试。4. 源码设计解析init_chat_model如何找到 Provider公开入口init_chat_model(...)会交给内部 helper 处理。helper 先通过_parse_model解析 provider 与模型名再从_get_chat_model_creator获取构造函数最后传入模型 ID 和其他参数创建适配器。主要逻辑可简化为# 概念伪代码展示工厂步骤不是可直接运行的 LangChain API。provider,model_idparse_model_identifier(openai:some-model)creatorget_provider_creator(provider)modelcreator(modelmodel_id,**kwargs)实际使用仍是调用公开的init_chat_model(openai:some-model)。解析器会将它拆为modelsome-model与model_provideropenai。若没写 provider当前实现会尝试按部分模型命名规则推断推断不出来时会明确要求调用者传入 provider。显式标注通常更易读、也更稳妥尤其是多个服务共用类似模型名时。provider 注册表保存模块路径、模型类名和创建函数。creator 查找阶段才按需导入对应 provider 模块缺少集成包时工厂会给出安装提示。惰性导入把可选依赖隔离开只使用本地 Runnable 的应用无需安装任何模型 SDK只用 OpenAI 时也不必安装 Anthropic、Google 等所有集成包。provider 集成包各自实现BaseChatModel所要求的生成接口并负责消息序列化、鉴权、参数转换、错误映射及模型特有能力。这套工厂也不是魔法兼容层统一的是常用调用形状和消息契约原生工具调用、结构化输出、上下文上限、参数名称等能力仍因模型而异。换 provider 时应用代码可能少改但仍需核对它实际支持的功能。源码位置以下路径相对 LangChain 仓库根目录libs/langchain_v1/langchain/chat_models/base.pyinit_chat_model解析 provider 和模型 ID再通过注册表与延迟导入找到集成包的创建器。libs/core/langchain_core/language_models/chat_models.pyBaseChatModel定义 chat model 的invoke、_generate等共同调用契约。libs/partners/openai/langchain_openai/chat_models/base.pyChatOpenAI将通用消息与参数转换为 OpenAI 请求并把响应适配回 LangChain 消息。libs/langchain_v1/pyproject.toml声明langchain包依赖及可选 provider 集成依赖。为什么这样设计如果 provider 包是核心包的强依赖安装基础框架就必须拉入大量不需要的 SDK版本冲突和安装体积都会上升如果每个应用各自写 provider 分派和导入又会重复处理模型类、错误提示和缺失依赖。注册表加按需导入把这类维护集中到框架工厂中同时保留第三方集成独立发布的空间。5. 可移植性不是“功能完全相同”统一接口让基本调用方式相似但 provider 能力可能不同某模型支持工具调用另一模型可能没有参数、上下文上限和结构化输出支持也会变化。因此应用应使用共同能力或明确针对 provider 分支并查看集成文档/模型 profile而不是假定所有实现等价。小结provider integration 是插件/适配器它执行供应商特有逻辑同时遵守 Core 的模型接口。init_chat_model把 provider 解析和导入收拢到工厂而不是散落在每个应用里。好抽象统一的是边界不会抹掉底层能力差异。本系列导航上一篇02 消息、ChatPromptTemplate 与 Chat Model 调用链下一篇04 Runnable 如何统一调用、批处理、异步与流式接口全系列LangChain 源码入门 
长河君 · 2026/10/15 13:53:10 · 阅读 1.2k LangChain 源码入门 03：BaseChatModel 与 Provider 适配器——模型如何接入 LangChain
1. 从协议到适配器各家的 API 在 URL、鉴权、消息表示、工具调用、错误类型、流式协议上都可能不同。LangChain 的分工是Core 定义基类与消息合同provider 包继承这些抽象并负责把数据翻译到服务商 API。可以把适配器想成旅行插头它不改变电器的用途也不能保证目的地每项服务完全相同但把物理接口差异集中到适配器一侧。2.init_chat_model的用户用法先看一段不请求模型的创建示例需要安装 provider 包但这里只构造对象、不调用invoke因此不需要 API Key也不会联网。选择一种包管理方式不要混用使用 uv 的独立项目可执行# uv 项目uvaddlangchain langchain-openai# macOS / Linuxpython-mvenv .venvsource.venv/bin/activate python-mpipinstalllangchain langchain-openai# Windows PowerShellpython-m venv.venv.venv\Scripts\Activate.ps1 python-m pip install langchain langchain-openaifromlangchain.chat_modelsimportinit_chat_model modelinit_chat_model(openai:替换为当前服务商支持的模型标识,temperature0)print(type(model).__name__)创建阶段解析 provider、按需导入适配类并构造对象这一步不请求模型因此不需要 API Key 或联网。真正调用.invoke(...)才会访问在线 API 并可能产生费用执行前设置有效的OPENAI_API_KEY确认模型 ID 属于你的账号/区域可用型号。密钥只放环境变量不要写进源码# macOS / LinuxexportOPENAI_API_KEY你的密钥# Windows PowerShell$env:OPENAI_API_KEY你的密钥replymodel.invoke(用一句话解释模型适配器。)print(reply.content)3. 你写集成时实现的是哪一层新 provider 通常需要提供自己的集成包、客户端和鉴权参数实现BaseChatModel的核心生成方法_generate接收标准化消息并返回ChatResult在生成结果中提供AIMessage并负责把通用消息转换为 provider 请求、把响应转换回来。如果它支持原生异步、流式或结构化输出也可以实现或覆盖相应能力。下面是刻意简化的伪适配器只展示“覆盖通用生成入口”的形状client和转换函数均为占位未展示消息转换的具体 API也省略构造器、类型标注、错误映射、streaming 和参数验证因此它不是可运行实现# 伪代码不要直接用于生产也不会执行真实 API 请求。classExampleChatModel(BaseChatModel):model:strpropertydef_llm_type(self)-str:returnexample-providerdef_generate(self,messages,stopNone,run_managerNone,**kwargs):provider_payloadconvert_messages_for_example_api(messages)provider_responseself.client.generate(provider_payload)returnconvert_response_to_chat_result(provider_response)真正集成不能只实现 happy path需考虑异常映射、流式 chunks、usage metadata、工具调用、token计数与共同测试。4. 源码设计解析init_chat_model如何找到 Provider公开入口init_chat_model(...)会交给内部 helper 处理。helper 先通过_parse_model解析 provider 与模型名再从_get_chat_model_creator获取构造函数最后传入模型 ID 和其他参数创建适配器。主要逻辑可简化为# 概念伪代码展示工厂步骤不是可直接运行的 LangChain API。provider,model_idparse_model_identifier(openai:some-model)creatorget_provider_creator(provider)modelcreator(modelmodel_id,**kwargs)实际使用仍是调用公开的init_chat_model(openai:some-model)。解析器会将它拆为modelsome-model与model_provideropenai。若没写 provider当前实现会尝试按部分模型命名规则推断推断不出来时会明确要求调用者传入 provider。显式标注通常更易读、也更稳妥尤其是多个服务共用类似模型名时。provider 注册表保存模块路径、模型类名和创建函数。creator 查找阶段才按需导入对应 provider 模块缺少集成包时工厂会给出安装提示。惰性导入把可选依赖隔离开只使用本地 Runnable 的应用无需安装任何模型 SDK只用 OpenAI 时也不必安装 Anthropic、Google 等所有集成包。provider 集成包各自实现BaseChatModel所要求的生成接口并负责消息序列化、鉴权、参数转换、错误映射及模型特有能力。这套工厂也不是魔法兼容层统一的是常用调用形状和消息契约原生工具调用、结构化输出、上下文上限、参数名称等能力仍因模型而异。换 provider 时应用代码可能少改但仍需核对它实际支持的功能。源码位置以下路径相对 LangChain 仓库根目录libs/langchain_v1/langchain/chat_models/base.pyinit_chat_model解析 provider 和模型 ID再通过注册表与延迟导入找到集成包的创建器。libs/core/langchain_core/language_models/chat_models.pyBaseChatModel定义 chat model 的invoke、_generate等共同调用契约。libs/partners/openai/langchain_openai/chat_models/base.pyChatOpenAI将通用消息与参数转换为 OpenAI 请求并把响应适配回 LangChain 消息。libs/langchain_v1/pyproject.toml声明langchain包依赖及可选 provider 集成依赖。为什么这样设计如果 provider 包是核心包的强依赖安装基础框架就必须拉入大量不需要的 SDK版本冲突和安装体积都会上升如果每个应用各自写 provider 分派和导入又会重复处理模型类、错误提示和缺失依赖。注册表加按需导入把这类维护集中到框架工厂中同时保留第三方集成独立发布的空间。5. 可移植性不是“功能完全相同”统一接口让基本调用方式相似但 provider 能力可能不同某模型支持工具调用另一模型可能没有参数、上下文上限和结构化输出支持也会变化。因此应用应使用共同能力或明确针对 provider 分支并查看集成文档/模型 profile而不是假定所有实现等价。小结provider integration 是插件/适配器它执行供应商特有逻辑同时遵守 Core 的模型接口。init_chat_model把 provider 解析和导入收拢到工厂而不是散落在每个应用里。好抽象统一的是边界不会抹掉底层能力差异。本系列导航上一篇02 消息、ChatPromptTemplate 与 Chat Model 调用链下一篇04 Runnable 如何统一调用、批处理、异步与流式接口全系列LangChain 源码入门