欢迎贡献代码!无论你是在修复 bug、添加功能,还是改进性能,你的贡献都会帮助成千上万的开发者获得更好的开发体验。

开始

如果你正在寻找可以着手处理的问题,请查看各仓库中标记为 “help wanted” 的 issue:

LangChain

标签

LangGraph

标签

Deep Agents

标签
提交大型新功能或重构之前,请先打开 issue 或在论坛发帖讨论。这可以确保变更与项目目标一致,并避免重复工作。

快速修复:提交 bugfix

对于简单 bugfix,你可以立即开始:
1

复现问题

在克隆仓库之前,请确保你可以可靠复现该 bug。这有助于确认问题,并为修复提供起点。维护者和其他贡献者应能根据你的描述复现问题,而无需额外设置或修改。
2

Fork 仓库

LangChainLangGraphDeep Agents 仓库 fork 到你的
3

克隆并设置

git clone https://github.com/your-username/name-of-forked-repo.git

# For instance, for LangChain:
git clone https://github.com/parrot123/langchain.git
# Inside your repo, initialize environment and install dependencies
uv venv && source .venv/bin/activate
uv sync --all-groups

# or, to install a specific group only:
uv sync --group test
如果你之前尚未安装 uv,需要先安装它
4

创建分支

为你的修复创建一个新分支。这有助于保持变更有组织,也让之后提交 pull request 更容易。
git checkout -b your-username/short-bugfix-name
5

编写失败测试

添加在没有你的修复时会失败的单元测试。这能验证 bug 已解决,并防止回归。
6

进行修改

按照代码质量标准修复 bug。做出解决问题所需的最小变更。强烈建议贡献者在开始编码前先在 issue 中留言。例如:
“我想处理这个问题。我的计划方法是 […简短说明…]。这是否符合维护者预期?”
30 秒的留言通常可以避免在初始方案不正确时浪费精力。
7

验证修复

确保测试通过且没有引入回归。提交 PR 前,请确保所有测试都能在本地通过。
make format
make lint
make test

# For bugfixes involving integrations, also run:
make integration_tests
# (You may need to set up API testing credentials)
8

记录变更

如果行为发生变化,请更新 docstring 和/或行内注释。
9

提交 pull request

按照提供的 PR 模板操作。如果适用,请使用 closing keyword 引用你正在修复的 issue,例如 Fixes #ISSUE_NUMBER,这样 PR 合并时会自动关闭该 issue。

完整开发设置

对于持续开发或更大的贡献:
  1. 查看贡献指南,了解功能、bugfix 和集成的要求
  2. 按照下方设置指南设置环境
  3. 了解仓库结构和包组织方式
  4. 学习开发流程,包括测试和 linting

贡献指南

在开始为 LangChain 项目贡献之前,请花点时间思考你为什么想贡献。如果你的唯一目标是在简历中添加一次 “first contribution”,或者只是想快速完成一个小任务,你可能更适合参加 boot-camp 或在线教程。 为开源项目贡献需要时间和精力,但它也能帮助你成为更好的开发者并学习新技能。不过,请了解它可能比跟随培训课程更难、更慢。也就是说,如果你愿意花时间把事情做好,贡献开源是值得的。

向后兼容性

除关键安全修复外,不允许对公共 API 进行 breaking change。有关主版本发布的详细信息,请参阅版本政策
通过以下方式保持兼容性:
始终保留
  • 函数签名和参数名
  • 类接口和方法名
  • 返回值结构和类型
  • 公共 API 的 import 路径
可接受的修改
  • 添加新的可选参数
  • 向类添加新方法
  • 在不改变行为的情况下提升性能
  • 添加新模块或函数
  • 这会破坏现有用户代码吗?
  • 检查你的目标是否为公共接口
  • 如有需要,它是否在 __init__.py 中导出?
  • 测试中是否已有使用模式?

新功能

项目对新功能保持较高标准。通常,如果没有现有 issue 展示迫切需求,项目不会接受外部贡献者提出的新核心抽象。这也适用于基础设施和依赖项变更。 一般来说,功能贡献要求包括:
1

设计讨论

打开 issue 并说明:
  • 你要解决的问题
  • 提议的 API 设计
  • 预期使用模式
2

实现

  • 遵循现有代码模式
  • 包含完整测试和文档
  • 考虑安全影响
3

集成考量

  • 这会如何与现有功能交互?
  • 是否存在性能影响?
  • 是否引入新依赖?
维护者会拒绝可能导致安全漏洞或报告的功能。

安全指南

安全至关重要。不要引入漏洞或不安全模式。
安全检查清单:
  • 验证并清理所有用户输入
  • 在模板和查询中正确转义数据
  • 不要对用户数据使用 eval()exec()pickle,因为这可能导致任意代码执行漏洞
  • 使用具体的异常类型
  • 不要在错误消息中暴露敏感信息
  • 实现正确的资源清理
  • 避免添加硬依赖
  • 尽量减少可选依赖
  • 检查第三方包是否存在安全问题

开发环境

