在 ZGI 中，用户能否看到一项资源，需要经过组织、工作区、成员身份、角色权限和资源范围的连续判断。邀请成功只说明账号进入了某个组织，无法直接证明它已经加入目标工作区，也无法证明当前角色拥有查看或创建对应资源的权限。
概念示意图：工作区资源访问依次检查组织状态、成员身份、角色权限和资源范围。
邀请成功后，先确认进入了哪个空间
企业里常见多个组织和工作区。成员从邀请链接进入后，可能停留在默认工作区，也可能切到了另一个组织。页面能够正常打开，目标资源仍然不会出现。
排查时先核对当前组织名称和工作区名称，再确认资源实际归属。若资源位于已归档工作区，普通访问列表也可能把它过滤掉。这个步骤能排除大量“账号正常、页面正常、资源消失”的误判。
工作区成员身份决定访问入口
组织成员和工作区成员处在不同范围。账号存在于组织中，还需要进入具体工作区，才能参与该空间里的 Agent、知识和数据库等资源协作。
管理员可以在成员管理中核对账号是否已经加入目标工作区、成员状态是否有效、绑定角色是否符合预期。若刚刚调整过成员或角色，建议重新进入工作区，避免继续依据旧页面判断。
角色名称不能代替有效权限
ZGI 工作区成员记录中包含角色、权限快照和权限来源。权限可能来自所有者身份、角色模板或直接配置。两名看起来拥有相近角色的成员，实际可执行动作仍可能不同。
例如，用户能够进入工作区，却没有创建 Agent 的权限；可以浏览知识条目，却无法新建知识库。此时应检查具体动作对应的权限，不能只看“成员”“编辑者”这样的角色名称。
| 检查层 | 重点核对 | 常见现象 |
|---|---|---|
| 组织 | 当前组织、成员状态 | 登录正常，进入了错误组织 |
| 工作区 | 空间归属、成员关系、归档状态 | 看得到平台，看不到目标空间 |
| 权限 | 角色、权限来源、具体动作 | 能查看，不能创建或编辑 |
| 资源 | 部门范围、资源级过滤 | 同一空间内只缺少部分内容 |
只缺少部分资源时，继续检查范围
如果同一工作区内只有部分资源不可见，问题通常已经越过登录和成员层。接下来要核对部门可见范围、资源归属和资源自身的访问条件。
这类问题需要一个可复现样本：记录用户账号、当前组织、工作区、缺失资源名称和期望动作。管理员用同一资源做对照，再比较普通成员的访问结果。只说“我什么都看不到”，很难分清资源没创建、被归档，还是访问范围没有覆盖。
一条更省时间的排查顺序
先让用户提供当前组织和工作区，再确认账号是否属于该工作区。随后检查角色对应的具体权限，最后查看部门和资源级范围。每调整一层，就用同一个资源和同一个动作复测。
这套顺序沿着真实访问链推进，可以避免一开始就修改大量角色配置。权限问题也不适合通过临时授予管理员来长期绕开。过宽权限会掩盖原来的配置缺口，后续很难确认普通成员到底需要哪些动作。
ZGI 将组织、工作区、成员、角色和权限放进同一套资源组织方式中。团队配置权限时，可以围绕“谁在什么空间，对哪类资源执行什么动作”留下明确规则。遇到成员看不到资源，也能沿着相同路径定位缺口。
