Agent.Space Workspace 使用 Owner、Editor 和 Viewer 三种角色。最简单的分配原则是：让一个人拥有足够完成本职工作的权限，但不要顺手多给不需要的管理能力。
- 负责成员、所有权和 Agent 使用费用的人，选择 Owner。
- 需要修改共享内容、继续 Agent Session 的团队成员，选择 Editor。
- 只需检查文件、对话和 Preview，不应改变项目的人，选择 Viewer。
这三种角色只适用于 Agent.Space Workspace。它们不会自动授予 GitHub 仓库权限、云平台权限，也不会让成员获得上游 Agent 账号。
Owner、Editor 与 Viewer 快速对比
角色控制的是 Workspace 内部动作。如果项目还使用版本控制、部署平台、数据库或其他服务，成员可能仍需单独获得那些系统的权限。
Owner：管理成员、所有权与使用责任
每个 Workspace 有一位 Owner。Owner 能完成 Editor 的项目工作，同时负责 Workspace 层面的协作边界。
Owner 可以：
- 为 Editor 或 Viewer 创建邀请链接；
- 撤销尚未失效的邀请链接；
- 把现有成员在 Editor 与 Viewer 之间调整；
- 从 Workspace 移除成员；
- 把所有权转让给另一位现有成员；
- 继续 Agent 工作，并承担该 Workspace 后续的 Agent 使用责任。
邀请链接应通过可信渠道发送。受邀者加入前，可以先查看 Workspace、获得的访问级别和费用归属。这个邀请只授予 Agent.Space 角色，不需要交换上游账号密码。
所有权转让是一项重要的运营变更。接收方会成为唯一 Owner，承担后续 Agent 使用责任；原 Owner 则变成 Editor。转让前必须结束或取消当前所有 Workspace Turn。应当像账号交接一样处理这项动作：确认接收人、清理进行中的工作，并明确之后由谁管理成员。
Editor：能参与实际工作，但不管理成员
Editor 可以修改共享内容，并继续团队正在进行的 Agent 工作。因此，需要直接参与项目的成员通常使用 Editor。
常见的 Editor 工作包括：
- 添加或修改项目文件；
- 创建 Session，并向受支持的 Agent 发送任务；
- 继续一个具备编辑权限的现有 Session；
- 把受支持的本地对话导入 Workspace；
- 一边检查文件、对话历史与 Preview，一边进行后续修改。
Editor 不能管理邀请链接、修改其他成员角色、移除成员或转让所有权。这条边界让日常项目工作不会自动附带账号管理权。
只有当成员确实需要做出改动时，才选择 Editor。如果对方只是之后可能要给反馈，不必因为“评审很重要”就给写权限；Viewer 已经可以检查共享证据。
Viewer：只读审阅与监督
Viewer 可以查看团队内容、对话、Agent 工作与 Preview，但不能修改共享文件、创建或发送 Agent 任务，也不能导入本地 Session。
Viewer 适合这些场景：
- Stakeholder 检查进度或渲染结果；
- 客户查看某个具体交付物；
- 审批人需要判断结果，但不应改变项目状态；
- 观察者学习当前工作流；
- 临时 Reviewer 在 Workspace 之外提供反馈。
“只读”并不等于“公开”。对方仍然是受邀的 Workspace 成员，可以看到该角色范围内的项目材料。只邀请确实应该看到文件和对话的人；审阅结束后，也应移除不再需要的访问。
常见角色分配场景
个人项目
创建者保持 Owner 即可。在其他人真正需要访问之前，没有必要为了形式额外制造角色。
开发或运营成员加入实际工作
如果对方需要改文件或继续 Agent 任务，使用 Editor。部署、代码仓库和外部服务的权限继续单独管理，只有同一份工作确实需要时才授予。
产品、设计、法务或客户审阅
如果对方只需查看当前文件、对话和 Preview，先使用 Viewer。只有当他们需要在 Workspace 内直接操作时，才升级为 Editor，而不是因为这次 Review 本身很重要就给写权限。
团队负责人交出责任
把成员改为 Editor，不等于转让所有权。先完成一份清楚的Coding Agent 团队交接。只有新负责人确实需要管理邀请与未来使用责任时，才转让所有权；否则继续使用 Editor。
最小权限不等于阻碍工作
“最小权限”（Least Privilege）是指只提供完成工作所需的最小动作集合，而不是不看职责就把所有人都设为 Viewer。
可以按这个顺序判断：
- 对方只需查看文件、对话和 Preview 吗？选择 Viewer。
- 对方需要修改共享文件或继续 Agent 工作吗？选择 Editor。
- 对方需要管理邀请、角色、所有权或 Workspace 使用责任吗？这属于 Owner 职责。
- 对方还需要 GitHub、部署、数据库或 Provider 权限吗？分别在那些系统里重新判断。
Coding Agent Workspace 安全指南进一步解释了为什么 Workspace 隔离与角色权限仍需配合 Secret 管理、版本控制和范围明确的外部 Credentials。
每次交接都要复查权限
实际责任改变时，角色也应调整。例如外包成员离开、客户 Review 结束、Owner 岗位变化、项目进入敏感阶段，或新阶段需要写权限时，都应该重新检查。
修改访问权限前：
- 结束或取消会让所有权转让不安全的进行中任务；
- 确认对方下一步究竟需要查看什么、修改什么；
- 把 Workspace 权限与外部系统权限分开；
- 明确告知对方是否会承担 Agent 使用责任；
- 所有权变化时，记录新 Owner 与后续管理员；
- 移除已经不再需要的访问。
移除成员会终止对方在 Workspace 内的访问；已单独分享的公开 Preview 或 Inspector 链接仍遵循各自的过期与撤销规则。移除访问不会重写更早消息与操作的归属，因此项目历史仍然能够说明之前发生过什么。
先分配 Workspace 角色，再单独增加其他权限
Agent.Space 角色回答的是一个具体问题：这个成员能在当前 Workspace 里做什么？Owner 管理协作边界，Editor 推进实际工作，Viewer 在不改变项目状态的前提下审阅。
如果需要理解角色怎样与 Session、共享文件配合，可以阅读 Agent.Space 如何工作。邀请团队前，再检查当前的 Agent.Space 安全与成员模型，然后给每个人分配与其实际职责相匹配的最小角色。