前言¶
DeepSeek Harness（DSH）已經具備模型路由、子 Agent、工具權限、審批、Session 日誌和後臺 jobs 等執行原語。實際開發中，團隊往往仍要在每輪會話裏重新描述如何拆任務、並行執行、驗證結果並彙總——策略難以複用，中斷後通常只能從頭重來，並行結果也散落在對話裏。
omdsh-dev/dsh_workflow（包名 @dsh-external/workflow）針對的正是這一層缺口：在 DSH 原生 workflow 工具之上，增加命名、發現、生成、複用、暫停/恢復、重跑/續跑、持久證據、成本記錄和治理等流程產品能力。它不替換 DSH 已有的一次性並行調度，而是把多 Agent 編排沉澱爲可審計、可分享、可演進的工程資產。
這是什麼¶
@dsh-external/workflow 是一個官方 bundle 形態、零核心 patch 的 DSH 插件，由 omdsh-dev 維護，在 SkillHub 社區目錄中歸類爲「工作流」。插件完整參考 KodaX 的 workflow 設計能力，並針對 DSH 的 Cordis、ctx.subagents、Session、後臺 jobs、審批、命令和工具機制做獨立實現。
許可證爲 MIT。README 標註兼容 DSH 0.0.1-rc.2，插件當前版本 0.1.2，測試套件 179 項通過。
核心功能¶
執行模型¶
下面介紹插件與 KodaX workflow 對標的執行能力。
- 版本化
dsh.workflowv1 capsule，包含 manifest、source、intent、inputs、requires、provenance。 - 統一
async function run(wf, args)入口，提供完整 WorkflowApi：phase、spawnAgent、runAgent、wait、snapshot/output、send/stop、parallel、pipeline、synthesize、單層嵌套 workflow、artifact、log、budget。 - 六個標準 pattern：classify-and-act、fan-out-and-synthesize、adversarial-verification、generate-and-filter、tournament、loop-until-done。
- 兩個內置 workflow：
parallel-investigation（可按 rubric/agent/concurrency 參數化）和scoped-review（含 packet/schema/read-contract/雙 primary/逐 finding verifier/audit artifact）。
發現與複用¶
workflow 搜索順序是確定性的：
- 插件內置 workflow 與 pattern（不可被磁盤文件遮蔽）；
- 項目目錄
.dsh/workflows； - 個人目錄
$DSH_HOME/workflows。
項目同名條目覆蓋個人條目；同一目錄中 .workflow.json 優先於 .ts/.mjs/.js。
生命週期與持久化¶
每個 run 有 running → paused/completed/failed/denied/stopped 狀態和穩定 id，默認寫入項目目錄：
.dsh/workflow-runs/<run-id>/
├── run.json # 狀態、結果摘要、成本
├── events.jsonl # append-only 事件圖
├── workflow.workflow.json # 不可變執行快照
├── results/ # 確定性 effect cache
└── artifacts/ # workflow 命名證據
支持按 run id 重跑（使用不可變 capsule snapshot）、按 saved name 重跑（使用當前保存版本），以及 resume-run（相同調用序號與 task input 命中緩存，其餘任務繼續執行）。
安全與治理¶
- 生成型腳本運行在 QuickJS WebAssembly 獨立堆中，只能通過凍結的 WorkflowApi 發起 effect，靜態 policy 拒絕 import/require、process、文件、shell、網絡等非確定性 API。
- manifest + preflight + 運行時硬限制管控 provider/模型/併發/預算。
approvalMode支持never | generated-and-local | always三級審批。
安裝與啓用¶
要求 Node.js >=22.19，以及與插件 compatibility.json 一致的 DSH 快照。
先做插件安裝，再驗證 profile 合成樹：
# 構建產物已提交，git 源安裝不需要在用戶側編譯
dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
# 驗證 bundle 已進入 profile 合成樹
dsh --profile web --dump-config
預期配置中出現：
- id: dsh-external-workflow
name: '@dsh-external/workflow'
重啓對應 DSH profile 後生效。安裝前建議閱讀 GitHub 倉庫 源碼與 MIT 許可證，確認以當前 DSH 進程權限運行是否符合團隊安全要求。
典型用法¶
重啓 profile 後，在會話中可直接使用斜槓命令：
/workflow list
/workflow parallel-investigation {"question":"爲什麼這個測試會間歇失敗？"}
/workflow create 爲這個倉庫設計一個並行安全評審流程
/workflow review --risk high --requirement "不得破壞公開 API" --test-evidence "pnpm test 通過" --wait
/workflow runs
workflow 啓動默認立即返回 { runId, status, jobId? }，不會佔住當前 turn。需要同步等待終態時，對命名 workflow、rerun、review 傳入 --wait。
模型也可調用三個工具：
workflow_list：發現 built-in、pattern、項目和個人 workflow。run_workflow：運行命名 workflow、從自然語言 scout-then-author，或執行受限 inline workflow。workflow_manage：查看、暫停、恢復、停止、重跑、續跑、保存、改名、修訂、刪除和清理。
常用管理命令：
/workflow help
/workflow show [--full] [runId]
/workflow pause|resume|stop [runId]
/workflow rerun|resume-run <runId|savedName> [JSON args] [--wait]
/workflow save <runId> <name> [project|personal]
/workflow prune [--dry-run] [--keep N] [--older-than 7d|24h]
常見配置片段如下，完整字段見倉庫 docs/CONFIGURATION.md：
- id: dsh-external-workflow
name: '@dsh-external/workflow'
config:
approvalMode: generated-and-local
maxAgents: 64
maxConcurrency: 8
maxRetainedRuns: 500
適用場景與注意¶
適合誰
- 需要把多 Agent 並行調查、代碼評審、任務拆解等流程固化爲可複用資產的個人開發者或團隊。
- 已在 DSH 上使用子 Agent 和後臺 jobs，希望補齊命名、持久化、續跑和成本記錄的團隊。
- 需要對標 KodaX workflow 行爲、在 DSH 生態內獨立實現同等能力的集成方。
使用注意
- 插件以當前 DSH 進程權限運行；trusted-local workflow 具有 Node 宿主權限，不要把不可信第三方源碼標爲 trusted-local。
- 它不替換 DSH 原生前臺
workflow工具——原生工具適合「這一次把若干工作並行跑完」，本插件負責更高一層的流程產品能力。 create和自由文本形式的/workflow <自然語言請求>由當前 Agent turn 接管 authoring，不接受--wait。- 當前 DSH 通用 subagent seam 不直接支持 existing-agent target、per-agent effort 和 worktree；相應請求需部署註冊 adapter，未註冊時會明確失敗。
結語¶
經過上面的步驟，omdsh-dev/dsh_workflow 把 DSH 已有 Harness 能力串成完整閉環：從一次性多 Agent 調度，升級爲可生成、可保存、可治理、可觀察、可恢復的 Workflow 層。
- SkillHub 目錄頁：omdsh-dev/dsh_workflow
- GitHub 倉庫：github.com/omdsh-dev/dsh_workflow
