LangSmith 使用层次结构来组织您的工作： 组织, 工作空间, 应用和 资源。此结构让您在协作与访问控制之间取得平衡，使您能够为团队需求选择合适的隔离级别。
LangSmith 权限系统建立在此层次结构之上。使用 基于角色的访问控制 (RBAC)用户 权限 的作用域限定在一个或多个工作空间，强制执行工作空间之间的隔离。使用更细粒度的 基于属性的访问控制 (ABAC)，可以基于工作空间内的标签或应用等属性进一步限制或授予访问权限（例如，仅允许用户访问开发资源或仅访问与特定应用关联的资源）。
本页介绍三种常见的工作空间组织方法，基于团队隔离需求：
- - 以团队为中心的工作空间：每个团队一个工作空间（推荐用于大多数客户）
- - 协作工作空间：每个工作空间多个团队
- - 项目隔离工作空间：每个团队多个工作空间（用于严格隔离要求）
以团队为中心的工作空间
此模型（每个团队单一工作空间）使用单一组织作为顶层边界。在组织内，使用多个工作空间来隔离不同的团队或业务单元。每个工作空间代表特定团队的逻辑边界，并管理该团队可以访问的数据和资源。在工作空间内，团队使用多个应用程序来分组支持同一代理的资源。应用程序还可以包含不同的资源，例如用于开发和生产环境的独立追踪项目。
graph LR
Org[Organization]
WS1[Workspace: Team A]
WS2[Workspace: Team B]
App1A[Application]
App1B[Application]
DevA[Dev Tracing Project]
ProdA[Prod Tracing Project]
DatasetA[Dataset]
DevB[Dev Tracing Project]
ProdB[Prod Tracing Project]
DatasetB[Dataset]
Org --> WS1
Org --> WS2
WS1 --> App1A
WS2 --> App1B
App1A --> DevA
App1A --> ProdA
App1A --> DatasetA
App1B --> DevB
App1B --> ProdB
App1B --> DatasetB
classDef orgStyle fill:#B2DEFF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef wsStyle fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef appStyle fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900
classDef resourceStyle fill:#F2FAFF,stroke:#40668D,stroke-width:1px,color:#2F4B68
class Org orgStyle
class WS1,WS2 wsStyle
class App1A,App1B appStyle
class DevA,ProdA,DatasetA,DevB,ProdB,DatasetB resourceStyle- Pros: 单一工作空间允许共享所有团队资源，使团队内的协作和迭代变得简单。它还简化了从开发到生产的升级过程。例如，相同的 提示词 可以使用标签进行版本控制并升级到生产环境，无需复制或重复。
- Cons: 主要权衡是同一团队各环境间的隔离有限。开发、测试和生产资源共存于同一应用程序中，因此团队必须依赖标签和约定来避免对生产环境的意外影响。 RBAC 在工作空间级别进行作用域限定。 ABAC 通过基于资源属性限制访问来提供更细粒度的权限，例如允许用户仅访问开发资源。
协作工作空间
在此模型（每个工作空间多个团队）中，多个团队在组织内共享一个工作空间，并使用应用程序和 ABAC 来分离资源并管理访问。因此，共享资源如 提示词 和 部署 可以在团队之间重复使用，而对敏感资源的访问（如 追踪 和 数据集 ）仅限于所属团队。
graph LR
Org[Organization]
WS[Shared Workspace]
AppA[Application: Team A]
AppB[Application: Team B]
TracesA[Traces: Team A]
DatasetA[Dataset: Team A]
PromptA[Prompt: Shared]
TracesB[Traces: Team B]
DatasetB[Dataset: Team B]
PromptB[Prompt: Shared]
Org --> WS
WS --> AppA
WS --> AppB
AppA --> TracesA
AppA --> DatasetA
AppA --> PromptA
AppB --> TracesB
AppB --> DatasetB
AppB --> PromptB
classDef orgStyle fill:#B2DEFF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef wsStyle fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef appStyle fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900
classDef restrictedStyle fill:#F8E8E6,stroke:#B27D75,stroke-width:1px,color:#634643
classDef sharedStyle fill:#FDF3FF,stroke:#7E65AE,stroke-width:1px,color:#504B5F
class Org orgStyle
class WS wsStyle
class AppA,AppB appStyle
class TracesA,DatasetA,TracesB,DatasetB restrictedStyle
class PromptA,PromptB sharedStyle- Pros: 提示和部署等通用资源可以在团队之间共享和重复使用，提高协作效率并减少重复工作。与以团队为中心的工作区模型不同，协作不限于单个团队，可以跨越工作区内的所有团队。
- Cons: 团队和环境之间的隔离比多工作区模型弱，取决于正确使用 ABAC。配置错误的标签或策略可能会暴露敏感 追踪 or 数据集 跨团队，并且跨多个团队管理权限会增加运维复杂性。
项目隔离工作区
在此模型（每个团队多个工作区）中，通过为单个团队创建多个工作区来增强隔离。工作区可以按项目或环境组织，例如单独的开发和生产工作区。每个工作区完全隔离，拥有自己的用户、数据和资源，访问权限严格限于该工作区。
graph LR
Org[Organization]
WSDev[Workspace: Dev]
WSProd[Workspace: Prod]
AppDev[Application]
AppProd[Application]
TracesDev[Traces]
DatasetDev[Dataset]
DeploymentDev[Deployment]
TracesProd[Traces]
DatasetProd[Dataset]
DeploymentProd[Deployment]
Org --> WSDev
Org --> WSProd
WSDev --> AppDev
WSProd --> AppProd
AppDev --> TracesDev
AppDev --> DatasetDev
AppDev --> DeploymentDev
AppProd --> TracesProd
AppProd --> DatasetProd
AppProd --> DeploymentProd
classDef orgStyle fill:#B2DEFF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef wsStyle fill:#E5F4FF,stroke:#006DDD,stroke-width:2px,color:#030710
classDef appStyle fill:#F6FFDB,stroke:#6E8900,stroke-width:2px,color:#2E3900
classDef resourceStyle fill:#F2FAFF,stroke:#40668D,stroke-width:1px,color:#2F4B68
class Org orgStyle
class WSDev,WSProd wsStyle
class AppDev,AppProd appStyle
class TracesDev,DatasetDev,DeploymentDev,TracesProd,DatasetProd,DeploymentProd resourceStyle