用 dsh_workflow 把 DSH 的一次性多 Agent 調度做成可恢復工作流

DeepSeek Harness 插件 DeepSeek DSH dsh_workflow 工作流自動化 多Agent 2026-08-17 76 閱讀

前言

DeepSeek Harness（以下簡稱 DSH）把模型路由、子 Agent、工具權限、審批、Session 日誌和後臺 jobs 都做成了可替換的插件能力。官方倉庫 deepseek-ai/deepseek-harness 的口號就是「一切皆插件」：不改內核，也能在配置層掛上新能力。

真正跑複雜任務時，缺口往往不在「能不能再起幾個 Agent」，而在流程本身。並行調查、分區評審、對抗驗證這類工作，如果每次都在當前會話裏重新描述怎麼拆、怎麼併發、怎麼彙總，策略很難複用；中途斷開後，結果散落在對話裏，通常只能從頭再來。DSH 自帶的前臺 workflow 工具適合「這一次把若干工作並行跑完」，但還不是一份可以命名、保存、審計和續跑的工程資產。

社區插件 dsh_workflow 做的就是這一層。本文按社區目錄頁、GitHub README、package.json 和許可證交叉覈對後整理：它是什麼、裝完能幹什麼、命令怎麼寫，以及安裝前必須看清的權限邊界。社區插件目錄是獨立站點，和 DeepSeek / 幻方沒有官方從屬關係，不要把它當成官方應用商店。

這是什麼

dsh_workflow 是一款面向 DSH 的工作流與自動化插件。社區目錄標註維護者爲 icetomoyo，許可證爲 MIT，主要語言是 TypeScript。npm 包名是 @dsh-external/workflow，掛進 profile 後的插件 id 爲 dsh-external-workflow。當前發佈版本是 0.1.2（2026-08-13）。截至 2026 年 8 月 17 日，GitHub 顯示 63 顆星。

倉庫簡介和目錄頁用同一句話概括它的目標：把 Claude Code 的 UltraCode 模式帶給 DSH，把一次性多 Agent 調度升級爲可生成、可保存、可治理、可觀察、可恢復的 Workflow 層。Claude Code 文檔裏，UltraCode 會爲實質任務自動寫編排腳本、扇出子 Agent；dsh_workflow 在 DSH 裏補的是更靠後的產品能力，而不是把 Claude Code 原樣搬過來。README 寫明：實現完整參考 KodaX 的 workflow 行爲，並針對 DSH 的 Cordis、ctx.subagents、Session、後臺 jobs、審批、命令和工具機制做獨立實現，不復制 KodaX 的受限許可源碼。

它明確不替換 DSH 已有的前臺 workflow 工具。原生工具繼續負責單次並行；本插件負責更高一層：按名字發現和運行、現場生成、暫停/恢復、按快照重跑或按緩存續跑、把 run graph / 事件 / artifact / 成本永久落盤。README 裏的「官方 bundle 形態、零核心 patch」指的是按 DSH 插件 bundle 方式掛載、不改 Harness 源碼，不是 DeepSeek 官方出品。

GitHub 上 icetomoyo/dsh_workflow、dsh-external/dsh_workflow 目前會解析到同一倉庫（組織 omdsh-dev 下的 dsh_workflow）。安裝時仍以目錄頁給出的命令爲準。

核心功能

一次性調度和可複用工作流的差別

DSH 已經有執行原語，缺的是把這些原語收成可維護的流程。倉庫 README 用對照表說明安裝前後的變化，核心差別可以收成這幾條：

  • 拆任務的策略不再每輪重寫，而是保存爲項目或個人 workflow，按名字運行。
  • 並行結果不再只留在會話氣泡裏，而是寫入 run graph、事件流、artifact、結果摘要和成本記錄。
  • 中斷後可以按 run 快照重跑，或用 effect cache 續跑未完成部分，不必整段推倒。
  • provider、模型檔位、併發和預算不再只靠提示詞約束，而是走 manifest、preflight 和運行時硬限制。
  • 生成出來的腳本默認跑在 capability-only 的 QuickJS WebAssembly 隔離堆裏，通過 JSON 邊界和審批分級收權。

對 DSH 項目來說，效果是：多 Agent 從「這一次的技巧」變成可以審計、分享和演進的工程資產。

膠囊、內置流程和六種模式

執行單元是版本化的 dsh.workflow v1 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。

