LangChain Core 1.6.9 发布：with_retry 支持可调用对象

版本概览

LangChain 生态的核心模块 langchain-core 发布了 1.6.9 版本，由 GitHub Actions 自动构建并通过 GitHub 的验证签名发布。这是在 1.6.8 之后的一次小版本迭代，主要围绕重试机制的灵活性做了增强。

作为整个 LangChain 框架的基础依赖，langchain-core 承载了诸如 Runnable 接口、消息抽象、回调系统等关键能力，几乎所有上层组件都依赖它。因此即便是一个小版本更新，也值得使用 LangChain 构建应用的开发者关注。

核心变更：with_retry 接受可调用对象

本次更新最值得关注的改动是 with_retry 现在可以接受一个可调用对象（callable）作为参数（PR #41158）。

在此之前，with_retry 通常通过固定的配置参数来控制重试行为，例如重试次数、是否对特定异常类型重试等。引入可调用对象后，开发者可以传入一个函数来动态决定是否触发重试，这为复杂场景提供了更细粒度的控制能力。

这意味着什么

在真实的生产环境中，调用大语言模型 API 时经常会遇到速率限制、临时网络波动或服务端错误。一个静态的重试策略（比如“固定重试 3 次”）往往无法应对所有情况。通过允许传入可调用对象，开发者可以：

• 根据异常的具体类型或内容决定是否重试
• 结合运行时上下文（如当前请求的优先级）动态调整策略
• 实现更智能的退避逻辑，减少对下游服务的冲击

这类改动看似微小，但对于构建稳健的 LLM 应用链路而言，重试逻辑的可编程化能显著提升系统的容错能力。

with_retry 是 LangChain Runnable 接口提供的一个链式方法，用于为任意 Runnable 组件包裹重试逻辑。其基本用法形如 chain.with_retry(stop_after_attempt=3, retry_if_exception_type=(RateLimitError,))，通过声明式配置指定最大重试次数、触发重试的异常类型以及等待策略等。它底层依赖 tenacity 库实现退避与终止逻辑。1.6.9 之前，所有重试判断条件都必须在调用时静态声明，无法在运行时根据具体错误内容或上下文做出差异化决策。

发布与签名

该版本由 github-actions 于发布，commit 哈希为 fc7dc77，并使用 GitHub 的验证签名机制进行了签名（GPG key ID: B5690EEEBB952194）。签名发布意味着开发者可以验证产物的来源真实性，这对于供应链安全日益受到重视的今天是一个基本保障。

版本号本身遵循了 release(core): 1.6.9 的发布流程（PR #41160），延续了 LangChain 规范化的版本管理方式。

供应链安全（Software Supply Chain Security）近年来因多起开源包投毒事件受到广泛重视。GPG 签名是其中一种常见的完整性验证手段：发布者用私钥对产物签名，使用者通过公钥（此处 key ID 为 B5690EEEBB952194）验证签名，从而确认包确实由声称的主体发布且未被篡改。GitHub Actions 自动签名发布的模式将签名流程纳入 CI/CD 管道，减少了人工操作带来的密钥泄露风险，也为 pip install 等场景提供了可审计的发布溯源链路。对于在生产环境中使用开源依赖的团队，关注依赖包是否有签名机制已逐渐成为安全基线之一。

开发者如何升级

对于已经在使用 LangChain 的项目，升级到该版本通常只需更新依赖版本约束即可。由于这是一个 patch/minor 级别的更新且主要为功能增强（feat），理论上向后兼容风险较低，但建议在升级后对关键链路的重试行为进行回归测试，确保与现有配置的兼容性。

如果你的应用大量依赖对外部 API 的调用，并且希望对失败重试做更精细的控制，那么升级到 1.6.9 以利用新的可调用重试参数会是一个合理的选择。

小结

langchain-core==1.6.9 是一次聚焦于重试机制灵活性的务实更新。虽然变更内容不多，但 with_retry 支持可调用对象这一改进切中了 LLM 应用在生产环境中对容错能力的实际需求。对于追求稳定性的团队而言，这类基础能力的持续打磨，往往比大版本的功能堆砌更有价值。