DSHIO/T 10—2026 插件標準

---

1 範圍

本標準規定了 DSH 插件的分類、技術要求、試驗方法、檢驗規則與標誌。

本標準適用於所有以 npm 包形式分發、可通過 dsh plugin 安裝到 DSH profile 的插件。

本標準不適用於：

• 套件（bundle）—— 見 DSHIO/T 11
• DSH 核心包本身
• 不提供 dsh.bundle.patch 的普通 npm 包

1.1 實施獨立性聲明

本標準不要求使用任何特定的開發工具、編程語言、構建流程或輔助庫。

凡滿足本標準全部技術要求者，即為符合，不論其如何實現。判定以可觀測的運行時行為為準，不以源碼結構為準。

具體含義：

1. 不強制使用 @deepseek-ai/dsh-tools。defineTool() 只是編寫工具的一種便捷方式；手寫符合 entry 契約的對象同樣合法。
2. 不強制 TypeScript。官方插件用 TS 是因為官方項目用 TS，不是標準要求。
3. 不強制官方構建流程。標準只規定產出物的結構，不規定如何生成。
4. 不強制 pnpm。dsh plugin 當前轉發給 pnpm，但標準只要求依賴能被正確解析。
5. 不強制特定 Cordis 版本。只要插件在目標 DSH 版本上能掛載並運行即可。

判定基於黑盒驗證：安裝、列裝、掛載、啟動、工具調用。不讀作者源碼。

---

2 規範性引用文件

下列文件中的條款通過本標準的引用而成為本標準的條款。凡是注日期的引用文件，僅注日期的版本適用。

非規範性引用（僅供參考）：

• 官方 DSH README（層優先序、engines.dsh 判定規則）
• dsh --dump-config-schema 輸出的 entry/patch JSON Schema

---

3 術語和定義

DSHIO/T 00—2026 界定的術語適用於本文件。

本文件補充定義：

3.1 基準版本

baseline version

DSHIO 當前用於認證判定的 DSH 版本。當前基準版本為 0.2.2-rc.1。

基準版本隨 DSH 發佈更新。更新程序見 DSHIO/T 35。

3.2 靜態層

static layer

不需要安裝即可判定的檢查。對應 DSHIO/T 20 的 T0 階段。

靜態層檢查三類對象：package.json、patch 文件、entry 結構。

3.3 動態層

dynamic layer

需要實際安裝與運行才能判定的檢查。對應 T1–T5 階段。

3.4 紅線組合

red-line combination

單獨出現即判定為高風險的權限組合。

當前定義一種：network 與（shell 或 fs-write）同時聲明。

理由：這兩類權限同時存在，構成「讀取本地資料並發送到外部」的完整路徑，而使用者無法從聲明看出實際流向。

---

4 分類

4.1 按提供能力分類

一個插件可以同時屬於多類。

4.2 按模型相關性分類

依據： 模型接入由獨立插件（dsh-llm-*）提供，不在 harness 核心內，因此安裝、掛載、啟動天然與模型無關。

4.3 按權限需求分類

---

5 技術要求

本章全部為強制性條款。 除標註「宜」者為推薦性。

5.1 結構要求

5.1.1 插件聲明

package.json 必須包含 dsh.bundle.patch 字段，其值為 patch 文件相對於包根目錄的路徑。

{
  "dsh": {
    "bundle": {
      "patch": "./cordis.patch.yml"
    }
  }
}

判定： 字段存在且值為非空字符串。

5.1.2 patch 文件存在

dsh.bundle.patch 指向的文件必須存在於發佈的包內。

判定： 從公共 CDN（unpkg / jsdelivr / npmmirror）能取到該文件。

常見失敗原因： 文件路徑與聲明不一致；files 數組漏了該文件。

5.1.3 patch 文件是合法 YAML

patch 文件必須能被 YAML 1.2 解析器解析。

判定： yaml.safe_load() 不拋異常。

最常見錯誤： 以 @ 開頭的值未加引號。

# 錯
name: @scope/pkg
# 對
name: "@scope/pkg"

YAML 中 @ 是保留指示符，不加引號會導致解析失敗。

5.1.4 patch 結構

patch 文件的頂層必須是數組，且至少含一個帶 insert 字段的項。

- insert:
    - id: my-plugin
      name: "my-package"

