前言¶
DSH 的理念是「一切皆插件」，社區插件目錄也是獨立站點，不是 DeepSeek 官方應用商店。對使用 DSH 做智能體開發的場景來說，直接給 Agent 一句需求後允許其自由修改，容易出現兩類問題：長會話中任務邊界慢慢漂移，以及 bash、write、edit 這類修改能力在任務完成後仍然可用。
dsh-governed-workflow 試圖把這類流程收斂成更明確的序列：先從公開 GitHub Issue 中讀取任務 authority，只有任務進入 RUNNING 後才允許受保護的修改；任務進入 BLOCKED、COMPLETED 或 REVIEW_PENDING 後再次禁止受保護修改，並把最終驗收留在 Builder Runtime 之外。
這是什麼¶
dsh-governed-workflow 是一個面向 DeepSeek Harness agents 的獨立社區插件，包名爲 dsh-governed-workflow。資料中出現的倉庫地址爲：
https://github.com/zcx369658780/governed-workflow-for-dsh
當前資料未明確標註維護者；倉庫路徑中的 zcx369658780 僅來自 GitHub 地址線索，本文不將其寫成已確認的維護者身份。
已覈實的版本與歸屬信息如下：
- 當前階段：
V0.9 Developer Technical Preview - 已驗證基線：
@deepseek-ai/dsh@0.1.0-rc.6 - 包名：
dsh-governed-workflow - 許可證：
MIT - 本項目不隸屬於 DeepSeek，也不代表 DeepSeek 官方背書
倉庫 slug 是 governed-workflow-for-dsh，包名是 dsh-governed-workflow。本文以資料中出現的包名作爲插件名。
核心功能¶
dsh-governed-workflow 的核心是把 Agent 工作流從“直接修改”改成“先確認 authority，再允許修改，最後進入獨立驗收”。
工作流如下：
GitHub Issue Authority
↓
OBSERVE
↓
ADMIT
↓
RUN
↓
BLOCK / COMPLETE
↓
REVIEW
具體能力包括：
-
GitHub Issue Authority
可選 provider 可以從公開 GitHub Issue 中讀取機器可解析的 authority block。Builder 不應從舊聊天記錄、分支存在或自己的計劃中推斷任務權限。 -
生命週期狀態機
任務按下面順序推進：
AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING → BLOCKED/COMPLETED → REVIEW_PENDING
非法遷移會 fail closed。
- RUNNING-only Mutation Guard
當前受保護的 DSH mutation tools 爲：
bash
write
edit
如果沒有 accepted authority，或任務狀態不是 RUNNING，這些受保護修改動作會被拒絕。
- 模型側治理工具
插件提供兩個模型側工具：
governance_status：只讀狀態查詢governance_transition：受限動作集中的狀態遷移
-
終態凍結
任務進入BLOCKED、COMPLETED或REVIEW_PENDING後，受保護修改會再次被禁止。 -
獨立驗收邊界
Builder 不能自行 ACCEPT、merge、關閉已接受任務，也不能創建或激活後續任務。最終決定留在 Builder Runtime 之外。 -
治理證據
authority 觀察與 lifecycle transition 會被記錄爲受限治理證據，用於審查和回放。
安裝與啓用¶
當前資料沒有確認已發佈的一鍵安裝命令。資料中給出的是 IH-1 候選安裝腳本，並且明確標註該候選尚待獨立驗收；在 IH-1 合併前，該腳本不在 main，因此暫不作爲已發佈的一鍵安裝命令。
候選腳本路徑爲：
scripts/install-dsh-governed-workflow.mjs
候選調用方式爲：
node scripts/install-dsh-governed-workflow.mjs --profile governed --ref <40位 Git commit SHA>
這一步要求顯式提供 DSH profile 和 immutable source ref，不默認安裝浮動的 main。
安裝後執行：
dsh --profile governed --dump-config
這一步用於確認 Governed Workflow 的五個默認組件已經加載。當前候選腳本不會自動啓用可選的 GitHub Issue network-authority bootstrap。
包信息與安裝邊界¶
已覈實的 package.json 字段顯示，該插件聲明瞭以下權限列表：
[
"harness:tool",
"harness:skill",
"harness:guard",
"session:append",
"network:read",
"credentials:none",
"subprocess:none",
"native-code:none"
]
其他已顯示的字段包括：
{
"name": "dsh-governed-workflow",
"version": "0.1.0",
"license": "MIT",
"type": "module",
"dshVersions": ["0.1.0-rc.6"]
}
安裝相關字段爲：
{
"install": {
"mode": "transactional",
"adapter": "profile-bundle",
"failurePolicy": "generation-rollback",
"touchesCurrentBeforeActivation": false
},
"lifecycle": {
"activation": "restart-profile",
"dispose": "unknown"
}
}
需要注意：資料中的 package.json 已截斷，未顯示完整字段，不能據此補全其他配置。README 中出現的 V0.9 Developer Technical Preview 與 package.json 中的 version: 0.1.0 可能表示不同版本體系，本文不將其統一爲同一個版本號。
典型用法¶
經過上面的安裝和配置確認步驟後，工作流大致按以下順序推進：
1、任務 authority 來自公開 GitHub Issue 中的機器可解析 authority block。資料沒有給出 authority block 的具體格式，因此這裏不展開格式細節。
2、任務狀態按 lifecycle 狀態機推進：
AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING
3、只有在 accepted authority 已存在，且狀態爲 RUNNING 時，受保護的 bash、write、edit 才允許執行。否則執行會被拒絕。
4、任務結束後進入終態：
BLOCKED
COMPLETED
REVIEW_PENDING
進入這些狀態後，受保護修改會再次被禁止。
5、驗收發生在 Builder Runtime 之外。Builder 不能自行 ACCEPT、merge、關閉已接受任務，也不能創建或激活後續任務。
適用場景與注意¶
這種流程比自由式 vibe coding 多了 Issue、狀態遷移和 Review 的流程成本，因此會犧牲一部分速度。它更適合需要明確停止條件、審查、回滾和驗收的項目。
更適合：
- 中等及以上規模項目
- 多文件修改
- 長會話任務
- 多階段交付
- 需要運行命令或修改真實代碼的場景
- 上線或數據風險較高的 vibe-coding 項目
- App、後端服務、研究工具、自動化系統和長期維護倉庫
不太適合：
- 一次性小腳本
- 幾分鐘的 throwaway prototype
- 完全可丟棄的實驗
- 治理成本明顯高於收益的場景
使用上需要特別注意：這不是完整 OS sandbox。allowedPaths 文件系統硬隔離、Git 命令語義、GitHub merge/close API 等仍不是 Runtime 強制邊界。插件會以當前 DSH 進程權限運行，因此安裝前應檢查源碼、許可證、權限字段和候選安裝腳本狀態。
鏈接與後續¶
dsh-governed-workflow 的價值在於把 Agent 的任務權限、生命週期和驗收邊界顯式化：先有 authority，再允許 RUNNING 期間的受保護修改，終態凍結後交給獨立驗收。
社區目錄頁 URL 未在已覈實資料中出現，本文不補充未確認鏈接。當前可覈驗的倉庫地址爲：
https://github.com/zcx369658780/governed-workflow-for-dsh
