刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · WeKnora

如果一个团队只想留一件「AI 基础设施」，大概率是知识库：文档散在飞书、GitLab、本地 PDF 和聊天记录里，每个人都在重复回答别人回答过的问题。腾讯 2025 年 7 月开源的 WeKnora 正是对准这个场景——而且来头不小：它是微信对话开放平台的核心技术框架，14 个月拿下 25.4k star。它到底是什么、怎么接进团队日常、和腾讯另一 个爆款 TencentDB-Agent-Memory 是什么关系、什么样的团队该用？这篇一次讲清。

是什么

WeKnora 是腾讯开源的企业级 LLM 知识管理框架，官方描述很直白：把原始文档变成「可查询的 RAG、一个自主推理的 Agent、一个自维护的 Wiki」。它的出身是理解这个项目的钥匙——README 明示 WeKnora 是微信对话开放平台的核心技术框架，官网挂在 weixin.qq.com 域名之下（weknora.weixin.qq.com），npm 官方插件的 scope 是 @wxg-prc-cpg，指向微信事业群。也就是说，这不是一个实验室项目，而是扛过微信生态真实流量的生产底座拿出来的开源版。

三大支柱：

v0.8.0（2026-09-03）又加了跨会话长期记忆（画像/偏好/事实/任务/兴趣五类，Agent 可调 search_memory），这个变化后面讲 TDA-M 关系时还会提到。

用户面向是双轨的：企业侧有多空间、四级 RBAC 角色（Owner/Admin/Contributor/Viewer）、审计日志、invite_only 邀请制、OIDC 单点登录；个人和开发者侧有 Lite 单二进制模式、桌面版、Chrome 插件、微信小程序、CLI、MCP Server 和 Go SDK。热度也不只是 star 墙：Docker Hub 四个官方镜像的拉取量在 35–56 万，与 25.4k star 的量级匹配，说明有相当规模的真实部署。

核心机制

架构上它走的是「极简栈」路线：三个进程——Go 主服务（REST + SSE 流式 + Agent 引擎 + 异步 worker）、Vue3 前端、Python docreader 文档解析微服务（gRPC）；基础设施只有 PostgreSQL 和 Redis 两个。妙处在 PostgreSQL 用的是 ParadeDB 发行版，一个容器同时提供业务库、BM25 全文检索和 pgvector 向量检索（HNSW 1024 维），所以默认部署不需要任何独立向量库——Milvus/Qdrant/Neo4j/MinIO/Langfuse 全是可选 profile，要了再加。Lite 模式更能退化成单个二进制（SQLite + sqlite-vec，连 Redis 都不要）。

文档入库是一条五阶段异步管道（解析→分块→向量化→多模态→后处理），支持 25+ 种格式，图片会走 VLM 打 Caption 和 OCR 写回子 chunk——搜图片描述也能召回原文。解析引擎可按文件类型路由：内置 Python 服务、Go 原生、anydoc（Rust cgo，v0.8.0 新增），还能外接 MinerU、PaddleOCR-VL 补复杂版面。

真正让我觉得「想得清楚」的是两处：

一是分块可治理。 大多数 RAG 项目的分块是黑盒，切坏了只能重传文档。WeKnora 的分块策略是三层自适应（先给文档画像，再选标题边界/启发式/递归切分），默认开父子分块（子块 384 字符做向量匹配、父块 4096 字符喂给 LLM），而且 v0.7.2 起检索分块可以在线编辑、逐版本 diff、一键回滚、自动重建索引——把「检索效果调优」从玄学变成了可运营的事。对照之下，Dify、RAGFlow、FastGPT、MaxKB 的文档里都找不到 chunk 级版本化编辑。

二是检索管线的工程完成度。 查询先过 LLM 意图分类（9 种意图，闲聊不走检索），然后 BM25 + 向量并行召回、加权 RRF 融合，rerank 用复合打分（0.6 模型分 + 0.3 检索基础分 + 0.1 来源权重），再过 MMR 去冗余、父子块回捞上下文；召回不足时用 jieba 做本地查询扩展（不花 LLM token）；FAQ 知识库还支持负例问题（「这个问题别用这条 FAQ 答」）。细节到引用机制都用低熵别名（cN/wN）防止内部 ID 进模型上下文。