判定： 頂層為 list；至少一項為 dict 且含 insert。

5.1.5 entry 完整性

insert 列表中的每個 entry 必須含非空字符串 id 與非空字符串 name。

判定： 遍歷每個 insert 數組的每個 dict，檢查兩字段。

5.1.6 entry 的可選字段

以下字段可選，出現時必須符合官方 schema：

依據： dsh --dump-config-schema 輸出的 entry 定義。

5.2 版本與入口要求

5.2.1 版本範圍聲明（宜）

package.json 宜包含 engines.dsh 字段，聲明兼容的 DSH 版本範圍。

缺失時的判定： 按 peerDependencies 中 @deepseek-ai/* 包的版本範圍判定。若兩者皆無，視為無版本約束（任何 DSH 版本都接受），僅記為建議改進。

{
  "engines": { "dsh": ">=0.2.0-rc.2" }
}

5.2.2 版本範圍包含基準版本

engines.dsh 聲明的範圍必須包含當前基準版本。

判定： 用 semver 規則判斷 0.2.2-rc.1 是否落在範圍內。

常見錯誤： 寫死上界。

// 錯：排除 0.2.2-rc.1
"engines": { "dsh": ">=0.2.0-rc.2 <0.2.2-0" }

// 對：只寫下界
"engines": { "dsh": ">=0.2.0-rc.2" }

依據： 官方 README 規定安裝與 profile 啟動都會校驗 engines.dsh 與運行時版本，不兼容需要顯式申請精確版本豁免。

5.2.3 代碼入口

package.json 必須聲明代碼入口：main 或 exports 至少有一個。

純配置型插件（4.1 分類中的「配置型」）可以只有 apply() 空實現，但仍須有可用入口，否則安裝校驗失敗。

{
  "type": "module",
  "main": "lib/index.js"
}

5.2.4 混合模組類型（宜）

ESM 包宜聲明 "type": "module"，避免 .mjs 後綴。

5.3 打包要求

5.3.1 files 數組完整性

若聲明 files 數組，必須包含：

• lib（或入口文件所在目錄）
• patch 文件

判定： 檢查 files 中是否有以 lib 開頭的項，以及是否覆蓋 dsh.bundle.patch 的值（去掉前導 ./ 後比較）。

未聲明 files 時： 視為包含全部文件，本條通過。

5.3.2 不得依賴本地路徑

以下字段的值不得以 file: 開頭或以 / 開頭：

dependencies、optionalDependencies、peerDependencies、dsh

devDependencies 不在此列 —— 開發依賴不隨包發佈，消費者安裝時不會被安裝。

常見錯誤： 把內部工具寫成 "my-kernel": "file:./kernel" 並放在 dependencies 裡，導致消費者安裝失敗。

5.3.3 包大小（宜）

node_modules 安裝後體積宜小於 50 MB。

說明： 不設強制上限，但體積過大會顯著拖慢安裝。參考：官方插件多在 1–20 MB。

5.4 行為要求（需沙箱測試）

5.4.1 可安裝

插件必須能從公共 npm registry 或指定 Git 倉庫解析並安裝到 DSH profile。

判定： T1 階段。見 DSHIO/T 20 與 DSHIO/T 21。

5.4.2 可列裝

安裝完成後，插件必須出現在 profile 的依賴列表中。

判定： T2 階段。

說明： 此階段斷網執行。

5.4.3 可掛載

插件的 entry 必須出現在 dsh --dump-config 的輸出中。

判定： T3 階段。斷網執行。

失敗判定： install_ok=true 但 registered=false 時，判定為 installs_but_not_registered。

5.4.4 可啟動

載入插件後 profile 必須能啟動，並連續存活至少 12 秒。

判定： T4 階段。斷網執行。

5.4.5 工具契約（工具型插件）

註冊的工具必須滿足：

判定： 靜態讀取工具註冊代碼，或 T5 階段觀察工具列表。

5.5 質量要求

5.5.1 工具描述說清使用場景

每個工具的 description 必須讓不熟悉該插件的人判斷出「什麼情況下應該調用這個工具」。

不合格的寫法：

• 只寫功能名稱："Searches plugins"、"Gets price"
• 只寫參數說明

合格的寫法：

• 「查詢 DeepSeek 模型價格。返回官方價目表加第三方服務商每百萬 token 報價，按從低到高排序，附量化說明。當被問到 DeepSeek 多少錢、哪家服務商最便宜時使用。」

判定方式： 需人工判斷。 引導問題：不知道這個插件的人看了描述，能判斷該不該用嗎？能判斷什麼時候用這個而不是別的嗎？

5.5.2 權限聲明與行為一致

插件聲明的權限集合必須：

• 覆蓋它實際使用的能力（不低報）
• 不聲明未使用的能力（不高報）

判定方式： 需人工判斷。 引導問題：聲明了 network 但從不發請求？聲明了 fs-write 但只讀？高報降低信任，低報導致運行失敗。

5.5.3 不得出現紅線組合

同時聲明 network 與（shell 或 fs-write）判定為紅線。

判定： 靜態讀取權限聲明。

例外： 確有必要的，必須在 README 中說明：

1. 為什麼需要網絡
2. 為什麼需要寫入或 shell
3. 資料流向

登記者仍為 high 風險，但不算不符合。

---

6 試驗方法

6.1 靜態層（T0）

不需要容器。 執行 deepseekbase_check 或等價實現。

靜態層完整結果可分三態：符合 / 不符合 / 需人工判斷。

6.2 動態層（T1–T4）

必須在符合 DSHIO/T 21 的沙箱中執行。

判定依 DSHIO/T 20 的階段定義。

6.3 模型相關層（T5，僅模型相關插件）

必須記錄模型相關環境指紋（見 DSHIO/T 21 第 6 章）。

方法：在指定模型下，用固定提示詞請求調用該插件註冊的工具，重複 3 次。

通過判據（必須在報告中寫明採用哪條）：

• 全過：3 次全部正確調用（認證用）
• 多數：3 次中至少 2 次（評估用，不得用於認證）

6.4 人工判斷層

5.5.1 與 5.5.2 只能人工判斷。

判定輸出必須是「需人工判斷 + 引導問題」，不得給出通過或失敗結論。

---

7 檢驗規則

7.1 檢驗分類

7.2 抽樣

本標準不涉及批次抽樣。 每個插件版本為一個獨立檢驗對象。

同一插件的不同版本（含補丁版本）視為不同對象，必須分別判定。

7.3 判定規則

7.3.1 單條判定

7.3.2 總體判定

7.3.3 條款嚴重度

7.4 重複性要求

兩次動態判定不同時：

1. 記為「不穩定」
2. 記錄兩次完整輸出
3. 不得作為認證依據

7.5 複檢

不符合的插件在作者修改並發佈新版本後，可重新檢驗。新版本視為新對象，不繼承舊判定。

---

8 標誌

8.1 符合聲明

通過檢驗的插件可以在其 README 中聲明：

符合 DSHIO/T 10—2026（基準 DSH 0.2.2-rc.1，靜態層 + 動態層）
檢驗日期：YYYY-MM-DD
環境指紋：dsh=0.2.2-rc.1;img=...;node=...;pnpm=...

必須同時聲明：

• 檢驗覆蓋的條款範圍（只做了靜態層就必須寫明）
• 環境指紋
• 檢驗日期

禁止： 只寫「符合 DSHIO 標準」而不註明版本、範圍與環境。

8.2 認證標誌

當前未啟用。 見 DSHIO/T 32 認證規則（草案，尚未實施）。

在本標準 v1.0 有效期間，不存在「DSHIO 認證」這一狀態。任何聲稱獲得 DSHIO 認證的表述均為虛假。

8.3 引用格式

引用本標準時寫：

DSHIO/T 10—2026 第 5.2.2 條

不要寫：

• DSHIO-DEV（已廢止的舊代號）
• DSHIO 插件標準第 2 條（必須帶標準號）

---

附錄 A（規範性）靜態檢驗清單

按此順序執行，任何 critical 不符合即中止：

---

附錄 B（資料性）常見失敗模式

---

附錄 C（資料性）與其他標準的關係

DSHIO/T 00  术语和定义
      ↓ 引用
DSHIO/T 10  插件标准（本文件）
      ↓ 引用
DSHIO/T 20  测试方法总则 ── 规定每个阶段「做什么」
DSHIO/T 21  测试条件     ── 规定「在什么条件下做」
      ↓ 被引用
DSHIO/T 32  认证规则     ── 规定「怎么判定合规」（未启用）

---

修訂記錄