微信团队给 DSH 写了个插件,背后是 2.2 万星的开源知识库

大家好，我是左手。

前两天我在翻 dsh 的插件列表，想给本地的 harness 再挂点东西。翻着翻着，一个包名把我卡住了。

@wxg-prc-cpg/dsh-weknora

wxg 这个前缀，稍微了解点腾讯组织架构的朋友应该都知道指的是什么。我当时脑子里的第一个念头是，微信事业群的团队，给 DeepSeek Harness 写插件？？？

我把这个包从 npm 上拖下来解开，一行行看了一遍。

看完之后的感受挺复杂的。一方面这插件做得确实讲究，另一方面它让我意识到一个我之前一直没太当回事的问题。所以这篇不光是聊插件，我想顺着它往回挖一层，看看背后那个东西到底是个什么货色。

先说清楚它补的是什么洞

前面几篇我一直在聊 DSH 这条线。harness 本身是个挺克制的壳，它管上下文、管工具调度、管插件怎么加载怎么卸载，这些事它做得干净。

但它的检索能力，其实很有限。

grep 和 glob 只看你打开的那个工作区，web_search 只看互联网。中间那块呢。你们公司内部的接口文档、项目命名规范、三年前那次架构选型的会议纪要、上一版产品上线后攒下来的用户反馈，这些既不在工作区里，也不在网上。

我自己的体感是，写代码的时候最耗时间的从来不是写，是找。找那个字段到底叫什么，找上一个同事为什么这么设计，找这个接口的超时到底配的多少。这些答案全都存在某个地方，只是不在 Agent 够得着的地方。

插件文档里有一句话我印象很深，它说 harness 没有自己的检索、向量或知识库能力，这个插件做的就是把你自己的文档补到缺的那一块。

一句话就把定位说清楚了。

我把它拆开看了

先看四个工具，这是插件往 Agent 手里塞的全部东西。

weknora_list_knowledge_bases 列知识库，weknora_search 混合检索、返回带评分的原文片段，weknora_read_document 把检索到的碎片按顺序拼回整篇正文，weknora_ask 则是把整个问题直接甩给 WeKnora 自己回答。

三个只需要 retrieve 能力的 Key，weknora_ask 额外要 chat，因为它得建会话、流式取答案。整个插件是只读的，不写库、不改分块、不删除。

这个权限设计我觉得挺克制的。给编码 Agent 一个能改知识库的工具，迟早会出事。

然后是代码本身。这个包的入口长这样。

看到 apply 和 inject 的时候我笑了一下。8 月 16 号那篇写 Cordis 的文章，我花了老大劲解释这个约定，说插件就是导出一个 apply 函数，靠 inject 声明依赖。当时举的例子都是我现编的，现在真家伙摆在眼前了。

它整个包没有任何运行时依赖，交给 ctx.tools.register() 的就是一个普通对象。每个注册都是一次 effect，所以插件卸载或者重新配置的时候，工具会被干净地撤掉，不用重启。

有意思的是几个设计取舍，都是那种你不在真实场景里摔过跤就想不到的。

比如检索的时候，它会把片段内容和文档名放在同一次调用里一起匹配。为什么，因为模型经常分不清自己要找的到底是「哪里讲过这件事」，还是「那份叫 XX 的文档在哪」。与其让模型自己想明白，不如两个都给它。

再比如，如果你没配知识库范围，它不会去问模型要挑哪个库。它会自己把当前凭据能看见的库全列出来一起用，而且这份清单一个进程只解析一次。

插件的原话是，让模型先去挑反而更糟，因为知识库的命名往往糟糕到无从选择。

我看到这句的时候真的愣了一下。这得是被多少个客户真实的知识库折磨过，才能写出这么一句。

还有个细节我觉得挺讲究，片段塞进上下文之前会按字符数截断，默认 1200。但截断这件事会明确告诉模型，返回里带一个 truncated 标记，而不是悄悄把尾巴切掉，让模型以为那就是全文。

配置写错了也一样。它会在插件加载阶段就报错，把每一条违规逐条列出来，而不是等模型第一次调工具的时候才炸在你脸上。

最后是这个包还带契约测试。仓库里有一份记录插件发出的所有 WeKnora 调用的 fixture，一边断言插件仍然只发这些调用，另一边在 WeKnora 的 Go 代码里断言真实的请求响应类型仍然认这些字段。任何一侧改名，CI 直接挂掉，而不是等到用户的 Agent 里才挂。

坦率的讲，两边的人都知道自己迟早会改坏对方的代码，所以提前把绳子拴上了。这种活儿不出彩，很见功力。

顺着插件往回挖

插件本身是个很小的东西。真正让我坐直的是它背后指向的那个项目。

