快速开始 - 本地开发
要运行文档的本地预览:http://localhost:3000。编辑 src/ 目录中的文件,即可立即看到更改。
前提条件
前提条件
编辑文档
在 GitHub 上快速编辑
在 GitHub 上快速编辑
对于拼写错误或小改动,可以直接在 GitHub 上编辑,无需本地设置:
- 点击任何页面底部的 在 GitHub 上编辑此页面。
- Fork 到您的个人账户。
- 在 GitHub 的网页编辑器中进行更改。
- 创建一个拉取请求。
仅编辑
src/ 中的文件 — build/ 目录是自动生成的。所有拉取请求必须链接到一个解决方案已由维护者批准的议题或讨论。请参阅我们的拉取请求要求。
创建可共享的预览构建(仅限 LangChain 团队)
创建可共享的预览构建(仅限 LangChain 团队)
当您创建或更新 PR 时,会自动生成一个预览分支/ID。PR 上会留下一条包含该 ID 的评论。
- 从评论中复制预览分支的 ID
- 在 Mintlify 仪表板中,点击 创建预览部署
- 输入预览分支的 ID 并点击 创建部署
- 选择预览并点击 访问 以查看
运行质量检查
在提交更改之前,确保您的代码通过格式化和代码检查:README 中的可用命令部分。
文档类型
所有文档都属于以下四个类别之一:操作指南
面向知道要完成什么任务的用户的任务导向型说明。
概念指南
提供更深入理解和见解的解释。
参考
API 和实现细节的技术描述。
教程
指导用户通过实践活动建立理解的课程。
在适用的情况下,所有文档必须同时包含 Python 和 JavaScript/TypeScript 内容。更多详情,请参阅将 Python 和 JavaScript/TypeScript 内容共置部分。
操作指南
操作指南是面向知道要完成什么任务的用户的任务导向型说明。操作指南的示例可在 LangChain 和 LangGraph 选项卡中找到。特点
特点
- 任务聚焦:专注于特定任务或问题
- 分步进行:将任务分解为更小的步骤
- 实践性:提供具体的示例和代码片段
提示
提示
- 关注 如何做 而不是 为什么
- 使用具体的示例和代码片段
- 将任务分解为更小的步骤
- 链接到相关的概念指南和参考
概念指南
概念指南抽象地涵盖核心概念,提供深入的理解。特点
特点
- 理解聚焦:解释事物为何如此运作
- 广角视角:比其他类型具有更高更广的视角
- 设计导向:解释决策和权衡
- 上下文丰富:使用类比和比较
提示
提示
- 关注 “为什么” 而不是“如何做”
- 提供功能使用不一定需要的补充信息
- 可以使用类比和参考替代方案
- 避免混入过多的参考内容
- 链接到相关的教程和操作指南
参考
参考文档包含详细的底层信息,准确描述存在哪些功能以及如何使用它们。Python 参考
JavaScript/TypeScript 参考
- 描述存在什么(所有参数、选项、返回值)
- 全面且结构化,便于查找
- 作为技术细节的权威来源
为参考文档做贡献
为参考文档做贡献
请参阅 Python 参考文档的贡献指南。
LangChain 参考最佳实践
LangChain 参考最佳实践
- 保持一致;遵循现有特定于提供者的文档模式
- 包括基本用法(代码片段)和常见的边缘情况/故障模式
- 注意功能何时需要特定版本
何时创建新的参考文档
何时创建新的参考文档
- 新的集成或提供者需要专门的参考页面
- 复杂的配置选项需要详细解释
- API 变更引入了新参数或行为
- 社区经常询问有关特定功能的问题
教程
教程是较长的分步指南,它逐步构建,引导用户通过特定的实践活动来建立理解。教程通常可在 学习 选项卡中找到。我们通常不会合并外部贡献者的新教程,除非有迫切需要。如果您觉得文档中缺少某个主题或涵盖不足,请提交新议题。
特点
特点
- 实践性:专注于实践活动以建立理解。
- 分步进行:将活动分解为更小的步骤。
- 实践性:提供顺序的、可运行的代码片段。
- 补充性:提供功能使用不一定需要的额外上下文和信息。
提示
提示
- 代码片段应该是顺序的,并且如果用户按顺序执行步骤,应该是可运行的。
- 为活动提供一些上下文,但链接到相关的概念指南和参考以获取更详细的信息。
写作标准
参考文档有不同的标准 - 详情请参阅参考文档贡献指南。
Mintlify 组件
使用 Mintlify 组件 来增强可读性:- 标注
- 结构
- 代码
<Note>用于有用的补充信息<Warning>用于重要的注意事项和破坏性更改<Tip>用于最佳实践和建议<Info>用于中性的上下文信息<Check>用于成功确认
Mermaid 图表
添加 mermaid 图表时,使用 LangChain 品牌调色板进行节点样式设置。从任何现有图表中复制classDef 行,或使用 CLAUDE.md 中的参考表。
| 角色 | 填充 | 描边 | 文本 |
|---|---|---|---|
| process | #E5F4FF | #006DDD | #030710 |
| trigger | #F6FFDB | #6E8900 | #2E3900 |
| decision | #FDF3FF | #7E65AE | #504B5F |
| output | #EBD0F0 | #885270 | #441E33 |
| alert | #F8E8E6 | #B27D75 | #634643 |
| neutral | #F2FAFF | #40668D | #2F4B68 |
页面结构
每个文档页面必须以 YAML frontmatter 开头:将 Python 和 JavaScript/TypeScript 内容共置
所有文档在可能的情况下都必须同时用 Python 和 JavaScript/TypeScript 编写。为此,我们使用自定义的内联语法来区分应出现在一种或两种语言中的部分:/oss/python/concepts/foo.mdx 和 /oss/javascript/concepts/foo.mdx 生成两个输出(每种语言一个)。每个输出的页面都需要添加到 /src/docs.json 文件中才能包含在导航中。
我们不希望缺乏对等性阻碍贡献。如果某个功能仅在一种语言中可用,那么在另一种语言赶上之前,仅在该语言中提供文档是可以的。在这种情况下,请包含一个说明,指出该功能在另一种语言中尚不可用。如果您需要帮助在 Python 和 JavaScript/TypeScript 之间翻译内容,请在社区 Slack 中提问,或在您的 PR 中标记维护者。
质量标准
通用指南
避免重复
避免重复
涵盖相同材料的多个页面难以维护并会引起混淆。每个概念或功能应只有一个规范页面。链接到其他指南,而不是重新解释。
频繁链接
频繁链接
文档部分不是孤立存在的。频繁链接到其他部分,以便用户了解不熟悉的主题。这包括链接到 API 参考和概念部分。
保持简洁
保持简洁
采取少即是多的方法。如果存在另一个有良好解释的部分,请链接到它,而不是重新解释,除非您的内容提供了新的角度。
无障碍要求
确保文档对所有用户都易于访问:- 使用标题和列表构建内容,便于快速浏览
- 使用具体、可操作的链接文本,而不是“点击此处”
- 为所有图像和图表包含描述性的替代文本
交叉引用
使用一致的交叉引用来连接文档和 API 参考文档。 从文档到 API 参考: 使用@[] 语法链接到 API 参考页面:
@[ChatAnthropic] 将根据构建的文档版本链接到 Python 或 JS API 参考页面,但前提是 link_map.py 文件中存在相应条目! 详情请参见下文。
自动链接如何工作
自动链接如何工作
@[] 语法由 handle_auto_links.py 处理。它在 link_map.py 中查找链接键,该文件包含 Python 和 JavaScript 范围的字典映射。支持的格式:| 语法 | 结果 |
|---|---|
@[ChatAnthropic] | 以 “ChatAnthropic” 作为显示文本的链接 |
@[`ChatAnthropic`] | 以 `ChatAnthropic`(代码格式)作为文本的链接 |
@[text][ChatAnthropic] | 以 “text” 作为文本,ChatAnthropic 作为链接映射中的键的链接 |
\@[ChatAnthropic] | 转义:渲染为字面量 @[ChatAnthropic](无链接 - 本页正在使用的就是这个!) |
- 打开
pipeline/preprocessors/link_map.py - 在
LINK_MAPS中的相应范围(python或js)添加一个条目 - 键是在
@[key]或@[text][key]中使用的链接名称,值是相对于参考主机的路径
README。具体请参阅 mkdocstrings 交叉引用链接语法。
本地化
如果某个功能在两个 SDK 中都存在,请同时为 Python 和 JavaScript/TypeScript 编写文档。如果目前仅支持一种语言,请确保该功能及其引用仅对该语言可见。代码内文档
示例必须正确、尽可能可复制粘贴,并且在您打开拉取请求之前必须经过测试。清楚地标记不可运行的代码片段(例如,伪代码或说明性片段)。获取帮助
我们的目标是尽可能简化开发者的设置。如果您在设置过程中遇到任何困难,请在社区 Slack 中提问或发布论坛帖子。内部团队成员可以在 #documentation Slack 频道中联系。将这些文档通过 MCP 连接到 Claude、VSCode 等,以获取实时答案。

