LangChain langchain==1.4.3 修复了 Agents 无法忽视的失败路径

LangChain 发布了 langchain==1.4.3，包含七项变更，其中包括对模型回退、结构化输出和格式错误工具调用的修复。该补丁还在框架的模型初始化器中新增了 Bedrock Mantle 支持。这一组合使得该版本的重要性超出了其补丁版本号所暗示的程度。

核心矛盾在于可靠性与抽象之间。LangChain 让开发者能够在不同模型和提供商之间使用统一的 agent 接口。然而，提供商特有的设置、响应格式和消息规则依然会穿透这一接口。

1.4.3 版本处理了多处可能导致 agent 在部署后停止运行的差异。 官方发布说明于 2026 年 9 月 28 日发布，距离两篇质疑早期工具调用修复方案的后续报道仅一天。

此次更新并未引入新的 agent 架构。它强化了 agent 代码与不断变化的提供商行为之间的转换层。对于在 OpenAI 兼容端点、Amazon Bedrock、Anthropic、Fireworks 或 Azure OpenAI 之间运行 agents 的团队而言，这一层往往决定了回退机制能否真正生效。

langchain==1.4.3 有何变化

此次发布聚焦于 agents 跨越提供商边界或重放不完整会话历史时出现的故障。

LangChain 的发布说明列出了自 1.4.2 以来的七个 pull request。其中四项直接影响模型或 agent 行为，其余变更涉及文档更新、移除注释代码，以及刷新锁定的依赖项。

第一项行为修复会在回退期间清理与缓存有关的模型设置。当 agent 因错误或可用性问题从首选模型切换至另一模型时，就会发生回退。

在此修复之前，原本面向首个提供商的设置可能会随请求一同传递。回退提供商可能会拒绝这些陌生设置，而不是完成请求。这会让一项韧性功能本身变成另一个故障点。

第二项重要变更是为 init_chat_model 注册两个 Amazon Bedrock Mantle 提供商。该函数为应用创建聊天模型集成提供了统一入口。

开发者现在可以将 bedrock_mantle_openai 或 bedrock_mantle_anthropic 指定为提供商。随后，LangChain 会将请求连接至由 langchain-aws 提供的相应类。

第三项变更调整了 agents 为 GPT-6 Sol、Luna 和 Astra 选择结构化输出的方式。结构化输出意味着模型返回符合预期 schema 的数据，而非不受约束的文本。

当模型配置不可用时，LangChain 过去可能会通过基于工具的策略调用这些模型。这一路径可能在 Bedrock 上循环或失败。1.4.3 版本识别这些模型名称，并默认选择提供商原生的结构化输出。

第四项行为变更会修复存储在 agent 历史记录中的格式错误工具调用。工具调用是模型生成的请求，用于让应用执行函数、检索数据或采取其他已定义操作。

部分提供商要求每个可识别的工具调用都必须有对应的结果消息。缺少结果的格式错误调用可能导致后续重放无效，即使原始轮次早已结束。

LangChain 现在会为可识别的无效调用添加错误结果，同时保留按工具调用 ID 匹配的有效结果。该修复适用于当前和历史消息，并不会要求模型重复调用。

此次发布还将锁定的 AnyIO 版本从 4.11.0 更新至 4.14.2。AnyIO 为不同 Python 事件循环实现提供异步兼容性。发布说明将其描述为依赖项更新，而非新的运行时能力。

一项文档修正更新了仓库设置指南和软件包详情。另一项维护变更移除了被注释的 Cohere extra。两者均不应改变应用行为。

综合来看，这些变更使 1.4.3 成为一个兼容性版本。它扩展了一条提供商路径，同时收紧了三条影响 agent 连续性的故障路径。

模型回退现在会移除不兼容的缓存设置

只有当第二个模型收到它能够理解的请求时，回退才能真正提高可用性。

从策略层面看，模型回退似乎很简单。应用选择一个主模型，指定一个或多个备选模型，并在请求失败时按列表依次尝试。

实际请求携带的不只是消息。它还可能包括缓存键、自定义标头、响应格式指令、工具定义、超时设置和提供商特有选项。

这些设置带来了隐藏的兼容性问题。某个提供商接受的缓存参数，对另一个提供商而言可能毫无意义或根本无效。原样传递它可能会导致回退请求在备用模型生成任何 token 之前就失败。

回退缓存修复针对两项设置。若回退目标不使用 Fireworks，它会移除 x-session-affinity；同时，它会在 Fireworks、OpenAI 和 Azure OpenAI 之外移除 prompt_cache_key。

会话亲和性会将相关请求引导至同一服务位置，从而提升缓存复用。这一行为依赖于提供商基础设施，不能假定它适用于所有端点。