正在使用 AI coding agent? 安装 LangChain Skills,以提升 agent 在 LangChain 生态任务上的表现。然后点击本页右上角的 “Copy page” 按钮,并将原始内容粘贴给你的 agent,让它自动设置环境。
Python 项目使用 uv 管理依赖。请确保已安装最新版本。
项目会尽力保持所有 Python 包的设置方式一致。进入包目录后,运行:
uv sync --all-groups
make test  # Verify unit tests pass before starting development
查看贡献指南后,请在下方仓库结构部分找到你正在处理的组件所在包目录。

仓库结构

LangChain 以 monorepo 形式组织,包含多个包:

核心包

  • langchain(位于 libs/langchain/):包含 chains、agents 和 retrieval 逻辑的主包
  • langchain-core(位于 libs/core/):基础接口和核心抽象
这些包位于 libs/partners/,是针对特定集成独立版本化的包。例如:许多 partner 包位于外部仓库。请查看集成列表了解详情。

开发流程

Pre-commit hooks

LangChainDeep Agents 仓库包含 pre-commit hooks,会在每次提交前自动运行格式化、linting 和验证检查。从仓库根目录安装它们:
pip install pre-commit  # or: uv tool install pre-commit
pre-commit install
这些 hooks 会强制执行:
  • 禁止直接提交到受保护分支
  • YAML 和 TOML 语法验证
  • 修复行尾空格和文件末尾
  • 规范化智能引号和非标准空格
  • 每个包的 make formatmake lint

运行测试

目录路径相对于你正在处理的包。
尽可能优先选择单元测试,而不是集成测试。单元测试会在每个 pull request 上运行,因此它们应该快速且可靠。集成测试会按计划运行,并需要更多设置,因此应保留用于确认与外部服务的接口点。

单元测试

位置tests/unit_tests/ 单元测试覆盖不需要调用外部 API 的模块化逻辑。如果添加新逻辑,你应该添加单元测试。在单元测试中,请检查前处理/后处理,并 mock 外部依赖。 要求
  • 不允许网络调用
  • 测试所有代码路径,包括边界情况
  • 对外部依赖使用 mock
运行单元测试:
make test

# Or directly:
uv run --group test pytest tests/unit_tests

# To run a specific test:
TEST_FILE=tests/unit_tests/test_imports.py make test

集成测试

位置tests/integration_tests/ 集成测试覆盖需要调用外部 API 的逻辑,通常是与其他服务的集成。 集成测试需要访问外部服务或提供商 API,这可能产生费用,因此默认不会运行。 并非每次代码变更都需要集成测试,但请记住,评审过程中可能会单独要求或运行集成测试。 要求
  • 使用外部服务测试真实集成
  • 使用环境变量存储 API key
  • 在凭据不可用时优雅跳过
运行集成测试:
make integration_tests

# Or directly:
uv run --group test --group test_integration pytest --retries 3 --retry-delay 1 tests/integration_tests

# To run a specific test:
TEST_FILE=tests/integration_tests/test_openai.py make integration_tests

代码质量标准

贡献必须遵循以下质量要求:
必需:所有函数都要有完整类型注解
def process_documents(
    docs: list[Document],
    processor: DocumentProcessor,
    *,
    batch_size: int = 100
) -> ProcessingResult:
    """Process documents in batches.

    Args:
        docs: List of documents to process.
        processor: Document processing instance.
        batch_size: Number of documents per batch.

    Returns:
        Processing results with success/failure counts.
    """

依赖项

LangChain 包会区分硬依赖可选依赖,以保持包轻量,并最大限度减少用户的安装开销。
几乎所有新依赖都应是可选依赖。在以下情况下使用可选依赖:
  • 该依赖只对特定集成或功能是必需的
  • 没有该依赖时,用户仍能有意义地使用该包
  • 该依赖很大,或有许多传递依赖
要求:
  • 未安装该依赖的用户必须能够导入你的代码,且没有任何副作用(无 warning、无 error、无 exception)
  • 不修改 pyproject.tomluv.lock
添加可选依赖:
  1. 将依赖添加到适当的测试依赖文件中,例如 extended_testing_deps.txt
  2. 添加一个单元测试,至少尝试导入新代码。理想情况下,该单元测试使用轻量 fixture 测试代码逻辑。
  3. 对任何需要该依赖的单元测试使用 @pytest.mark.requires("package_name") 装饰器。

测试编写指南

为了编写有效测试,请遵循以下良好实践:
  • 在 docstring 中使用自然语言描述测试
  • 使用描述性变量名
  • 断言要全面
def test_document_processor_handles_empty_input():
    """Test processor gracefully handles empty document list."""
    processor = DocumentProcessor()

    result = processor.process([])

    assert result.success
    assert result.processed_count == 0
    assert len(result.errors) == 0

提交 PR

测试通过且代码符合质量标准后:
  1. 推送分支并打开 pull request
  2. 遵循提供的 PR 模板
  3. 使用 closing keyword 引用相关 issue,例如 Fixes #123
  4. 等待 CI 检查完成
如果你的 PR 包含 AI 生成内容,必须遵循可接受的 LLM 使用方式政策。看起来像低投入 AI 生成垃圾内容的 PR 会被直接关闭且不作评论。
请及时处理 CI 失败。维护者可能会关闭在合理时间内无法通过 CI 的 PR。

获取帮助

目标是让开发者设置尽可能易于使用。如果在设置过程中遇到任何困难,请在 community slack 提问,或打开论坛帖子
现在你已经准备好为 LangChain 贡献高质量代码了!