前言¶

用 DSH 跑 agent 的人大概都遇到過一類問題：模型信誓旦旦地說「我記得這部分上下文」「計劃已經定好了」「benchmark 通過了」「這次 release 沒問題」，但你找不到它得出結論的依據。它只是斷言，沒有證據。

現有的做法通常是在系統提示里加幾句「請謹慎、請說明依據」，或者爲每個場景單獨裝一個 skill 包。前者約束很弱，後者讓同一套紀律散落在五個包裏，各自要裝一次、各自在索引裏佔一個位置。

dsh-ops-kit 是維護者 YaoleWu 提交到 SkillHub 社區目錄的插件，分類爲工作流，目前 2 個 star。它把紀律壓成一句話：在 agent 說「我記得」「計劃可行」「基準通過」「發佈安全」之前，它應該能指出證據。 五個只讀 skill pack 共享這套原則，同時附帶一個運行時 doctor，用來檢查官方 PTY prompt handshake 的兼容性。

定位¶

一句話：dsh-ops-kit 是 DeepSeek Harness 的只讀能力包，把記憶檢索、編排規劃、agent loop 規則、基準結果門禁和發佈檢查清單打包在一起，給 agent 提供「計劃、檢查和證據詞彙」，而不替它執行有副作用的操作。

它明確不做這些事：不悄悄建 issue、不調遠程 API、不啓動 benchmark、不改倉庫、不讀憑據。所有帶副作用的動作都留在包外，成爲一次顯式、可審查的操作。

順帶一提「只讀」的判斷依據：清單裏的工具一側只有 Git-first memory 和 repository audit 標註爲 Read-only，其餘標註爲 None（無副作用）；包本身不下載憑據、不注入運行輸出，也不包含機器相關的配置。

核心能力¶

插件註冊了八個工具，按能力包劃分如下。

Capability pack                    工具                         作用                                   副作用
Capability index                   dsh_ops_capability_catalog   列出包含的能力包                         無
Evidence-based orchestration       dsh_ops_workflow_plan        產出 scope → baseline → context →
                                                                    execute → verify → handoff 計劃      無
Skill reference                    dsh_ops_skill_read           讀取包內完整的 skill 定義                無
Git-first memory                   dsh_ops_memory_search        在限定的本地 Markdown / 代碼根目錄下
                                                                    檢索先前上下文，帶來源出處            只讀
Repository audit                   dsh_ops_repository_audit     審計 Git 乾淨度、未跟蹤文件、
                                                                    憑據路徑衛生                        只讀
Release hygiene                    dsh_ops_release_checklist    產出完整的 DSH 插件發佈檢查清單         無
Release verification               dsh_ops_plugin_doctor        按清單逐項覈查插件倉庫的可安裝性與
                                                                    可發佈性                            只讀
Runtime health                     dsh_ops_runtime_doctor       檢查官方 terminal / persistent-bash
                                                                    prompt 兼容性                       只讀

三個設計上的取捨值得單獨說。

第一，編排規則不做成獨立工具。leader-only dispatch、共享 worktree 的協調、運行時歸屬、清理證據這幾項 agent loop 規則，以及基準門禁的 manifest、precheck、產物清單、結果完整性檢查，都內嵌在 workflow-plan 和 release-checklist 兩個 skill 裏。

第二，清單和核查是分開的兩個工具。dsh_ops_release_checklist 說「發佈需要什麼」，dsh_ops_plugin_doctor 用它去量「實際上做到了沒有」。README 裏的解釋是，一條沒人覈查的清單，就是一個啓動套件打印 SKIPPED 然後 exit 0、CI 變綠而集成檢查根本沒跑的坑，也是一個插件長期停在 "private": true、根本無法發佈的問題。