类似地，提示缓存键可帮助支持该功能的提供商将请求与缓存的提示材料关联。它并非每个模型 API 都通用的字段。

当选定的回退目标支持这些设置时，中间件会保留它们。它也会保持无关配置和标头不变，包括现有的 Anthropic 缓存标记处理。

这一差异很重要。移除所有可选设置虽然能避免部分兼容性错误，但也会丢弃支持这些设置的提供商所能提供的有用能力。

因此，该实现会使用回退模型的 _llm_type 来决定哪些设置应当保留。它会为回退调用创建经过清理的设置，而不会修改原始请求。

这一设计保护了后续处理。如果请求对象在中间件之间共享，或通过另一条路径重试，一次回退尝试不应永久抹去其配置。

该 pull request 包含同步和异步测试覆盖。测试检查了标头清理、不支持的缓存键移除，以及回退提供商接受该设置时的保留行为。

这是一个狭窄的修复，但带来了广泛的运营启示。跨提供商回退并非只是模型名称的列表，而是涉及请求所附每个字段的转换问题。

团队仍应测试其部署的每个有序提供商组合。成功的 OpenAI 到 Azure 路径，并不能验证 OpenAI 到 Anthropic 或 Fireworks 到 Bedrock 的行为。

该补丁仅清理了 pull request 所涉及的设置。随着模型 API 演进，其他提供商特有参数仍可能造成不兼容。

因此，应用团队应将回退完成情况与主模型成功情况分开监控。将两条路径合并的仪表板，可能会掩盖一个从未获得可用响应的回退系统。

团队还应记录每个请求最终由哪个模型提供服务。缺少这一信号，团队就无法将输出变化或延迟升高与提供商切换关联起来。

最能说明问题的测试，不是中间件能否捕获一次强制异常，而是整个下游请求能否使用生产环境中的精确设置成功完成。

其中包括结构化输出、工具、缓存和消息历史。1.4.3 消除了两个已知陷阱，但并未让所有提供商变得可互换。

Bedrock Mantle 加入 LangChain 的统一模型入口

LangChain 现在通过共享初始化器公开 Bedrock Mantle，但应用必须明确指定提供商。

新集成将 bedrock_mantle_openai 和 bedrock_mantle_anthropic 加入 init_chat_model 可识别的提供商列表。这两个名称分别对应 ChatOpenAIMantle 和 ChatAnthropicMantle。

这两个类均位于 langchain-aws，而非主 LangChain 软件包中。Mantle 集成在运行时需要 langchain-aws 1.7.9 或更高版本。

根据已合并的 pull request，这些类会自行解析区域 Mantle 端点。它们还可以处理 Bedrock API key、AWS_BEARER_TOKEN_BEDROCK 环境变量，或从标准 AWS 凭据派生出的临时凭据。

这让自定义创建函数无需进入常规设置流程。开发者可使用已经为其他提供商进行路由的同一高级初始化器。

不过，基于名称的推断仍被有意限制。LangChain 继续将以 anthropic.* 开头的模型标识符与现有 Bedrock 提供商关联。

以 openai.* 开头、托管于 Bedrock 的 OpenAI 标识符不会自动选择 Mantle。开发者必须提供 Mantle 提供商名称或显式的提供商前缀。

维护者避免修改既有推断逻辑，因为那会在无提示的情况下将应用重定向至不同端点。保留当前行为降低了已在使用 Bedrock 集成的团队的升级风险。

这形成了合理的权衡。显式配置增加了一点设置要求，但它避免了补丁版本改变既有工作负载发送请求的位置。

依赖安装同样值得关注。pull request 的讨论最终确定，应针对所使用的模型系列采用组合 extras。

文档列出的组合为：对于 OpenAI 兼容的 Mantle 模型使用 langchain[aws,openai]，对于 Anthropic 兼容模型使用 langchain[aws,anthropic]。这种方式使通用 AWS extra 保持更轻量。

讨论还记录了 langchain-aws 中残留的依赖问题。由凭据派生的临时密钥可能会在刷新时延迟导入额外的 token 生成软件包。

这意味着成功导入或启动测试可能无法覆盖所有身份验证路径。使用临时凭据的团队应在预发布环境中测试刷新行为，而不只是首个请求。

更广泛的压力落在框架维护者身上，而非某一家竞争公司。云平台正越来越多地通过多种 API 家族、凭据系统和区域端点提供模型。

统一初始化器必须隐藏足够多的差异，以减少应用代码；同时也必须暴露足够多的差异，以避免产生误导性的自动选择。

LangChain 的决定倾向于在提供商边界进行显式路由。当相同的模型系列前缀可能通往不同 Bedrock 服务时，这比猜测更安全。

