WeKnora｜功能调研与权限配置

产品定位与实现

三类核心能力

普通文档的处理过程是：导入 → 解析与分块 → 建立关键词/向量索引 → 检索与重排 → 带引用回答。这条流程更新检索资料，不会直接修改模型权重。[5][6][7]

技术组成：Go / Gin 后端、Vue 3 / TypeScript / TDesign 前端、Python gRPC 文档解析、PostgreSQL / ParadeDB、Redis / Asynq；图谱、存储和模型服务可另行配置。[3][4]

核心功能、常见场景与使用入口

资料同步来源

已实现：飞书 / Lark Wiki、飞书 / Lark Drive、Notion、Confluence、语雀、钉钉文档、腾讯 IMA、GitLab、RSS / Atom。首次导入后可计划同步，增量更新和删除检测依连接器而定；RSS 滚动淘汰旧条目不触发对应资料删除。[12]

v0.8.2 文档明确：GitHub、Google Drive、OneDrive、Web Crawler、Slack、IMAP 的数据源项尚未实现。Slack 机器人对话接入已有，不能与 Slack 历史资料同步混为一项。[12][21]

面向企业的场景示例

以下是根据功能提出的配置用法，不代表官方客户案例或市场使用占比。

常用入口如何选

首次使用建议顺序：配置对话和向量模型 → 新建文档库或 FAQ 库 → 导入样本 → 检查解析分块 → 用问题集验证检索与引用 → 再添加 Wiki、Agent 和渠道。Wiki 可通过索引配置开启，不必把它理解成只能独立建立的第三类库。[7][8][9][10][33]

按模块或类型分权限：支持到哪一层

“未见”限定于此次核查的 v0.8.2 数据模型、路由与服务实现；不是对未来版本的断言。Agent 的 @文档、@标签和知识库选择属于检索范围控制，不能代替用户授权。

共享权限怎样合成

组织共享先取 共享记录权限与接收空间的组织角色中较低者；如果具体用户在自己空间中是 Viewer，再封顶为只读。组织角色使用 viewer / editor / admin；工作空间角色使用 Owner / Admin / Contributor / Viewer，两套角色分别管理。[14]

同一个 KB 若经多个组织可达，取各条通道有效权限中的最高值。撤销一条共享后，还要检查其他组织或共享 Agent 是否仍提供访问路径。[15][41]

若某组织包含销售、技术、人事、财务全部空间，共享进去的知识库就应按这些空间共同可读来设计。需要不同接收人群时，分设共享组织或调整空间成员，不能只修改共享库的标签。此处为依据共享模型给出的配置判断。[14]

角色、API Key 与渠道配置

工作空间角色矩阵

下表是官方设计口径。历史资源创建者降级为 Viewer 的写权限疑点见“判断依据 3”，不据此宣称所有降权路径已通过实测。

成员管理这一行以路由与权限细表为准：Admin 不能代替 Owner 增删成员或改角色。Contributor 的“自己的资源”以知识库创建者为准；某人上传过一个文件，不代表他取得了那个文件的单独管理权。[14][16]

平台系统管理员是另一种身份，负责全局设置、任务队列和平台审计；它不会自动获得其他空间的知识内容。跨空间数据访问还由 CanAccessAllTenants 等配置单独控制。主机和数据库管理员具备的底层访问能力，不属于应用 RBAC 能隔离的范围。[23]

API Key：可配置的能力

这些字段有管理界面可配置，并由服务端路由和范围校验执行。未声明 API Key 策略的路由默认拒绝。[14][40]

API 主体按能力授权，不套用人类 Contributor / Viewer 的角色阶梯；因此不能用上方人类账号下载矩阵推定 API Key 的下载权限。[14][16]

示例：给“采购资料问答”创建的配置，仅演示字段，未在任何系统执行。

{
  "name": "采购资料问答",
  "full_access": false,
  "knowledge_base_ids": [
    "采购制度库ID",
    "供应商产品库ID"
  ],
  "capabilities": [
    "retrieve",
    "chat"
  ]
}

需要录入资料时，使用另一把具有 ingest 的受限 Key。若要求“可上传但不可删”，现有 ingest 组合仍过宽，应在业务后端拆分接口或扩展权限。[14]

接入现有员工系统

X-External-User-ID 或签名外部用户 Token 用于标识终端用户、隔离会话和相关 OAuth；不会自动把员工部门转换成知识库权限。同一把宽范围 Key 配不同用户 ID，仍共享该 Key 的资料访问范围。[19]

可采用的实现：业务后端验证员工身份 → 查询其部门/角色 → 选用对应受限 Key 或权限空间 → 固定允许 KB → 调用 WeKnora。员工身份再单独用于会话隔离。Key 保留在后端；不要把“前端传哪个 KB 就查哪个 KB”当作授权。此处为集成建议。

MCP、机器人、网页挂件

启用了技能的共享 Agent 还会在来源空间沙箱中运行，可能带入管理员配置的技能环境变量（如 API Key）；官方文档说明成员可以让 Agent 读出这些值。共享知识库只读，不能推定工具环境和凭据也具有相同隔离。[14]

本地部署、维护成本与访问时效

官方标准部署建议 4 核 CPU / 8GB 内存起步，明确不含本地模型权重；默认 ParadeDB 已提供关键词与向量索引，不必为了起步额外部署独立向量数据库。吞吐量需按模型、资料和同时请求数实测，本文不估算 TPS。[3][4]

“部署在本地”与“所有处理留在内网”

以上是根据可替换模型、解析、存储与工具架构作出的部署判断；本地模型可经 Ollama 或兼容接口连接，模型职责与协议需逐项检查。[3][6][33]

撤权与文件链接

1. 按部门隔离，可以通过现有功能实现

权限边界先用工作空间确定，知识库再用于资料组织和共享。同一空间内的成员应当属于基本相同的读取人群；角色负责区分维护、配置与管理职责。[14][15]

此表为结构示例，不代表建议现在导入上述敏感资料。试点先使用虚构样本；同一领导可加入多个空间，不需要复制一份所有内容到“领导综合库”。

2. 同库逐文档授权，需要扩展授权链

如果目标是“甲能看 A 文件，乙能看 B 文件，丙只能问不能读原文”，或者“只给某岗位开放上传按钮”，当前固定角色和分类字段不能直接满足全部要求。需要先明确对象、操作与成员/用户组关系。

二次开发必须把授权条件带到关键词/向量检索之前，并在原文、分块、图片、FAQ、Wiki 和工具调用路径复核。仅在页面隐藏分类、在答案生成后删除敏感词，无法阻止未授权资料进入模型上下文。此处为工程判断。

3. 采用前需要核验的权限边界

本文没有将静态代码疑点写成已复现漏洞，也没有把官方设计矩阵视为生产环境安全验收结果。研究结论可以用于选型；是否投用取决于部署版本和验证结果。

1. 确定权限表与知识范围

先列“谁可以读、谁可以维护、谁可以管理、资料放在哪里”。优先分清业务模块与文档格式：通常应按部门、项目或保密人群分空间，按主题与处理策略分库，按年份/型号/格式打标签。

2. 用样本执行权限验收

以下是拟执行用例，本次未部署或执行这些测试。允许请求与禁止请求都需要留存结果。

3. 根据验收决定接入方式

若“按部门空间隔离 + 按库共享”满足需求，保留原生授权并接入 Web / IM / MCP；若必须“同一界面逐员工逐文档授权”，先完成业务网关或 ACL 扩展设计，再导入受限资料。