DSH缓存插件过4项测试,Profile待验收

关注「山海只能局」，用东方文化看懂现代科技。

在 DSH 会话里输入 /cache，读者想知道一段长任务用了多少缓存、下一次调用能否少付输入费用。开源插件 dsh-cache-stabilizer（https://github.com/dongsheng123132/dsh-cache-stabilizer）把供应商返回的缓存数字变成可核对的命令结果。

DeepSeek Harness 团队 11 月 5 日公布产品与社区进展：截至 11 月 4 日，以使用 DeepSeek 官方 API 的用户为统计范围，日活为 154 万、日消耗 Token 约 92 万亿；团队称第三方插件约 3.5 万个，约六成活跃用户制作或安装过至少一个插件。这些是团队运营口径，未见独立审计；插件数量的去重和安装状态算法未公开。团队同日表示将提升插件 API 稳定性与安全机制、筹建官方插件市场，并准备面向作者的 Token 激励与技术交流计划；市场、规则和激励细节尚未落地。

对开发者，这关系到长上下文的调用费用和排错效率；对普通用户，问题更朴素：界面上的“缓存优化”有没有真实数字。插件不能凭空制造命中率，它读取 DSH 会话的 usage 事件，供应商未提供指标时会显示没有数据。

截至 11 月 7 日，官方最新发布标签是 0.2.2-rc.1，发布时间为 11 月 4 日；npm latest 与 next 指向 rc.1，alpha 指向 0.2.2-alpha.3。rc.1 是候选发布版，不是正式稳定版，标签对应提交 66491b05e3f05ad35bcdd4f6cd7ed26041d9e3db。

聊天产品主要让用户在一段对话里调用模型；DSH 是一个可组合的 agent harness，模型、工具、会话、系统提示和工作流以 Profile 组合。插件可以挂接系统事件、增加命令或工具，改变的不只回答风格，也包括每轮调用前的实际运行路径。

因此，插件的 README、npm 上架或商城收录只能说明“有人发布了一个包”。安装命令成功说明包管理器完成了一段操作；真实可用还要检查 Bundle 被哪一个 Profile 装载、重启后是否进入 Loader、命令是否可见、任务最后是否得到预期结果。

GitHub Discussion #12232 的一位 Windows 11 用户报告：从 0.2.1-rc.5 升到 0.2.2-rc.1 后，装有 ds-bot 的每轮约 57 毫秒失败；报告把原因指向 system-prompt/assemble 阶段没有 tools 字段。它是单个社区复现，不是官方确认的普遍影响；但本篇插件也对该字段直接调用 map，存在同类失败路径。后一句是源码结构推断，不代表该插件已被证实在 rc.1 上失败。

本次选择的重点插件是dsh-cache-stabilizer 0.1.1（https://github.com/dongsheng123132/dsh-cache-stabilizer），维护者为 GitHub 账号 dongsheng123132；源码仓库固定在完整提交 04defdea448054edcd2a0bb45f8dff0c77cb2ab2。该提交包含 dsh.bundle.patch，仓库 License 文件标为 MIT。npm 对 dsh-cache-stabilizer@0.1.1 返回 404，因此本文不把它写成已发布的 npm tarball；检查范围是 GitHub 固定提交源码。近 30 天内容索引和 DSH 插件历史没有找到同一仓库或同名插件的介绍记录。 本次审阅的固定源码样本为 1 个；全量 dsh.bundle.patch 仓库与 Bundle 计数尚未完成，不能从该样本推算生态总量。 本次审阅的固定源码样本为 1 个；全量 dsh.bundle.patch 仓库与 Bundle 计数尚未完成，不能从该样本推算生态总量。

源码做两件事：只把 DSH 默认 persona 中那句精确的工作目录提示移到 runtime context；再把每个工具 schema 内的对象键排序。数组顺序不动，未知 persona 不改写。/cache 命令读取 assistant/message 事件里的 cacheReadTokens、inputTokens 与 cacheWriteTokens，不读取对话文本。

权限审阅看到的运行行为限于注册 commands、监听 system-prompt/assemble、返回改写后的 assembly 和读取当前会话 token 用量。静态源码里没有文件读写、网络请求或 shell 调用。安装包仍会由包管理器写进所选 Profile；安装前应在隔离 Profile 中核对包版本、脚本和权限。源码安全审阅不能代替运行验收。

