WeKnora：从企业文档到可执行知识

把企业文档变成一套可运行的知识系统

WeKnora 的定位并不只是“给文档加一个聊天框”。它把知识库、检索问答、工具调用和 Wiki 维护放进同一个运行时，让同一批企业资料可以服务三种不同强度的任务：需要快速查证时返回带原文引用的答案；需要跨步骤处理时交给具备工具的智能体；需要沉淀团队共识时，把文档整理成可持续修订的页面和知识图谱。

这次精读基于 WeKnora 的 v0.9.0 版本快照。项目采用 Go 与 Gin 构建主服务，Vue 3 负责 Web 界面，Python 文档解析服务通过 gRPC 接收文件并返回 Markdown、图片和 OCR 结果。默认基础设施是 ParadeDB／PostgreSQL、Redis 与对象存储：前者同时承担业务数据、BM25 关键词检索和 pgvector 向量检索，后者由 Asynq 驱动文档处理、知识富化、Wiki 生成等异步任务。需要独立扩容时，也可以切换到 Elasticsearch、OpenSearch、Milvus、Weaviate、Qdrant、Doris 或腾讯云 VectorDB。

三个核心能力共享同一份事实来源

快速问答走的是经典检索增强生成路径。系统先理解问题、改写查询，再并行召回知识库分块、可选网页结果和 Neo4j 图谱实体。候选内容经过重排、去重、上下文扩展和提示词组装，最后以流式文本返回。引用不是回答末尾再补的一串装饰，而是由检索阶段保留的分块身份、文档信息和模型上下文别名共同完成；前端可以把引用展开到原始文档中的具体片段。

使用方式	解决的问题	运行边界
快速问答	在知识库中定位事实并生成可核验回答	检索增强生成流水线，不执行开放式工具任务
智能推理	检索、阅读、调用工具、处理文件和完成多步工作	ReAct 循环，受工具白名单、迭代上限和执行权限约束
Wiki	把跨文档知识组织成可链接、可追溯、可回滚的页面	异步 Map-Reduce 管道，写入经过来源引用和版本控制

这三条路径共用知识库、租户与空间权限，但并没有把“回答”和“修改”混为一谈。检索可以使用只读范围；Wiki 写入、沙箱命令、外部工具和自动化任务则分别经过资源授权、执行权限和审批策略。这种拆分是 WeKnora 作为企业知识运行时最重要的工程边界之一。

入库不是简单切块，而是持续生成检索资产

文档上传后，主服务先登记知识记录，再把解析任务交给队列。文档解析服务支持 PDF、Word、Excel、网页、EPUB 和图片等多种格式，并保留页面与图片产物。处理阶段会根据文档结构选择父子分块或标题分块，批量调用向量模型生成嵌入，同时建立关键词索引。随后，摘要、候选问题、实体与图片说明等富化任务异步补充到分块元数据中。只有这些子任务完成后，文档才会进入完成状态。

这种设计使“可搜索”不再等同于“原始文本已经落库”。分块会携带上下文关系，图片会有描述和 OCR 文本，父块可以在命中子块后补足上下文。对于需要多模态能力的知识库，文本与图片还可以进入同一向量空间；若对话模型具备视觉能力，系统会把真正命中的原图随上下文一起交给模型。相比只索引纯文本，这更接近企业资料的真实形态，也意味着模型调用、解析和索引成本会随着文档数量与图片密度增长。

混合检索的关键不是“向量加关键词”四个字

WeKnora 的混合检索在应用层统一完成。向量检索与关键词检索各自返回候选，再用加权 Reciprocal Rank Fusion 融合。默认向量权重为 0.7、关键词权重为 0.3；在融合前，两路分数会归一化到零到一，融合时每个分块只取自己在各检索器家族中的最佳排名。这样做的目的不是把两套不可比较的原始分数硬相加，而是用排名表达“谁更靠前”。如果只有一路检索可用，系统不会执行双路融合。

