前言¶

DeepSeek Harness（dsh）是 DeepSeek AI 开源的智能体运行时，架构口号是「一切皆插件」。模型、工具、会话、界面都可以拆成独立模块，由 Cordis 组装进一个 profile。这种结构方便扩展，也带来一个很具体的问题：智能体跑完一轮之后，对话里经常会出现「已经跑过测试」「检查通过了」之类的表述，但本地并没有一张可以单独打开、又不带会话原文的执行摘要。

dsh-verification-receipt 做的事情比较克制。它不会去证明测试真的跑过，也不会给代码正确性背书。每次耐久的 turn/end 到来后，它只把这一轮里已经记录下来的工具计数，以及词法层面上「看起来像验证」的信号，追加到本地 JSONL 文件里。仓库 README 把它概括成一句更小、也更好检查的问题：这一轮中，DSH 记录了哪些形似验证操作的执行信号？

本文按目录页与 GitHub 仓库交叉核实后的资料，介绍这个插件是什么、凭证里有什么、怎么安装，以及它明确不做什么。

这是什么¶

dsh-verification-receipt 是一款会话与消息类插件，由 GitHub 用户 030611 维护，当前版本为 0.1.0，许可证是 MIT，主要语言是 TypeScript。社区目录页收录于 2026-08-14；截至 2026-08-18，目录页与 GitHub 仓库均显示 5 颗星。npm 上可以按同名包 dsh-verification-receipt 安装。

它是一个小型、被动的 Profile Bundle：package.json 声明 dsh.bundle.patch，cordis.patch.yml 插入一个普通观察插件，id 为 verification-receipt。任何提供核心 Session 服务的 DSH 输出面都可以使用它。插件会暂时读取已有耐久事件里的工具名称、原始参数和结果状态来计算汇总，但落盘时不会保留这些输入。它不追加 Session 事件、不注册工具、不添加 prompt 段、不注入上下文、不发起模型调用，也不改变模型历史。

需要先分清两件事。第一，社区插件目录 deepseek-harness-plugin.com 是独立站点，用来检索和安装社区插件，与 DeepSeek / 幻方没有官方从属关系，不要把它当成官方应用商店。第二，仓库自己也写明：本插件由社区维护，并非 DeepSeek 官方项目。同一维护者还列出了几款相关的 trust-layer 插件，分别是 Telemetry Redactor、Evidence Audit 和 Context Provenance；dsh-verification-receipt 有意不做 evidence-audit 账本，各行保持独立，不引入哈希链、产物捕获、claim-evidence 关联或协议证明。

凭证里有什么¶

默认输出文件是：

$DSH_HOME/verification-receipts/v1/receipts.jsonl

DSH_HOME 未设置时，路径解析到 ~/.dsh 下。可以在 profile 的 cordis.patch.yml 里用绝对路径覆盖：

- id: verification-receipt
  config:
    outputPath: /absolute/private/path/receipts.jsonl

仓库 README 给出的每行结构如下（字段值为文档示例，不是某次真实用户会话）：

{
  "schemaVersion": 1,
  "kind": "dsh-verification-receipt",
  "sessionIdHash": "sha256:…",
  "turn": 3,
  "turnEndSeq": 42,
  "endedAt": 1786630000000,
  "outcome": "completed",
  "tools": {
    "calls": 4,
    "succeeded": 3,
    "failed": 1,
    "unresolved": 0,
    "topLevel": 2,
    "nested": 2
  },
  "verificationSignals": [
    {
      "source": "command",
      "category": "test",
      "status": "failed"
    }
  ],
  "claim": "execution-trace-only",
  "receiptHash": "sha256:…"
}

几个字段需要按文档字面理解：

1、claim 固定为 execution-trace-only。凭证只能说明 DSH 记录了工具调用，并且词法启发式发现了可能的验证信号。
2、tools 是计数，不是命令原文。它统计调用次数、成功、失败、未决，以及顶层 / 嵌套调用。
3、verificationSignals 只保留 source、粗粒度 category 和观察到的 status。
4、sessionIdHash 是确定性、无密钥且带域分隔的 SHA-256，用来在不保存原始 session id 的前提下把同一 Session 的凭证分组。仓库明确说这是化名化，不是匿名化：如果 Session id 可预测或熵低，观察者可以离线猜测候选值并重算 hash。
5、receiptHash 是对其前面全部凭证字段按输出顺序计算的 SHA-256。两个 hash 都没有密钥，均可重算。能编辑一行的人也能重新计算它。独立行无法暴露删除、插入、重排、截断、回滚或替换。它不是签名、可信时间戳、哈希链、承诺或防篡改日志。

落盘凭证不包含：工具参数或 call id、工具结果正文或错误消息、助手或用户消息正文、原始 session id、工作目录、provider 名称或模型名称。

启发式信号怎么判定¶

以下两种情况会产生启发式信号：

1、工具名称类似 test、typecheck、lint、build、check、verify 或 validate 工作。
2、类 shell 工具在内存中的 command 或 cmd 参数类似上述工作。

分类只做词法匹配，不解析 shell 语义、不展开别名，也不执行命令。DSH 原生工具错误以及可识别的非零 shell 退出标记计为失败。后台命令保持 unresolved，因为后续 job 结果可能发生在本轮之外。即使是 status: succeeded，也只表示观察到的调用没有已识别失败标记；它不表示测试通过，甚至不表示测试确实运行。

