可访问的文档是 LangChain 的重要组成部分。我们欢迎新功能/集成的文档，以及社区对现有文档的改进。
我们通常不会在没有迫切需求的情况下合并来自外部贡献者的新教程。如果您认为文档中缺少某个主题或未得到充分涵盖，请开启新问题。
所有文档都属于四个类别之一：

概念指南

提供更深入理解和见解的解释

参考文档

API 和实现细节的技术描述

教程（学习）

指导用户通过实践活动建立理解的课程

操作指南

为知道他们想要完成什么的用户提供面向任务的说明

​
入门

​
快速编辑：修复拼写错误

对于修复拼写错误等简单更改，您可以直接在 GitHub 上编辑，无需设置本地开发环境：
先决条件：
1

查找页面

导航到任何文档页面，滚动到页面底部，然后单击链接”在 GitHub 上编辑此页面的源代码”
2

分叉仓库

GitHub 将提示您将仓库分叉到您的账户。确保分叉到您的
3

进行更改

直接在 GitHub 的 Web 编辑器中更正拼写错误
4

提交更改

单击 Commit changes... 并为您的提交提供描述性标题，如 fix(docs): summary of change。如果适用，请添加扩展描述
5

创建拉取请求

GitHub 将重定向您以创建拉取请求。为其提供标题（通常与提交相同）并遵循 PR 模板检查清单（如果存在）
文档 PR 通常在几天内审查。请密切关注您的 PR 以解决维护者的任何反馈。除非您有新信息要提供，否则请勿顶起 PR - 维护者将在他们有空时处理它。

​
完整开发 IDE 设置

对于更大的更改或持续贡献，在您的机器上设置本地开发环境很重要。我们的文档构建管道在您编辑时提供本地预览和实时重载，这对于确保您的更改在提交之前按预期显示很重要。 请查看文档仓库 README.md 中概述的设置环境的步骤。

​
文档类型

在适用的情况下，所有文档都必须同时提供 Python 和 JavaScript/TypeScript 的翻译。有关详细信息，请参阅我们的本地化指南。

​
概念指南

概念指南抽象地涵盖核心概念，提供深入理解。
  • Understanding-focused: Explain why things work as they do
  • Broad perspective: Higher and wider view than other types
  • Design-oriented: Explain decisions and trade-offs
  • Context-rich: Use analogies and comparisons
  • Explain design decisions - “why does concept X exist?”
  • Use analogies and reference alternatives
  • Avoid blending in too much reference content
  • Link to related tutorials and how-to guides
  • Focus on the “why” rather than the “how”

​
References

Reference documentation contains detailed, low-level information describing exactly what functionality exists and how to use it.

Python reference

 A good reference should:
  • Describe what exists (all parameters, options, return values)
  • Be comprehensive and structured for easy lookup
  • Serve as the authoritative source for technical details
See the contributing guide for Python reference docs.
  • Be consistent; follow existing patterns for provider-specific documentation
  • Include both basic usage (code snippets) and common edge cases/failure modes
  • Note when features require specific versions
  • New integrations or providers need dedicated reference pages
  • Complex configuration options require detailed explanation
  • API changes introduce new parameters or behavior
  • Community frequently asks questions about specific functionality

​
Writing standard

Reference documentation has different standards - see the reference docs contributing guide for details.

​
Mintlify components

Use appropriate Mintlify components to enhance readability:
  • Callouts
  • Structure
  • Code
  • <Note> for helpful supplementary information
  • <Warning> for important cautions and breaking changes
  • <Tip> for best practices and advice
  • <Info> for neutral contextual information
  • <Check> for success confirmations

​
Page structure

Every documentation page must begin with YAML frontmatter: 
---
title: "Clear, specific title"
---

​
Co-locate Python and JavaScript/TypeScript content

All documentation must be written in both Python and JavaScript/TypeScript when possible. To do so, we use a custom in-line syntax to differentiate between sections that should appear in one or both languages: 
:::python
Python-specific content. In real docs, the preceding backslash (before `python`) is omitted.
:::

:::js
JavaScript/TypeScript-specific content. In real docs, the preceding backslash (before `js`) is omitted.
:::

Content for both languages (not wrapped)
We don’t want a lack of parity to block contributions. If a feature is only available in one language, it’s okay to have documentation only in that language until the other language catches up. In such cases, please include a note indicating that the feature is not yet available in the other language.
If you need help translating content between Python and JavaScript/TypeScript, please ask in the community slack or tag a maintainer in your PR.

​
Localization

We are working to add support for other languages, thanks to our LangChain Ambassadors!

​
Quality standards

​
General guidelines

Multiple pages covering the same material are difficult to maintain and cause confusion. There should be only one canonical page for each concept or feature. Link to other guides instead of re-explaining.
Take a less-is-more approach. If another section with a good explanation exists, link to it rather than re-explain, unless your content presents a new angle.

​
Accessibility requirements

Ensure documentation is accessible to all users:
  • Structure content for easy scanning with headers and lists
  • Use specific, actionable link text instead of “click here”
  • Include descriptive alt text for all images and diagrams

​
Testing and validation

Before submitting documentation:
1

Test all code

Run all code examples to ensure they work correctly
2

Check formatting

make lint
make format
3

Build locally

docs build
Verify the build completes without errors
4

Review links

Check that all internal links work correctly

​
In-code documentation

​
Language and style

Use Google-style docstrings with complete type hints for all public functions.
Follow these standards for all documentation:
  • Voice: Use second person (“you”) for instructions
  • Tense: Use active voice and present tense
  • Clarity: Write clear, direct language for technical audiences
  • Consistency: Use consistent terminology throughout
  • Conciseness: Keep sentences concise while providing necessary context

​
Code examples

Always test code examples before publishing. Never include real API keys or secrets.
Requirements for code examples:
1

Completeness

Include complete, runnable examples that users can copy and execute without errors
2

Realism

Use realistic data instead of placeholder values like “foo” or “example”
3

Error handling

Show proper error handling and edge case management
4

Documentation

Add explanatory comments for complex logic
Example of a well-documented function: 
def filter_unknown_users(users: list[str], known_users: set[str]) -> list[str]:
    """Filter out users that are not in the known users set.

    Args:
        users: List of user identifiers to filter.
        known_users: Set of known/valid user identifiers.

    Returns:
        List of users that are not in the known_users set.

    Raises:
        ValueError: If users list contains invalid identifiers.
    """
    return [user for user in users if user not in known_users]

​
Getting help

Our goal is to have the simplest developer setup possible. Should you experience any difficulty getting setup, please ask in the community slack or open a forum post.
You now have everything you need to contribute high-quality documentation to LangChain! 🎤🦜
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.