对开发者而言，实际收益是构建方式的一致性。应用可以通过配置选择由 Mantle 支持的模型，而无需构建单独的工厂函数。

其限制同样重要。统一构建并不能保证提供商之间具有完全相同的行为。身份验证、支持的参数、流式事件、工具调用和结构化输出仍可能不同。

采用这一新路径的团队应测试其真实的 agent 工作负载。基础提示可以验证连通性，但无法验证工具执行、schema 强制、回退或凭据续期。

此次发布让接入 Mantle 更加容易。生产就绪仍取决于对完整请求生命周期的验证。

GPT-6 结构化输出不再通过工具模拟

GPT-6 修复会在模型配置元数据缺失时选择原生 schema 处理，从而减少对合成工具调用的依赖。

Agent 框架需要一种策略，将模型输出转换为带类型的应用数据。一种路径是请求提供商提供原生结构化输出。另一种则将所需 schema 表示为可调用工具。

工具策略可适用于缺少原生 schema 控制能力的模型。但它也增加了一层协议处理，包括工具选择、参数生成、结果处理和对话重放。

LangChain 通常使用模型配置来判断模型支持哪种策略。模型配置是描述原生结构化输出等能力的元数据。

问题会在这类元数据缺失时出现。LangChain 需要根据模型标识符或其他可用信息作出回退决策。

对于 GPT-6 Sol、Luna 和 Astra，之前的回退策略会选择基于工具的结构化输出。GPT-6 修正指出，这一路径可能会在 Bedrock 上循环或失败。

版本 1.4.3 将这些模型标识符加入原生输出回退列表。相关测试表明，它可识别裸名称和带 Bedrock 前缀的形式。

影响范围很明确：没有配置文件的情况下，使用这些 GPT-6 变体的 Agent 现在默认会选择提供商原生结构化输出。

这并不意味着所有模型都会得到相同处理。这是一条兼容性规则，适用于其预期能力已知的特定模型。

这一变化也说明，能力元数据已成为关键基础设施。仅凭模型名称通常无法完整反映端点行为。

同一提供商可以通过多个接口托管一个模型。这些接口可能暴露不同的 schema 功能、接受的字段或错误语义。

基于配置文件的系统为框架提供了一个集中描述这些差异的位置。然而，当配置文件缺失、延迟或不可用时，应用仍需要合理的行为。

LangChain 的回退列表填补了这一空白。弱点在于维护：每个新支持的模型系列都必须被准确识别，并随着提供商行为的变化而更新。

假阴性会让具备能力的模型走上不必要的工具模拟路径。假阳性则可能向未正确实现该功能的端点请求原生输出。

当前修复优先处理一个已知故障场景。它为所列 GPT-6 模型移除了有问题的路径，而没有重新定义整个框架中的结构化输出选择机制。

开发者仍应验证与其生产契约相似的 schema。嵌套对象、联合类型、可选字段和较长的枚举列表，可能暴露小型示例无法发现的差异。

他们还应将验证错误与提供商错误分开检查。即使结构化输出请求被接受，返回的数据仍可能无法通过应用的 schema 校验。

重试需要谨慎设置上限。触发另一个完全相同请求的 schema 失败可能产生昂贵循环，尤其是在框架错误分类端点能力时。

最稳妥的发布方式是比较三项结果：提供商接受情况、schema 验证和下游使用情况。仅通过第一步并不能证明结构化输出可靠。

此版本减少了特定模型不必要的工具模拟。随着模型目录持续扩展，它也再次强调了准确配置文件的价值。

无效工具调用暴露了最棘手的 Agent 状态问题

LangChain 的修复保留了可重放的历史记录，但后续报告显示，消息规范化仍然对提供商规则十分敏感。

Agent 对话不只是一个转录记录。它是一个状态机，其中助手的工具请求和工具结果必须构成有效配对。

一次格式错误的工具调用可能打破这一序列。模型可能生成无效参数、遗漏必需标识符，或返回框架无法解析的结构。

如果框架存储了该调用却没有匹配结果，那么当提供商验证被重放的历史记录时，后续请求可能失败。错误可能在最初缺陷发生数轮后才出现。

LangChain 的工具调用修复会为每个可识别的无效工具调用添加一个错误 ToolMessage。它还会在重建消息状态时检查历史调用。

修复通过匹配工具调用 ID 来保留现有结果。它不会重试格式错误的请求，因此避免了让模型自动重复某项操作。

这种行为支持一个重要的恢复目标：对话可以记录所请求工具操作失败，同时保持周边历史记录可用。

没有这样的记录，Agent 可能无法继续恢复。应用将不得不丢弃历史记录、手动重写消息，或新建一个线程。

挑战在于，不同提供商对工具消息关系的解释并不相同。一种在某个消息协议下有效的修复，可能违反另一提供商更严格的排序规则。

