一、聊天模型核心能力定义聊天模型大语言模型LLM在各种与语言相关的任务例如文本生成、翻译、摘要、问答等中表现出色。现代 LLM 通常通过聊天模型接口访问该接口将消息列表作为输入并返回消息作为输出而不是使用纯文本。这里需要注意 LLM 与 LangChain 中聊天模型的关系在 LangChain 的官方文档中认为 LLM 大多数是纯文本补全模型。这些纯文本模型封装的 API 接受一个字符串提示作为输入并输出一个字符串补全结果 (实际上 LLM 还包括多模态输入)。OpenAI 的 GPT‑5 就是作为 LLM 来实现的。LangChain 中的聊天模型通常由 LLM 提供支持但经过专门调整以用于对话。关键在于它们不是接受单个字符串作为输入而是接受聊天消息列表并返回一条 AI 消息作为输出。通过 API 定义聊天模型方式 1ChatOpenAIChatOpenAI 定义聊天模型在快速上手模块中已经涉及。class langchain_openai.chat_models.base.ChatOpenAI 是 LangChain 为 OpenAI 的聊天模型(如 gpt‑5gpt‑5‑mini) 提供的具体实现类。其继承了 class langchain_openai.chat_models.base.BaseChatOpenAI且 BaseChatOpenAI 实现了标准的 Runnable 接口。ChatOpenAI 常用初始化参数说明:示例若使用其它与 OpenAI 兼容的大模型例如 DeepSeek则可以使用以下定义方式参数说明base_url出于与 OpenAI 兼容考虑要将 base_url 设置为https://api.deepseek.com/v1 来使用但注意此处 v1 与模型版本无关。openai_api_key需要单独申请 DeepSeek 的 API Key然后重新进行环境变量配置。invoke() 调用介绍方式 2 之前需要先来了解一下关于 Runnable 接口中的 .invoke() 调用。该方法是将单个输入转换为对应的输出。例如对于聊天模型来说就是根据用户的问题输入输出相应的答案。invoke() 方法定义请求参数input输入一个 Runnable 实例config默认空用于 Runnable 的配置。返回值返回一个 Runnable 实例class langchain_core.runnables.config.RunnableConfig 常用参数说明:具体示例下面的方式 2 会用到方式 2init_chat_model上面的 ChatOpenAI 用于明确创建 OpenAI 聊天模型的实例。而 init_chat_model() 是一个工厂函数它可以初始化多种支持的聊天模型 (如 OpenAI、Anthropic、FireworksAI 等)不仅仅是 OpenAI 的聊天模型。init_chat_model() 函数定义init_chat_model() 常用参数说明:init_chat_model() 的返回值说明 :函数返回一个与指定的 model_name 和 model_provider 相对应的 BaseChatModel (如ChatOpenAIChatAnthropic等)。注意要是模型可配置则返回一个聊天模型模拟器该模拟器在传入配置后于运行时才会初始化底层模型。示例 1基本用法使用不同的模型提供方需要安装为其各自包与设置各自的 API Key 环境变量例如OpenAI 环境变量配置为OPENAI_API_KEY your_openai_api_key安装命令pip install -U langchain-openaiAnthropic 环境变量配置为ANTHROPIC_API_KEY your_anthropic_api_key安装命令pip install -U langchain-anthropicDeepSeek 环境变量配置为DEEPSEEK_API_KEY your_deepseek_api_key安装命令pip install -U langchain-deepseekGoogleVertexAI 环境变量配置为GOOGLE_API_KEY your_google_api_key安装命令pip install -U langchain-google-vertexai输出示例 2创建可配置模型class langchain_core.runnables.config.RunnableConfig 常用参数说明:输出示例 3具有默认值的可配置模型输出相关问题:二、通过本地部署的 LLM 定义聊天模型ChatOllama若想使用 ChatOllama需要先安装 Ollama 包class langchain_ollama.chat_models.base.ChatOllama是 LangChain 为通过 Ollama 部署的聊天模型提供的具体实现类。ChatOllama同样也实现了标准的 Runnable 接口。ChatOllama 常用初始化参数说明:示例输出三、聊天模型 -- 调用工具调用工具是什么?工具调用根本作用是让大语言模型LLM具备与外部世界交互的能力。LLM 本身是一个封闭的知识系统其能力受限于其训练数据存在滞后性和内在的文本生成逻辑。它无法执行直接计算、查询实时信息、操作数据库或调用任何外部 API。工具调用打破了这层壁垒其作用具体体现在扩展能力边界模型可以借助工具完成它自身无法完成的任务如执行数学计算、搜索网络、查询数据库等。保证信息实时性通过调用搜索工具或数据库查询工具LLM 可以获取最新的、训练数据中不存在的信息避免回答过时或 “一本正经地胡说八道”。处理复杂任务将一个复杂的用户请求如 “分析我上个月的消费趋势”分解成多个步骤并依次调用不同的工具如 “从数据库获取数据” → “用 Python 进行数据分析” → “生成图表”来协同完成。协调这件事这更体现在 Agent 智能体上。连接现有系统可以将企业内部已有的系统、API 和数据库封装成工具让 LLM 成为一个用自然语言驱动的统一接口极大地提升了自动化和集成能力。在 LangChain 中聊天模型提供了额外的功能工具调用。它能使 LLM 与外部服务、API 和数据库进行交互。工具调用还可用于从非结构化数据中提取结构化信息并执行各种其他任务。例如当我们希望获取当前天气情况时由于 LLM 无法获取实时信息此时我们就可以借助工具通过外部服务进行搜索完成查询再例如当我们希望获取数据库表中的数据时由于 LLM 无法直接获取表数据此时我们就可以借助工具通过与数据库交互完成查询。流程Tool Creation创建数据库工具Tool Binding把工具绑定到大模型Tool Calling大模型输出工具调用参数Tool Invocation执行工具拿到数据库返回结果创建工具使用 tool 装饰器创建工具在 LangChain 中实现了一个tool 装饰器来创建工具tool 装饰器是自定义工具的最简单方法。如下所示:可以看出工具通过 tool 加 Python 函数实现其中该装饰器默认使用函数名称作为工具名称。该装饰器将使用函数的文档字符串作为工具的描述。因此函数名、类型提示和文档字符串都是传递给工具 Schema 的一部分不可缺失。定义好的描述是使模型良好运行的重要部分。什么是 Schema答想象以不同的方式比如我们在 JSON 中表示有关一个人的信息示例 1示例 2这两种表述同样有效尽管示例 2 显然比示例 1 更正式。记录的设计在很大程度上取决于其在应用程序中的预期用途因此这里没有正确或错误的答案。但是当应用程序说 “给我一个人的 JSON 记录” 时重要的是要确切地知道该如何组织记录。例如我们需要知道需要哪些字段以及如何表示这些值。这就是 JSON Schema 的用武之地。你可能见过这种可视化配置方式实际上是在构造 JSON Schema转换成编码方式则为以下内容此 JSON Schema 片段描述了上述第二个示例的结构若用此 JSON Schema “验证” 示例 1那么示例 1 是不符合当前 JSON Schema 的但是示例 2 可以 “验证” 通过。注意JSON Schema 是数据本身而不是计算机程序它只是一种 “描述其他数据结构” 的声明格式。简明扼要地描述数据的表面结构并根据数据自动验证数据很容易。但是由于 JSON Schema 不能包含任意代码因此无法表达数据元素之间的关系存在某些约束。因此对于足够复杂的数据格式任何 “验证工具” 都可能有两个验证阶段一个在 schema (或结构) 级别一个在语义级别。后一种检查可能需要使用更通用的编程语言来实现。最后回答一下问题Schema 就是描述其他数据结构的声明格式用于自动验证数据而存在。有了以上概念铺垫对于工具 schema它将从函数名、类型提示和文档字符串中获取相关属性以此来声明一个工具包括其名称、描述、输入参数、输出类型等等。这里需要说明的是若是简单定义工具如上述示例工具 schema 需要解析 Google 风格的文档字符串去获取【参数描述】。什么是 Google 风格的文档字符串Google 风格是 Python 文档字符串的一种写作规范。它并非 Python 语言官方强制要求而是由 Google 为其内部 Python 项目制定的规范后来因为其极高的可读性和简洁性而在整个 Python 社区中变得非常流行。它使用Args:Returns:等关键字参数描述简洁明了如下所示除了这种方式还有其他方式可以让工具 schema 获取相关工具声明需要的内容。下面再展示其他常用的工具定义模式模式 1依赖 Pydantic 类若使用 tool 定义工具时没有提供文档字符串则会报错点击运行报错ValueError: Function must have a docstring if description not provided.此时在 LangChain 中可以使用 Pydantic 类提供运行时数据验证和类型检查。通过 Field(description...) 添加字段描述LangChain 会自动提取。注意除非提供默认值否则所有字段都是required。如下所示完整代码如下所示注意是代码中 tool 的 args_schema 参数它表示工具函数在未提供描述、文档字符串等需要传递给工具 Schema 的内容时依赖 Pydantic 类使用 args_schema 参数定义并提供工具输入参数的 schema。默认为 None。点击运行后不会报错且将来运行时会进行数据验证。因此我们再次印证了函数名、类型提示和文档字符串都是传递给工具 Schema 的一部分不可缺失。模式 2依赖 Annotated在 LangChain 中可以依赖 Annotated 和文档字符串传递给工具 Schema。使用 StructuredTool 类提供的函数创建工具langchain_core.tools.structured.StructuredTool 类用来初始化工具其中 from_function 类方法通过给定的函数来创建并返回一个工具。from_function 类方法定义如下关键参数说明示例 1常规用法对于用该类方法创建的工具同样函数名、类型提示和文档字符串也都是传递给工具 Schema 的一部分不可缺失。示例 2加入配置依赖 Pydantic 类同样的让工具函数不提供描述、文档字符串等需要传递给工具 Schema 的内容。此时可以使用args_schema参数依赖 Pydantic 类定义并提供工具输入参数的 schema 属性。使用description参数替代文档字符串中对于工具描述的 schema 属性。示例 3加入 response_format 配置如果希望我们的工具区分消息内容content和其他工件artifact让大模型读取 content而一些用来构造 content 的原始数据保存下来若后续有一些记录、分析的步骤就可以派上用场了这就是 artifact。artifact 通常需要使用字典 Dict 或列表 List 保存。接下来举个例子再来理解下。例如我们定义了一个搜索天气的 tool若使用搜索引擎工具查询 “今天的天气如何” 时content 可能是“根据最新搜索结果今天北京晴气温在 25℃到 32℃之间。建议穿短袖衣物。”artifact 可能是某搜索引擎 API 返回的完整 JSON 响应其中包含多个搜索结果条目、每个条目的标题、链接、摘要、排名等元数据。则对于以上原生数据无论我们今后做日志记录、分析或自定义后续的处理都很方便。例如存在以下场景我们不仅仅想要一个总结性的答案还想要具体的链接、来源或多个备选答案。工具的 content 输出不符合你的预期我们想查看原始数据来理解问题出在哪里是工具解析的问题还是 API 本身返回的问题。需要记录每次工具调用的完整原始响应以满足数据分析的要求。……从这里就可以对比出只返回 content 无法做到这些事情。如何做到我们需要在定义工具时指定 response_formatcontent_and_artifact 参数并确保我们返回一个元组 (content, artifact)代码如下说明tool也支持response_format参数如果我们直接使用工具参数调用工具将只返回输出的 content 部分若想要看到工具返回的元组我们需要模拟大模型调用工具的姿势如下所示。这将返回一个ToolMessage结果如下小结一下由于 LLM 大多理解文本所以工具的主要输出 content 必须是结构良好、简洁的文本以便模型能够轻松理解和基于它进行推理、生成下一步的指令。在链Chain中工具调用之后的其他组件或函数可能需要工具的原始且结构化数据即 artifact来执行特定操作。这些数据可能是庞大的、且非文本的。这些数据不适合直接塞给模型。因此artifact 其实是为了给链中后续的组件或函数使用的不被大模型所直接使用