第三，doctor 只檢查不修改。它覈對 dsh.bundle 加 cordis.patch.yml 能否安裝、patch 行與包名是否對應、private / files / exports 是否可發佈、@deepseek-ai/* 是否保持爲 peer、以及啓動套件是否打印 SKIPPED 後 exit 0。它自己從不編輯 node_modules。

安裝與啓用¶

安裝走 registry，不需要構建步驟，也不需要 allowBuilds 審批。

dsh plugin --profile <profile> add dsh-ops-kit

如果希望手工編輯 profile manifest，等價寫法如下。

// ~/.dsh/profiles/<profile>/package.json
{
  "dependencies": {
    "dsh-ops-kit": "^0.1.0"
  },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-ops-kit"]
    }
  }
}

改完之後對該 profile 重新安裝依賴並重啓。

包的版本號是 0.1.1，許可證爲 MIT，Node 要求 >=22.19.0，@deepseek-ai/cordis、@deepseek-ai/dsh-skill、@deepseek-ai/dsh-tools 聲明爲 peer dependencies。包內還帶了一個受保護的 dsh-terminal-hotfix 命令，只在精確佈局匹配後修補官方 rc.6 的編譯入口，改動前生成帶時間戳的備份，改完驗證 prompt handshake：

dsh-terminal-hotfix --check
dsh-terminal-hotfix --apply

應用後需要重啓 DSH。該命令不會被插件加載器自動執行，也不會靜默改動依賴。

配置本地檢索根目錄¶

dsh_ops_memory_search 和 dsh_ops_repository_audit 需要限定可檢查的目錄。根目錄要儘量窄，且絕不指向憑據目錄。

# example overlay; adapt to the profile's configuration format
- id: dsh-ops-kit
  config:
    roots:
      - /workspace/project
      - /workspace/memory
    maxFiles: 120
    maxBytesPerFile: 160000

如果不配置 roots，工具默認使用 DSH 進程的當前工作目錄。憑據類路徑和常見的 run/secret 目錄會被拒絕或跳過。

典型用法與驗證¶

裝好之後的驗證鏈路如下，按這個順序走一遍。

pnpm install --offline --ignore-scripts
pnpm build
pnpm typecheck
pnpm test

在真實 profile 裏裝好後，README 建議逐項確認：DSH endpoint 返回 HTTP 200、profile 重啓後仍在運行、包內 skill 被列出、dsh_ops_capability_catalog 返回全部能力包、dsh_ops_runtime_doctor 狀態健康。

如果 doctor 報告 terminal-prompt-mismatch，先用 dsh-terminal-hotfix --check 確認，再決定是否應用可回滾的修補。

適用場景與注意事項¶

適合這類人：已經在用 DSH 跑多步研究、多 agent 協作、基準測試或插件發佈流程，並且希望 agent 在關鍵節點停下來給證據而不是直接給結論。插件裏的方案偏保守，如果你需要的是激進自動執行，它不合適。

三點必須說清楚。

第一，插件以當前 DSH 進程的權限運行。安裝前先自己審一遍源碼和許可證。許可證是 MIT，README 聲明這是從通用工程實踐提煉的獨立集成層，不是任何內部倉庫的副本，包內不含憑據、私有數據、運行輸出或機器相關配置。

第二，README 內嵌的 package.json 片段裏，repository / bugs / homepage 三個字段寫的是 LeslieWylie/dsh-ops-kit，與社區目錄頁記錄的維護者 YaoleWu 不一致。files 字段裏列出的 README.zh.md 也沒有在本 README 導航中明確給出鏈接。這類字段與倉庫歸屬的出入，裝之前應以實際倉庫爲準。

第三，SkillHub 是獨立站點，與 DeepSeek / 幻方沒有官方從屬關係，不是官方應用商店。上面的 star 數和分類來自該目錄頁的記錄。

小結¶

dsh-ops-kit 的價值不在多，在於把同一條紀律——結論要有證據——攤到記憶、編排、benchmark、發佈四個環節裏，並且讓 agent 的每一步都落在可審查的只讀檢查上。如果你在 DSH 裏跑的流程已經有「看起來對但沒人驗證」的風險，可以從 dsh_ops_capability_catalog 和 dsh_ops_runtime_doctor 兩個工具開始，它們不帶副作用，能先告訴你這個包裝了什麼、運行時是否健康。

目錄頁：https://www.skillhub.cn/plugins/YaoleWu/dsh-ops-kit
倉庫：https://github.com/YaoleWu/dsh-ops-kit