概念

本概念指南涵盖与在 LangSmith 中管理用户、组织和工作区相关的主题。

资源层次结构

组织

组织是 LangSmith 中具有自己的计费配置的用户的逻辑分组。通常，每个公司有一个组织。一个组织可以有多个工作区。有关更多详细信息，请参阅设置指南。

首次登录时，系统将自动为您创建一个个人组织。如果您想与他人协作，可以创建一个单独的组织并邀请您的团队成员加入。 个人组织和共享组织之间存在一些重要差异：

特征	个人	共享
Maximum workspaces	1	Variable, depending on plan (see pricing page
Collaboration	Cannot invite users	Can invite users
Billing: paid plans	Developer plan only	All other plans available

工作区

信息

工作区以前称为租户。在过渡期间，某些代码和 API 可能在一段时间内仍会引用旧名称。

工作区是组织内用户和资源的逻辑分组。工作区将资源和访问控制的信任边界分开。 用户可能在企业空间中拥有权限，这些权限授予他们访问该企业空间中的资源的权限，包括跟踪项目、数据集、注释队列和提示。有关更多详细信息，请参阅设置指南。

建议为组织中的每个团队创建一个单独的工作区。要进一步组织资源，您可以使用 Resource Tags 对工作区中的资源进行分组。

下图显示了一个示例工作区设置页面：

下图说明了组织、工作区以及工作区范围内和工作区内的不同资源之间的关系：

有关在哪个范围（组织或工作区）中可用的功能的详细信息，请参阅下表：

资源/设置	范围
Trace Projects	Workspace
Annotation Queues	Workspace
Deployments	Workspace
Datasets & Experiments	Workspace
Prompts	Workspace
Resource Tags	Workspace
API Keys	Workspace
Settings including Secrets, Feedback config, Models, Rules, and Shared URLs	Workspace
User management: Invite User to Workspace	Workspace
RBAC: Assigning Workspace Roles	Workspace
Data Retention, Usage Limits	Workspace*
Plans and Billing, Credits, Invoices	Organization
User management: Invite User to Organization	Organization**
Adding Workspaces	Organization
Assigning Organization Roles	Organization
RBAC: Creating/Editing/Deleting Custom Roles	Organization

* 数据保留设置和使用限制也将很快在组织级别推出 ** 自托管安装可以通过功能标志启用用户加入组织的工作区级邀请。 有关详细信息，请参阅自托管用户管理文档。

资源标签

资源标签允许您在工作区中组织资源。每个标签都是可以分配给资源的键值对。 标签可用于在 UI 和 API 中筛选工作区范围的资源：项目、数据集、注释队列、部署和实验。

每个新工作区都带有两个默认标签键：Application和Environment;顾名思义，这些标签可用于根据它们所属的应用程序和环境对资源进行分类。 可以根据需要添加更多标签。

LangSmith 资源标签与 AWS 等云服务中的标签非常相似。

用户管理和 RBAC

用户

用户是有权访问 LangSmith 的人员。用户可以是一个或多个组织的成员，也可以是这些组织内的工作区。

组织成员在组织设置中进行管理：

工作区成员在工作区设置中进行管理：

API 密钥

自 2024 年 10 月 22 日起弃用的旧版密钥

我们终止了对前缀为ls__2024 年 10 月 22 日，支持个人访问令牌 （PAT） 和服务密钥。我们要求对所有新集成使用 PAT 和服务密钥。前缀为ls__自 2024 年 10 月 22 日起不再有效。

个人访问令牌 （PAT）

个人访问令牌 （PAT） 用于对 LangSmith API 的请求进行身份验证。它们由用户创建，范围限定为用户。PAT 将具有与创建它的用户相同的权限。

PAT 的前缀为lsv2_pt_

服务密钥

服务密钥类似于 PAT，但用于代表服务账户对 LangSmith API 的请求进行身份验证。

服务密钥以lsv2_sk_

注意

要了解如何创建服务密钥或 Personal Access Token，请参阅设置指南

组织角色

组织角色不同于下面的企业功能 （RBAC），用于多个工作区的上下文。您的组织角色决定了您的工作区成员资格特征和组织级别权限。请参阅 组织设置指南 以了解更多信息。

所选的组织角色也会影响工作区成员资格，如下所述：

• Organization Admin授予管理所有组织配置、用户、计费和工作区的完全访问权限。一Organization Admin具有Admin访问组织中的所有工作区
• Organization User可以读取组织信息，但不能在组织级别执行任何写入作。一Organization User可以像往常一样添加到工作区的子集并分配工作区角色（如果启用了 RBAC），这些角色在工作区级别指定权限。

信息

这Organization User角色仅在具有多个工作区的计划中可用。在仅限于单个工作区的组织中，所有用户都是Organization Admins. 自定义组织范围的角色尚不可用。

有关所有组织权限，请参阅下表：

	组织用户	组织管理员
View organization configuration	✅	✅
View organization roles	✅	✅
View organization members	✅	✅
View data retention settings	✅	✅
View usage limits	✅	✅
Admin access to all workspaces		✅
Manage billing settings		✅
Create workspaces		✅
Create, edit, and delete organization roles		✅
Invite new users to organization		✅
Delete user invites		✅
Remove users from an organization		✅
Update data retention settings*		✅
Update usage limits*		✅

工作区角色 （RBAC）

注意

RBAC（基于角色的访问控制）是一项仅适用于 Enterprise 客户的功能。如果您对此功能感兴趣，请通过以下方式联系我们的销售团队 sales@langchain.dev 其他计划默认为所有用户使用 Admin 角色。

角色用于定义用户在工作区中拥有的权限集。有三个内置系统角色无法编辑：

• Admin- 对工作区中的所有资源具有完全访问权限
• Viewer- 对工作区中的所有资源具有只读访问权限
• Editor- 具有除企业空间管理（添加/删除用户、更改角色、配置服务密钥）以外的完全权限

组织管理员还可以创建/编辑对不同资源具有特定权限的自定义角色。

可以在组织设置中的Roles标签：

有关分配和创建角色的更多详细信息，请参阅访问控制设置指南。

最佳实践

环境分离

使用资源标签 使用默认标签键按环境组织资源Environment以及环境的不同值（例如dev,staging,prod).此标记结构将允许您立即组织跟踪项目并轻松实施 权限。例如，资源标签上的 ABAC 将提供一种精细的方式来限制对生产跟踪项目的访问。我们不建议您使用 Workspaces 进行环境隔离，因为您无法共享资源 跨工作区。如果您想从staging自prod，我们建议您改用 prompt 标签。有关更多信息，请参阅文档。