倉庫目前帶兩個內置流程：

  • parallel-investigation：可按 rubric、agent、concurrency 參數化的並行調研。
  • scoped-review：帶 packet / schema / read-contract、雙 primary、逐 finding verifier 和 audit artifact 的分區評審。/workflow review 可以直接捕獲當前 Git 範圍並啓動它，不需要給 DSH 核心打 /review 補丁。

另外還有六個標準 pattern：classify-and-act、fan-out-and-synthesize、adversarial-verification、generate-and-filter、tournament、loop-until-done。Agent 側可以指定 phase、scope、只讀、provider / 子 Agent 類型，以及 fast | balanced | deep 三檔路由。

發現順序是確定的，不會「碰巧讀到另一份同名文件」：

  1. 插件內置 workflow 與 pattern（磁盤文件不能遮蔽）
  2. 項目目錄 .dsh/workflows
  3. 個人目錄 $DSH_HOME/workflows

項目同名條目覆蓋個人條目；同一目錄裏 .workflow.json 優先於 .ts/.mjs/.js。符號鏈接、路徑逃逸、超大文件、未知 capsule 字段、版本不兼容、manifest 和文件名不一致，都會在執行前失敗。

生命週期、落盤和續跑

每個 run 都有穩定 id，狀態在 running → paused/completed/failed/denied/stopped 之間切換。默認寫入項目目錄：

.dsh/workflow-runs/<run-id>/
├── run.json                    # 狀態、結果摘要、成本
├── events.jsonl                # 只追加的事件圖
├── workflow.workflow.json      # 生成型 workflow 的不可變執行快照
├── results/                    # 已完成且驗證通過的 effect cache
└── artifacts/                  # workflow 命名證據

按 run id 重跑用的是該次不可變 snapshot；按已保存名字重跑用的是當前保存版本。resume-run 在相同調用序號和相同 task input 上命中緩存，其餘任務繼續執行。終態 run 會按 maxRetainedRuns 自動清理，也可以用 prune 預覽或執行清理。

斜槓命令、模型工具和後臺 jobs 走同一套引擎、run store 和安全策略。workflow 啓動和 run_workflow 默認立刻返回 { runId, status, jobId? }，長流程不會佔住當前 turn；需要同步等到終態時，再顯式加 --wait 或 wait: true。

安裝與啓用

社區目錄頁給出的安裝命令如下，在 DeepSeek Harness 終端裏運行即可：

dsh plugin add github:icetomoyo/dsh_workflow

目錄頁同時提示：如需可復現安裝，請固定 commit 哈希。當前 main 最新提交是 44b83c182aa02d1be8a0803e8446cb495f93cd8f（作者 icetomoyo，2026-08-13），可以寫成：

dsh plugin add github:icetomoyo/dsh_workflow#44b83c182aa02d1be8a0803e8446cb495f93cd8f

GitHub README 額外給出了掛到 web profile 的寫法，並說明構建產物已經提交，git 源安裝不需要在用戶側編譯：

dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
dsh --profile web --dump-config

驗證時，配置裏應出現：

- id: dsh-external-workflow
  name: '@dsh-external/workflow'

改完 profile 後需要重啓對應 DSH 進程。運行要求來自 README 和 package.json：Node.js >=22.19（package.json 寫的是 ^22.19.0 || >=24.0.0），以及與倉庫 compatibility.json 一致的 DSH 快照。該文件當前記錄的兼容基線是 DSH 0.0.1-rc.2，測試時間 2026-08-13。

插件以當前 dsh 進程的權限運行，安裝時可能執行代碼。安裝前請檢查源代碼倉庫和許可證。

典型用法

重啓對應 profile 後，README 建議先在會話裏跑這組命令：

/workflow list
/workflow parallel-investigation {"question":"爲什麼這個測試會間歇失敗？"}
/workflow create 爲這個倉庫設計一個並行安全評審流程
/workflow review --risk high --requirement "不得破壞公開 API" --test-evidence "pnpm test 通過" --wait
/workflow runs

/workflow list 會列出內置、pattern、項目和個人 workflow；無效條目會報告，但不會執行。/workflow <name> [JSON args] 按名字啓動已保存流程。/workflow show 默認看最新 run，/workflow stop 默認停當前活動 run。

/workflow create <request> 以及未知名稱的 /workflow <自然語言請求> 不會把斜槓命令卡在 command/run 上。它們會立刻結束命令處理，把原始用戶問題作爲真正的 user message 交給當前主 Agent；內部的編寫約定則以摺疊的 plugin context 交給模型，避免污染會話標題。主 Agent 先用自身工具調查 workspace，再以 source + manifest 調用 run_workflow 生成並啓動流程。這條路徑不接受 --wait；需要同步等待時，請對命名 workflow、rerun 或 review 使用 --wait。