融合之后还要经过重排。默认重排阈值是 0.2；当全部结果都低于阈值、但最高分仍达到 0.15 时，可以保留最佳候选作为兜底。若仍然没有结果，系统会把阈值乘以 0.7 再试一次，但不会低于 0.3。最终排序使用复合分数：重排模型分占 0.6，检索基础分占 0.3，来源权重占 0.1。之后通过最大边际相关性选择结果，默认相关性与冗余惩罚的比例为 0.7 比 0.3，以减少同一页或相邻段落的重复占位。

这些参数说明 WeKnora 把检索质量拆成多个可观测环节：召回、融合、重排、多样性与上下文组装。调整关键词权重并不自动等于提高答案准确率，仍然需要用同一组代表性问题比较完整链路。

重排完成后，系统会合并连续分块、补足短上下文的相邻内容，并处理跨库近重复结果。Wiki 页面在重排后还会获得 1.3 倍加权，因为它们是模型预先综合过的知识，通常比未经整理的原始片段更适合直接进入回答上下文。引用链仍然保留到源文档与源分块，所以 Wiki 加速的是召回，而不是取消证据。

快速问答与智能推理是两条执行路径

快速问答把主要精力放在一次检索和一次可靠生成上。查询理解阶段可以做意图识别、问题改写、实体抽取和图片描述；检索阶段可以同时访问知识库、网页和知识图谱；生成阶段通过事件总线把令牌流送入 SSE 连接，并支持断线后从共享流管理器续传。每一轮还会执行上下文压缩、引用别名替换和错误恢复，避免把内部标识符直接暴露给模型。

智能推理则进入 ReAct 循环。引擎每轮从数据库重建会话历史，本身不跨轮缓存状态；模型选择工具、观察结果、继续推理，直到完成或达到迭代上限。内置工具覆盖知识检索、文档阅读、网页搜索、MCP 服务、Wiki 维护、技能、浏览器控制、沙箱命令、后台任务和长期记忆。工具注册表负责参数校验、输出截断和资源清理，事件总线把思考、调用、结果和最终回答推送给前端，Langfuse 追踪则记录轮次、令牌和工具执行。

长任务会遇到上下文窗口限制。WeKnora 因此加入令牌估算、历史压缩、迭代守卫和运行中补充要求。用户在任务执行期间追加的约束可以进入当前轮次，而不是只能等待下一轮。这里的设计重点是可恢复和可观察：工具结果、审批状态、会话历史和运行事件都有明确落点，服务重启后可以重新判断下一步，而不是假设一次长连接永不中断。

子智能体拿到的是完整任务，不是父会话的影子

多智能体协作采用了更克制的上下文边界。子智能体收到的是自包含的任务说明，不会自动继承父智能体的完整历史、附件或隐式偏好。这样虽然要求委派者把目标、材料位置和完成标准写清楚，却避免了把无关上下文一起复制给每个子任务，降低令牌消耗和串话风险。父智能体负责拆分、追踪进度与汇总，子智能体的结果再回到协作流程。

这个选择也影响提示词设计。任务描述必须包含足够的信息才能独立执行，不能只写“继续处理上面的内容”。对于企业环境，这种显式委派更容易审计：每个子任务都能看到自己的输入、工具范围和输出证据，而不是依赖一条隐形的共享思路。

权限、审批与自动化把“能干”限制在可接受范围

WeKnora 把执行权限分成只读、修改前确认和自动执行三级。只读模式不能通过一次审批获得写入能力；确认模式在普通写入前请求批准；自动执行允许一般写入，但删除等破坏性操作仍然需要确认，被标记为强制审批的工具也不能被普通授权跳过。空间角色和资源权限始终先于执行权限生效，智能体不能因为拿到自动执行权限就编辑原本无权访问的知识库。

自动化以任务创建者的身份运行，只使用创建者当前有权访问的资源，不会保存一份永久有效的用户凭证。权限变化会影响下一次运行。任务可以按 Cron 调度，默认执行时长为 30 分钟，最长 4 小时；等待审批最多 7 天。连续失败三次后任务自动暂停，避免在错误配置下继续消耗模型与工具资源。失败任务、暂停状态和待审批事项都会保留，而不是被后台重放为未知写入。

