关于DeepSeek Harness(DSH)本地 vLLM 插件安装选择，请各位折友们给个建议。
-
以下是AI给的建议，请大家审核批注下，谢谢。
一、本机实际需求
适用场景:日常学习 + 日常办公+资料整理,模型为本地部署 vLLM
二、核心原则:本地 vLLM 场景,插件要"少而按需"
瓶颈不在插件数量,而在本地 27B-int4 模型的三个硬约束:
- 工具选择精度 —— 系统提示里的工具越多,小模型越容易选错工具、漏参数。每个插件基本都往系统提示里加工具 schema,这是真实代价。vLLM 的 prefix caching 能让"稳定前缀"的重算变便宜,但解决不了"选不准"。
- 延迟 —— 本地推理比云端 API 慢一到两个数量级。凡是"每回合多调一次模型"的功能(自动标题、反馈打分、子代理群)都会被直接放大成等待。
- 隐私 —— 本地部署的动机通常就是数据不出内网,反过来要避开任何往云端回传会话内容的插件。
结论:现有 base + web-app 已覆盖大多数日常场景,只需按下面的分层挑少量插件,其余不装。
三、推荐安装清单(按优先级)
① 模型接入层:把 vLLM 连接做得更科学
首选:
dsh-llm-qwen-local(作者 starefinger)面向本地 Qwen(正是 Qwen3.8-27B 这一形态)的专用 LLM 适配器,特点:
- 按模型的多模态开关(同一 vLLM 上"有图/纯文本"两个模型可分别声明能力,纯文本模型关掉图像实打实省上下文);
- 完全可配置的推理档位(reasoning effort);
- 请求图像投影;
- 中英双语 Web 设置页——模型能力(上下文、图像、推理档)从手改 YAML 变成设置页可维护。
定位:当前 pi-ai 手写路由已可用,它属于升级而非必需;想要更科学的本地模型管理体验就装。
备选:
dsh-llm-gateway-compat(社区插件,官方 Discussion #3814)OpenAI 兼容网关的协议方言修复包。若日后遇到 vLLM 特有的兼容问题(工具调用序列化格式等)再装,平时不需要。
② 体验层:本地慢推理的最佳解药(建议第一个装)
dsh-autofork(作者 vlln)Agent 忙时自动分叉会话:你新发的指令立刻在新会话里得到响应,旧会话留在后台跑完并把结果回注。本地模型单流又慢,"排队等待"是最大体验痛点,这个插件性价比极高。
③ 办公层(三选一,不要都装)
三个功能高度重叠,全装 = 系统提示里三套相似工具,正好踩中 27B 模型"工具选择精度"的坑:
插件 方式 特点 dsh-office-toolkit(cnkids,推荐)纯 JS 跨平台,无外部依赖 读写 Word/Excel:docx / xlsx / xls / doc / rtf / odt,最省心 dsh-officecli(violetdream)依赖 officecli 命令 操作 Office 文档,需系统里装 officecli dsh-office(beancookie 目录收录)模型读写 + Web 端预览 额外提供 Web 客户端 docx/pdf 预览 典型用途:起草周报、处理表格、生成会议纪要、批量改文档。
④ 推理机管理层(可选,换量化/加机器时很实用)
dsh-model-manager(作者 Ansonfishing)在 DSH 内管理本地推理服务器(llama.cpp / SGLang / vLLM):
- GPU 注册表;
- 参数 profile;
- VRAM 校验(换模型/量化前先验证显存是否够);
- tok/s 基准测试(量化效果、不同 max-len 的实际速度)。
这是把"本地推理运维"工程化的做法:改配置前先测,而不是出问题再查。
⑤ 学习层
- 内置 skills(无需安装,最科学的手段) —— 写你自己的技能包:学习陪练、论文精读、周报模板、代码讲解等。技能是按需触发的,不永久膨胀系统提示,是本地模型下定制行为的最优机制。优先写技能,而不是装一堆常驻工具插件。
dsh-shoucang-memory/ 守藏记忆(作者 Fishsb) —— 分层长期记忆库 + 会话蒸馏 + 深度睡眠整合 + 设置面板。适合"学习伙伴要记得我的进度"的场景。注意:整合任务消耗额外推理,请在 GPU 低峰期调度,别和重活抢卡。- 会话导出 —— Web profile 默认已带跨会话检索(sqlite);若想把会话导出成 markdown 做学习笔记,装一个 session-log-export 类小插件即可,不必为此上大型插件。
四、不建议安装 / 注意避开
插件 原因 dsh-suite(STARDUSTLC 18 插件全家桶)"一条命令全装"与本地模型约束正面冲突:常驻工具成倍增加 → 选择精度下降 + 上下文压力 + 首 token 变慢。按需单装才是科学做法 modlens(视觉外挂)给纯文本模型补视觉用;Qwen3.8-27B 本身就接收图像输入,重复 dsh-session-log-deepseek/ 遥测类把会话日志上传 DeepSeek 云,与本地部署的隐私初衷相反,不要开 大量 MCP 服务器 每个 server 带来一批工具;本地 27B 建议最多接 1–2 个,确有需要再上 npm 带 
️ 弃用标记的包(如 aiko-dsh-office、dsh-iwiw-memory)存疑/弃用标记,优先选活跃维护的
五、实操建议
- 安装渠道:已装的
dshmarket(设置 → 插件市场)直接搜索、点一下安装——它只收录 awesome-dsh-plugin 精选列表,比裸装 GitHub 源码安全;命令行方式:dsh plugin --profile web add <包名>。注意:本文插件名以 GitHub 仓库名为准,具体 npm 包名请以市场搜索结果为准(市场卡片上可见)。
- A/B 验证:市场支持热禁用/启用(HMR 约 1 秒生效,无需重启)。装完每个插件先跑一个典型任务,质量/速度变差就关掉——这是最实际的"科学性"检验法。
- 权限:当前
danger-full-access全局放行。日常学习问答(尤其配合 Office 读写)建议改用更保守的权限预设,只在明确要操作文件时放开,降低误操作风险。 - vLLM 侧:确认 prefix caching 开启(默认开);长会话用内置
/compact压缩即可,不必为长上下文加插件;换量化/改--max-model-len前可用 dsh-model-manager 先做 VRAM 校验与 tok/s 测试。
六、一句话总结
autofork + office-toolkit(三选一)+ qwen-local(可选)+ model-manager(可选)+ 自建 skills + 守藏记忆(按需),其余不装。
对本地 27B 模型,"少装"本身就是最科学的选择。
-
以下是AI给的建议，请大家审核批注下，谢谢。
一、本机实际需求
适用场景:日常学习 + 日常办公+资料整理,模型为本地部署 vLLM
二、核心原则:本地 vLLM 场景,插件要"少而按需"
瓶颈不在插件数量,而在本地 27B-int4 模型的三个硬约束:
- 工具选择精度 —— 系统提示里的工具越多,小模型越容易选错工具、漏参数。每个插件基本都往系统提示里加工具 schema,这是真实代价。vLLM 的 prefix caching 能让"稳定前缀"的重算变便宜,但解决不了"选不准"。
- 延迟 —— 本地推理比云端 API 慢一到两个数量级。凡是"每回合多调一次模型"的功能(自动标题、反馈打分、子代理群)都会被直接放大成等待。
- 隐私 —— 本地部署的动机通常就是数据不出内网,反过来要避开任何往云端回传会话内容的插件。
结论:现有 base + web-app 已覆盖大多数日常场景,只需按下面的分层挑少量插件,其余不装。
三、推荐安装清单(按优先级)
① 模型接入层:把 vLLM 连接做得更科学
首选:
dsh-llm-qwen-local(作者 starefinger)面向本地 Qwen(正是 Qwen3.8-27B 这一形态)的专用 LLM 适配器,特点:
- 按模型的多模态开关(同一 vLLM 上"有图/纯文本"两个模型可分别声明能力,纯文本模型关掉图像实打实省上下文);
- 完全可配置的推理档位(reasoning effort);
- 请求图像投影;
- 中英双语 Web 设置页——模型能力(上下文、图像、推理档)从手改 YAML 变成设置页可维护。
定位:当前 pi-ai 手写路由已可用,它属于升级而非必需;想要更科学的本地模型管理体验就装。
备选:
dsh-llm-gateway-compat(社区插件,官方 Discussion #3814)OpenAI 兼容网关的协议方言修复包。若日后遇到 vLLM 特有的兼容问题(工具调用序列化格式等)再装,平时不需要。
② 体验层:本地慢推理的最佳解药(建议第一个装)
dsh-autofork(作者 vlln)Agent 忙时自动分叉会话:你新发的指令立刻在新会话里得到响应,旧会话留在后台跑完并把结果回注。本地模型单流又慢,"排队等待"是最大体验痛点,这个插件性价比极高。
③ 办公层(三选一,不要都装)
三个功能高度重叠,全装 = 系统提示里三套相似工具,正好踩中 27B 模型"工具选择精度"的坑:
插件 方式 特点 dsh-office-toolkit(cnkids,推荐)纯 JS 跨平台,无外部依赖 读写 Word/Excel:docx / xlsx / xls / doc / rtf / odt,最省心 dsh-officecli(violetdream)依赖 officecli 命令 操作 Office 文档,需系统里装 officecli dsh-office(beancookie 目录收录)模型读写 + Web 端预览 额外提供 Web 客户端 docx/pdf 预览 典型用途:起草周报、处理表格、生成会议纪要、批量改文档。
④ 推理机管理层(可选,换量化/加机器时很实用)
dsh-model-manager(作者 Ansonfishing)在 DSH 内管理本地推理服务器(llama.cpp / SGLang / vLLM):
- GPU 注册表;
- 参数 profile;
- VRAM 校验(换模型/量化前先验证显存是否够);
- tok/s 基准测试(量化效果、不同 max-len 的实际速度)。
这是把"本地推理运维"工程化的做法:改配置前先测,而不是出问题再查。
⑤ 学习层
- 内置 skills(无需安装,最科学的手段) —— 写你自己的技能包:学习陪练、论文精读、周报模板、代码讲解等。技能是按需触发的,不永久膨胀系统提示,是本地模型下定制行为的最优机制。优先写技能,而不是装一堆常驻工具插件。
dsh-shoucang-memory/ 守藏记忆(作者 Fishsb) —— 分层长期记忆库 + 会话蒸馏 + 深度睡眠整合 + 设置面板。适合"学习伙伴要记得我的进度"的场景。注意:整合任务消耗额外推理,请在 GPU 低峰期调度,别和重活抢卡。- 会话导出 —— Web profile 默认已带跨会话检索(sqlite);若想把会话导出成 markdown 做学习笔记,装一个 session-log-export 类小插件即可,不必为此上大型插件。
四、不建议安装 / 注意避开
插件 原因 dsh-suite(STARDUSTLC 18 插件全家桶)"一条命令全装"与本地模型约束正面冲突:常驻工具成倍增加 → 选择精度下降 + 上下文压力 + 首 token 变慢。按需单装才是科学做法 modlens(视觉外挂)给纯文本模型补视觉用;Qwen3.8-27B 本身就接收图像输入,重复 dsh-session-log-deepseek/ 遥测类把会话日志上传 DeepSeek 云,与本地部署的隐私初衷相反,不要开 大量 MCP 服务器 每个 server 带来一批工具;本地 27B 建议最多接 1–2 个,确有需要再上 npm 带 ️ 弃用标记的包(如 aiko-dsh-office、dsh-iwiw-memory)存疑/弃用标记,优先选活跃维护的
五、实操建议
- 安装渠道:已装的
dshmarket(设置 → 插件市场)直接搜索、点一下安装——它只收录 awesome-dsh-plugin 精选列表,比裸装 GitHub 源码安全;命令行方式:dsh plugin --profile web add <包名>。注意:本文插件名以 GitHub 仓库名为准,具体 npm 包名请以市场搜索结果为准(市场卡片上可见)。
- A/B 验证:市场支持热禁用/启用(HMR 约 1 秒生效,无需重启)。装完每个插件先跑一个典型任务,质量/速度变差就关掉——这是最实际的"科学性"检验法。
- 权限:当前
danger-full-access全局放行。日常学习问答(尤其配合 Office 读写)建议改用更保守的权限预设,只在明确要操作文件时放开,降低误操作风险。 - vLLM 侧:确认 prefix caching 开启(默认开);长会话用内置
/compact压缩即可,不必为长上下文加插件;换量化/改--max-model-len前可用 dsh-model-manager 先做 VRAM 校验与 tok/s 测试。
六、一句话总结
autofork + office-toolkit(三选一)+ qwen-local(可选)+ model-manager(可选)+ 自建 skills + 守藏记忆(按需),其余不装。
对本地 27B 模型,"少装"本身就是最科学的选择。
整体判断：方向对，「少而按需」这个原则是对的——本地 27B-int4 的真实瓶颈就是工具 schema 膨胀 + 每回合多次调模型，不是插件数量。几处批注：
-
prefix caching 别当万能。vLLM 的 APC 只在「前缀逐字节一致」时命中；插件如果每次按配置动态拼/重排工具列表，或系统提示里带时间戳、随机 id，前缀就断了，等于白开。要吃到 APC，得保证工具段顺序和内容稳定。这也反过来支持你「office 三选一」的结论。
-
真正决定工具能不能用的是 vLLM 启动参数，不是插件本身：必须带
--enable-auto-tool-choice --tool-call-parser hermes（Qwen 系用 hermes 或 qwen 解析器），否则不会返回结构化 tool_calls，插件装了也白装。建议把这条放在清单第 0 位。 -
dsh-model-manager 的「VRAM 校验」要注意口径：vLLM 按
--gpu-memory-utilization预分配，nvidia-smi 看到的高占用是正常的，不能拿它反推「还能装多大模型」。换量化前的显存估算，按「权重 + KV(层数×头数×ctx×dtype) + 激活/图」手算更靠谱。 -
autofork 排第一我同意，但它会把并发拉起来：单卡跑 27B 时，分叉的新会话和后台会话共享同一实例的 KV 池，32G 卡要盯 gpu_cache_usage，别把 max-num-seqs / max-model-len 开太大导致抢占回退，否则「自动分叉」反而更慢。装在吞吐有余量的时候。
-
避开 telemetry 那条最关键，本地部署的隐私价值就在这，同意；MCP 限 1–2 个也对。
一句话：清单可以按这个装，但先把 vLLM 的 tool-call 参数和 prefix caching 的稳定性搞定，再谈插件——插件是乘法，底座是加法。