倉庫還提供受限 capsule 示例 examples/review.workflow.json。它聲明 readOnly: true，按 implementation / tests / docs 這類獨立 scope 做 fan-out，再走 verifier 和 synthesize，適合對照 capsule 字段看一遍，而不是直接當生產流程複製。

模型側對應三個工具：

  • workflow_list：發現可用 workflow
  • run_workflow：運行命名流程、從自然語言 scout-then-author，或執行受限 inline workflow
  • workflow_manage：查看、暫停、恢復、停止、重跑、續跑、保存、改名、修訂、刪除和清理

常用治理命令還包括：

/workflow help
/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]

斜槓命令通過 ctx.userQuestions 做一次性人類確認；模型工具使用當前 turn 的 ctx.approval。後臺運行會盡量註冊到 ctx.jobs，同時始終保留插件自己的 durable run id。

如果用的是 DSH Web，左側工作區在「手動排序」且會話數超過 5 條時會摺疊其餘會話。新 workflow 會話已經歸屬對應工作區，必要時點「展開其餘 N 個會話」，或把視圖改成「最近更新」。

適用場景與注意事項

比較適合這些情況：

  • 需要把並行調研、分區評審、對抗驗證做成可複用流程，而不是每次在對話裏重寫拆解方式
  • 希望 run 有穩定 id、事件圖和成本記錄，中斷後能重跑或續跑
  • 團隊要把多 Agent 策略當成項目資產放進 .dsh/workflows，而不是隻留在某個人的會話裏

不適合把它當成 DSH 原生 workflow 工具的替代品。單次把幾項工作並行跑完，繼續用前臺工具即可。也不要指望它自動補齊當前 DSH 子 Agent 接口裏還沒有的能力：README 寫明，通用 subagent seam 目前不直接支持 existing-agent target、per-agent effort 和 worktree；這些請求需要部署側註冊 adapter，未註冊時會明確失敗，而不是悄悄降級。

還需要記住這些邊界：

  • 生成型腳本只能通過凍結的 WorkflowApi 產生副作用，運行在獨立的 QuickJS WebAssembly 堆中；import/require、process、文件、shell、網絡、timer 和非確定性 API 會被靜態拒絕。它仍然是進程內組件，不是操作系統級容器。
  • 項目或個人目錄裏的可信本地模塊（.ts/.mjs/.js）以 Node 宿主權限執行，每次都要顯式確認。不要把未審查的第三方源碼標成 trusted-local。
  • 只有生成型 capsule run 會保存不可變 script snapshot；純函數的 trusted-package / local run 不能從 run id 再保存。
  • dsh.workflow v1 與 KodaX capsule 不做協議兼容，外部 capsule 不會被誤執行。
  • 內建 verification 覆蓋實際 read/mutation 工具證據、Git workspace 變化、required path 前後指紋和文本後置條件；非 Git 工作區或需要外部權威證據時，要自己註冊 verification adapter。

常見配置項（完整字段見倉庫 docs/CONFIGURATION.md）包括 approvalMode（never | generated-and-local | always，README 示例默認 generated-and-local）、maxAgents、maxConcurrency、maxRetainedRuns，以及 fast / balanced / deep 三檔的 provider 與 token 上限。workflow 聲明的 requirement 不在部署能力清單裏時會直接失敗，不會偷偷降級。

再次強調：插件以當前 dsh 進程的權限運行，安裝時可能執行代碼。安裝前檢查源代碼和 MIT 許可證；需要可復現環境時，固定 commit，並覈對 compatibility.json 裏的 DSH 快照。

小結

dsh_workflow 沒有另起一套和 DSH 平行的編排內核，而是把已經存在的 provider、子 Agent、審批、Session 和 jobs 收成可命名、可落盤、可續跑的工作流層。對經常要把多 Agent 跑法沉澱下來的人來說，它補的是「流程產品」而不是「再多一個並行開關」。

目錄頁：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh_workflow/

GitHub：https://github.com/icetomoyo/dsh_workflow

相關文章

快速從零部署一個DeepSeek-R1服務 2025-04-05 使用 dsh-anchored-standard 爲 DeepSeek Harness 配置兩階段 Agent 預設 2026-08-17 用 dsh-web-ui 把 DeepSeek Harness 網頁界面補成工作臺 2026-08-17 用 modlens 給 DeepSeek Harness 的純文本模型補上視覺 2026-08-17 用 dsh-TUI 給 DeepSeek Harness 補上全屏終端界面 2026-08-17
羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