仓库给出的支持边界可以记这几条：

1、JSON 字符串或对象参数中的字符串 command / cmd 会检查，但只检查已识别的类 shell 工具名。
2、大小写、引号，以及可见的 bash -lc / pwsh -Command wrapper 可以词法匹配，前提是分类关键词仍在字符串中可见。
3、数组命令、argv、嵌套命令对象、自定义 shell 工具名不支持，不会产生信号。
4、不含可见分类关键词的别名或 wrapper 会漏判。
5、echo "do not run tests" 这类引用文本会被词法匹配，因此误判是预期现象。

文档要求把每个匹配都叫做「启发式信号」，不要叫做「测试已运行」，也不要把它当成证明或质量门禁。

安装与启用¶

目录页给出的安装命令如下，在 DeepSeek Harness 终端中运行即可。dsh CLI 会从 GitHub 解析插件并安装到当前配置：

dsh plugin add github:030611/dsh-verification-receipt

如需可复现安装，目录页建议固定 commit 哈希：

dsh plugin add github:030611/dsh-verification-receipt#commit

把上面的 commit 换成实际提交哈希。仓库 README 另外给出了按 profile 安装已发布 npm 包的写法，适用于需要给指定 profile 发凭证的情况：

dsh plugin --profile web add dsh-verification-receipt
dsh --profile web --dump-config

如果其他 profile（例如 headless）也需要凭证，换用对应 profile 名重复第一条命令。本地开发时，克隆仓库并运行 pnpm install --frozen-lockfile && pnpm run check，再把 checkout 路径而不是包名传给 dsh plugin ... add。

package.json 声明的 Node 引擎为 ^22.19.0 || >=24.0.0。兼容性证据以 DeepSeek Harness 提交 47f943859bef60e4160492346772ded9b24f765a 为审计基线；该提交的 manifest 声明 @deepseek-ai/dsh-session 0.1.0-rc.5、Cordis 4.0.1 和 Schemastery 3.18.1。peer 范围从这些版本开始，在 dsh-session 稳定版 0.1.0 或 Cordis / Schemastery 下一个 semver 主版本之前结束。发布检查也覆盖当前可安装的 dsh-session 0.1.0-rc.6。范围内但未点名的版本只是兼容预期，不是实测证据。

目录页和仓库都提醒：插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前请检查源代码仓库和许可证。

对模型循环的影响¶

按仓库的「模型体验」说明，这个观察插件尽量不碰智能体主路径：

1、不增加 token 成本。
2、不给模型注册新工具。
3、不改 Session 日志，只读已有事件。
4、不改 prompt 与上下文。
5、监听器同步扫描已结束的 turn，并排队本地文件 I/O；turn 路径不等待磁盘。

它适合想在本地留一份轻量执行痕迹、又不希望插件改写对话或工具面的场景。例如排查某一轮到底调了几次工具、有没有出现名称或命令里带 test / lint / build 的调用，以及这些调用在 DSH 记录里是成功、失败还是未决。它不适合拿来做发布门禁、合规存证或对抗性防篡改。

适用场景与注意事项¶

适合使用的情况可以归纳为：需要一份隐私最小化的逐轮摘要；可以接受词法启发式的漏判和误判；输出文件只给本机运行 DSH 的用户读写。SECURITY.md 要求不要把 JSONL 放到智能体可见的工作区、共享目录、同步公开文件夹或不受信任的挂载点上。插件在支持的 POSIX 文件系统上创建目录和文件时会请求 0700 / 0600，但不会收紧已有权限，Windows 可能忽略 POSIX mode，并且会跟随预先存在的符号链接。请配置可信、私有且非符号链接的路径。

已知限制同样来自仓库，写作时不要把它们理解成「以后会自动修好」的承诺：

1、凭证只覆盖插件运行期间观察到的事件；不会回填构造 seed 历史或插件卸载期间结束的 turn。
2、进程崩溃可能丢失尚在队列中的凭证，因为 turn/end 不会同步等待这个可选本地 sink。
3、各行彼此独立，无法检测删除、重排、截断或回滚。
4、凭证状态复述 DSH 记录的工具结果和可识别的 shell 标记，不会独立执行或验证任何内容。
5、没有跨进程锁。两个 DSH 进程同写一个文件时，行顺序和行边界完整性均无保证；应每进程使用独立文件。崩溃可能留下不完整尾行，读取方必须拒绝或隔离它。
6、进程内写入队列有序但无界；缓慢或卡死的文件系统会持续增加内存占用。
7、文件没有内建轮转、保留策略、加密、签名或恢复机制。

这是一个 0.x 预发布插件，安全修复只针对最新提交。DeepSeek Harness 本身也仍在开发者预览阶段，官方仓库标明会有破坏性变更。安装社区插件前，除了看许可证，还应核对当前 dsh 版本是否落在该包声明的 peer 范围内。

小结¶

dsh-verification-receipt 给 DeepSeek Harness 的每一轮留下一张很薄的本地凭证：工具计数，加上词法层面的验证信号。它回答的问题很小，边界也很清楚——记录执行痕迹，不证明语义正确。如果你需要的是「这一轮 DSH 记下了什么」，而不是「智能体说的是否属实」，可以按目录页命令安装后查看 $DSH_HOME/verification-receipts/v1/receipts.jsonl。

目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-verification-receipt/

GitHub：https://github.com/030611/dsh-verification-receipt