Zed Organizations：团队订阅、成员邀请与多组织切换的完整指南

Zed Organizations：团队订阅、成员邀请与多组织切换的完整指南

【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed

Zed 的组织（Organization）机制是 Zed Business 团队订阅的管理中心：组织内集中管理成员、账单与管理员控制项。本篇基于官方文档docs/src/business/organizations.md，并结合 Zed 编辑器客户端源码（cloud_api_types、title_bar、client等 crate），讲清楚个人组织与团队组织的区别、如何创建组织、如何通过邮件邀请和管理成员，以及编辑器内组织切换在源码层面是如何实现的，读完你可以独立完成一个 Zed 团队订阅从创建到日常成员管理的全流程。

什么是 Zed Organization

一个 Zed 组织就是团队的 Zed Business 订阅，成员、账单和管理控制都集中在一处管理。与之配套的整体能力见 Zed Business 概览：持有付费 Business 席位的成员可以使用 Zed 托管 AI 模型和无限 Edit Predictions，管理员则统一控制哪些 AI 功能可用、哪些数据会离开团队环境。

个人组织（Personal Organization）

• 每个 Zed 账号在注册时会自动获得一个个人组织，它有独立的订阅、账单和设置，与你加入的任何团队组织完全隔离。
• 个人组织始终处于激活状态——加入某个 Zed Business 组织不会替换或影响它。
• 在 Zed 编辑器中，标题栏有一个组织菜单，以名称显示你当前的组织；点击它可以列出你所属的全部组织并在其间切换。

这一设计在客户端类型定义中有直接对应。从源码结构看，Organization 结构体 恰好包含三个字段：id、name和is_personal，其中is_personal: bool正是编辑器区分“个人组织”与“团队组织”的依据：

#[derive(Debug, PartialEq, Serialize, Deserialize)] pub struct Organization { pub id: OrganizationId, pub name: Arc<str>, pub is_personal: bool, }

而登录响应 GetAuthenticatedUserResponse 会一次性带回该用户的全部组织及上下文信息，包括默认组织与每个组织各自的套餐、配置：

pub struct GetAuthenticatedUserResponse { pub user: AuthenticatedUser, pub feature_flags: Vec<String>, pub organizations: Vec<Organization>, pub default_organization_id: Option<OrganizationId>, pub plans_by_organization: BTreeMap<OrganizationId, KnownOrUnknown<Plan, String>>, pub configuration_by_organization: BTreeMap<OrganizationId, OrganizationConfiguration>, pub plan: PlanInfo, }

这解释了“个人组织独立于团队组织”是如何落地的：每个组织各自映射一份Plan（订阅）与一份OrganizationConfiguration（管理员配置），互不干扰。

编辑器中的组织菜单与切换

文档描述“点击标题栏的组织名称可查看全部组织并切换”。在 标题栏实现 中可以看到对应逻辑：当前组织取自user_store.current_organization()，业务组织通过!organization.is_personal过滤得到，弹出列表中每一项都附带该组织对应的plan（通过user_store.plan_for_organization(&organization.id)查询）；用户选择后调用set_current_organization(organization, cx)（见 title_bar.rs 第 1373-1378 行附近）完成切换。

切换动作在服务端也是有据可查的：客户端类型 UpdateSystemSettingsBody / SystemSettings 中携带selected_organization_id: Option<OrganizationId>，表明“当前选中组织”是作为系统设置持久化的状态，而非仅存在于 UI 内存中。

多组织：同时属于多个 Organization

一个 Zed 账号可以同时属于多个组织。当你已是某组织成员、又收到第二个组织的邀请时，两个成员身份并存，各自拥有独立的订阅、账单和管理控制。

切换方式有两种：

• Web 仪表盘：使用左上角的组织切换器（org switcher）。
• Zed 编辑器：点击标题栏的组织名称，在列表中查看全部组织并切换。

源码中plans_by_organization与configuration_by_organization均为以OrganizationId为键的映射（见上文 cloud_api_types.rs），说明多组织场景下，订阅与数据控制配置是严格按组织维度隔离存储的——这也正是各组织“各自的订阅与管理员控制”不会串扰的结构基础。

创建组织

1. 访问仪表盘的新建入口https://dashboard.zed.dev/create-organization。
2. 创建者自动成为该组织的 Owner。
3. 若账号下没有已保存的支付方式，会进入结账（checkout）流程；若已有支付方式，则跳过该步骤。
4. 完成后进入邀请页，添加第一批成员。

角色层面，新组织只有创建者这一个 Owner，其余权限边界见 Roles & Permissions。

邀请成员（Inviting members）

关键规则：