WeKnora，中文名维娜拉。腾讯开源的，出自微信对话开放平台那个团队。

GitHub 上现在 2.2 万星，3200 多 fork，MIT 协议，Go 写的，Python 那边还有个独立的文档解析服务。2025 年 7 月建的仓库，8 月正式对外开源。

然后我看了下发布节奏，有点吓人。

第一个 release 是 2025 年 9 月 10 号，最新这个 v0.8.0 是 2026 年 9 月 3 号。整一年，39 个 release，基本就是一个月一个大版本的节奏。

而我整理这篇稿子的时候，v0.8.0 才发出来九天。九天前的东西，README 和更新日志全是新的。

它整体的架构是这样。

WeKnora v0.8.0 官方架构图，我只裁了下白边

你能看到左边是文档处理，解析、分块、向量化、建图、生成 Wiki 一条流水线下来，中间是 RAG 和 Agent 引擎，下面挂数据库和外部服务。整条链路是解耦的，向量库、存储、模型厂商都能换。

我特别喜欢左上角那一排，八个入口里第七个就是 CLI，第八个直接写着 DeepSeek Harness Plugin。也就是说，这个插件在官方的架构图里是有一席之地的，不是随手玩票。

回到项目本身。官方的定位是一句话，把散落文档变成会思考的知识资产。

它干了三件事。

最外面那层是 RAG 问答，这个大家熟。向量加 BM25 混合检索，召回片段喂给模型，答案标注来源。

它在这个环节上做了我觉得最有价值的一件事，就是让引用必须可视。

官方截图，回答在左，引用抽屉在右

你点任意一个引用，它能直接把原文摊在你面前，告诉你这句话出自哪份文档、第几个分块、还带个匹配度。

官方这张图里它自己在处理智能家居的文档，有个细节看着很舒服，它给出的配置步骤是带具体参数的，客厅主灯调到 70%、空调设 26 度制冷、仅夏季生效。这说明它是真读进去了，不是扫了个标题就开始编。

RAG 这东西要落地，信不信得过比答得漂不漂亮重要得多。

再往上一层是 ReAct Agent，这个就有意思了。它不是在知识库里问答，它是能自己规划任务链路的。先检索知识库，不够再联网搜，还不够就去调 MCP 工具，最后整合成一份带引用的结果。

官网上的演示是一个竞品分析的需求，你能看到它的执行过程被拆成好几步，理解意图、知识库召回 14 条、联网补充 6 条、调数据看板 MCP、最后生成报告。中间工具调用还能设人工审批节点。

而我觉得这个项目最有想法的地方，是第三块，叫 Wiki 模式。

官方截图，右边是 Agent 自动整编出来的 Wiki 页面，左边是页面之间的知识图谱

这个模式它不只是存你的文档，它让 Agent 主动把你的原始文档读完，然后自己写出一套互相链接的 Markdown 知识页面，再把页面之间的关系渲染成一张知识图谱。

你看右边，它生成了一个「日常费用报销」的页面，提交时限、常见科目、每个科目单价多少、需要什么附件，全给你整编好了。左边那张网就是节点之间的连接关系，点哪跳哪，还能看这个知识点被哪些文档支撑着。

这个能力不新鲜，新鲜的在于它支持人工编辑、页面版本历史、行级 diff 和一键回滚。也就是说 Agent 写错了你能改，改完能对比，不满意能退回去。

我见过太多所谓自动生成知识库的产品，生成那一刻很惊艳，然后就没有然后了，因为没人敢改它，也没人知道它哪句是编的。WeKnora 这块是认真做过功课的。

v0.8.0 那个大版本

既然它九天前刚发新版，我顺手看了下更新日志，这次升级的重点全都指向同一件事，让 Agent 能真的动手干活。

最核心的是技能沙箱。你可以装技能，技能能在沙箱里跑代码、读文件、调命令。

官方截图，技能在沙箱里跑完代码，产出一份排好版的 Word 并在对话里直接预览

这张图挺说明问题的。你跟它说要一份人形机器人的介绍文档，它在沙箱里读过知识库、跑完代码，真的生成了一份排好版的 Word，还能直接在对话里预览。

注意对话里那两行小字，思考了 17 轮，调用了 20 次工具，总共耗时 2 分 38 秒。

这里面有个我觉得很关键、但容易被忽略的改动。v0.8.0 把本地宿主机进程这个执行后端直接删掉了，沙箱只剩 Docker、E2B、Cube 三种容器化的方案，而且 Docker 默认还是关的，得自己手动开。

这个决定挺狠的，等于砍掉了最方便的那条路。但方向我完全认同。

