精读 LangChain 官方文档（二）Model 篇：把模型调用升级成工程化推理接口

本文基于 LangChain Python 官方文档整理：
Models：https://docs.langchain.com/oss/python/langchain/models
Markdown 版本：https://docs.langchain.com/oss/python/langchain/models.md
对应开源文档编辑入口：
https://github.com/langchain-ai/docs/edit/main/src/oss/langchain/models.mdx

跑通第一个 create_agent 示例以后，下一个问题就是，模型到底怎么接？

如果只是写一个 demo，模型调用看起来像一行代码：输入一句话，返回一段文本。

但一旦进入真实业务，问题就会马上变复杂：同一个系统可能要切换供应商，要控制 temperature 和 max_tokens，要处理超时和重试，要支持流式输出，要让模型调用工具，要把结果变成可入库的结构化对象，还要在日志里追踪 token 用量和调用成本。

这就是 LangChain Models 文档真正值得精读的地方。

它不是只在讲“怎么初始化一个模型”，而是在讲：如何把模型从一个孤立的文本生成 API，包装成一个可调用、可配置、可观测、可扩展的工程化推理接口。

这篇文档的核心主线可以概括成一句话：

Model Interface = Provider Adapter + Invocation Protocol + Capability Contract。

也就是说，LangChain 的模型层主要解决三件事：

• Provider Adapter：把不同模型供应商接到同一套接口下面。
• Invocation Protocol：统一 invoke、stream、batch 这些调用方式。
• Capability Contract：描述模型是否支持工具调用、结构化输出、多模态、推理、缓存和运行时切换。

下面这张图先把主线串起来：

图里可以重点看这条链路：

Provider -> Chat Model -> Invocation -> Capabilities -> Production Control

理解这条链路后，Models 页面里的参数、方法和高级主题就不会再是散落的 API 清单，而是同一个模型工程层的不同侧面。

1. Models（模型层）：它到底解决什么问题

它解决的问题：
Models 解决的是“如何让大模型稳定进入应用系统”，而不是只解决“如何问模型一句话”。

官方文档一开始强调，LLM 能解释和生成文本，也能做翻译、总结、问答等任务。更重要的是，很多模型已经不只是文本生成器，还支持工具调用、结构化输出、多模态和推理。

在 Agent 系统里，模型是 reasoning engine，也就是推理引擎。它决定什么时候回答、什么时候调用工具、如何解释工具结果，以及什么时候给出最终答案。

示例：

import os

from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

response = model.invoke("请用三句话解释 LangChain 的模型层有什么价值。")
print(response.text())

这里：

• ChatOpenAI：LangChain 的 OpenAI-compatible 聊天模型封装，可以连接兼容 OpenAI 协议的模型服务。
• model：模型实例，封装了模型名称、鉴权信息、调用地址和默认参数。
• qwen3.7-max：本文示例默认使用的模型名称。
• QWEN_API_KEY：环境变量名，用来保存 API 密钥，避免把真实密钥写进代码。
• QWEN_BASE_URL：环境变量名，用来保存 OpenAI-compatible 服务地址。
• invoke：一次性调用模型，等待完整响应后返回。
• response.text()：从返回的消息对象中提取文本内容。

业务场景：
在企业客服系统里，模型不是孤立存在的。它要根据用户问题判断是否查订单、是否调用售后规则、是否输出结构化工单。模型层如果没有统一接口，后面所有 Agent、工具、前端和监控都会被供应商差异拖住。

最简记法：

模型层不是“调用模型”，而是把模型变成应用系统可管理的推理接口。

2. Basic Usage（基础用法）：Agent 里用，也可以单独用

它解决的问题：
基础用法让同一个模型接口既能服务 Agent，也能服务普通文本生成、分类和抽取任务。

官方文档把模型用法分成两类：

• With agents：在创建 Agent 时指定模型，让模型参与 Agent 循环。
• Standalone：直接调用模型，不进入 Agent 循环，适合简单生成、分类、抽取。

示例：

import os

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

# 单独使用模型：适合一次性分类、总结、抽取
summary = model.invoke("请总结一段售后工单的核心诉求。")

