Article content is shown in its original language.
DSH 0.1.7-rc.2 是预发布版；dsh-context 提供上下文面板与命令。本文核对了固定包、源码与权限路径，但未完成插件运行验收。
长会话卡住时，读者要知道的不是“装一个插件”
让智能体改一份长文档，聊到后半段，它忘了前面某个约束；补充说明又挤占上下文。使用者想知道：这轮会话占了多少空间，哪些消息在消耗额度，何时该拆分任务。DeepSeek Harness（DSH）不同于只回答问题的聊天窗口，它让模型在工具、文件与任务中行动；会话状态因此也会影响结果和成本。
9 月 24 日的官方 GitHub release 标为 dsh-v0.1.7-rc.2，prerelease=true。它不是可被写成“稳定版全面发布”的证据。记录提到插件详情和设置页显示问题的修复、安装失败提示改善，以及自动审阅入口调整；自动审阅拒绝后，允许人工审批的会话可由用户决定是否继续。这些改动与插件可见性、安装判断和授权路径相关，却不等于任何第三方插件已经通过官方安全审查。
今日选择的单一插件是社区维护的 dsh-context。其仓库维护者为 bowenliang123，README 介绍上下文仪表盘、侧栏面板和 /context 命令。功能方向与长会话成本问题相连：先看组成与变化，再决定是否继续堆对话。我们的证据停在仓库、固定 npm 包和本地只读静态审计；本文没有把作者演示当作我们自己的运行结果。
一个插件的两种身份：仓库提交与 npm 包
在 9 月 27 日本次核对时，dsh-context 仓库可见提交 423ea4f2acb7ea14c81776955682129d24e352be；npm 固定包是 0.56.2，包元数据里的 gitHead 则为 198ec93105bc942f2b576133edc01eed25a624d2。两个提交不同。仓库最新源码可用于理解开发方向，安装决策却要回到实际拿到的包字节，不能把“看过仓库”写成“审过安装包”。
本地只读审计把 npm 0.56.2 归档与注册表 SHA-512 比对，结果匹配；归档有 10 个条目，未见绝对路径、.. 穿越路径或符号链接。包元数据声明 host 入口、Web client 注入和对 0.1.7-rc.2 的兼容字段。匹配只说明下载字节与注册表声明一致；兼容字段是发布者声明，不是我们完成 Profile 重启后的运行证明。
npm 在 9 月 19 日至 25 日给出 30,834 次包下载。这个量可以说明包被请求的频率，不能推算独立使用者，更不能证明安全。GitHub 搜索 topic:dsh-plugin 在本次查询返回 16,257 个候选仓库；Topic 是标签集合，里面包括宿主、实验项目和不具备独立 Bundle 的仓库。这里的 16,257 绝不等于可安装插件总数。
它读得到什么，比面板长什么样更重要
dsh-context 要做上下文统计，代码路径需要读取会话相关数据；静态检查还看见读取配置与 API Key，并向配置的 /user/balance 端点发起请求的路径。它们与余额显示功能有因果关系，也构成隐私和凭证边界。使用者应把“读取会话内容”“读取密钥”“联网到哪个域名”“Web client 注入宿主模块”分别核对，不能用一句“只是统计插件”盖住差异。
安全检查的第一步是固定包名、版本、归档摘要和来源仓库；第二步是检查 Bundle 声明与本机实际授予的文件、网络、命令权限；第三步是准备一次性 Profile 和虚构会话，再观察权限提示、单次重启、/context 的最终输出以及卸载后的状态。今天只完成前半段的公开资料读取和归档审计。我们没有在真实 Profile 中安装、重启或执行任务，也没有完成卸载回滚。
至少有四种失败会改变判断：latest 变化造成包与代码错配；完整性不匹配意味着下载对象不可信；网络端点或凭证范围解释不清会让成本面板变成数据外流路径；关键词静态扫描漏掉动态加载和依赖代码。遇到前两项应停下重新固定对象，遇到第三项应只在隔离环境复核授权，遇到第四项则不能把“扫描没命中”当成零权限。撤销路径应先备份 Profile、记录安装前插件列表，测试结束卸载固定插件并核对配置差异；未做这些动作前，“可回滚”仍是待验项目。
一个搜索结果，能证明哪一层事实
寻找 DSH 插件时，GitHub Topic 给广覆盖，也混入同名与非标准仓库；Awesome 清单或生态地图适合按主题导航，却依赖维护者更新；可搜索网页目录能把用途与分类排在一起，但收录不是安全审计；Plugin Leaderboard 展示互动或安装热度，不能代替权限复核；内置或订阅式市场减轻安装步骤，也不能代替一次性 Profile 的最终任务测试。
这些入口解决的是覆盖、导航、热度或便利的不同片段。共同缺口是：固定来源、权限可读、运行证据和可撤销变更没有连成一条连续决策链。用户看见一个条目后，仍需要追问具体 Commit、Bundle、下载对象、宿主授权、重启结果和回滚证据。把这些问题写进安装流程，比把目录规模当作安全承诺有用。
目录是起点，运行验收仍在本机
在这条决策链末端，DSH.Store 国际站可用于按用途发现插件并查看来源、权限与目录状态；国内站是另一访问入口，不是第二套生态。本次读取其 registry/catalog.json：索引共 728 条记录，其中 approved 21、blocked 328、unlisted 379。网站首页显示的“349 在架插件”是另一展示口径；任何一个数字都不能写成“728 个已审计可运行插件”。目录里的审查状态和候选安装限制，提供的是筛选信息，不替代读者自己的本机验收。
若决定试装，安全插件管理器仓库可供使用者查看固定来源、权限提示与安装/撤销机制，并可在核对代码后 Star；仓库存在或命令返回成功，都不等于 dsh-context 已在你的 Profile 生效。插件开发者则可研究插件制作仓库的 Bundle 打包与审计路径，再依仓库当前许可证处理修改和分发，也可在认为有价值时 Star。两条路径分别服务使用与开发，不要求读者为本文选择任何产品。
这件事的机会是让长会话从“感觉要满了”变成可检查的状态，风险是把会话和凭证权限交给未经运行验收的代码。下一步需要一次隔离 Profile 试验：固定 npm 0.56.2，截图记录权限，重启一次，用虚构长会话核对面板和 /context 输出，再卸载并核对配置恢复。只有这组结果齐全，才能把“可发现、可下载、静态可审”升级为“此环境可用”。
原稿日期：2026-09-27。