概述
集成细节
模型特性
设置
要访问 OpenAI 模型,您需要安装langchain-openai 集成包并获取一个 OpenAI 平台 API 密钥。
安装
凭证
前往 OpenAI 平台 注册并生成 API 密钥。完成后,在您的环境中设置OPENAI_API_KEY 环境变量:
base_url。解析顺序(第一个匹配的优先):
- 显式
base_url(或openai_api_base)参数。 OPENAI_API_BASE— 由 LangChain 在初始化时读取。OPENAI_BASE_URL— 由底层openaiSDK 客户端读取。LangChain 也会检查此值以决定是否默认启用stream_usage;当设置时,默认关闭,因为许多非 OpenAI 端点不支持流式 Token 使用。
实例化
现在我们可以实例化我们的模型对象并生成响应:ChatOpenAI] API 参考。
Token 参数弃用OpenAI 于 2024 年 9 月弃用
max_tokens,改为使用 max_completion_tokens。max_tokens 仍然支持以向后兼容,但内部会自动转换为 max_completion_tokens。调用
流式输出元数据
OpenAI 的 Chat Completions API 默认不流式传输 Token 使用统计信息(请参阅 OpenAI API 参考中关于流式选项)。 要在使用 @[ChatOpenAI] 或 AzureChatOpenAI 流式传输时恢复 Token 计数,将 stream_usage=True 作为初始化参数或在调用时设置:
与 Azure OpenAI 一起使用
Azure OpenAI v1 API 支持自
langchain-openai>=1.0.1 起,ChatOpenAI 可以直接与 Azure OpenAI 端点使用新的 v1 API。这提供了一种统一的方式来使用 OpenAI 模型,无论其是否托管在 OpenAI 或 Azure 上。对于传统的 Azure 特定实现,请继续使用 AzureChatOpenAI。Using Azure OpenAI v1 API with API Key
Using Azure OpenAI v1 API with API Key
要使用
ChatOpenAI 与 Azure OpenAI 一起使用,将 base_url 设置为您的 Azure 端点,并附加 /openai/v1/:Using Azure OpenAI with Microsoft Entra ID
Using Azure OpenAI with Microsoft Entra ID
v1 API 添加了对 Microsoft Entra ID(以前称为 Azure AD)认证的原生支持,并自动刷新 Token。将一个 Token 提供者可调用对象传递给 Token 提供者是一个可调用对象,它自动检索和刷新认证 Token,无需手动管理 Token 过期。在使用异步函数时,您也可以将一个 Token 提供者可调用对象传递给
api_key 参数:api_key 参数。您必须从 azure.identity.aio 导入 DefaultAzureCredential:当使用异步可调用对象作为 API 密钥时,您必须使用异步方法(
ainvoke、astream 等)。同步方法将引发错误。工具调用
OpenAI 有一个 工具调用 API,它允许您描述工具及其参数,并让模型返回一个包含要调用的工具及其输入的 JSON 对象。工具调用对于构建使用工具的链和智能体非常有用,并且可以更通用地从模型中获取结构化输出。绑定工具
使用ChatOpenAI.bind_tools,我们可以轻松地将 Pydantic 类、字典模式、LangChain 工具甚至函数作为工具传递给模型。底层这些会被转换为 OpenAI 工具模式,如下所示:
严格模式
需要
langchain-openai>=0.1.21strict 参数,这将强制模型遵守工具参数模式。了解更多。
如果
strict=True,工具定义也会被验证,并且接受 JSON schema 的子集。关键在于,schema 不能有可选参数(那些带有默认值的)。阅读 完整文档 了解支持哪些类型的 schema。工具调用
注意 AIMessage 有一个tool_calls 属性。它以标准化的 ToolCall 格式包含内容,该格式与模型提供者无关。
异步工具
异步工具调用 允许模型在发出工具调用后继续工作,而无需等待结果。在使用 Responses API 时,ChatOpenAI 通过将 extras={"async": True} 传递给 @tool 来支持这一点:
异步工具仅通过 Responses API(
use_responses_api=True)支持。async 标志通过消息历史来回传递,以便在回合之间保持提示缓存前缀的完整性。自定义工具
需要
langchain-openai>=0.3.29Context-free grammars
Context-free grammars
结构化输出
OpenAI 支持一种原生的 结构化输出功能,该功能确保其响应符合指定的模式。 您可以在单个模型调用中访问此功能,或通过指定 LangChain 智能体的 响应格式 来使用此功能。以下为示例。Individual model calls
Individual model calls
Agent response format
Agent response format
带工具调用的结构化输出
OpenAI 的 结构化输出 功能可以与工具调用同时使用。模型将生成工具调用或符合预期模式的响应。以下为示例:响应 API
需要
langchain-openai>=0.3.9ChatOpenAI] 将路由到响应 API,如果使用这些功能之一。您也可以在实例化 @[ChatOpenAI] 时指定 use_responses_api=True。
网络搜索
要触发网络搜索,将{"type": "web_search"} 作为其他工具一样传递给模型。
图像生成
需要
langchain-openai>=0.3.19{"type": "image_generation"} 作为其他工具一样传递给模型。