# 放入 Agent：适合模型需要结合工具和状态完成任务
agent = create_agent(
    model=model,
    tools=[],
    system_prompt="你是一名企业客服助手，回答要先给结论，再说明依据。",
)

这里：

• summary：单独模型调用的返回结果，适合不需要工具和多步推理的任务。
• create_agent：LangChain 创建 Agent 的入口。
• tools：Agent 可调用的工具列表，这里为空表示暂不调用外部工具。
• system_prompt：系统提示词，用来定义 Agent 的角色、语气和约束。

业务场景：
如果你只是把一段用户反馈归类为“物流、售后、退款”，单独调用模型就够了。如果你要查订单、核对政策、生成处理建议，就应该把模型放进 Agent，让它和工具、状态、日志一起工作。

最简记法：

简单任务直接调模型，复杂任务把模型放进 Agent。

3. Initialize a Model（模型初始化）：把供应商差异藏到统一接口后面

它解决的问题：
模型初始化解决的是“不同供应商如何接入同一套 LangChain 调用接口”。

官方文档推荐的通用入口是 init_chat_model。它可以通过模型名称和供应商信息初始化不同 provider 的聊天模型。实际项目里，也可以直接使用具体模型类，例如 ChatOpenAI。

示例：

import os

from langchain.chat_models import init_chat_model

model = init_chat_model(
    model="qwen3.7-max",
    model_provider="openai",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

response = model.invoke("请解释一下什么是模型供应商适配层。")

这里：

• init_chat_model：LangChain 的通用聊天模型初始化函数。
• model：模型名称或模型标识。
• model_provider：模型供应商标识。这里用 openai 表示按 OpenAI-compatible 协议连接。
• api_key：鉴权密钥参数，建议从环境变量读取。
• base_url：自定义 API 地址，用于 OpenAI-compatible 服务。

业务场景：
一个公司可能先用 A 模型做内部助手，后续因为成本、稳定性或上下文长度切换到 B 模型。如果业务代码直接写死供应商 SDK，切换成本会很高；如果统一经过 LangChain 模型接口，后续迁移就会轻很多。

最简记法：

初始化不是为了创建对象，而是为了把不同供应商接到同一条模型管线上。

4. Supported Providers（供应商与模型）：模型名称更新不必等框架发版

它解决的问题：
供应商支持解决的是“如何在不重写业务逻辑的情况下试验和切换不同模型”。

官方文档说明，LangChain 通过独立的 integration packages 支持主流模型供应商。每个供应商包实现同一套标准接口，所以应用逻辑可以尽量不关心底层供应商细节。

更关键的一点是：新的模型名称通常可以直接传给供应商 API，不一定要等 LangChain 核心包更新。

示例：

import os

from langchain_openai import ChatOpenAI

primary_model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

fallback_model = ChatOpenAI(
    model="qwen3.7-plus",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

这里：

• primary_model：主模型实例，适合承担复杂推理或高质量输出任务。
• fallback_model：备用模型实例，适合在成本、限流或可用性约束下使用。
• model 参数：只要供应商 API 支持，通常可以传入新的模型名称。

业务场景：
做 AI 写作平台时，普通摘要可以用成本更低的模型，长文改写或复杂推理再用更强模型。供应商和模型选择应该是工程配置，而不是散落在业务函数里的硬编码。

最简记法：

LangChain 让模型切换尽量变成配置问题，而不是业务重写问题。

5. Parameters（模型参数）：控制模型行为，而不是只看模型名称

它解决的问题：
参数让同一个模型在不同业务场景下表现出不同的稳定性、创造性、长度和容错能力。

官方文档列出的常见参数包括：

• model：模型名称或标识。
• api_key：供应商鉴权密钥。
• temperature：控制随机性。
• max_tokens：控制最大输出长度。
• timeout：控制请求超时时间。
• max_retries：控制失败后的重试次数。

示例：

import os

from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
    temperature=0.2,
    max_tokens=1200,
    timeout=60,
    max_retries=6,
)

response = model.invoke("请把用户投诉整理成一份结构清晰的处理建议。")

这里：

• temperature=0.2：降低随机性，让输出更稳定，适合客服、工单、知识库问答。
• max_tokens=1200：限制输出长度，避免回答过长导致成本失控。
• timeout=60：最多等待 60 秒，避免请求长时间阻塞。
• max_retries=6：遇到网络错误、限流或服务端错误时重试，官方默认值就是 6。

业务场景：
生成营销文案可以适当提高 temperature，让语言更有变化；生成合同摘要、客服处理建议、数据库字段解释时，应该降低 temperature，让输出更稳定。

最简记法：

模型名称决定上限，参数决定它在当前业务里的行为边界。

6. Connection Resilience（连接韧性）：失败重试不是补丁，而是生产默认项

它解决的问题：
连接韧性解决的是“模型 API 不稳定时，应用如何保持可用”。

官方文档说明，LangChain chat models 默认会对网络错误、429 限流和 5xx 服务端错误做指数退避重试。401 未授权、404 不存在这类客户端错误不会重试。

示例：

import os

from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
    timeout=120,
    max_retries=10,
)