使用情况和计费

数据保留

2024 年 5 月，LangSmith 引入了 400 天的跟踪数据最长保留期。2024 年 6 月，LangSmith 推出了 一种新的基于数据保留的定价模型，客户可以在 Exchange 中的跟踪上配置更短的数据保留期 节省高达 10 倍的成本。在此页面上，我们将介绍数据保留的工作原理以及 LangSmith 的定价。

为什么留存很重要

• 隐私：许多数据隐私法规（例如欧洲的 GDPR 或加利福尼亚州的 CCPA）都要求组织删除个人数据 一旦它不再需要用于收集它的目的。设置保留期有助于遵守 这样的规定。
• 成本：LangSmith 对数据保留期较低的跟踪收取较低的费用。有关详细信息，请参阅我们关于如何优化支出的教程。

运作方式

LangSmith 现在有两层基于数据保留的跟踪，具有以下特征：

	基础	扩展
Price	$.50 / 1k traces	$5 / 1k traces
Retention Period	14 days	400 days

保留期结束后的数据删除

在指定的保留期之后，将无法再通过 runs 表或 API 访问跟踪。关联的所有用户数据 在此后的一天内，将从我们的内部系统中删除跟踪（例如输入和输出）。一些元数据 与每个跟踪关联的跟踪可能会无限期保留，以用于分析和计费目的。

数据保留自动升级

谨慎

自动升级可能会影响您的账单。请仔细阅读本节以充分了解您的 估计的 LangSmith 追踪成本。

当您使用某些功能时baseTier 跟踪，则其数据保留期将自动升级为extended层。这将增加保留期和跟踪成本。

在以下情况下，跟踪将升级的方案的完整列表：

