dsh plugin 知识库插件和长期记忆插件到底有什么区别？

dsh plugin 知识库插件答的是「文档里写了什么」，长期记忆插件答的是「我们之前聊过什么」。前者把工作区里的 Markdown、PDF、代码等文件建成索引，供模型检索引用；后者把会话中的结论沉淀下来跨会话复用。两者的数据源、失效方式和调优手段都不一样，混着选往往两头都不好用。

DeepSeek Harness 的知识库插件一定要用嵌入模型吗？

DeepSeek Harness 的知识库插件不一定需要嵌入模型：纯关键词方案（如 TF-IDF 检索）不依赖外部 API 与嵌入模型，装完即可用，代价是同义改写的问法命中率差一些；混合方案会把词法检索与本地嵌入语义检索的结果融合，召回更好，但要额外配置嵌入提供者与运行环境。按「文档里术语是否稳定」来选即可。

知识库型 dsh plugin 该怎么装，装进哪个 profile？

知识库型 dsh plugin 和其它插件一样按 profile 安装：命令是 dsh plugin --profile add ，--profile 必填，决定索引服务挂在哪个 profile 下。注意它是跟着 profile 走的——只装进 web 时，用 headless 跑的任务拿不到这份知识库，需要哪个 profile 用就装进哪个。

装完 dsh plugin 知识库插件怎么验证模型真的能查到我的文档？

验证 dsh plugin 知识库是否真的接上，最直接的办法是问一个只有你的文档里才有的具体术语。索引健全时，回答里会出现该术语并给出文件出处（部分插件还会给出精确行号）；如果模型答得笼统或说找不到，先查索引目录是否覆盖了你的文档、再查索引是否已经建完——索引是异步构建的，刚装完就问常常还没建好。

dsh plugin 知识库插件索引整个工作区好，还是只索引几个目录好？

dsh plugin 知识库的索引范围以「少而准」为原则：只索引真正要问的文档目录，通常比整仓索引效果更好。整仓索引会把 node_modules、构建产物、日志一并卷进来，既拖慢构建，又让检索结果被噪声挤占。多数插件都提供排除规则，先把产物目录排掉，再按需要逐个加目录。

dsh plugin 知识库怎么选？DeepSeek Harness 文档问答插件的原理与接入

选 dsh plugin 知识库，第一步不是看谁功能多，而是先分清它和长期记忆插件解决的是两个问题：知识库插件答「文档里写了什么」，记忆插件答「我们之前聊过什么」。选定之后要看的只有三件事：它用什么检索方式（纯关键词、纯语义还是混合）、要不要额外的嵌入模型或运行环境、以及它把索引挂在哪个 profile 下——这三条决定了你装完是马上能用，还是要先配一圈环境。

先分清两类 dsh plugin：记忆插件记会话，知识库插件答文档

记忆插件与知识库插件的数据源完全不同：前者从会话里沉淀结论，后者从文件里建索引，因此不能互相替代（来源）。 对照着看：

维度	记忆插件	知识库插件
数据从哪来	会话中产生的结论、偏好、项目事实	工作区里的文档、笔记、代码
典型问法	「上次我们定的方案是什么」	「A 模块的鉴权流程在哪写了」
什么时候更新	对话过程中持续写入	文档变化后重建或增量更新索引
主要风险	记忆过时、互相污染	索引范围失控、噪声挤占结果

如果你的诉求是「让模型读懂我的一批文档」，看的是知识库插件；如果是「别每次都重新交代背景」，那属于记忆插件，对照表与选型见《dsh 记忆插件有哪些？》。两者可以同时装，但装之前最好先想清楚各自解决哪一半问题。

知识库型 dsh plugin 靠什么工作：索引、检索与要不要模型

知识库插件的差别集中在检索这一环：纯关键词方案装完即用，混合方案召回更好但要配嵌入提供者；索引建在哪、收录哪些文件，则决定它答不答得准（来源）。按这三层看：