这里：

• timeout：单次请求的最长等待时间。
• max_retries：最大重试次数。长任务、弱网络、复杂 Agent 可以适当提高。
• 429：请求频率过高导致的限流错误。
• 5xx：供应商服务端错误。
• 401：鉴权失败，通常是密钥错误，不应该靠重试解决。

业务场景：
一个 Agent 正在处理 20 分钟的数据分析任务，如果中途因为一次临时网络波动失败，用户体验会很差。模型层的重试、Agent 层的 checkpointer、任务层的状态保存应该一起设计。

最简记法：

生产环境里的模型调用，默认要考虑超时、重试和恢复。

7. Invocation（调用方式）：invoke、stream、batch 对应三类业务节奏

它解决的问题：
调用方式解决的是“模型输出应该一次拿完、边生成边展示，还是并发处理多条输入”。

官方文档把主要调用方法分成三类：

• invoke()：单次调用，返回完整消息。
• stream()：流式调用，边生成边返回 chunk。
• batch()：批量调用，多条独立输入并发处理。

示例：

# invoke：适合一次性拿完整结果
answer = model.invoke("请解释什么是 invoke。")

# stream：适合前端逐字展示或长回答生成
for chunk in model.stream("请逐步解释 LangChain 模型流式输出。"):
    print(chunk.text, end="", flush=True)

# batch：适合批量分类、批量摘要、批量标签生成
responses = model.batch([
    "请判断这条反馈属于售后还是物流：蛋糕破损了。",
    "请判断这条反馈属于售后还是物流：快递还没到。",
    "请判断这条反馈属于售后还是物流：想改收货地址。",
])

这里：

• invoke()：返回单个 AIMessage，适合逻辑简单、结果较短的任务。
• stream()：返回多个 AIMessageChunk，适合长文本和实时 UI。
• batch()：并发处理多个独立输入，适合后台批处理。
• chunk.text：流式 chunk 中的文本片段。

业务场景：
后台每天批量给 500 条用户评论打标签，适合 batch()；在线客服回答用户问题，适合 invoke()；AI 写作工具生成长文章，适合 stream()，因为用户不想等到最后才看到结果。

最简记法：

invoke 管单次结果，stream 管实时体验，batch 管批量吞吐。

8. Tool Calling（工具调用）：模型不直接做事，而是请求程序做事

它解决的问题：
工具调用让模型可以请求外部系统，例如数据库查询、Web 搜索、代码执行或业务 API。

官方文档说明，一个工具通常由两部分组成：

• schema：工具名称、描述和参数定义。
• function 或 coroutine：真正执行动作的函数或协程。

模型拿到工具定义后，可以在后续调用中决定是否使用工具。LangChain 使用 bind_tools 把工具绑定到模型上。

示例：

import os

from langchain.tools import tool
from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

# 查询订单状态的工具函数，供模型在需要订单信息时调用
@tool
def get_order_status(order_id: str) -> str:
    """根据订单编号查询订单状态。"""
    return f"订单 {order_id} 当前状态：已发货，预计明天送达。"