我自己以前的担心就是，让 Agent 能执行代码，等于把电脑的钥匙交出去了。它删错文件、污染依赖、把内网地址发出去，你事后才知道。WeKnora 的做法是每一轮对话分一个独立沙箱，会话里的命令、文件、附件、产物都在这个工作区里共享，会话结束统一回收，出网默认阻断。

它不能保证你不做傻事。但至少能保证炸的时候炸不到宿主机。

另外两个新东西，一个是跨会话长期记忆，记住你是谁、你常问什么、在办什么事。有意思的是它的默认状态是关的，而且自动提炼出来的记忆要你确认才生效，成员之间的记忆互相隔离。

这个选择跟那些默认全开、后台自动整理记忆的产品正好相反。没有对错，看你在什么场景里用。个人用当然是越省心越好，但你想想一个企业知识库，如果它自动记住了某个人随口说的一句客户报价然后对所有人生效，那个后果谁来担。

还有一个不那么起眼的优化，Office 文档现在能在 Go 进程里直接解析了，不用再跨网络去调那个 Python 服务。少一个依赖、少一跳通信，自托管的人会懂这有多舒服。

想试的话，成本比我想的低

我本来以为要装这么一套东西得折腾半天，结果官方给的路子短得有点意外。

前提是机器上有 Docker 和 Git，然后四条命令。

跑完打开 http://localhost 就是主界面，后端 API 在 8080。要 Neo4j 知识图谱、MinIO 存储、Langfuse 链路追踪，就往上叠 profile。

说实话，这几条命令我抄下来的时候心里是有点不得劲的。因为我想实际跑一遍再写，结果本机 Docker Desktop 的引擎它就是不起来。。。我又不想为了写篇文章去动别人的设置，所以这次我确实没有独立部署实测。

这一篇我能保证的是，插件包我是从 npm 上拖下来解开摸过的，源码我是一行行看的，官方架构图、更新日志、仓库里的文档我都对着核过。但是具体跑起来的手感、界面的响应速度、中文文档解析的质量到底怎么样，这些我没资格替你下结论，得你自己上手。

所以如果你只是想先看看它长什么样，更省事的是走线上那条路。WeKnora 本身就是微信对话开放平台的核心框架，官方在 chatbot.weixin.qq.com 上有现成的线上应用，扫码绑定，一分钟就能用，分知识助理和智能客服两类。

不想部署又想要自己的库，还有个 Chrome 插件，任意网页选中一段文字或者整页，一键存进指定知识库。刷到好资料顺手就归档了，这个场景我用得上。

现在说我的判断

回到最开始那个让我愣住的包名。

一个项目的成熟度，有时候不看它自己有多少功能，看它愿不愿意、以及有没有能力把自己交给别人用。WeKnora 本身是个完整的产品，有界面、有权限、有审计、有可观测性，全套企业级的东西都齐了。但它还专门写了一行 cordis.patch.yml，把四个只读工具干干净净地递给外面的编码 Agent。

这个动作说明它想明白了一件事。知识库不该是个你得走进去问的系统，它应该是一种随时能被调用的能力。

所以我给的建议是分开看。

如果你在给团队搭内部知识库，或者手上有大量结构混乱的文档要处理，WeKnora 值得认真花一个下午试试，尤其是它那个 Wiki 模式，我看下来觉得是同类里做得最实的一个。部署前记得先看看安全声明，官方明确建议部署在内网而不是公网。

如果你已经在用 DSH 写代码，那就更简单了，两个环境变量的活。

但要提醒一句，我觉得官方的快速问答那条链路，装了插件也只是让你少切几次窗口。真正的价值在跨多份文档的那些问题上，写代码写到一个接口不知道为什么这么设计，让 Agent 去库里翻一遍，那个体验是不一样的。

至于不适合谁。如果你的知识本来就没多少，或者全都在一个仓库的 README 里躺着，那装这一套是给自己找活干。工具是有重量的，别为了用而用。

最后说回那个包。我一开始是冲着「微信团队给 DSH 写插件」这个反差去的，觉得挺新鲜。看完之后我发现，真正让我记住的不是这个反差。

是那句写着知识库命名往往糟糕到无从选择的注释。

一个团队得被多少真实的、命名乱七八糟的知识库折磨过，才会在产品里为这种事专门做一层兜底。这种东西，看文档是看不出来的。

那今天就聊到这。

项目地址

https://github.com/Tencent/WeKnora

更新日志（想看它一年发了多少个版本，翻这个），https://github.com/Tencent/WeKnora/blob/main/CHANGELOG.md

DSH 插件

https://www.npmjs.com/package/@wxg-prc-cpg/dsh-weknora

不想部署的，微信对话开放平台上有现成的，https://chatbot.weixin.qq.com

我是左手，我们下篇见。