横向对比的口径（来自博客园 iTech 与 SegmentFault 两篇独立分析，加上各竞品 README）：Dify（156k star）是应用开发平台、RAGFlow（90.8k）强在复杂版面 PDF 的 DeepDoc 解析、FastGPT（29.7k）卖可视化工作流、MaxKB（22.8k，注意 GPL-3.0）主打智能客服。WeKnora 的独有项是 Wiki 模式和分块治理，以及中文/国内生态纵深——IM 集成 10 家（企业微信、QQBot、钉钉、飞书都在），数据源直连飞书/语雀/钉钉；短板是无工作流画布（要走「预制管线+参数调节」路线）、复杂版面 PDF 解析靠外接引擎、英文社区声量小。

怎么跑起来：部署与团队接入

部署门槛出乎意料地低：git clone → cp .env.example .env → docker compose pull → docker compose up -d，四条命令。默认拉起 5 个容器（前端、后端、docreader、ParadeDB、Redis），全量镜像约 7G，其中 docreader 一个就 1.58G（内置 LibreOffice/Playwright/OCR 栈）。官方资源建议只有一句「4 核 CPU / 8GB 内存起步」——本体纯 CPU 可跑，GPU 完全取决于模型放在哪。

模型层三种接法：

  1. 外部 API：21 个内置 provider，OpenAI/DeepSeek/智谱/SiliconFlow 等皆可，还有 litellm provider 和 generic（任意 OpenAI 兼容端点）——已有 LiteLLM 网关的团队一行配置直连；
  2. 本地 Ollama：官方推荐组合 qwen3:8b（5.2G）+ bge-m3 向量（1.2G），再配 bge-reranker-v2-m3；按权重大小推断，一张 24G 的 3090 跑 8b 甚至 14b 组合都有余量（推断值，非官方声明）；
  3. 混合：LLM 走 API、embedding/rerank 放本地。

对内网团队有个关键事实：没有任何腾讯云强制依赖。对象存储默认 local、向量默认 postgres、腾讯系能力（COS、腾讯云 VectorDB、混元）全是可选项；README 明示支持私有化和离线部署，社区有纯内网机器全离线部署的完整教程；官方自己的安全建议就是「部署在内网/私网」。IM 接入用 WebSocket 长连接模式时不需要公网域名，企业微信只填 Bot ID 和 Secret 就能通——这对内网环境是决定性的便利。

团队日常接入的路径基本齐了：

一个要如实指出的缺口：Confluence 出现在数据源架构图里但仓库内没有连接器实现细节，判断为未完成；如果团队知识主阵地是 Confluence，先按「没有」做打算。

运维面要留个心眼：这是个 0.x 项目，有破坏性变更史——0.6.0 改了 RBAC 行为、0.7.1 整体移除了 Neo4j 会话记忆、0.8.0 移除了 Local 宿主机沙箱；升级前要读 QA.md。官方文档没有备份章节，备份面就是 PostgreSQL 数据卷 + 文件卷，得自己管。

和 TDA-M（TencentDB-Agent-Memory）是什么关系

先正名：腾讯体系内没有字面叫「TDM-A」的产品，这个称呼指向的是 TencentDB-Agent-Memory（缩写 TDA-M）。我 8 月曾在 202 上部署过它的三件套（memory-hub/memory-proxy/memory-core，给 dsh 做记忆注入），9 月已整体清理——所以这个关系问题是带着使用经历问的。

结论：不同团队、不同层、互补而非同源。

证据链也干净：两个仓库的贡献者零交集；把两个项目名放一起做精确短语检索，找不到任何同框材料；双方 README 和官方公告互不提及。这就是腾讯内部两条独立演进的开源路线，不是一家的两块。

