- 以团队为中心的工作空间：每个团队一个工作空间（推荐给大多数客户）
- 协作式工作空间：每个工作空间包含多个团队
- 项目隔离的工作空间：每个团队拥有多个工作空间（适用于严格的隔离需求）
以团队为中心的工作空间
此模型（每个团队一个工作空间）使用单个组织作为顶级边界。在组织内部，使用多个工作空间来隔离不同的团队或业务单元。每个工作空间代表特定团队的逻辑边界，并管理该团队可以访问的数据和资源。在工作空间内，团队使用多个应用来分组支持同一智能体的资源。一个应用还可能包含不同的资源，例如用于开发和生产环境的独立追踪项目。- 优点： 单个工作空间允许共享所有团队资源，使得团队内部的协作和迭代变得简单直接。它还简化了从开发到生产的升级过程。例如，同一个提示词可以通过标签进行版本控制和升级到生产环境，而无需复制或重复。
- 缺点： 主要的权衡在于同一团队不同环境之间的隔离有限。开发、测试和生产资源共存于同一个应用中，因此团队必须依赖标签和约定来避免对生产环境造成意外影响。RBAC 的作用范围在工作空间级别。ABAC 通过基于资源属性（例如允许用户仅访问开发资源）限制访问，提供了工作空间内更细粒度的权限控制。
协作式工作空间
在此模型（每个工作空间包含多个团队）中，多个团队在组织内共享一个工作空间，并使用应用和ABAC来分离资源并管理访问。因此，提示词和部署等共享资源可以在团队间重复使用，而对追踪记录和数据集等敏感资源的访问则仅限于所属团队。- 优点： 提示词和部署等公共资源可以在团队间共享和重用，增强了协作并减少了重复工作。与以团队为中心的工作空间模型不同，协作不仅限于单个团队，可以扩展到工作空间内的所有团队。
- 缺点： 团队和环境之间的隔离性弱于多工作空间模型，并且依赖于 ABAC 的正确使用。标签或策略配置错误可能导致敏感的追踪记录或数据集在团队间暴露，跨多个团队管理权限也增加了操作复杂性。
项目隔离的工作空间
此方法仅应在需要严格隔离时使用。
- 优点： 团队、项目和环境之间具有强隔离性。仅拥有开发工作空间访问权限的用户无法查看或访问生产数据或任何生产资源，降低了意外更改或跨环境误用的风险。
- 缺点： 资源无法在工作空间之间共享。即使是将智能体从开发升级到生产环境，重用提示词、数据集或实验也需要在工作空间之间手动复制，这会带来摩擦和重复工作。
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.