• 将 Feedback 添加到跟踪上的任何运行
• Annotation Queue 接收来自跟踪的任何运行
• Run Rule （运行规则） 匹配跟踪中的任何运行

为什么要使用自动升级跟踪？

我们有两个原因支持用于跟踪的自动升级模型：

1. 我们认为，从根本上说，符合这些条件中的任何一个的跟踪都比其他跟踪更有趣，并且 因此，用户能够让他们停留更长时间是件好事。
2. 从理念上讲，我们希望向客户收取一个数量级的费用，以用于可能无法有意义交互的跟踪。 我们认为自动升级使我们的定价模型与 LangSmith 带来的价值保持一致，其中只有具有有意义交互的跟踪 按更高的费率收费。

如果您对我们的定价模式有任何疑问或疑虑，请随时联系 support@langchain.dev 并告诉我们您的想法！

数据保留对下游功能有何影响？

• 注释队列、运行规则和反馈：使用这些功能的跟踪将自动升级。
• 监控：即使在基本层跟踪的数据保留期结束后，监控选项卡仍将继续工作。它由 跟踪存在 >30 天的元数据，这意味着即使basetier 跟踪。
• 数据集：数据集具有无限期的数据保留期。以不同的方式重述，如果您将跟踪的输入和输出添加到数据集中， 它们永远不会被删除。如果您使用 LangSmith 进行数据收集，我们建议您利用数据集 特征。

计费模式

计费指标

在您的 LangSmith 发票上，您将看到我们收取费用的两个指标：

• LangSmith 跟踪（基本费用）
• LangSmith 跟踪（延长数据保留升级）。

第一个指标包括所有跟踪，与层无关。第二个指标仅计算延长保留跟踪的数量。

为什么要测量所有跟踪记录 + 升级跟踪记录，而不是基本跟踪记录和扩展跟踪记录？

在考虑我们的定价时，一个自然而然的问题是为什么不直接显示basetier 和extended层 直接在发票上跟踪？

虽然我们知道这会更直接，但它并不适合跟踪升级。考虑一个base层跟踪，并升级到extended7 月 3 日的级别。这base层 跟踪发生在 6 月的账单周期内，但升级发生在 7 月的账单周期内。因此 我们需要能够独立衡量这两个事件，以便正确地向客户收费。

如果您的跟踪记录为延长保留跟踪记录，则base和extended指标都将被记录 具有相同的时间戳。

成本明细

跟踪的基本费用为每条跟踪 0.05 美分。我们对升级进行了定价，以便extended保留跟踪 成本是基本层跟踪价格的 10 倍（每条跟踪 50 美分），包括这两个指标。因此，每次升级的成本为 45 美分。

速率限制

LangSmith 具有速率限制，旨在确保所有用户的服务稳定性。

为确保访问和稳定性，LangSmith 将以 HTTP 状态代码 429 进行响应，表明在以下情况下已超出速率或使用限制：

场景

Application Load Balancer 在 1 分钟内的临时吞吐量限制

此 429 是在 1 分钟时段内按每个 API 密钥/访问令牌超过固定数量的 API 调用的结果。窗口的开始时间会略有不同（不能保证从时钟分钟的开始开始），并且可能会根据应用程序部署事件而变化。

收到最大事件数后，我们将以 429 响应，直到到达评估窗口开始后 60 秒，然后重复该过程。

此 429 由我们的 Application Load Balancer 引发，是独立于计划层级的所有 LangSmith 用户的一种机制，可确保所有用户的服务连续性。

方法	端点	限制	窗
DELETE	Sessions	30	1 minute
POST OR PATCH	Runs	5000	1 minute
POST	Feedback	5000	1 minute
*	*	2000	1 minute

注意

LangSmith 开发工具包采取措施，通过将单个会话 ID 的最多 100 个运行批处理到单个 API 调用中，以最大限度地降低在与运行相关的终端节点上达到这些限制的可能性。

计划级别的每小时跟踪事件限制

此 429 是达到提取的最大每小时事件数的结果，并在 UTC 的每个时钟小时开始时在固定窗口中进行评估，并在每个新小时的顶部重置。

在此上下文中，事件是运行的创建或更新。因此，如果创建了 run，然后在同一小时时段内更新，则计为 2 个事件，计入此限制。