但交叠在发生：WeKnora v0.8.0 新增的跨会话长期记忆，与 TDA-M 的 L1/L3 能力方向相同。不过 WeKnora 的记忆成熟度要打折扣——它 v0.7.1 曾把基于 Neo4j 的会话记忆整体删掉，v0.8.0 又换形态重新引入，而 TDA-M 从 2026 年 4 月起就把记忆当唯一主线打磨。两者倒是都兼容 DeepSeek Harness。选型口径一句话：要文档知识库选 WeKnora，要 agent 会话记忆/经验沉淀选 TDA-M；两者没有官方集成，想组合得自己打通。

数据说话

先泼冷水：官方 README 没有任何检索准确率数字，唯一评测相关的内容是内置了召回命中率/BLEU/ROUGE 评测功能（是工具，不是成绩）。网上流传的「幻觉减少 75%」「问答准确率 92%」出自营销号文章，无任何来源，官方从未背书。一个连 benchmark 都不放的官方 README，可以解读为谨慎，也意味着所有效果数字都得看第三方。

第三方里最有分量的是 53AI 的一篇生产级选型复盘（团队自测）：修正调优后 R@5≈0.81、R@10≈0.87；聚合类问题加编排器后向量召回覆盖率从 16% 拉到 100%；6 类攻击 ×5 次 30/30 全防住；4 个复杂业务场景达到资深人员水平。代价也写了：复杂报告单次生成可能几十秒，不适合实时搜索框；精确条款问答场景里 GraphRAG 和 Wiki 是负收益，最后都关了。中文的坑也有实名记录：PostgreSQL 全文检索默认没有中文分词，多版本规范文本 99% 雷同时向量分数全挤在 0.97–0.99 分不开，得在生成层加版本守卫。

负面样本同样有：掘金一位开发者用 2080Ti 本地部署实测中文学术 PDF，结论「整体感觉准确率一般」（作者自己也承认数据量小、结论可能片面），部署侧还踩了「二次启动仍拉最新镜像导致失败」的脚本 bug。

质疑侧必须如实呈现：GitHub issue #600 直接问「WeKnora 的核心是不是一套封装得很好的对话工作流？知识库是不是只是按字数切分？」——这条 issue 至今 open 且官方零回复；更早的 #13 问与竞品相比的优势，官方只贴了两篇公众号链接。另外 issue 区的活跃度有相当部分带「腾讯犀牛鸟开源专属」标签（腾讯高校开源人才计划的运营机制），看社区热度时要打个折。平衡地说，维护本身的证据是正面的：最近推送停在查询前一天（2026-09-16）、2026 年保持月更 release、用户提交的 issue 有快速跟进修复的记录。

值不值得跟：我们团队的评判

把材料对到我们自己的环境（一台 Unraid docker 服务器、一张 3090、一个 LiteLLM 网关，全员 Claude Code/ZCode/DSH 工具链），适配清单是漂亮的：

风险清单同样明确：单人主导（第一名贡献者 lyingbug 占约 2/3 commits，和之前深挖过的 teamai-cli 一个模式，巴士因子高）；0.x 有破坏性变更史，升级要看 changelog；没有工作流画布，要画布编排还得配 Dify/FastGPT；中文 BM25 有实测踩坑记录，上线初期要留调优时间；官方零 benchmark，效果预期要靠自己的评测集说话。

我的结论：值得试点，且试点成本极低。 建议路径四步——① Lite 单二进制在本机先跑通体验（零依赖）；② 内网服务器起标准五容器，模型先走 LiteLLM 网关，导一批团队真实文档（飞书/GitLab 自动同步开起来）；③ 建 invite_only 团队空间，拉 2-3 个同事用两周，用内置评测跑自己的召回基线；④ 顺手把 MCP 接进编码 Agent、企微机器人挂到群里。评估时盯两个数：自己评测集的召回率，和「别人问过的问题第二次直接答」的使用频次。

最后一句边界提醒：如果你看中它 v0.8.0 的「长期记忆」就想用它替代 agent 记忆方案（比如我清理掉的 TDA-M 那个用途）——方向不对。WeKnora 的主线是文档知识库，记忆是刚起步的附属能力；agent 会话记忆是另一条赛道，别让一个项目背两种预期。

参考阅读