权限与团队协作
Dify 不是一个人的玩具。当团队一起建应用、接知识库、调模型，就需要成员角色、权限边界与协作流程。本章讲清团队怎么安全地玩转 Dify。
1. 工作区与成员
回顾第 3 章：工作区是隔离单元。把「同一个业务线的人」放进一个工作区，共享应用、知识库与工具。
邀请成员方式：
- 「设置 → 成员 → 邀请」，填邮箱发送邀请
- 企业版支持 SSO（单点登录） 与 LDAP/SCIM 批量同步账号
ℹ️一个账号多工作区
成员可同时属于多个工作区，在右上角切换。不同工作区数据互不可见，天然隔离各业务线。
2. 角色与权限
Dify 内置角色（具体随版本，常见如下）：
| 角色 | 能力 |
|---|---|
| 管理员（Admin） | 管理成员、模型密钥、工作区设置 |
| 编辑者（Editor） | 创建/编辑应用、知识库、工具 |
| 使用者（User/Viewer） | 使用已发布应用、查看日志（受限） |
典型分工：
管理员 → 管密钥、管成员、管合规
算法/开发 → 搭应用、调工作流、接模型
业务/运营 → 写知识库文档、看日志反馈⚠️API Key 与密钥权限收紧
模型供应商 Key、后端 API Key 属于高敏感信息。只给管理员/必要人员可见，避免普通成员误用或泄露导致额度被盗刷。
3. 应用协作流程
推荐一个安全的协作节奏：
草稿开发（编辑者）
→ 内部预览自测
→ 发布到「仅团队可见」灰度
→ 收集日志与标注
→ 确认稳定后发布为公开/嵌入- 用版本管理留存每次发布快照，出问题可回滚（第 6 章）
- 重大改动先在小流量验证，再全量
4. 数据安全与合规
- 知识库文档谁可上传、谁可删，按角色控制
- 日志可能含用户隐私，限制查看权限并定期清理
- 自部署版（第 2 章）数据完全不出内网，满足合规
💡把「谁负责什么」写进文档
团队初期人少容易全员 Admin，随着人数增长务必分权。建一份简单的「职责说明」：谁管密钥、谁管发布、谁看日志，能省很多扯皮。
5. 与研发流程结合
- 知识库文档变更可走 Git/同步（如 Notion 同步）
- 关键应用配置建议评审后再发布
- 用第 15 章的标注集做回归，保障协作不破坏质量
🎯动手做
在一个测试工作区里，邀请一位同事（或自己用两个账号），分别设为「编辑者」和「使用者」，验证不同角色能看到和能操作的范围差异。
小结
- 工作区隔离业务线；成员多工作区可切换
- 角色分管理员/编辑者/使用者，密钥权限收紧
- 协作走「草稿→灰度→全量」+ 版本回滚
- 合规场景优先自部署；下一步两个端到端实战 →