这是由我们的应用程序引发的，并且因计划层而异，我们的 Startup/Plus 和 Enterprise 计划层上的组织的每小时限制高于我们的免费和开发人员计划层，这些层是专为个人使用而设计的。

计划	限制	窗
Developer (no payment on file)	50,000 events	1 hour
Developer (with payment on file)	250,000 events	1 hour
Startup/Plus	500,000 events	1 hour
Enterprise	Custom	Custom

计划级别的每小时跟踪数据摄取限制

此 429 是在跟踪输入、输出和元数据中达到最大数据量的结果，并在 UTC 的每个时钟小时开始时在固定窗口中进行评估，并在每个新小时的顶部重置。

通常，输入、输出和元数据在运行创建和更新事件时发送。因此，如果创建了一个运行，并且在创建时的大小为 2.0MB，在同一个小时时段内更新时的大小为 3.0MB，则根据此限制，将计为 5.0MB 的存储空间。

这是由我们的应用程序引发的，并且因计划层而异，我们的 Startup/Plus 和 Enterprise 计划层上的组织的每小时限制高于我们的免费和开发人员计划层，这些层是专为个人使用而设计的。

计划	限制	窗
Developer (no payment on file)	500MB	1 hour
Developer (with payment on file)	2.5GB	1 hour
Startup/Plus	5.0GB	1 hour
Enterprise	Custom	Custom

计划级别的每月唯一跟踪限制

此 429 是达到每月提取的最大跟踪数的结果，在每个日历月的开始（UTC 时间）开始的固定窗口中进行评估，并在每个新月的月初重置。

这是由我们的应用程序引发的，并且仅适用于没有存档付款方式的开发人员计划层级。

计划	限制	窗
Developer (no payment on file)	5,000 traces	1 month

自行配置的每月使用限制

此 429 是达到组织管理员配置的使用限制的结果，从每个日历月的 UTC 月初开始，在固定窗口中进行评估，并在每个新月的月初重置。

这是由我们的应用程序引发的，并且根据组织的配置设置而有所不同。

在应用程序中处理 429 响应

由于某些 429 响应是临时的，并且可能会在连续调用中成功，因此，如果您在应用程序中直接调用 LangSmith API，我们建议使用指数回退和抖动实现重试逻辑。

为方便起见，使用 LangSmith SDK 构建的 LangChain 应用程序内置了此功能。

注意

请务必注意，如果长时间使终端节点饱和，重试可能无效，因为您的应用程序最终将运行足够大的积压工作以耗尽所有重试。

如果是这种情况，我们想更具体地讨论您的需求。请联系 LangSmith 支持部门，提供有关您的应用程序吞吐量需求和示例代码的详细信息，我们可以与您合作，更好地了解最佳方法是修复错误、更改应用程序代码还是不同的 LangSmith 计划。

使用限制

LangSmith 允许您配置跟踪的使用限制。请注意，这些是使用限制，而不是支出限制，后者 意味着它们允许您限制某些事件的发生次数，而不是您将花费的总金额。

LangSmith 允许您设置两个不同的每月限制，这与上述数据保留指南中讨论的 Billable Metrics 相同：

• 所有跟踪限制
• 扩展的数据保留跟踪限制

这些允许您分别限制总跟踪数和延长数据保留跟踪数。

使用限制的属性

使用限制是近似值，这意味着我们不保证限制的准确性。在极少数情况下，有 在限制使用量之前，可能会处理超过限制阈值的其他跟踪 开始应用。

延长数据保留跟踪限制的副作用

延长的数据保留跟踪限制具有副作用。如果已达到限制，则任何可能 导致跟踪层的自动升级变得不可访问。这是因为跟踪的自动升级会导致 要创建另一个延长保留跟踪，而限制又不应允许该跟踪。因此，您可以 不再：

1. 匹配运行规则
2. 向跟踪添加反馈
3. 将运行添加到注释队列

这些功能中的每一个都可能导致自动升级，因此我们会在达到限制时将其关闭。

更新使用限制

使用限制可以从Settings页面Usage and Billing.Limit 值被缓存，因此它 可能需要一两分钟才能应用新的限制。

相关内容

• 有关如何优化支出的教程