model_with_tools = model.bind_tools([get_order_status])

response = model_with_tools.invoke(
    "请帮我查一下订单 A10086 到哪里了，并用一句话回复用户。"
)

print(response.tool_calls)

这里：

• @tool：把普通 Python 函数声明成 LangChain 工具。
• get_order_status：工具函数名，模型会根据名称和描述判断是否需要调用。
• order_id：工具参数，表示订单编号。
• bind_tools：把工具列表绑定到模型实例。
• tool_calls：模型返回的工具调用请求列表。

业务场景：
客服助手不能凭空回答订单状态。它应该先请求订单查询工具，再根据查询结果生成面向用户的回复。这就是工具调用的价值：让模型负责判断和表达，让程序负责真实动作。

最简记法：

工具调用不是让模型执行代码，而是让模型提出可执行请求。

9. Structured Output（结构化输出）：把回答变成可校验的数据

它解决的问题：
结构化输出解决的是“模型回答如何被程序稳定解析、校验、入库和展示”。

官方文档说明，LangChain 支持让模型输出匹配给定 schema。常见 schema 形式包括 Pydantic、TypedDict、JSON Schema 等。

示例：

import os

from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

class TicketSummary(BaseModel):
    """售后工单摘要。"""

    category: str = Field(description="工单类别，例如物流、退款、破损、改地址")
    urgency: str = Field(description="紧急程度，例如低、中、高")
    user_intent: str = Field(description="用户最核心的诉求")
    suggested_reply: str = Field(description="建议回复给用户的话")

model_with_structure = model.with_structured_output(TicketSummary)

result = model_with_structure.invoke(
    "用户说：蛋糕收到时已经压坏了，今天生日会要用，现在很着急。"
)

print(result)

这里：

• BaseModel：Pydantic 的模型基类，用来定义结构化数据。
• Field：字段定义工具，可以写字段说明。
• TicketSummary：结构化输出 schema，约束模型返回的字段。
• category：工单类别字段。
• urgency：紧急程度字段。
• user_intent：用户意图字段。
• suggested_reply：建议回复字段。
• with_structured_output：让模型按指定结构返回结果。

业务场景：
如果客服系统要把 AI 输出写入数据库，就不能只拿一段自然语言。它需要 category、urgency、user_intent 这些字段，后续才能筛选、统计、派单和看板展示。

最简记法：

自然语言适合给人读，结构化输出适合给系统用。

10. Model Profiles（模型画像）：先知道模型能做什么，再决定怎么用

它解决的问题：
模型画像解决的是“应用如何动态识别模型能力，而不是靠人工记忆每个模型的特性”。

官方文档提到，LangChain chat models 可以通过 profile 属性暴露模型能力，例如：

• max_input_tokens：最大输入 token 数。
• image_inputs：是否支持图片输入。
• reasoning_output：是否支持推理输出。
• tool_calling：是否支持工具调用。
• structured_output：是否支持结构化输出。

示例：

profile = model.profile

if profile and profile.get("tool_calling"):
    print("当前模型支持工具调用。")

if profile and profile.get("max_input_tokens", 0) > 100000:
    print("当前模型适合处理较长上下文。")

这里：

• profile：模型能力画像字典。
• max_input_tokens：模型可接收的最大输入规模。
• tool_calling：模型是否适合进入工具调用链路。
• structured_output：模型是否适合做稳定结构化返回。

业务场景：
一个文档分析系统可以根据 max_input_tokens 决定是否先压缩上下文；一个 Agent 平台可以根据 tool_calling 决定某个模型能不能出现在“可调用工具”的模型列表里。

最简记法：

模型画像就是模型能力的机器可读说明书。

11. Multimodal 与 Reasoning（多模态与推理）：模型能力不再只有文本

它解决的问题：
多模态和推理能力解决的是“模型输入输出不再只是普通文本时，应用如何统一处理内容块”。

官方文档把多模态列为模型能力之一。很多模型可以处理图片、音频、视频等非文本信息。推理模型还可能输出 reasoning 相关内容块，用来表达中间推理过程或摘要。

示例：

response = model.invoke([
    {
        "role": "user",
        "content": [
            {"type": "text", "text": "请根据这张商品图判断用户可能关注哪些卖点。"},
            {"type": "image_url", "image_url": {"url": "https://example.com/product.png"}},
        ],
    }
])

for block in response.content_blocks:
    if block["type"] == "text":
        print(block["text"])

这里：

• content：消息内容，可以从字符串升级成内容块列表。
• type：内容块类型，例如 text、image_url、reasoning。
• image_url：图片输入地址。
• content_blocks：LangChain 标准化后的内容块列表。

业务场景：
电商运营助手可以读取商品图，生成卖点建议；质检系统可以读取用户上传照片，判断是否属于包装破损；数据分析助手可以在推理模型输出里保留推理摘要，方便调试。

最简记法：

多模态让模型看见更多信息，推理能力让模型处理更复杂任务。

12. Prompt Caching 与 Server-side Tool Use（缓存与服务端工具）：成本和能力都开始下沉到供应商侧

它解决的问题：
缓存和服务端工具解决的是“如何降低重复上下文成本，以及如何利用供应商内置工具能力”。

官方文档把 prompt caching 分成三层：

• provider implicit caching：供应商自动缓存，命中后自动降低成本或延迟。
• provider explicit controls：由开发者显式指定缓存点。
• LangChain middleware：在 Agent 中对稳定的系统提示词、工具内容做缓存优化。

同时，一些供应商支持 server-side tool use，也就是模型可以在服务端完成 Web 搜索、代码解释器等工具循环，并把调用和结果作为内容块返回。

示例：

response = model.invoke(
    "请基于稳定的公司售后政策，生成一段给用户的解释。"
)

print(response.usage_metadata)

这里：

• prompt caching：提示词缓存，通常用于重复的大段系统提示词、工具说明或稳定上下文。
• usage_metadata：模型响应里的用量元数据，可能包含 token 和缓存命中相关信息。
• server-side tool use：供应商侧工具调用，工具执行不一定需要本地 ToolMessage 往返。

业务场景：
企业知识库助手每次都会带上相同的角色规则和长工具说明，如果供应商支持缓存，重复 token 成本可能下降。研究助手如果使用供应商内置 Web 搜索，也可能在单轮响应里完成搜索与总结。

最简记法：

缓存优化成本，服务端工具扩展能力，但都要看供应商支持边界。

13. Rate Limiting、Base URL、Token Usage（生产治理）：模型调用也要有流量、网络和成本账本

它解决的问题：
生产治理解决的是“模型调用上线后，如何控制流量、连接地址、代理、token 用量和排查信息”。

官方文档提到几个非常工程化的点：

• rate_limiter：控制请求速率。
• base_url：连接 OpenAI-compatible 服务或代理地址。
• openai_proxy：在特定集成里配置 HTTP 代理。
• logprobs：获取 token 级概率信息。
• usage_metadata：获取 token 用量。
• RunnableConfig：在调用时传入 run_name、tags、metadata、callbacks、max_concurrency 等运行配置。

示例：

import os

from langchain_core.rate_limiters import InMemoryRateLimiter
from langchain_openai import ChatOpenAI

rate_limiter = InMemoryRateLimiter(
    requests_per_second=0.2,
    check_every_n_seconds=0.1,
    max_bucket_size=5,
)

model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
    rate_limiter=rate_limiter,
)

response = model.invoke(
    "请生成一段客服回复。",
    config={
        "run_name": "customer_reply_generation",
        "tags": ["customer-service", "demo"],
        "metadata": {"business": "points_mall"},
    },
)

print(response.usage_metadata)

这里：

• InMemoryRateLimiter：LangChain 内置的内存限流器。
• requests_per_second：每秒允许的请求数。
• check_every_n_seconds：检查是否可发起请求的间隔。
• max_bucket_size：令牌桶最大突发容量。
• run_name：本次调用在日志和追踪里的名称。
• tags：标签，用于追踪系统里过滤和分组。
• metadata：业务元数据，可记录用户、订单、业务线等上下文。
• usage_metadata：token 用量和相关统计信息。