沙箱提供了执行能力，也暴露了必须正视的安全边界

技能脚本和命令工具运行在 Docker、E2B 或 Cube 沙箱中，网络策略、凭据注入、文件交换和后台任务都有独立配置。会话级沙箱适合隔离单次任务；按用户复用沙箱则减少启动和环境准备成本，但安全性明显不同。官方文档明确指出，共用沙箱中的命令以 root 执行，同一机器上的会话之间没有操作系统级隔离，一个会话可以访问其他会话目录，进程和磁盘也彼此可见。

Docker 后端还需要特别小心 Docker socket。能够访问宿主机 Docker 守护进程的工具，在效果上接近宿主机 root，不能把它当成普通容器权限。项目在 README 中建议把服务部署在内网或私有网络，并通过防火墙、访问控制和定期升级缩小暴露面。对于企业落地，更稳妥的做法是分离网络、限制挂载与凭据、默认拒绝不必要的出站访问，并避免让不可信用户共享同一台执行环境。

Wiki 是一条异步 Map-Reduce 知识生产线

开启 Wiki 后，新文档会触发独立任务。第一阶段从文档中抽取候选实体和概念；第二阶段逐个分块为候选页面标注引用，并发现新的页面标题；第三阶段按页面标识合并内容，生成摘要、正文、来源引用和页面间链接。Reduce 写入使用逐页面锁和快照感知的更新方式，避免多个批次同时覆盖同一页面。内容必须尽量由引用支撑，模型生成的自链接和没有来源的断言会被约束。

文档重新解析时，系统会发出撤回或替换引用更新，而不是把旧内容永久留在页面里。批次结束后还有一次不调用模型的后处理：重建索引页、清理死链、补充交叉链接、删除空目录并维护图谱。Wiki 页面支持自动生成、智能体编辑、人工编辑和回滚四类来源；每次覆盖前保存旧版本，回滚会创建新版本而不是改写历史。历史记录达到软上限五十版时优先清理自动版本，硬上限二百版时再统一裁剪。

文档入库
  → 候选页面抽取
  → 分块引用标注
  → 按页面增量合并
  → 来源与链接校验
  → 索引重建、死链清理、交叉链接

这条链路把 Wiki 和普通“文档摘要”区分开来。摘要只消费一篇文档，Wiki 则需要处理跨文档的同义实体、页面合并、证据迁移和关系图。它也不是实时数据库事务：生成在后台异步完成，模型调用量取决于文档规模和抽取粒度，因此管理员需要把成本、等待时间和内容新鲜度作为一个整体来配置。

适合什么团队，以及部署前的取舍

WeKnora 适合拥有大量内部文档、既需要引用式问答又希望把知识整理成共享资产的团队。研发资料、产品文档、客服知识和项目复盘可以进入同一套检索与 Wiki 管道；需要自动巡检、定期汇总或跨工具操作时，再启用智能体、技能、MCP 与自动化。它不适合把“接入模型”当作部署终点的场景，因为真正的运维工作还包括解析质量、索引重建、模型成本、权限设计、沙箱网络策略和人工审阅。

项目提供 Docker Compose、Helm、Lite 单二进制和桌面形态，模型供应商、向量存储与对象存储都可以替换。这让私有化部署更现实，但也意味着每个后端组合都需要单独验证。项目包含评估数据集与工具，但这次精读没有复现统一基准，因此不能据此宣称它在所有企业问答任务上优于其他系统。更合理的判断是：它把检索、智能体和 Wiki 三类能力做成了同一套可操作的知识基础设施，并把权限、审计、引用和版本控制放在了足够靠前的位置。

从 RobotWorld 的归口看，WeKnora 同时属于智能体、智能体运行框架和知识管理三个方向。它的价值不在于某一个检索参数，而在于把这些能力接成了一个可部署、可追踪、可约束的企业知识回路。