langchain/openai 1.5.x 演进全解析Responses API 工具生态、推理模型与错误重试机制【免费下载链接】langchainjsThe agent engineering platform项目地址: https://gitcode.com/GitHub_Trending/la/langchainjs导读langchain/openai是 LangChain.js 生态中承载 OpenAI 官方能力的核心集成包当前版本为 1.5.13仓库内版本号见 package.json。本文基于 CHANGELOG.md 中 0.6.10 至 1.5.13 的全部变更记录结合 源码目录 中的实现细节系统梳理该包在双 APIChat Completions / Responses路由、内置工具全家桶、推理模型reasoning支持、错误可重试性建模、跨供应商消息互操作与流式输出增强等方向上的演进脉络。读者将掌握这些能力背后的调用链与源码证据可直接应用于基于 LangChain.js 的 OpenAI 应用开发与排障。包的基础信息与依赖从 package.json 可以看到该包的关键事实包名langchain/openai版本1.5.13许可证 MITNode.js 运行要求 22type: moduleESM 优先同时提供 CJS 产物dist/index.cjs。核心依赖openai官方 SDK^7.10.01.5.9 升级至 v7、js-tiktoken^1.0.12用于 token 统计、zod^3.25.76 || ^4用于工具 schema 定义。对等依赖langchain/coreworkspace 版本说明该包强依赖 core 的BaseChatModel、消息类型、stampRetryable、ContextOverflowError等基础能力。测试与构建脚本pnpm testvitest 单测、pnpm test:int集成测试、pnpm test:standardlangchain/standard-tests标准测试、pnpm typegen:profiles由 profiles.toml 生成 profiles.ts。双 API 架构Chat Completions 与 Responses API 的自动路由这是整个 CHANGELOG 反复出现的主线之一。从 chat_models/index.ts 的源码可见ChatOpenAI内部同时维护两个实例ChatOpenAICompletions对应src/chat_models/completions.ts与ChatOpenAIResponses对应src/chat_models/responses.ts二者通过ChatOpenAIFields暴露的useResponsesApi选项控制为true时所有请求强制走 Responses API为false默认时仅在满足条件时才使用 Responses API。模型自动路由的实现依据路由决策核心是utils/misc.ts中的_modelPrefersResponsesAPI(model)函数以及isReasoningModel的启发式判断源码见 utils/misc.tsisReasoningModel以/^o\d/匹配的 o 系列模型如 o1、o3或以gpt-5开头但不是gpt-5-chat的模型判定为推理模型。CHANGELOG 记录了多轮针对性的自动路由调整1.2.0 起 Prefer responses API for 5.2 pro1.2.5 起 codex 系列codex-mini-latest、gpt-5-codex、gpt-5.1-codex等自动路由到 Responses API1.4.5 新增gpt-5.5、gpt-5.5-pro档案并默认gpt-5.5-pro走 Responses API1.5.12 将gpt-5.6-sol也路由到 Responses APIso function tools work with reasoning。这些判断与单元测试一一对应1.2.5 新增isReasoningModel与_modelPrefersResponsesAPI的单测。两套 API 间的一致性修复1.5.12 修复 base URL 反序列化fix base url deserialization保证自定义 endpoint 场景下配置可正确往返。1.5.13 修复 OpenAI Responses API 在 Zero Data RetentionZDR下的 replay当一次响应包含多个 reasoning item 时v0 路径默认复用response_metadata.output以保留每个 reasoning item 的id/encrypted_content原始顺序v1 路径下AIMessage.contentBlocksoutputVersion: v1同样修复additional_kwargs.reasoning保持不变。1.5.11 修复 ZDR 流式场景下的encrypted_content解析OpenAI 最近将encrypted_content的规范负载放在最终done事件中且该字段不再需要出现在include参数中即可传递。1.2.7 修复将response.output存入response_metadata以保证推理模型的来回round-trip传输1.4.7 保留 Responses API 顶层 id 到 AI 消息上。推理模型Reasoning支持全景推理模型是近版本迭代最密集的领域CHANGELOG 中至少涉及以下能力reasoning effort 配置0.6.11 修正 reasoning effort 参数的命名大小写proper casing。0.6.10 重新加入reasoning_effort参数。1.2.4 新增reasoningEffort快捷调用选项它作为reasoning.effort的便利简写自动合并进 o1/o3 等推理模型调用当两者同时提供时reasoning.effort优先该快捷方式被标记为deprecated官方鼓励使用完整形式reasoning.effort。1.2.4 同时修复将service_tier传给 Responses API此前 Responses 路径可能丢失该参数。对话中途调整推理强度1.5.12 支持configuration_update内容块content blocks用于在对话中途修改 reasoning effort 而不会使已缓存的 prompt 前缀失效。这对 Prompt Caching 场景有直接价值以往调整推理强度可能触发缓存重算。推理内容的流式合并与往返1.4.4 为流式 reasoning content blocks 增加 index确保分块chunk能正确合并。1.4.1 修复ChatOpenAICompletions中保留reasoning_content。1.5.2 修复 Responses API 输入侧 reasoning item 的两个被拒错误由流式重组如经streamEvents得到的 reasoning block 没有 id若以id: 回放会触发400 Invalid input[n].id: 现在缺省时省略idreasoning 输入项只应携带summary不应携带content否则触发400 Invalid input[n].content: array too long现在不再转发content。1.2.5 修复 ZDR 响应输入中纳入加密推理内容encrypted reasoning。1.1.0 修复 reasoning 与function_callid 配对问题。内置工具全家桶Responses API 工具生态1.2.0 是工具能力的大版本一次 PR 集群#9541 系列为包引入了大量内置工具。从 tools/index.ts 的导出可以看到完整清单工具模块说明Web SearchwebSearch.tsResponses API 的web_search内置工具支持过滤选项File SearchfileSearch.ts向量检索文件支持过滤、排名、混合搜索权重Code InterpretercodeInterpreter.ts沙箱执行 Python可配置内存限制、自动容器Shellshell.ts服务端 shell 执行Local ShelllocalShell.ts本地 shell 执行Computer UsecomputerUse.ts计算机操作点击、拖拽、键入、截图、滚动等动作类型在源码中均有导出类型MCP Connectormcp.ts连接 MCP 服务器支持远程服务器选项与审批过滤器Image GenerationimageGeneration.ts图像生成1.2.5 起支持action选项generate/edit/autoApply PatchapplyPatch.ts应用代码补丁DALL·Edalle.ts图像生成集成Tool SearchtoolSearch.ts动态工具发现详见下节配套修复还包括1.2.3 将 OpenAI 图像生成输出提升为正式的 image content blocks1.5.2 支持流式传输内置工具的进度事件stream built-in tool progress events。Tool Search按需工具发现与 defer_loading1.3.0 新增tools.toolSearch()工厂函数源码见 toolSearch.ts面向大工具池场景不再把全部工具定义塞进每次请求而是让模型按需发现并加载。核心机制defer_loadingLangChain 工具可通过extras: { defer_loading: true }标记为延迟加载该标记经bindTools()透传进 Responses API 请求体。两种执行模式ToolSearchOptions.executionserver默认OpenAI 服务端内部完成搜索client客户端通过 agent 中间件提供结果此时可额外传入description与parameters工具 schema。响应项处理转换器需同时处理非流式与流式两种tool_search_call/tool_search_output响应项core 的块翻译器将其映射为server_tool_call→server_tool_call_result从而打通 agent 中间件链路。官方示例源码注释中自带可在仓库 toolSearch.ts 查看getWeather工具声明extras: { defer_loading: true }随后model.invoke(What is the weather in SF?, { tools: [tools.toolSearch(), getWeather] })模型在需要时先发起 tool search 再执行真实函数调用。错误处理可重试性建模与上下文溢出识别1.5.8 是错误体系的关键版本借助langchain/core的stampRetryableOpenAI 提供方开始为错误显式标注是否可重试让重试中间件如modelRetryMiddleware能区分瞬态故障与确定性故障。其实现位于 utils/client.ts 的wrapOpenAIClientError错误场景转换结果可重试连接超时APIConnectionTimeoutErrorTimeoutError是用户中止APIUserAbortErrorAbortError否上下文溢出见_isOpenAIContextOverflowError的多条消息匹配ContextOverflowError.fromError()构造时即标记不可重试否400 且消息含tool_calls打上INVALID_TOOL_RESULTS否401 未授权打上MODEL_AUTHENTICATION否429 限流打上MODEL_RATE_LIMIT是其后 AsyncCaller 会在配额耗尽场景重新标记为否404 模型不存在打上MODEL_NOT_FOUND1.5.8 起否关键设计点CHANGELOG 1.5.8 原文要点错误保留原始类因此对openaiSDK 错误类型的instanceof判断不受影响每次调用传入的maxRetries会转发给重试循环避免外层重试如modelRetryMiddleware与 SDK 内置重试互相叠加放大。ContextOverflowError 的演进1.2.8 在langchain/core引入ContextOverflowErrorOpenAI 与 Anthropic 提供方同步接入ContextOverflowError.fromError()静态工厂随后 1.2.8 又引入createNamespace基于Symbol.for的命名空间品牌标识替代手写的 duck-typeisInstance检查。1.3.1 扩展识别规则DeepSeek 在超出上下文限制时返回maximum context length400 错误现被wrapOpenAIClientError识别为ContextOverflowError从而让下游如 summarization middleware 的 fallback能正确处理——这对在 OpenAI 兼容 endpoint 上运行 DeepSeek 模型的用户非常实用。中止Abort信号处理1.2.4 完善了所有 provider 的中止行为invoke()在流式中途被中止时抛出ModelAbortErrorlangchain/core/errors新增携带累积的partialOutputstream()被中止时抛出普通AbortErrorchunk 已交给调用方_generate()开头执行signal.throwIfAborted()及早检查_streamResponseChunks循环内检查中止信号提前返回相关标准测试收录在langchain/standard-tests本包通过pnpm test:standard接入见 internal/standard-tests。跨供应商消息互操作Anthropic / Gemini 消息的清洗当把其他供应商的消息对象传给ChatOpenAI时OpenAI 转换器必须过滤对方私有的内容块否则请求会被 API 拒绝1.2.6 丢弃来自 Anthropic 的tool_use内容块已在message.tool_calls中表示避免 OpenAI API 报错1.5.9 丢弃 Gemini 原生的functionCall内容块同样已由tool_calls承载修复将ChatGoogleGenerativeAI消息传给ChatOpenAI例如 LangGraph 中的跨供应商 handoff时请求失败的问题1.5.10 修复仅含工具调用的 v1 assistant 消息发送content: null而非[]1.2.0 修复工具/函数调用场景下AIMessage的 content 内容1.2.1 修复ToolMessage中 provider 原生内容在未字符串化情况下的透传1.2.6 同时修复多轮对话中 annotations 转换回 OpenAI 格式的问题。流式输出增强原生 streamEvents 事件转换器1.5.0 新增原生streamEvents事件转换器native streamEvents event converters让 Responses API 的流事件能映射为 core 的标准事件。相关实现与测试见 utils/stream_events.ts 与 utils/responses_stream_events.ts。1.4.7 修复自定义工具调用经 Responses API chunks 的流式传递。1.5.1 将 Responses API 流迭代错误包装进既有 OpenAI 客户端错误处理。usage chunk 的回调修复1.2.10 修复 Completions API 流式场景下最后一个 usage chunk此前_streamResponseChunks只通过 async generator 产出该 chunk未调用runManager.handleLLMNewToken()导致基于回调的消费者如 LangGraph 的StreamMessagesHandler永远收不到usage_metadatachunk。修复后与主循环行为一致。流式 JSON 解析的健壮性1.4.6 修复convertResponsesDeltaToChatGenerationChunk中裸JSON.parse(msg.text)gpt-5-mini在service_tier: auto下会间歇性地在合法 JSON 对象后附带多余 token/控制字符导致SyntaxError杀死整个流。现在解析包在try/catch中失败时additional_kwargs.parsed保持 undefined流正常结束由既有withStructuredOutput管线处理——includeRaw: true经withFallbacks返回{ raw, parsed: null }includeRaw: false抛出可捕获重试的类型化OutputParserException。1.3.1 补充对空文本的防护streaming json_schema 且 text 为空时不再裸调JSON.parse。1.2.3 优化流式 chunk 聚合去掉冗余排序optimize stream chunk aggregation and remove redundant sorting。零保留数据ZDR下的推理内容1.2.5 修复 ZDR 响应输入中包含加密推理内容encrypted reasoning in ZDR responses input1.5.11、1.5.13 继续完善流式与多推理项的 ZDR replay见前文。结构化输出与严格模式1.2.12 为结构化输出增加标准 schema 支持standard schema support与langchain/core的 standard schema 体系对齐相关工具见 utils/output.ts。1.5.3 将严格工具strict tools与严格结构化输出响应解耦decouple strict tools from strict structured output response允许两者独立控制1.2.0 也支持在providerStrategy中手动设置 strict 标记。0.6.10 为 json schema 响应格式增加冗余度verbosity选项。1.1.1 尊重interopZodTransformInputSchema中的 JSON Schema 引用respect JSON schema references保证含$ref的 schema 转换正确。1.5.4 修复 Responses 输入中 assistant content 发出output_text1.5.5 过滤 Chat Completions API 拒绝接收的内容块与 tool_call 内容块。模型档案ModelProfile与自动能力声明1.1.1 为ChatModel增加ModelProfile与.profile属性。模型档案由 profiles.toml 生成目前声明的能力覆盖项包括imageUrlInputs、pdfInputs、pdfToolMessage、imageToolMessage、toolChoice、structuredOutputgpt-3.5-turbo被单独降级为全部禁用。这些档案为框架层如自动选择工具调用/结构化输出策略提供了可编程的模型能力查询接口。其他值得关注的稳定性与兼容性修复LangSmith Gateway1.5.6 为 OpenAI、Anthropic、Fireworks 的 chat model 增加 LangSmith Gateway 环境配置经langchain/core/utils/gateway的resolveLangSmithGatewayConfig解析见 base.ts。usage 元数据映射1.5.9 将 OpenAI 的cache_write_tokens映射到usage_metadata.input_token_details.cache_creation与既有cached_tokens → cache_read映射对齐此前 prompt 缓存写入 token 数会被静默丢弃0.6.16 移除 token usage 中的原始 OpenAI 字段0.6.15 将 Responses API usage 转为 tracing 格式1.5.7 修复system_fingerprint缺失时response_metadata中缺少usage的问题。API Key 与请求头1.1.2 支持apiKey为可调用函数callable function同时修复缺失或不一致的 user-agent 请求头。文件输入1.2.4 修复file_url/file_id无 filename 元数据时的校验问题不允许时不发送 filename1.4.2 为 OpenAI 文件输入填充占位文件名LC_AUTOGENERATED见 misc.ts 的getRequiredFilenameFromMetadata1.5.2 将标准 url 文件块路由到原生input_file1.2.11 随 SDK v6.24.0 增加 docx/pptx/xlsx/csv 文件输入转换测试。Prompt Cache 保留1.2.0 增加 prompt cache retention 支持OpenAICacheRetentionParam见 types.ts。依赖与安全1.4.5 移除直接 uuid 依赖以修复已知漏洞1.1.3 修复moduleResolution: node兼容性。trace 元数据1.2.11 在构造时将包版本写入this.metadata.versionsLangSmith trace 中可直接看到包版本。版本演进小结从 CHANGELOG 的时间线看langchain/openai的演进可概括为三个阶段0.6.xLangChain v0 时代基础稳定性修复——流式修复、reasoning effort 参数规范化、usage 格式统一、base64 embeddings。1.01.1LangChain v1 兼容期面向 v1 的兼容更新消息/工具转换工具函数从类中上提hoist导出 converters引入 ModelProfile。1.2.x 至今工具化与推理模型深耕期内置工具全家桶落地、tool_search 与 defer_loading、reasoning 模型全程支持effort、configuration_update、ZDR 加密推理内容、错误可重试性建模、原生 streamEvents 转换器、跨供应商消息清洗。对开发者而言这些变更的实用结论是新的推理模型gpt-5.x、o 系列、codex会被自动路由到 Responses API 以获得完整的 reasoning 与工具支持生产环境应关注wrapOpenAIClientError的语义化错误ContextOverflowError、MODEL_RATE_LIMIT等来编写重试与降级策略跨供应商 handoff如 Anthropic/Gemini → OpenAI在 1.5.9 已具备安全的原生消息转换保障。【免费下载链接】langchainjsThe agent engineering platform项目地址: https://gitcode.com/GitHub_Trending/la/langchainjs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 @langchain/openai 1.5.x 演进全解析：Responses API 工具生态、推理模型与错误重试机制
langchain/openai 1.5.x 演进全解析Responses API 工具生态、推理模型与错误重试机制【免费下载链接】langchainjsThe agent engineering platform项目地址: https://gitcode.com/GitHub_Trending/la/langchainjs导读langchain/openai是 LangChain.js 生态中承载 OpenAI 官方能力的核心集成包当前版本为 1.5.13仓库内版本号见 package.json。本文基于 CHANGELOG.md 中 0.6.10 至 1.5.13 的全部变更记录结合 源码目录 中的实现细节系统梳理该包在双 APIChat Completions / Responses路由、内置工具全家桶、推理模型reasoning支持、错误可重试性建模、跨供应商消息互操作与流式输出增强等方向上的演进脉络。读者将掌握这些能力背后的调用链与源码证据可直接应用于基于 LangChain.js 的 OpenAI 应用开发与排障。包的基础信息与依赖从 package.json 可以看到该包的关键事实包名langchain/openai版本1.5.13许可证 MITNode.js 运行要求 22type: moduleESM 优先同时提供 CJS 产物dist/index.cjs。核心依赖openai官方 SDK^7.10.01.5.9 升级至 v7、js-tiktoken^1.0.12用于 token 统计、zod^3.25.76 || ^4用于工具 schema 定义。对等依赖langchain/coreworkspace 版本说明该包强依赖 core 的BaseChatModel、消息类型、stampRetryable、ContextOverflowError等基础能力。测试与构建脚本pnpm testvitest 单测、pnpm test:int集成测试、pnpm test:standardlangchain/standard-tests标准测试、pnpm typegen:profiles由 profiles.toml 生成 profiles.ts。双 API 架构Chat Completions 与 Responses API 的自动路由这是整个 CHANGELOG 反复出现的主线之一。从 chat_models/index.ts 的源码可见ChatOpenAI内部同时维护两个实例ChatOpenAICompletions对应src/chat_models/completions.ts与ChatOpenAIResponses对应src/chat_models/responses.ts二者通过ChatOpenAIFields暴露的useResponsesApi选项控制为true时所有请求强制走 Responses API为false默认时仅在满足条件时才使用 Responses API。模型自动路由的实现依据路由决策核心是utils/misc.ts中的_modelPrefersResponsesAPI(model)函数以及isReasoningModel的启发式判断源码见 utils/misc.tsisReasoningModel以/^o\d/匹配的 o 系列模型如 o1、o3或以gpt-5开头但不是gpt-5-chat的模型判定为推理模型。CHANGELOG 记录了多轮针对性的自动路由调整1.2.0 起 Prefer responses API for 5.2 pro1.2.5 起 codex 系列codex-mini-latest、gpt-5-codex、gpt-5.1-codex等自动路由到 Responses API1.4.5 新增gpt-5.5、gpt-5.5-pro档案并默认gpt-5.5-pro走 Responses API1.5.12 将gpt-5.6-sol也路由到 Responses APIso function tools work with reasoning。这些判断与单元测试一一对应1.2.5 新增isReasoningModel与_modelPrefersResponsesAPI的单测。两套 API 间的一致性修复1.5.12 修复 base URL 反序列化fix base url deserialization保证自定义 endpoint 场景下配置可正确往返。1.5.13 修复 OpenAI Responses API 在 Zero Data RetentionZDR下的 replay当一次响应包含多个 reasoning item 时v0 路径默认复用response_metadata.output以保留每个 reasoning item 的id/encrypted_content原始顺序v1 路径下AIMessage.contentBlocksoutputVersion: v1同样修复additional_kwargs.reasoning保持不变。1.5.11 修复 ZDR 流式场景下的encrypted_content解析OpenAI 最近将encrypted_content的规范负载放在最终done事件中且该字段不再需要出现在include参数中即可传递。1.2.7 修复将response.output存入response_metadata以保证推理模型的来回round-trip传输1.4.7 保留 Responses API 顶层 id 到 AI 消息上。推理模型Reasoning支持全景推理模型是近版本迭代最密集的领域CHANGELOG 中至少涉及以下能力reasoning effort 配置0.6.11 修正 reasoning effort 参数的命名大小写proper casing。0.6.10 重新加入reasoning_effort参数。1.2.4 新增reasoningEffort快捷调用选项它作为reasoning.effort的便利简写自动合并进 o1/o3 等推理模型调用当两者同时提供时reasoning.effort优先该快捷方式被标记为deprecated官方鼓励使用完整形式reasoning.effort。1.2.4 同时修复将service_tier传给 Responses API此前 Responses 路径可能丢失该参数。对话中途调整推理强度1.5.12 支持configuration_update内容块content blocks用于在对话中途修改 reasoning effort 而不会使已缓存的 prompt 前缀失效。这对 Prompt Caching 场景有直接价值以往调整推理强度可能触发缓存重算。推理内容的流式合并与往返1.4.4 为流式 reasoning content blocks 增加 index确保分块chunk能正确合并。1.4.1 修复ChatOpenAICompletions中保留reasoning_content。1.5.2 修复 Responses API 输入侧 reasoning item 的两个被拒错误由流式重组如经streamEvents得到的 reasoning block 没有 id若以id: 回放会触发400 Invalid input[n].id: 现在缺省时省略idreasoning 输入项只应携带summary不应携带content否则触发400 Invalid input[n].content: array too long现在不再转发content。1.2.5 修复 ZDR 响应输入中纳入加密推理内容encrypted reasoning。1.1.0 修复 reasoning 与function_callid 配对问题。内置工具全家桶Responses API 工具生态1.2.0 是工具能力的大版本一次 PR 集群#9541 系列为包引入了大量内置工具。从 tools/index.ts 的导出可以看到完整清单工具模块说明Web SearchwebSearch.tsResponses API 的web_search内置工具支持过滤选项File SearchfileSearch.ts向量检索文件支持过滤、排名、混合搜索权重Code InterpretercodeInterpreter.ts沙箱执行 Python可配置内存限制、自动容器Shellshell.ts服务端 shell 执行Local ShelllocalShell.ts本地 shell 执行Computer UsecomputerUse.ts计算机操作点击、拖拽、键入、截图、滚动等动作类型在源码中均有导出类型MCP Connectormcp.ts连接 MCP 服务器支持远程服务器选项与审批过滤器Image GenerationimageGeneration.ts图像生成1.2.5 起支持action选项generate/edit/autoApply PatchapplyPatch.ts应用代码补丁DALL·Edalle.ts图像生成集成Tool SearchtoolSearch.ts动态工具发现详见下节配套修复还包括1.2.3 将 OpenAI 图像生成输出提升为正式的 image content blocks1.5.2 支持流式传输内置工具的进度事件stream built-in tool progress events。Tool Search按需工具发现与 defer_loading1.3.0 新增tools.toolSearch()工厂函数源码见 toolSearch.ts面向大工具池场景不再把全部工具定义塞进每次请求而是让模型按需发现并加载。核心机制defer_loadingLangChain 工具可通过extras: { defer_loading: true }标记为延迟加载该标记经bindTools()透传进 Responses API 请求体。两种执行模式ToolSearchOptions.executionserver默认OpenAI 服务端内部完成搜索client客户端通过 agent 中间件提供结果此时可额外传入description与parameters工具 schema。响应项处理转换器需同时处理非流式与流式两种tool_search_call/tool_search_output响应项core 的块翻译器将其映射为server_tool_call→server_tool_call_result从而打通 agent 中间件链路。官方示例源码注释中自带可在仓库 toolSearch.ts 查看getWeather工具声明extras: { defer_loading: true }随后model.invoke(What is the weather in SF?, { tools: [tools.toolSearch(), getWeather] })模型在需要时先发起 tool search 再执行真实函数调用。错误处理可重试性建模与上下文溢出识别1.5.8 是错误体系的关键版本借助langchain/core的stampRetryableOpenAI 提供方开始为错误显式标注是否可重试让重试中间件如modelRetryMiddleware能区分瞬态故障与确定性故障。其实现位于 utils/client.ts 的wrapOpenAIClientError错误场景转换结果可重试连接超时APIConnectionTimeoutErrorTimeoutError是用户中止APIUserAbortErrorAbortError否上下文溢出见_isOpenAIContextOverflowError的多条消息匹配ContextOverflowError.fromError()构造时即标记不可重试否400 且消息含tool_calls打上INVALID_TOOL_RESULTS否401 未授权打上MODEL_AUTHENTICATION否429 限流打上MODEL_RATE_LIMIT是其后 AsyncCaller 会在配额耗尽场景重新标记为否404 模型不存在打上MODEL_NOT_FOUND1.5.8 起否关键设计点CHANGELOG 1.5.8 原文要点错误保留原始类因此对openaiSDK 错误类型的instanceof判断不受影响每次调用传入的maxRetries会转发给重试循环避免外层重试如modelRetryMiddleware与 SDK 内置重试互相叠加放大。ContextOverflowError 的演进1.2.8 在langchain/core引入ContextOverflowErrorOpenAI 与 Anthropic 提供方同步接入ContextOverflowError.fromError()静态工厂随后 1.2.8 又引入createNamespace基于Symbol.for的命名空间品牌标识替代手写的 duck-typeisInstance检查。1.3.1 扩展识别规则DeepSeek 在超出上下文限制时返回maximum context length400 错误现被wrapOpenAIClientError识别为ContextOverflowError从而让下游如 summarization middleware 的 fallback能正确处理——这对在 OpenAI 兼容 endpoint 上运行 DeepSeek 模型的用户非常实用。中止Abort信号处理1.2.4 完善了所有 provider 的中止行为invoke()在流式中途被中止时抛出ModelAbortErrorlangchain/core/errors新增携带累积的partialOutputstream()被中止时抛出普通AbortErrorchunk 已交给调用方_generate()开头执行signal.throwIfAborted()及早检查_streamResponseChunks循环内检查中止信号提前返回相关标准测试收录在langchain/standard-tests本包通过pnpm test:standard接入见 internal/standard-tests。跨供应商消息互操作Anthropic / Gemini 消息的清洗当把其他供应商的消息对象传给ChatOpenAI时OpenAI 转换器必须过滤对方私有的内容块否则请求会被 API 拒绝1.2.6 丢弃来自 Anthropic 的tool_use内容块已在message.tool_calls中表示避免 OpenAI API 报错1.5.9 丢弃 Gemini 原生的functionCall内容块同样已由tool_calls承载修复将ChatGoogleGenerativeAI消息传给ChatOpenAI例如 LangGraph 中的跨供应商 handoff时请求失败的问题1.5.10 修复仅含工具调用的 v1 assistant 消息发送content: null而非[]1.2.0 修复工具/函数调用场景下AIMessage的 content 内容1.2.1 修复ToolMessage中 provider 原生内容在未字符串化情况下的透传1.2.6 同时修复多轮对话中 annotations 转换回 OpenAI 格式的问题。流式输出增强原生 streamEvents 事件转换器1.5.0 新增原生streamEvents事件转换器native streamEvents event converters让 Responses API 的流事件能映射为 core 的标准事件。相关实现与测试见 utils/stream_events.ts 与 utils/responses_stream_events.ts。1.4.7 修复自定义工具调用经 Responses API chunks 的流式传递。1.5.1 将 Responses API 流迭代错误包装进既有 OpenAI 客户端错误处理。usage chunk 的回调修复1.2.10 修复 Completions API 流式场景下最后一个 usage chunk此前_streamResponseChunks只通过 async generator 产出该 chunk未调用runManager.handleLLMNewToken()导致基于回调的消费者如 LangGraph 的StreamMessagesHandler永远收不到usage_metadatachunk。修复后与主循环行为一致。流式 JSON 解析的健壮性1.4.6 修复convertResponsesDeltaToChatGenerationChunk中裸JSON.parse(msg.text)gpt-5-mini在service_tier: auto下会间歇性地在合法 JSON 对象后附带多余 token/控制字符导致SyntaxError杀死整个流。现在解析包在try/catch中失败时additional_kwargs.parsed保持 undefined流正常结束由既有withStructuredOutput管线处理——includeRaw: true经withFallbacks返回{ raw, parsed: null }includeRaw: false抛出可捕获重试的类型化OutputParserException。1.3.1 补充对空文本的防护streaming json_schema 且 text 为空时不再裸调JSON.parse。1.2.3 优化流式 chunk 聚合去掉冗余排序optimize stream chunk aggregation and remove redundant sorting。零保留数据ZDR下的推理内容1.2.5 修复 ZDR 响应输入中包含加密推理内容encrypted reasoning in ZDR responses input1.5.11、1.5.13 继续完善流式与多推理项的 ZDR replay见前文。结构化输出与严格模式1.2.12 为结构化输出增加标准 schema 支持standard schema support与langchain/core的 standard schema 体系对齐相关工具见 utils/output.ts。1.5.3 将严格工具strict tools与严格结构化输出响应解耦decouple strict tools from strict structured output response允许两者独立控制1.2.0 也支持在providerStrategy中手动设置 strict 标记。0.6.10 为 json schema 响应格式增加冗余度verbosity选项。1.1.1 尊重interopZodTransformInputSchema中的 JSON Schema 引用respect JSON schema references保证含$ref的 schema 转换正确。1.5.4 修复 Responses 输入中 assistant content 发出output_text1.5.5 过滤 Chat Completions API 拒绝接收的内容块与 tool_call 内容块。模型档案ModelProfile与自动能力声明1.1.1 为ChatModel增加ModelProfile与.profile属性。模型档案由 profiles.toml 生成目前声明的能力覆盖项包括imageUrlInputs、pdfInputs、pdfToolMessage、imageToolMessage、toolChoice、structuredOutputgpt-3.5-turbo被单独降级为全部禁用。这些档案为框架层如自动选择工具调用/结构化输出策略提供了可编程的模型能力查询接口。其他值得关注的稳定性与兼容性修复LangSmith Gateway1.5.6 为 OpenAI、Anthropic、Fireworks 的 chat model 增加 LangSmith Gateway 环境配置经langchain/core/utils/gateway的resolveLangSmithGatewayConfig解析见 base.ts。usage 元数据映射1.5.9 将 OpenAI 的cache_write_tokens映射到usage_metadata.input_token_details.cache_creation与既有cached_tokens → cache_read映射对齐此前 prompt 缓存写入 token 数会被静默丢弃0.6.16 移除 token usage 中的原始 OpenAI 字段0.6.15 将 Responses API usage 转为 tracing 格式1.5.7 修复system_fingerprint缺失时response_metadata中缺少usage的问题。API Key 与请求头1.1.2 支持apiKey为可调用函数callable function同时修复缺失或不一致的 user-agent 请求头。文件输入1.2.4 修复file_url/file_id无 filename 元数据时的校验问题不允许时不发送 filename1.4.2 为 OpenAI 文件输入填充占位文件名LC_AUTOGENERATED见 misc.ts 的getRequiredFilenameFromMetadata1.5.2 将标准 url 文件块路由到原生input_file1.2.11 随 SDK v6.24.0 增加 docx/pptx/xlsx/csv 文件输入转换测试。Prompt Cache 保留1.2.0 增加 prompt cache retention 支持OpenAICacheRetentionParam见 types.ts。依赖与安全1.4.5 移除直接 uuid 依赖以修复已知漏洞1.1.3 修复moduleResolution: node兼容性。trace 元数据1.2.11 在构造时将包版本写入this.metadata.versionsLangSmith trace 中可直接看到包版本。版本演进小结从 CHANGELOG 的时间线看langchain/openai的演进可概括为三个阶段0.6.xLangChain v0 时代基础稳定性修复——流式修复、reasoning effort 参数规范化、usage 格式统一、base64 embeddings。1.01.1LangChain v1 兼容期面向 v1 的兼容更新消息/工具转换工具函数从类中上提hoist导出 converters引入 ModelProfile。1.2.x 至今工具化与推理模型深耕期内置工具全家桶落地、tool_search 与 defer_loading、reasoning 模型全程支持effort、configuration_update、ZDR 加密推理内容、错误可重试性建模、原生 streamEvents 转换器、跨供应商消息清洗。对开发者而言这些变更的实用结论是新的推理模型gpt-5.x、o 系列、codex会被自动路由到 Responses API 以获得完整的 reasoning 与工具支持生产环境应关注wrapOpenAIClientError的语义化错误ContextOverflowError、MODEL_RATE_LIMIT等来编写重试与降级策略跨供应商 handoff如 Anthropic/Gemini → OpenAI在 1.5.9 已具备安全的原生消息转换保障。【免费下载链接】langchainjsThe agent engineering platform项目地址: https://gitcode.com/GitHub_Trending/la/langchainjs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考