WeKnora 共享空间Organization完全指南跨空间协作、角色权限与知识库/智能体共享【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnoraWeKnora 的共享空间Organization是标准版提供的跨空间协作机制不同空间Tenant的用户通过加入同一组织实现知识库与智能体的跨空间共享、检索与协作。本文基于 docs/wiki/安全认证/共享空间说明.md 展开并结合仓库内组织管理 API、Go SDK 与访问控制中间件源码完整讲解空间创建与加入、三种成员角色、知识库/智能体共享规则、权限叠加判定与智能体停用偏好帮助你掌握从「建立协作空间」到「跨空间使用共享资源」的全链路实操能力。共享空间概述跨空间协作的载体在 WeKnora 中用户可以在同一系统内属于不同空间Tenant账户。共享空间是打通这些空间、实现跨空间协作的载体。通过加入同一共享空间成员可以实现共享知识库将本空间的知识库共享到空间供空间内其他成员使用查看、检索按授权可编辑共享智能体将本空间的智能体共享到空间供空间内其他成员在对话等场景中使用访问他人共享的知识库和智能体作为空间成员可以看到并使用其他成员共享进来的资源。核心概念对照概念说明共享空间系统中的「组织」Organization用于跨空间共享是跨空间协作的最小单元空间创建者自动成为组织 Owner不可被移除或降级源码层面由OwnerID与OwnerTenantID双重锁定空间成员管理员admin/ 编辑者editor/ 只读viewer三种角色知识库/智能体归属始终属于一个空间共享不改变归属只记录「以何种权限共享到了哪个空间」从源码看组织Organization模型定义在 internal/types/organization.go其中OwnerTenantID记录了组织创建者当时的所属空间其成员关系行在organization_tenant_members表中不可删除、不可变更从而保证组织永远不会因为创建者后续切换空间或被软删除而变成「孤儿组织」。这正是「空间创建者不可被移除或降级」在数据模型上的保证。版本前提共享空间是标准版功能Lite 版不提供见 docs/wiki/项目概述/Lite与标准版区别.md。Lite 为单空间、开箱即用的轻量部署形态不包含成员邀请、跨成员共享等协作能力。角色与权限三种成员角色的能力边界空间成员按能力分为管理员 / 编辑者 / 只读三种角色权限矩阵如下能力管理员编辑者只读查看、检索共享知识库✓✓✓编辑共享知识库内容✓✓✗将知识库共享到本空间✓✓✗管理空间设置与成员✓✗✗生成/刷新邀请码✓✗✗源码中的角色模型三种角色在 internal/types/organization.go 中定义为OrgMemberRole常量admin对组织及共享知识库拥有完整控制权editor可编辑共享知识库内容但不能管理空间设置viewer仅可查看和检索共享知识库。角色之间通过HasPermission(required)方法建立viewer editor admin的层级关系对应数值 1/2/3高角色自动继承低角色的全部能力。关键机制权限取「最小交集」当一个用户既是某组织的成员又通过共享关系获得某个知识库时其有效权限并不是简单相加而是取最小值取交集。internal/types/organization.go中的MinOrgRole(a, b)实现了这一逻辑在admin editor viewer阶梯上取两者中更低的那一个。实际应用中它会同时叠加三重因素共享记录里设定的permissionviewer/editor当前用户在该组织中的角色my_role_in_org调用方在其所属空间内的租户 RBAC 角色上限。因此文档 API 中的my_permission min(permission, my_role_in_org)是服务端最终生效的权限任何单独一方的授权都不会被放大。访问判定的完整链路从 internal/middleware/kb_access.go 可以看到RequireKBAccess中间件统一承载所有知识库访问的解析与拦截其判定流程为KB 属于我当前空间─是─► 走空间 RBAC角色 creator_id └─否─► KB 共享给我所在空间─是─► 取 min(共享权限, 空间角色) └─否─► 403 / 404该中间件还做了两件重要的事有效租户上下文重写当请求命中某个「共享进来的知识库」时会将c.Request.Context()重写为资源源空间的租户 ID使下游检索、Embedding 查询落到正确的存储而 Gin 上下文中的调用者身份保持不变灰度开关当配置项tenant.enable_rbac false时守卫只记录「本应拒绝」的日志并放行便于安全灰度切换完整 RBAC 说明见 docs/wiki/安全认证/RBAC说明.md。与空间 RBAC 的关系空间 RBAC 解决「同一空间内你能对自己/别人的资源做什么」共享空间解决「跨空间让别的空间的人也能用我的 KB/Agent」两者正交。空间 RBAC 是纵向的纵深防御共享空间是横向的协作通道一次对「他人共享过来的 KB」的写操作必须同时穿过两道闸口——共享时设了「可写」 你在该空间不是 Viewer 源空间的 RBAC 仍放行。另外API Key 的跨空间访问不会携带 Admin 光环共享路径的权限完全由organization_members.role决定。空间的创建与加入从建站到成员入伙创建共享空间管理员或任意已登录用户通过POST /api/v1/organizations创建组织。创建者自动成为owner并生成邀请码。请求体字段字段类型必填说明namestring是组织名称1-255 字符descriptionstring否组织描述最多 1000 字符avatarstring否头像 URL最多 512 字符invite_code_validity_daysint否邀请码有效天数0永久1/7/30默认 7member_limitint否成员上限0不限默认 50curl --location http://localhost:8080/api/v1/organizations \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { name: AI 技术团队, description: 专注于 AI 技术研究与知识管理, invite_code_validity_days: 7, member_limit: 50 }响应返回组织 ID、my_role: owner、成员计数等信息。GET /organizations可获取当前用户所属的全部组织及每个空间内的知识库数、智能体数resource_counts字段供侧栏直接渲染。加入方式一邀请码加入未加入的用户可通过POST /organizations/preview/:code先预览不加入返回组织名称、成员数、是否已开启审核等信息确认无误后调用POST /organizations/join加入。注意join仅适用于require_approval: false的组织若组织开启了审核require_approval: true必须改用加入申请流程。curl --location http://localhost:8080/api/v1/organizations/join \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { invite_code: ABC123XY }加入方式二搜索可加入的空间设置searchable: true的组织可通过GET /organizations/search?q关键词被检索到仅返回元数据不泄露邀请码随后通过POST /organizations/join-by-id直接加入若目标组织开启审核该接口会自动创建加入申请。加入方式三提交加入申请需审核的场景curl --location http://localhost:8080/api/v1/organizations/join-request \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { invite_code: ABC123XY, message: 希望加入团队参与知识库建设, role: editor }申请支持指定期望角色viewer/editor/admin。管理员通过GET /organizations/:id/join-requests查看待审核列表request_type区分join新加入与upgrade角色升级并用PUT /organizations/:id/join-requests/:request_id/review审核审核通过时可强制分配角色缺省按申请者请求的角色。成员与空间管理邀请管理员可GET /organizations/:id/search-users搜索系统内用户自动排除已在组织内的用户再POST /organizations/:id/invite直接添加为成员无需审核角色调整PUT /organizations/:id/members/:user_id更新成员角色DELETE /organizations/:id/members/:user_id移除成员不可移除 owner邀请码刷新POST /organizations/:id/invite-code重新生成邀请码仅 owner/admin旧邀请码立即失效组织设置PUT /organizations/:id更新名称、描述、require_approval、searchable、成员上限等DELETE /organizations/:id仅 owner 可删除并同时清理成员与共享关系离开与升级成员可POST /organizations/:id/leave离开owner 需先转让或删除组织也可POST /organizations/:id/request-upgrade主动申请角色升级。上述接口的完整参数与响应示例见 docs/api/organization.mdGo SDK 封装见 client/organization.go如CreateOrganization、JoinOrganizationByInviteCode、ShareKnowledgeBase、ListSharedAgents等。路由层在 internal/router/routes_agent.go 注册其中组织列表、加入、搜索等基础操作以Viewer为最低门槛。知识库共享规则与操作共享规则要点只有知识库所属空间下的用户才能发起共享发起人必须是目标空间的管理员或编辑者共享时指定权限只读viewer或可写editor同一知识库可共享到多个空间各自独立配置权限互不影响。共享 / 改权限 / 取消将知识库共享到组织curl --location http://localhost:8080/api/v1/knowledge-bases/kb-00000001/shares \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { organization_id: org-00000001, permission: viewer }响应返回共享记录kbs-xxxxx其中source_tenant_id标明知识库的源空间。查询该知识库已共享到的所有组织用GET /knowledge-bases/:id/shares调整权限用PUT /knowledge-bases/:id/shares/:share_idbody 传{permission: editor}取消共享用DELETE /knowledge-bases/:id/shares/:share_id。空间视图组织内能看到什么切换到某个空间后知识库列表由GET /organizations/:id/shared-knowledge-bases提供它聚合了三种来源通过POST /knowledge-bases/:id/shares直接共享进来的知识库通过共享智能体携带进来的知识库只读source_from_agent字段标识来源智能体与知识库选择模式当前用户自己共享出去的知识库is_mine: true。GET /organizations/:id/shares则返回「被共享进来」的知识库列表其中my_permission min(permission, my_role_in_org)即为当前用户的有效权限仅本组织成员可查看。智能体共享规则与前置条件共享规则要点智能体共享到空间时仅支持只读viewer与知识库不同不提供可写权限同一智能体可共享到多个空间前置条件智能体须已配置完成方可共享——例如已选择对话模型若启用了knowledge_search工具还需配置好 rerank重排模型。模型配置参见 docs/wiki/核心功能/内置模型管理.md。共享接口POST /agents/:id/shares还要求当前用户在目标组织中具有 editor 或 admin 角色且智能体共享响应会附带能力范围摘要scope_kb/scope_web_search/scope_mcp等便于接收方在对话前了解该智能体可以使用哪些工具与知识库。curl --location http://localhost:8080/api/v1/agents/agent-00000001/shares \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { organization_id: org-00000001, permission: viewer }查询与取消分别使用GET /agents/:id/shares与DELETE /agents/:id/shares/:share_id仅共享者本人或具有相应权限的管理员可取消。组织内智能体列表用GET /organizations/:id/shared-agents获取含is_mine标识。智能体停用机制个人偏好不影响他人共享进来的智能体若不想在自己空间的对话中出现可以将其「停用」。这一机制的关键语义是停用是当前空间对通过共享空间获得的智能体的个人偏好设置数据层面由disabled_by_me字段表达仅影响本空间在对话中选择智能体时的展示不改变共享关系本身不影响其他成员的使用也不影响共享关系在其他空间的展示。对应的接口为POST /shared-agents/disabled设置某共享智能体对本空间隐藏查询时GET /shared-agents返回的disabled_by_me: true即表示当前空间已在对话下拉中隐藏该智能体。可见这一机制与「取消共享」有本质区别取消共享是全局的、由共享者执行的资源关系变更停用是本地的、由使用方执行的展示偏好。我的共享视图跨组织的资源聚合共享空间还提供两个「跨组织聚合」接口用于全局视图GET /shared-knowledge-bases返回当前用户通过所有组织共享获得的知识库列表供「全部知识库」视图使用GET /shared-agents返回当前用户通过所有组织共享获得的智能体列表含disabled_by_me标记供「全部智能体」视图使用。这两个接口让用户不必逐个切换空间即可在单一视图中查看所有共享资源也是「共享不改变资源归属」这一原则在体验层的体现——资源仍属于各自的源空间只是统一呈现在当前用户的共享集合中。实践建议与边界认知权限边界牢记「取小」共享权限与空间角色是取交集的给成员只读角色即可防止越权编辑反过来即使共享时给了「可写」若接收方在组织内是 viewer实际依然只能只读。归属不变是设计根基共享只建立「空间 ↔ 资源」的授权关系知识库/智能体始终归属原空间删除、迁移等操作仍受源空间 RBAC 约束跨空间写操作需同时通过两道闸口。智能体共享前先完成配置对话模型、rerank 模型等未配置完成时无法共享这与 docs/wiki/核心功能/内置模型管理.md 描述的模型管理流程配套使用。数据源导入的知识库可被共享通过数据源导入见 docs/wiki/集成扩展/数据源导入开发.md建立的知识库同样遵循上述共享规则导入后即可作为普通知识库发起共享。认证体系的配合多空间场景下的用户认证依赖 OIDC 等统一认证入口见 docs/wiki/安全认证/OIDC认证调用流程.md共享空间的访问最终仍落到各空间 RBAC 校验见 docs/wiki/安全认证/RBAC说明.md。相关文档导航docs/wiki/安全认证/共享空间说明.md — 本文原始说明文档docs/wiki/安全认证/RBAC说明.md — 单空间内的角色与资源归属跨空间写操作需同时满足两边docs/wiki/项目概述/Lite与标准版区别.md — Lite 不支持共享空间docs/wiki/安全认证/OIDC认证调用流程.md — 多空间场景下的用户认证docs/wiki/集成扩展/数据源导入开发.md — 数据源导入的知识库可被共享docs/wiki/核心功能/内置模型管理.md — 智能体共享前需确保模型已配置docs/api/organization.md — 组织管理、成员管理、加入申请、知识库/智能体共享的完整 REST API 文档client/organization.go — 组织与共享能力的 Go SDK 客户端封装internal/types/organization.go —OrgMemberRole角色定义与MinOrgRole权限取小实现internal/middleware/kb_access.go — 知识库访问守卫与有效租户上下文重写实现【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
WeKnora 共享空间（Organization）完全指南：跨空间协作、角色权限与知识库/智能体共享
WeKnora 共享空间Organization完全指南跨空间协作、角色权限与知识库/智能体共享【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnoraWeKnora 的共享空间Organization是标准版提供的跨空间协作机制不同空间Tenant的用户通过加入同一组织实现知识库与智能体的跨空间共享、检索与协作。本文基于 docs/wiki/安全认证/共享空间说明.md 展开并结合仓库内组织管理 API、Go SDK 与访问控制中间件源码完整讲解空间创建与加入、三种成员角色、知识库/智能体共享规则、权限叠加判定与智能体停用偏好帮助你掌握从「建立协作空间」到「跨空间使用共享资源」的全链路实操能力。共享空间概述跨空间协作的载体在 WeKnora 中用户可以在同一系统内属于不同空间Tenant账户。共享空间是打通这些空间、实现跨空间协作的载体。通过加入同一共享空间成员可以实现共享知识库将本空间的知识库共享到空间供空间内其他成员使用查看、检索按授权可编辑共享智能体将本空间的智能体共享到空间供空间内其他成员在对话等场景中使用访问他人共享的知识库和智能体作为空间成员可以看到并使用其他成员共享进来的资源。核心概念对照概念说明共享空间系统中的「组织」Organization用于跨空间共享是跨空间协作的最小单元空间创建者自动成为组织 Owner不可被移除或降级源码层面由OwnerID与OwnerTenantID双重锁定空间成员管理员admin/ 编辑者editor/ 只读viewer三种角色知识库/智能体归属始终属于一个空间共享不改变归属只记录「以何种权限共享到了哪个空间」从源码看组织Organization模型定义在 internal/types/organization.go其中OwnerTenantID记录了组织创建者当时的所属空间其成员关系行在organization_tenant_members表中不可删除、不可变更从而保证组织永远不会因为创建者后续切换空间或被软删除而变成「孤儿组织」。这正是「空间创建者不可被移除或降级」在数据模型上的保证。版本前提共享空间是标准版功能Lite 版不提供见 docs/wiki/项目概述/Lite与标准版区别.md。Lite 为单空间、开箱即用的轻量部署形态不包含成员邀请、跨成员共享等协作能力。角色与权限三种成员角色的能力边界空间成员按能力分为管理员 / 编辑者 / 只读三种角色权限矩阵如下能力管理员编辑者只读查看、检索共享知识库✓✓✓编辑共享知识库内容✓✓✗将知识库共享到本空间✓✓✗管理空间设置与成员✓✗✗生成/刷新邀请码✓✗✗源码中的角色模型三种角色在 internal/types/organization.go 中定义为OrgMemberRole常量admin对组织及共享知识库拥有完整控制权editor可编辑共享知识库内容但不能管理空间设置viewer仅可查看和检索共享知识库。角色之间通过HasPermission(required)方法建立viewer editor admin的层级关系对应数值 1/2/3高角色自动继承低角色的全部能力。关键机制权限取「最小交集」当一个用户既是某组织的成员又通过共享关系获得某个知识库时其有效权限并不是简单相加而是取最小值取交集。internal/types/organization.go中的MinOrgRole(a, b)实现了这一逻辑在admin editor viewer阶梯上取两者中更低的那一个。实际应用中它会同时叠加三重因素共享记录里设定的permissionviewer/editor当前用户在该组织中的角色my_role_in_org调用方在其所属空间内的租户 RBAC 角色上限。因此文档 API 中的my_permission min(permission, my_role_in_org)是服务端最终生效的权限任何单独一方的授权都不会被放大。访问判定的完整链路从 internal/middleware/kb_access.go 可以看到RequireKBAccess中间件统一承载所有知识库访问的解析与拦截其判定流程为KB 属于我当前空间─是─► 走空间 RBAC角色 creator_id └─否─► KB 共享给我所在空间─是─► 取 min(共享权限, 空间角色) └─否─► 403 / 404该中间件还做了两件重要的事有效租户上下文重写当请求命中某个「共享进来的知识库」时会将c.Request.Context()重写为资源源空间的租户 ID使下游检索、Embedding 查询落到正确的存储而 Gin 上下文中的调用者身份保持不变灰度开关当配置项tenant.enable_rbac false时守卫只记录「本应拒绝」的日志并放行便于安全灰度切换完整 RBAC 说明见 docs/wiki/安全认证/RBAC说明.md。与空间 RBAC 的关系空间 RBAC 解决「同一空间内你能对自己/别人的资源做什么」共享空间解决「跨空间让别的空间的人也能用我的 KB/Agent」两者正交。空间 RBAC 是纵向的纵深防御共享空间是横向的协作通道一次对「他人共享过来的 KB」的写操作必须同时穿过两道闸口——共享时设了「可写」 你在该空间不是 Viewer 源空间的 RBAC 仍放行。另外API Key 的跨空间访问不会携带 Admin 光环共享路径的权限完全由organization_members.role决定。空间的创建与加入从建站到成员入伙创建共享空间管理员或任意已登录用户通过POST /api/v1/organizations创建组织。创建者自动成为owner并生成邀请码。请求体字段字段类型必填说明namestring是组织名称1-255 字符descriptionstring否组织描述最多 1000 字符avatarstring否头像 URL最多 512 字符invite_code_validity_daysint否邀请码有效天数0永久1/7/30默认 7member_limitint否成员上限0不限默认 50curl --location http://localhost:8080/api/v1/organizations \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { name: AI 技术团队, description: 专注于 AI 技术研究与知识管理, invite_code_validity_days: 7, member_limit: 50 }响应返回组织 ID、my_role: owner、成员计数等信息。GET /organizations可获取当前用户所属的全部组织及每个空间内的知识库数、智能体数resource_counts字段供侧栏直接渲染。加入方式一邀请码加入未加入的用户可通过POST /organizations/preview/:code先预览不加入返回组织名称、成员数、是否已开启审核等信息确认无误后调用POST /organizations/join加入。注意join仅适用于require_approval: false的组织若组织开启了审核require_approval: true必须改用加入申请流程。curl --location http://localhost:8080/api/v1/organizations/join \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { invite_code: ABC123XY }加入方式二搜索可加入的空间设置searchable: true的组织可通过GET /organizations/search?q关键词被检索到仅返回元数据不泄露邀请码随后通过POST /organizations/join-by-id直接加入若目标组织开启审核该接口会自动创建加入申请。加入方式三提交加入申请需审核的场景curl --location http://localhost:8080/api/v1/organizations/join-request \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { invite_code: ABC123XY, message: 希望加入团队参与知识库建设, role: editor }申请支持指定期望角色viewer/editor/admin。管理员通过GET /organizations/:id/join-requests查看待审核列表request_type区分join新加入与upgrade角色升级并用PUT /organizations/:id/join-requests/:request_id/review审核审核通过时可强制分配角色缺省按申请者请求的角色。成员与空间管理邀请管理员可GET /organizations/:id/search-users搜索系统内用户自动排除已在组织内的用户再POST /organizations/:id/invite直接添加为成员无需审核角色调整PUT /organizations/:id/members/:user_id更新成员角色DELETE /organizations/:id/members/:user_id移除成员不可移除 owner邀请码刷新POST /organizations/:id/invite-code重新生成邀请码仅 owner/admin旧邀请码立即失效组织设置PUT /organizations/:id更新名称、描述、require_approval、searchable、成员上限等DELETE /organizations/:id仅 owner 可删除并同时清理成员与共享关系离开与升级成员可POST /organizations/:id/leave离开owner 需先转让或删除组织也可POST /organizations/:id/request-upgrade主动申请角色升级。上述接口的完整参数与响应示例见 docs/api/organization.mdGo SDK 封装见 client/organization.go如CreateOrganization、JoinOrganizationByInviteCode、ShareKnowledgeBase、ListSharedAgents等。路由层在 internal/router/routes_agent.go 注册其中组织列表、加入、搜索等基础操作以Viewer为最低门槛。知识库共享规则与操作共享规则要点只有知识库所属空间下的用户才能发起共享发起人必须是目标空间的管理员或编辑者共享时指定权限只读viewer或可写editor同一知识库可共享到多个空间各自独立配置权限互不影响。共享 / 改权限 / 取消将知识库共享到组织curl --location http://localhost:8080/api/v1/knowledge-bases/kb-00000001/shares \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { organization_id: org-00000001, permission: viewer }响应返回共享记录kbs-xxxxx其中source_tenant_id标明知识库的源空间。查询该知识库已共享到的所有组织用GET /knowledge-bases/:id/shares调整权限用PUT /knowledge-bases/:id/shares/:share_idbody 传{permission: editor}取消共享用DELETE /knowledge-bases/:id/shares/:share_id。空间视图组织内能看到什么切换到某个空间后知识库列表由GET /organizations/:id/shared-knowledge-bases提供它聚合了三种来源通过POST /knowledge-bases/:id/shares直接共享进来的知识库通过共享智能体携带进来的知识库只读source_from_agent字段标识来源智能体与知识库选择模式当前用户自己共享出去的知识库is_mine: true。GET /organizations/:id/shares则返回「被共享进来」的知识库列表其中my_permission min(permission, my_role_in_org)即为当前用户的有效权限仅本组织成员可查看。智能体共享规则与前置条件共享规则要点智能体共享到空间时仅支持只读viewer与知识库不同不提供可写权限同一智能体可共享到多个空间前置条件智能体须已配置完成方可共享——例如已选择对话模型若启用了knowledge_search工具还需配置好 rerank重排模型。模型配置参见 docs/wiki/核心功能/内置模型管理.md。共享接口POST /agents/:id/shares还要求当前用户在目标组织中具有 editor 或 admin 角色且智能体共享响应会附带能力范围摘要scope_kb/scope_web_search/scope_mcp等便于接收方在对话前了解该智能体可以使用哪些工具与知识库。curl --location http://localhost:8080/api/v1/agents/agent-00000001/shares \ --header X-API-Key: sk-xxxxx \ --header Content-Type: application/json \ --data { organization_id: org-00000001, permission: viewer }查询与取消分别使用GET /agents/:id/shares与DELETE /agents/:id/shares/:share_id仅共享者本人或具有相应权限的管理员可取消。组织内智能体列表用GET /organizations/:id/shared-agents获取含is_mine标识。智能体停用机制个人偏好不影响他人共享进来的智能体若不想在自己空间的对话中出现可以将其「停用」。这一机制的关键语义是停用是当前空间对通过共享空间获得的智能体的个人偏好设置数据层面由disabled_by_me字段表达仅影响本空间在对话中选择智能体时的展示不改变共享关系本身不影响其他成员的使用也不影响共享关系在其他空间的展示。对应的接口为POST /shared-agents/disabled设置某共享智能体对本空间隐藏查询时GET /shared-agents返回的disabled_by_me: true即表示当前空间已在对话下拉中隐藏该智能体。可见这一机制与「取消共享」有本质区别取消共享是全局的、由共享者执行的资源关系变更停用是本地的、由使用方执行的展示偏好。我的共享视图跨组织的资源聚合共享空间还提供两个「跨组织聚合」接口用于全局视图GET /shared-knowledge-bases返回当前用户通过所有组织共享获得的知识库列表供「全部知识库」视图使用GET /shared-agents返回当前用户通过所有组织共享获得的智能体列表含disabled_by_me标记供「全部智能体」视图使用。这两个接口让用户不必逐个切换空间即可在单一视图中查看所有共享资源也是「共享不改变资源归属」这一原则在体验层的体现——资源仍属于各自的源空间只是统一呈现在当前用户的共享集合中。实践建议与边界认知权限边界牢记「取小」共享权限与空间角色是取交集的给成员只读角色即可防止越权编辑反过来即使共享时给了「可写」若接收方在组织内是 viewer实际依然只能只读。归属不变是设计根基共享只建立「空间 ↔ 资源」的授权关系知识库/智能体始终归属原空间删除、迁移等操作仍受源空间 RBAC 约束跨空间写操作需同时通过两道闸口。智能体共享前先完成配置对话模型、rerank 模型等未配置完成时无法共享这与 docs/wiki/核心功能/内置模型管理.md 描述的模型管理流程配套使用。数据源导入的知识库可被共享通过数据源导入见 docs/wiki/集成扩展/数据源导入开发.md建立的知识库同样遵循上述共享规则导入后即可作为普通知识库发起共享。认证体系的配合多空间场景下的用户认证依赖 OIDC 等统一认证入口见 docs/wiki/安全认证/OIDC认证调用流程.md共享空间的访问最终仍落到各空间 RBAC 校验见 docs/wiki/安全认证/RBAC说明.md。相关文档导航docs/wiki/安全认证/共享空间说明.md — 本文原始说明文档docs/wiki/安全认证/RBAC说明.md — 单空间内的角色与资源归属跨空间写操作需同时满足两边docs/wiki/项目概述/Lite与标准版区别.md — Lite 不支持共享空间docs/wiki/安全认证/OIDC认证调用流程.md — 多空间场景下的用户认证docs/wiki/集成扩展/数据源导入开发.md — 数据源导入的知识库可被共享docs/wiki/核心功能/内置模型管理.md — 智能体共享前需确保模型已配置docs/api/organization.md — 组织管理、成员管理、加入申请、知识库/智能体共享的完整 REST API 文档client/organization.go — 组织与共享能力的 Go SDK 客户端封装internal/types/organization.go —OrgMemberRole角色定义与MinOrgRole权限取小实现internal/middleware/kb_access.go — 知识库访问守卫与有效租户上下文重写实现【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