建索引——把文档切分、抽取文本、写入本地索引库。这一步通常在插件后台跑，是异步的，所以刚装完就问往往还没建好。
检索——三种路线，取代表插件的实际做法：
- 纯关键词（TF-IDF）：不依赖外部 API，也不需要嵌入模型，装完就能用。代表是 dsh-plugin-rag，它按关键词为项目文件建索引并支持 CLI 搜索，可配置索引路径与返回条数，自动跳过 node_modules 之类目录（来源）。
- 混合检索：把词法检索与语义检索的结果融合排序。代表是 docindex，它用 SQLite FTS5 做词法检索、叠加本地嵌入的语义检索，以 RRF 融合，支持中文分词、增量更新与精确行号引用（来源）。它需要较新的 Node 运行时，装之前先核对。
- 服务化检索：把知识库做成常驻服务，由 MCP 通道对外提供检索能力。代表是 local-rag-wiki，它按仓库提供一个受管控的 Markdown wiki，支持语义检索与受控读写，用来跨会话积累项目知识（来源）。
交给模型——检索结果以工具或上下文注入的形式进入对话。多数插件会注册一组查询工具，模型在需要时自己调用；有的还会把索引统计注入系统提示，让模型先知道「这里有一份可查的库」。插件到底给模型加了哪些能力，可以按《一个 dsh plugin 里有什么？》里的能力件逐一核对。

要不要嵌入模型，取决于你的提问方式：文档里的术语稳定、提问也照抄术语，纯关键词就够；如果提问常常换说法、跨语言，混合检索的收益才明显。多花的成本是嵌入提供者的配置与索引构建时间。

dsh plugin 知识库接入路线：装进哪个 profile、索引哪几个目录、怎么验证命中

接入分三步：按 profile 安装插件、划定索引目录、再用一个只有文档里才有的术语验证问答是否命中（来源）。

装进你要用的那个 profile。知识库是跟着 profile 走的，命令形态与其它插件一致：

bash

# npm 包名
dsh plugin --profile web add dsh-plugin-rag

# GitHub 直装
dsh plugin --profile web add github:johnxu22786/docindex

--profile 必填且决定插件落在 $DSH_HOME/profiles/<名字>。只装进 web、却用 headless 跑任务，是「装了但查不到」最常见的原因，多 profile 的隔离细节见《多个 profile 装同一个 dsh plugin》。

划定索引目录。原则是「少而准」：先排掉 node_modules、构建产物、日志，再逐目录加入你真正要问的文档。多数插件把索引路径做成可配置项，改完要触发一次重建或等增量更新接上——增量与监控能力因插件而异。
验证命中。别问「这个项目是做什么的」这类泛问题，要问一个只可能出现在你文档里的具体术语或编号：

bash

# 装完先确认插件已在目标 profile 里
dsh plugin --profile web list

回答里出现该术语、并给出文件出处（有的插件会给精确行号），才算真的接上。若答得笼统或说找不到，按顺序查：索引目录是否覆盖了那份文档 → 索引是否已建完 → 提问的术语是否与文档用词一致。

选之前先做两件核对：一是版本与环境要求（混合检索方案常有 Node 版本下限），二是维护状态与权限范围——索引意味着它要读你的文件。这两件事的判定方法见《dsh plugin 值不值得装？》。找同类插件、横向比较卡片信息，可以打开 DSH Plugin Hub 的设置 → 插件市场，在分类里按「知识库」逐项看。

dsh plugin 知识库的注意事项

一句话总结：先分清它是答文档还是记会话，再看检索方式与索引范围，最后落到正确的 profile 上验证。 六条提醒：

别把记忆插件当知识库用：记忆从会话沉淀、知识从文件索引，数据源不同，替换不了；
索引是异步的：刚装完就问常常答不出，先等索引建完再验证；
索引范围宁小勿大：整仓索引会把产物与日志卷进来，拖慢构建又稀释结果；
混合检索有额外成本：嵌入提供者与运行时版本要先核对，别装完才发现跑不起来；
插件跟 profile 走：web、headless、desktop 之间不共享插件，用哪个装哪个；
先看权限与维护状态：索引类插件必须读你的文件，装之前用信任信号逐项过一遍再决定。

不想在命令行里逐个试的话，DSH Plugin Hub 的插件市场里有知识库分类，卡片上能看到插件类型、安装命令与信任确认弹窗，点安装后由市场代执行——适合先快速试一个再用命令行细调索引范围。

来源：dsh CLI README、DSH Plugin Hub、dsh-plugin-rag、docindex、local-rag-wiki