我把固定提交中的 stabilizer.mjs 与维护者测试文件放到隔离目录，使用 Node 26.8.1 运行 node --test。四项测试全部通过：工作目录提示移动、自定义 persona 不被猜改、工具 schema 对象键排序、缓存命中率按供应商用量拆分。耗时约 0.1 秒，没有安装 DSH，也没有读取真实会话。

这四项是插件维护者的单元测试，只证明这些纯函数在给定样本上的行为。它们没有覆盖 DSH 0.2.2-rc.1 的真实 assemble hook、Web 与 Desktop Profile、供应商 usage 兼容性，也没有证明安装后 /cache 能显示当前任务数据。

至少有三个失败点要写在验收单里：一，若当前 hook 的 assembly.tools 为 undefined，插件无条件执行 assembly.tools.map 会让回合报错；二，供应商没有 cacheReadTokens 或 inputTokens 时，命令会显示无统计，不能解释为命中率为零；三，自定义 Profile 或未来 schema 变化可能改变提示词语义或字段对象，四项纯函数测试覆盖不到。

有 DSH 0.2.2-rc.1 的读者，可先建立可丢弃 Profile 并复制现有配置；固定安装 dsh-cache-stabilizer@0.1.1 对应的 GitHub commit，先审查 cordis.patch.yml、package.json、index.js 和 lib/stabilizer.mjs。不要在有未提交工作、生产 API 密钥或关键本地插件的 Profile 上试装。

安装完成只是中间步骤。按官方插件流程让目标 Profile 加载 Bundle，再重启 DSH；打开新会话确认 /cache 命令注册，发送不含敏感资料的短消息，再运行 /cache。最终验收要看命中、未命中和写入统计与供应商返回的 usage 记录一致，并确认工具调用和普通对话没有异常。

若启动失败，先查该 Profile 最近一次插件变更和错误日志。命令行支持按 Profile 移除插件：dsh plugin --profile <profile> remove dsh-cache-stabilizer；然后重启并确认该 Bundle 不在 Profile 列表。桌面插件管理器也有社区报告称某些删除路径失败；如果移除未生效，不要反复安装覆盖，改用官方 CLI 和 Profile 备份恢复流程。

11 月 7 日 12:18（北京时间），GitHub 的 dsh-plugin Topic 搜索返回 27,826 个仓库候选。它只表示带该 Topic 的仓库搜索结果，不等于插件、Bundle、可安装包或审计样本总数。本次固定并检查了 1 个插件仓库；没有完成全 GitHub 的 dsh.bundle.patch 扫描，因此符合该文件条件的仓库数和 Bundle 总数都未知。

入口能回答的问题不同：GitHub Topic 提供仓库覆盖线索；Awesome 清单按人工维护的类别导航；可搜索网页目录补关键词检索；Plugin Leaderboard 汇集部分兼容性尝试；内置或订阅式市场减少查找和安装步骤。Topic、清单收录、热度榜和安装按钮都不能证明固定源码安全，也不能证明目标 Profile 的任务输出正确。

这些入口仍缺一条连续的决策链：固定到可复查的来源，读清文件、网络与命令权限，在目标 DSH 版本完成真实任务验收，并能撤回 Profile 变更。本次对 dsh-cache-stabilizer 固定到完整 Git Commit；npm 对 0.1.1 返回 404，所以审阅对象是仓库源码与维护者测试，不是已发布 npm 包。 本次审阅的固定源码样本为 1 个；全量 dsh.bundle.patch 仓库与 Bundle 计数尚未完成，不能从该样本推算生态总量。

在这条缺口之后，再看目录层的可核验信息：11 月 7 日读取的 DSH.Store 国际站（https://dsh.store/） 与国内站（https://dsh-store.cn/）返回同一份索引，索引更新时间为 11 月 7 日 05:20（北京时间），共有 884 条目录记录。分类标签可以重叠：experimental 463、tools 185、ui 99、workflow 56、memory 40、sessions 40、visualization 40。其中 126 条带 package manifest 与 installPath；目录自报 2 条 installability verified、2 条 runtime verified，这些标记不是独立认证。两站是访问入口，不是两套生态。

插件使用者可查看并 Star dsh-safe-plugin-manager（https://github.com/AI-Scarlett/dsh-safe-plugin-manager），它的仓库说明固定来源、权限审阅和可撤销管理流程；使用者仍需自行验收目标 Profile。插件开发者可研究并 Star build-dsh-plugin（https://github.com/AI-Scarlett/build-dsh-plugin）的打包与验证流程；修改或再分发前，应先核对该仓库 License。