DSHIO/T 00—2026 術語和定義

---

1 範圍

本標準界定了 DSHIO 標準體系中使用的術語和定義。

本標準適用於 DSHIO 全部標準的編寫、引用與實施。

本標準不規定技術要求，只規定詞的含義。凡 DSHIO 其他標準使用本標準界定的術語，均按本章定義理解。

---

2 規範性引用文件

無。

說明： 本標準是體系的根，不引用任何其他標準。

---

3 術語和定義

3.1 體系與主體

3.1.1

DSHIO DeepSeek Harness Input/Output

本標準體系的發布機構代號。不是官方機構，不是認證機構，是標準的編寫與維護方。

注： DSHIO 不擁有 DeepSeek Harness，不對其行為負責。DSHIO 標準是第三方歸納，不是官方規範。

3.1.2

DSH DeepSeek Harness

本標準體系所規範的宿主程序。以下各版本均指 @deepseek-ai/dsh 這個 npm 包。

注： DSH 名稱含 "DeepSeek"，但其架構與模型解耦 —— 見 3.4.1「模型無關性」。

3.1.3

DSH 版本 DSH version

dsh --version 輸出的字符串，例如 0.2.2-rc.1。

本標準體系中凡涉及版本判定，一律以該命令的輸出為準。

3.1.4

作者 author

開發並發布 DSH 插件的自然人或組織。

3.1.5

使用者 user

安裝並運行 DSH 及其插件的人。

3.1.6

認證 certification

DSHIO 依據標準對某插件作出符合性判定，並公開該判定的行為。

注： 認證不是批准，不是許可，是「在特定條件下測過的公開記錄」。

---

3.2 插件的構成

3.2.1

插件 plugin

向 DSH 提供一項或多項能力的軟件單元。以 npm 包形式分發，通過 cordis.patch.yml 聲明在配置樹中的位置。

判別條件（三條全滿足才是插件）：

1. package.json 含 dsh.bundle.patch 欄位
2. 存在該欄位指向的 patch 文件
3. 該 patch 文件的 insert 列表至少含一個 entry

注： 只有 dsh 欄位但 patch 指向不存在的文件，不算插件 —— 見 3.6.3「畸形插件」。

3.2.2

套件 bundle

一組插件的集合。以 dsh.profile.bundles 列表成員的形式出現。

與插件的區別： 套件本身不提供能力，它只是把多個插件和它們的配置打包。

例： @deepseek-ai/dsh-web-app 是套件，它包含 web 界面、會話管理、工具執行器等一組插件。

3.2.3

工具 tool

插件向模型暴露的可調用函數。以 defineTool() 註冊。

判別條件： 在 ctx.tools.register() 中註冊，且有 name、description、parameters、execute 四個欄位。

3.2.4

服務 service

插件向其他插件提供的可注入能力。以 inject 聲明依賴。

例： dsh-fs 提供文件讀寫服務，dsh-llm 提供模型調用服務。

3.2.5

entry 配置樹中的一個條目

cordis.patch.yml 的 insert 列表中的一項。含 id、name、config、inject 等欄位。

官方 Schema： dsh --dump-config-schema 輸出中的 entry 定義。

3.2.6

patch 配置補丁

一個 YAML 文件，描述對配置樹的插入、覆蓋或禁用操作。DSH 插件的入口補丁文件名約定為 cordis.patch.yml。

---

3.3 運行環境

3.3.1

profile 配置檔

DSH 啟動時載入的一組插件及其配置的集合。對應 $DSH_HOME/profiles/<name>/ 目錄。

出廠 profile： web、headless、sdk、sdk-minimal、acp

注： desktop 是保留名，由 Electron 宿主擁有，CLI 不接受。

3.3.2

配置樹 composed config tree

profile 的所有 patch 層按優先序合成後得到的 entry 列表。用 dsh --dump-config 查看。

3.3.3

層優先序 layer precedence

配置合成的順序。後者覆蓋前者：

1. 各 bundle 的 patch，按 dsh.profile.bundles 顺序
2. profile 的 cordis.patch.yml
3. home 级 $DSH_HOME/cordis.patch.yml
4. --patch 覆盖层