拉取请求的时间线让这种不确定性显而易见。9 月 27 日，用户提交了涉及 Anthropic 线程和已修复工具结果的后续报告。

一份报告称，生成的 tool_result 缺少匹配的 tool_use，导致无效调用后出现提供商错误。另一份报告建议在每个 payload 中都保留修复后调用的父级关系。

这些报告在版本 1.4.3 发布前被关闭，修复仍保留在该版本中。不过，它们的存在仍提醒我们，不应将消息规范化视为已尘埃落定的问题。

该拉取请求在开发期间还收到了一项性能警报。一项记录的基准测试显示，Agent 实例化时间从 4.5 毫秒增加到 5.4 毫秒，回归幅度为 16.62%。

该数字来自一次中间比较，不应被视为对最终版本的独立基准测试。它指出了一个值得测试的领域，而非已确认的生产影响。

对大多数已部署 Agent 而言，提供商延迟将远大于一毫秒的构造时间差异。反复构建 Agent 的高吞吐服务则可能面临不同的成本结构。

团队应在自身进程中对最终包进行基准测试。结果取决于初始化模式、中间件、工具、模型配置和对象复用方式。

正确性仍是更大的问题。修复后的历史记录既必须满足提供商要求，也必须准确呈现实际发生的情况。

错误结果不应暗示外部操作已经执行。它也应避免促使 Agent 在后续推理中假定操作成功。

使用重要工具的应用应在对话消息列表之外保留独立的执行记录。面向模型的历史记录不足以构成审计追踪。

这些记录应包括所请求的工具、已验证参数、执行状态、返回数据及任何副作用。它们还可帮助团队重建故障，而无需依赖生成的文本。

工程团队可以借助可搜索的本地技术文档集合来支持这项工作。当提供商错误在延迟重放后出现时，运行手册、schema 和事故记录会尤其有价值。

更深层的教训是，Agent 的耐久性依赖于状态修复。更好的模型并不能消除规范化错误消息、保留因果关系以及区分尝试操作与已完成操作的需要。

版本 1.4.3 改进了这一修复路径。后续讨论表明，开发者应针对计划重放的每个提供商进行测试。

开发者在发布后应关注什么

接下来的证据应来自跨提供商工作负载、更新后的模型配置，以及围绕真实故障构建的重放测试。

第一个信号是混合提供商环境下的回退完成情况。团队应同时启用缓存设置、工具、流式输出和结构化输出，测试主模型与回退模型。

如果这些请求无需人工逐个清理提供商差异即可完成，新的清理逻辑便发挥了作用。新的被拒绝参数将削弱当前过滤器足够广泛的假设。

第二个信号是 Bedrock Mantle 在持续认证下的行为。启动测试无法覆盖临时凭证刷新、长期运行的工作进程或区域端点变更。

若两种受支持模型系列都能成功刷新，将增强集成可行性的依据。刷新过程中的依赖失败则表明安装指南仍需完善。

第三个信号是修复后历史记录的可移植性。开发者应通过生产环境中使用的每个提供商，重放格式错误和部分修复的工具调用历史记录。

理想结果是 Agent 能在不丢弃上下文或虚构工具成功的情况下继续运行。提供商特定的验证错误将表明，共享修复策略还需要进一步专门化。

从 1.4.2 升级的团队应先从回归测试开始，而非大范围投入生产。最有价值的案例是此前失败的历史记录和请求配置。

使用 Mantle 时，应将 langchain-aws 固定在兼容版本，然后在干净环境中验证所需 extras。现有开发机器可能因无关安装而掩盖缺失依赖。

对于 GPT-6 结构化输出，应检查所选策略并验证真实 schema。不要假定一个成功的简单对象就能覆盖嵌套的生产响应。

对于模型回退，应记录所选模型和清理后的请求类别。避免记录密钥、原始凭证或机密提示内容。

对于工具调用修复，应在移除敏感数据后，将格式错误的调用保留为测试夹具。当提供商或框架版本变化时，这些夹具可以防止回归。

这些变化都不能取代应用层控制。超时、有限重试、幂等键、执行记录和人工审核，对于重要操作仍然必不可少。

该版本改进的是当提供商差异传导至 Agent 层时的框架行为。这一点很有价值，因为这类差异正变得越来越常见。

因此，langchain==1.4.3 最适合被理解为一个可靠性补丁，同时带来一项值得关注的集成功能。它的重要性在于试图保留的场景：回退、schema 生成、对话重放和提供商路由。

如果你的 Agent 使用这些路径，请在升级前复现故障，并在升级后重新运行它们。然后测试组合工作流，因为生产故障很少会遵守各项修复之间的边界。