前言¶

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