文件搜索
要触发文件搜索,将 文件搜索工具 作为其他工具一样传递给模型。您需要填充 OpenAI 管理的向量存储,并在工具定义中包含向量存储 ID。有关更多详细信息,请参阅 OpenAI 文档。工具搜索
需要
langchain-openai>=1.1.11@tool(extras={"defer_loading": True}) 标记工具,并将 OpenAI 的搜索工具添加到可用工具中。下方提供了示例。
Server-side tool search
Server-side tool search
OpenAI 可以跨可用工具进行搜索,并在同一响应中返回加载的工具(如果适用,则附带工具调用):
Client-executed tool search
Client-executed tool search
计算机使用
@[ChatOpenAI] 支持 "computer-use-preview" 模型,这是一个用于内置计算机使用工具的专用模型。要启用,请将 计算机使用工具 作为传递其他工具一样传递给模型。
目前,计算机使用工具的工具输出位于消息 content 字段中。要回复计算机使用工具调用,请构造一个 @[ToolMessage],在其 additional_kwargs 中包含 {"type": "computer_call_output"}。消息的内容将是一个屏幕截图。下方,我们演示了一个简单的示例。
首先,加载两个屏幕截图:
content 中包含对计算机使用工具的调用:
ToolMessage]:
- 它有一个
tool_call_id匹配计算机调用中的call_id。 - 它在其
additional_kwargs中有{"type": "computer_call_output"}。 - 其内容是一个
image_url或一个input_image输出块(有关格式,请参阅 OpenAI 文档)。
previous_response_id:
代码解释器
OpenAI 实现了一个 代码解释器 工具来支持沙盒化的代码生成和执行。Example use
应用补丁
需要
langchain-openai>=1.3.0{"type": "apply_patch"} 作为其他工具一样传递给模型。不需要输入模式——模型知道如何构建 operation 对象。
apply_patch_call 内容块,每个块描述一个单个文件操作(create_file、update_file 或 delete_file):
call_id 的 apply_patch_call_output 块发送回去。成功时,将 status 设置为 "completed",或使用描述性的 output 设置 "failed",以便模型可以调整和重试:
远程 MCP
OpenAI 实现了一个 远程 MCP 工具,允许模型生成的调用访问 MCP 服务器。Example use
MCP Approvals
MCP Approvals
OpenAI 有时会请求批准,然后再与远程 MCP 服务器共享数据。在上述命令中,我们指示模型永远不需要批准。我们也可以配置模型始终请求批准,或始终为特定工具请求批准:然后响应可能包括类型为
"mcp_approval_request" 的块。要提交对批准请求的批准,请在输入消息中将其结构化为一个内容块:管理对话状态
Responses API 支持管理 对话状态。手动管理状态
您可以使用 LangGraph 手动管理状态,就像其他对话模型一样:传递 previous_response_id
在使用 Responses API 时,LangChain 消息将在其元数据中包含一个 "id" 字段。将此 ID 传递给后续调用将延续对话。请注意,从计费角度来看,这与手动传递消息 等效。
previous_response_id:
use_previous_response_id=True,则请求有效负载将丢弃直到最新响应的所有输入消息,并使用最新响应的 ID 设置 previous_response_id。
也就是说,
上下文管理
Responses API 支持自动 服务器端上下文压缩。当对话达到 Token 阈值时,这会减少对话大小,从而支持长时间运行的交互:AIMessage 响应可能包含内容中带有 "type": "compaction" 的块。这些应在对话历史记录中保留,并可以按 通常方式 追加到消息序列中。可以保留最接近的 compaction 项之前的消息,或丢弃以提高延迟。
推理输出
一些 OpenAI 模型将生成单独的文本内容来说明其推理过程。有关详细信息,请参阅 OpenAI 的 推理文档。 OpenAI 可以返回模型推理的摘要(尽管它不暴露原始推理 Token)。要配置 @[ChatOpenAI] 返回此摘要,请指定 reasoning 参数。@[ChatOpenAI] 将在设置此参数时自动路由到 Responses API。
reasoning_effort 参数,它翻译为 reasoning.effort 并添加 summary: "auto":
作为标准参数的
reasoning_effort 需要 langchain-openai>=1.4.1。在对话中途更改推理努力
使用一个configuration_update 内容块在回合之间更改推理努力,而无需修改请求级别的 reasoning_effort 参数——保持提示词前缀可缓存。将块直接嵌入一个 HumanMessage:
在对话中途添加工具
additional_tools 需要 langchain-openai>=1.6.5。additional_tools 内容块从对话中的某个点开始提供工具。当您的应用程序在 工具搜索 流程之外加载工具时,这很有用。将块放在一个 @[SystemMessage] 中:
use_responses_api=True。在 Chat Completions 或在 SystemMessage 之外的消息上,ChatOpenAI 会引发 ValueError。您也可以将块包装在 non_standard 块中,这是 content_blocks 返回它的方式。
微调
您可以通过传递相应的modelName 参数来调用微调的 OpenAI 模型。
这通常采用 ft:{OPENAI_MODEL_NAME}:{ORG_NAME}::{MODEL_ID} 的形式。例如:
多模态输入(图像、PDF、音频)
OpenAI 有支持多模态输入的模型。您可以将图像、PDF 或音频传递给这些模型。有关在 LangChain 中如何执行此操作的更多信息,请参阅 多模态输入 文档。 您可以在 OpenAI 的文档 中查看支持不同模态的模型列表。 对于所有模态,LangChain 支持其跨提供商的标准以及 OpenAI 的原生内容块格式。 将多模态数据传入 @[ChatOpenAI],创建一个包含数据的内容块,并将其整合到消息中,例如如下:
Images
Images
PDFs
PDFs
注意:OpenAI 要求 PDF 输入时必须指定文件名。在使用 LangChain 的格式时,请包含
filename 键。Read more about OpenAI file names for multimodal messages.参考 PDF 文档如何指南中的示例。In-line base64 data
预期输出
Requires
langchain-openai>=0.2.6gpt-4o 和 gpt-4o-mini 系列)支持 预测输出,这允许您提前传递 LLM 预期输出的一部分,以减少延迟。这对于编辑文本或代码等场景很有用,在这些场景中,模型输出的只有一小部分会改变。
Here’s an example:
预测会按 Token 额外计费,并可能因这种降低的延迟而增加您的使用量和成本。
音频生成(预览)
需要
langchain-openai>=0.2.3gpt-4o-audio-preview 模型上使用音频输入和输出。
output_message.additional_kwargs['audio'] 会包含类似下面这样的字典:
model_kwargs['audio']['format'] 中传入的格式。
我们还可以在 OpenAI 的 expires_at 到期之前,把这条带有音频数据的消息作为消息历史的一部分再传回模型。
输出音频存储在
AIMessage.additional_kwargs 的 audio 键下,而输入内容块在 HumanMessage.content 列表中的类型和键为 input_audio。更多信息请参阅 OpenAI 的音频文档。提示缓存
OpenAI 的提示缓存功能会自动缓存超过 1024 个 token 的提示词,以降低成本并缩短响应时间。该功能对所有较新的模型(gpt-4o 及更新版本)默认启用。
手动缓存
您可以使用prompt_cache_key 参数影响 OpenAI 的缓存行为,并优化缓存命中率:
缓存键策略
您可以根据应用需求采用不同的缓存键策略:模型级缓存
您还可以通过model_kwargs 在模型级别设置默认缓存键:
使用断点的显式缓存
需要
langchain-openai>=1.3.5。Chat Completions API 与 Responses API 均支持。"prompt_cache_breakpoint": {"mode": "explicit"}。显式断点需要 GPT-5.6 或更新版本的模型系列。
- Chat Completions
- Responses API
View example trace
为此示例打开一个公开的 LangSmith 运行。
prompt_cache_breakpoint 嵌套在 extras 字典中:
View example trace
为此示例打开一个公开的 LangSmith 运行。
请求级缓存选项
需要
langchain-openai>=1.3.5。prompt_cache_options 适用于 GPT-5.6 及更新版本的模型系列。prompt_cache_options 参数传入请求级提示缓存选项:
mode:"implicit"(默认)或"explicit"。在"implicit"模式下,OpenAI 会在最新一条消息上放置缓存断点,同时也会使用您提供的显式断点。在"explicit"模式下,只有您的断点会用于缓存读写。如果请求中没有显式断点,则不会使用提示缓存。ttl:请求写入的断点的最短缓存生存时间。唯一支持的值是"30m",这也是默认值。
View example trace
为此示例打开一个公开的 LangSmith 运行。
prompt_cache_retention("in_memory" 或 "24h")。该字段与 prompt_cache_options 相互独立,并且在 GPT-5.6 及更新版本的模型系列中已被弃用。
缓存写入 token
当 OpenAI 将新内容写入提示缓存时,会在响应中报告cache_write_tokens。ChatOpenAI 会以 input_token_details 中的 cache_creation 呈现该值:
View example trace
为此示例打开一个公开的 LangSmith 运行。
"priority" 和 "flex" 服务层级中,这些键会加上层级名称前缀——例如 "priority_cache_read" 和 "priority_cache_creation"。
Flex 处理
OpenAI 提供多种服务层级。"flex" 层级为请求提供更低的价格,代价是响应可能更慢,且资源不一定始终可用。这种方式最适合非关键任务,包括模型测试、数据增强或可异步运行的作业。
要使用它,请在初始化模型时设置 service_tier="flex":
API 参考
有关所有功能和配置选项的详细文档,请前往 @[ChatOpenAI] API 参考。
官方原文:src/oss/python/integrations/chat/openai.mdx · 非官方翻译,译文由 AI 生成,以英文原文为准。