业务场景：
如果一个后台任务同时处理 1000 条评论，没有限流可能瞬间打爆供应商额度；如果没有 metadata，后续很难知道某次高成本调用来自哪个业务模块。

最简记法：

生产里的模型调用，既要跑得动，也要查得清、控得住、算得出成本。

14. Configurable Models 与 Dynamic Model Selection（运行时选型）：让模型选择进入业务策略层

它解决的问题：
运行时选型解决的是“同一个应用如何根据任务复杂度、成本、上下文和用户等级选择不同模型”。

官方文档讲了两种方式：

• configurable_fields：让模型字段在运行时通过配置切换。
• dynamic model selection：通过 middleware 根据当前 state 和 context 动态选择模型。

示例：

import os

from langchain.agents import create_agent
from langchain.agents.middleware import ModelRequest, ModelResponse, wrap_model_call
from langchain_openai import ChatOpenAI

basic_model = ChatOpenAI(
    model="qwen3.7-plus",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

advanced_model = ChatOpenAI(
    model="qwen3.7-max",
    api_key=os.environ["QWEN_API_KEY"],
    base_url=os.environ["QWEN_BASE_URL"],
)

# 根据对话复杂度动态选择模型，短对话用基础模型，长对话用高级模型
@wrap_model_call
def dynamic_model_selection(request: ModelRequest, handler) -> ModelResponse:
    """根据当前消息数量选择合适的模型。"""
    message_count = len(request.state["messages"])

    if message_count > 10:
        selected_model = advanced_model
    else:
        selected_model = basic_model

    return handler(request.override(model=selected_model))

agent = create_agent(
    model=basic_model,
    tools=[],
    middleware=[dynamic_model_selection],
)

这里：

• basic_model：基础模型，适合短任务、低成本任务。
• advanced_model：高级模型，适合长上下文、复杂推理或高价值任务。
• @wrap_model_call：模型调用中间件装饰器，用来拦截并改写模型调用。
• ModelRequest：模型调用请求对象，包含当前 state、runtime context 等信息。
• ModelResponse：模型调用响应对象。
• request.state["messages"]：当前 Agent 状态里的消息列表。
• request.override(model=selected_model)：使用新的模型覆盖当前请求。

业务场景：
一个企业 AI 助手可以对普通用户使用低成本模型，对 VIP 客户、高风险售后、长文档分析使用更强模型。这样既能控制成本，也能保证关键任务质量。

最简记法：

运行时选型让“用哪个模型”从代码常量变成业务策略。

总结：Models 篇真正讲的是模型工程层

如果把 LangChain Models 文档压缩成一张心智表，可以这样理解：

模块	作用
ChatOpenAI / init_chat_model	初始化模型，把供应商接入统一接口
model	指定具体模型名称或标识
api_key / base_url	处理鉴权和 OpenAI-compatible 连接地址
temperature / max_tokens	控制输出随机性和长度
timeout / max_retries	控制请求等待和失败重试
invoke	获取一次完整响应
stream	获取实时输出 chunk
batch	并发处理多条独立输入
bind_tools	让模型知道可以请求哪些工具
with_structured_output	让模型按 schema 返回结构化结果
profile	读取模型能力画像
usage_metadata	追踪 token 用量和成本信息
RunnableConfig	给调用附加运行名、标签、元数据、回调和并发控制
wrap_model_call	在 Agent 运行时动态选择或改写模型

一句话总结：

LangChain 的 Models 层，是把“模型 API”升级成“可配置、可调用、可观测、可治理的推理接口”。

学习时可以把它分成三层：

第一层：接入模型
init_chat_model / ChatOpenAI / model / api_key / base_url

第二层：调用模型
invoke / stream / batch / tool calling / structured output

第三层：治理模型
profile / timeout / max_retries / rate_limiter / usage_metadata / dynamic model selection

理解这一层后，再读 Structured Output、Streaming、Event Streaming、Messages 和 Tools 时，它们就不再是分散 API，而是同一个 Agent 工程结构的组成部分。