來源： 官方 README 第 42–44 行。

3.3.4

沙箱 sandbox

隔離的容器運行環境，用於在不影響宿主的情況下安裝與運行插件。

本標準體系中的沙箱必須滿足：

• 與宿主隔離
• 可限制 CPU、內存、網絡
• 每次測試後銷毀

---

3.4 模型相關性

3.4.1

模型無關性 model agnosticism

DSH 的核心能力（安裝、掛載、啟動、工具註冊）不依賴具體模型的性質。

依據： 模型接入由獨立插件提供（dsh-llm-deepseek、dsh-llm-pi-ai 等），不在 harness 核心內。

意涵： 一個插件在 DeepSeek 模型下能裝上，換成其他模型也能裝上。安裝性與模型無關。

3.4.2

模型相關要求 model-dependent requirement

其結果取決於所用模型的要求。典型為：

• 工具調用可靠性
• 提示詞兼容性
• token 成本

本標準體系中，凡模型相關要求，判定結論必須註明所用模型。

3.4.3

模型接入插件 model adapter

把某個模型提供商接入 DSH 的插件。命名約定 dsh-llm-<provider>。

例： dsh-llm-deepseek、dsh-llm-pi-ai

---

3.5 測試與判定

3.5.1

測試階段 test stage

插件測試中的一個獨立檢查環節。本標準體系定義六個階段：

T0–T4 為模型無關階段；T5 為模型相關階段。

3.5.2

測試條件 test condition

影響測試結果的外部因素集合。包括但不限於 DSH 版本、容器鏡像、資源限制、網絡狀態、超時設置。

完整清單見 DSHIO/T 21。

3.5.3

判定 verdict

對一次測試的結論。本標準體系定義五種：

注： 判定只覆蓋到失敗的那個階段，後續階段不執行。

3.5.4

可複現性 reproducibility

在相同測試條件下重複執行，得到相同判定的性質。

本標準體系要求： 任何對外發布的判定，必須至少執行兩次且結果一致。

3.5.5

首次錯誤 first error

判定失敗時，測試輸出中第一條能定位失敗原因的非空行。

用途： 給作者修復線索，不用於判定本身。

---

3.6 符合性

3.6.1

符合 conforming

滿足某標準全部強制性條款的狀態。

判定主體： 認證機構（當前為 DSHIO 自身）。 判定依據： 該標準的技術要求與試驗方法。

3.6.2

不符合 non-conforming

不滿足某標準一條或多條強制性條款的狀態。

必須註明： 不符合哪一條、在什麼條件下、什麼測試中發現。

3.6.3

畸形插件 malformed plugin

滿足「插件」的部分特徵但無法完成安裝的包。典型情形：

• 有 dsh.bundle.patch 但文件不存在
• patch 文件 YAML 語法錯誤
• insert 列表為空

判別： T0 靜態檢查即可識別，不需要進入 T1。

3.6.4

例外 exception

標準要求與實際情況衝突時，經公開登記的偏離。

例外必須包含： 偏離哪一條、為什麼、影響範圍、有效期。

未登記的偏離不是例外，是不符合。

3.6.5

參照實現 reference implementation

第一個按某標準完整實現並通過全部條款的實例。

用途： 證明標準可執行。

規則： 標準發布前必須有參照實現。無參照實現的標準不得從「草案」轉為「現行」。

---

3.7 安全與權限

3.7.1

權限聲明 declared capability

插件在 manifest 中聲明的所需能力。

本標準體系使用的能力標識：

fs-read、fs-write、network、shell、credentials、dynamic-code、llm、env

3.7.2

紅線 red line

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

當前定義： network 與（shell 或 filesystem 寫權限）同時出現 → 構成資料外洩路徑。

3.7.3

風險等級 risk level

對插件權限組合的風險歸類。本標準體系使用三級：low、medium、high。

判定方法見 DSHIO/T 24。

---

4 縮略語

---

附錄 A（規範性）多語言術語對照

本附錄是強制性的。 各標準的譯文必須使用本表譯法。

---

附錄 B（資料性）被取代的術語

本標準體系早期使用、現已廢止的表述：

---

修訂記錄