• 成员通过电子邮件地址邀请；受邀者接受邀请后，其 Zed 账号即加入该组织。
• Owner、Admin 和 Member 都计入付费 Business 席位；Billing Manager 不占付费席位，但可访问账单功能。
• 受邀者在接受邀请时需通过GitHub 账号认证后才正式加入。

操作步骤：

1. 进入组织仪表盘的Members页面。
2. 点击+ Invite Member。
3. 输入成员的邮箱地址并选择一个角色（role）。
4. 对方会收到一封带加入链接的邮件；接受并以 GitHub 认证后即成为组织成员。

各角色能做什么，完整权限矩阵在 roles.md 的角色表格 中定义（例如 Admin 可以邀请/移除成员、改角色、配置组织设置，但不能取消订阅或转让所有权；Billing Manager 只有账单权限，不占席位）。

管理成员（Managing members）

只有 Owner 和 Admin 可以从仪表盘的 Members 页管理成员。

修改成员角色

1. 在 Members 页找到目标成员（可按角色过滤或按名字搜索）。
2. 打开菜单（三点菜单），选择新角色。

移除成员

1. 在 Members 页找到目标成员。
2. 点击Remove并确认。

移除成员的生效范围需要准确理解：

• 终止的是该成员对本组织订阅、账单及管理员所配设置的使用权；
• 其个人 Zed 账号（即个人组织）以及其他组织成员身份完全不受影响——这与前述“每个组织独立映射 Plan 与配置”的客户端数据结构一致。

组织仪表盘（Organization Dashboard）的访问权限

仪表盘展示成员、角色与账单信息，不同角色的访问级别如下：

角色	仪表盘访问
Owner / Admin	完整访问（成员、角色、账单、管理控制）
Billing Manager	仅账单相关功能
Member	无仪表盘访问

Owner 和 Admin 进一步可在仪表盘的Data & Privacy页面配置组织级控制项，如 Admin Controls 中列出的 Collaboration、Zed Model Provider、Edit Prediction（含 Feedback）与 Agent Thread Feedback 等开关。这些控制项在编辑器客户端的类型定义中同样有明确对应：

pub struct OrganizationConfiguration { pub is_zed_model_provider_enabled: bool, pub is_agent_thread_feedback_enabled: bool, pub is_collaboration_enabled: bool, pub edit_prediction: OrganizationEditPredictionConfiguration, } pub struct OrganizationEditPredictionConfiguration { pub is_enabled: bool, pub is_feedback_enabled: bool, }

（见 cloud_api_types.rs 第 61-73 行。）也就是说，组织级开关是通过登录时的configuration_by_organization下发到每个客户端的，成员无法在本地覆盖。

源码纵深：组织如何影响客户端行为

除了展示与切换，OrganizationId还深度参与了客户端的运行时链路，几处典型实现：

• 按组织签发的 LLM 令牌：CreateLlmTokenBody 以organization_id为入参创建LlmToken，即托管 AI 的访问令牌是按组织维度签发的；client.rs 中的令牌缓存与刷新（cached、refresh_llm_token、clear_and_refresh等方法）也全部携带organization_id参数——切换组织后，客户端会使用对应组织的令牌访问服务。
• 按组织归属的反馈上报：Agent 线程反馈、Edit Prediction 反馈的请求体（SubmitAgentThreadFeedbackBody、SubmitEditPredictionFeedbackBody）都带organization_id: Option<OrganizationId>字段（cloud_api_types.rs 第 98-127 行），使组织管理员能够按组织统计与管控反馈数据；这与 Admin Controls 中“Business 下反馈默认关闭、由管理员开关控制”的策略呼应。
• 当前组织状态持久化：如前所述，SystemSettings.selected_organization_id让“当前组织”成为可持久化的系统设置，重启后仍保持你选择的组织上下文。

可以推断，组织 ID 贯穿了从身份认证、订阅计费到 AI 令牌与反馈数据归属的整条链路，这是“一个账号、多个组织、互不串扰”得以成立的核心机制。

小结

• 每个 Zed 账号自带一个永久的个人组织，团队组织与其完全隔离；账号可同时属于多个组织，通过仪表盘左上角切换器或编辑器标题栏菜单切换。
• 在https://dashboard.zed.dev/create-organization创建组织，创建者成为 Owner；无支付方式时先走结账流程，随后进入邀请页。
• 成员经邮箱邀请、GitHub 认证后加入；Owner/Admin/Member 占付费 Business 席位，Billing Manager 只管理账单不占席位。
• 管理成员（改角色、移除）仅限 Owner 与 Admin，且只影响本组织内权限，不波及成员的账号与其他组织身份。
• 客户端源码（cloud_api_types、title_bar、client）印证了组织维度的订阅映射、配置下发、令牌签发与切换状态持久化，是理解这套机制实现细节的最佳入口。

【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed