前言¶
在 DeepSeek Harness（DSH）裏做多輪 Agent 協作時，常見做法是讓不同角色輪流在對話裏接話，或由開發者手工編排每一步交接。這樣缺少明確的流程約束：審查有沒有真正擋在合併前、測試失敗後會不會仍沿「通過」路徑推進，往往依賴臨場記憶或額外提示詞。dsh-agent-team-workflow（倉庫 huaComPj/dsh-workflow-plugin）把「Manager 協調 → 角色分工執行 → 獨立 Judge 覈驗 → 再進入下一節點」做成可配置的串行工作流，並支持可視化編輯與 YAML 持久化，讓團隊按節點交付，而不只是輪流回答。
這是什麼¶
該插件由社區維護者 huaComPj 發佈，分類爲工作流，npm 包名爲 dsh-agent-team-workflow，當前資料中的版本爲 0.2.1-rc.2，許可證爲 MIT。它爲 DeepSeek Harness 提供可配置的串行團隊工作流：Manager 協調任務，按角色安排開發、審查、測試等 Actor 分工執行，獨立 Judge 根據節點驗收條件覈驗結果，未通過則不能沿通過路徑繼續。
工作流按節點串行推進，不是並行任務調度器；覈驗能約束流程，但不保證模型輸出絕對正確。恢復或終止流程不會撤銷已發生的文件修改、推送或合併。
核心功能¶
下面介紹 README 中已明確列出的能力。
角色分工與獨立覈驗。 按流程安排各角色；Judge 根據當前節點的驗收條件覈驗結果，未通過就不能沿通過路徑推進。
可視化配置。 在畫布上編輯節點、結果分支、角色屬性和子流程，保存爲 YAML；工作流可複用，也可按項目調整。
按角色選擇模型。 默認繼承 Manager 的模型，也可爲不同角色和 Judge 單獨配置模型與思考檔位。
在對話中啓動。 通過「啓動工作流」彈窗或 /dsh-flow start 提交任務，不必手工協調每輪交接。
進度可見、異常可處理。 可查看當前節點、Actor / Judge、執行記錄和 BLOCK 原因；補充信息或處理障礙後可恢復推進。安裝提供 betterSidebar 服務的配套側欄後，還可打開「工作流監控」。
安裝與啓用¶
需要 Node.js ≥ 22.19（推薦 Node.js 24）、DSH ≥ 0.2.1-rc.2，以及可用的 dsh、pnpm 命令。安裝已發佈版本時無需克隆插件源碼或自行構建。
已有 DSH 實例時，應先結束活動任務並停止對應實例；安裝後啓動或重啓 Web 並刷新瀏覽器。已有開發版時避免與 npm 版重複加載；使用自定義 DSH_HOME 時全程保持一致。
1. 安裝插件¶
這一步從 npm 安裝指定候選版本並啓動 DSH Web：
dsh plugin --profile web add dsh-agent-team-workflow@0.2.1-rc.2
dsh web
2. 初始化默認工作流¶
在已加載插件的 DSH 對話中執行。先用 --dry-run 預覽，再正式初始化：
/dsh-flow init --dry-run
/dsh-flow init
經過上面的步驟，會安裝 通用 Manager preset 和 development-workflow 示例工作流。已有不同內容時默認跳過，不覆蓋自定義配置，也不刪除其他模板。
3. 選擇 Manager 並準備環境¶
重啓 DSH 後，選擇 團隊工作流 Manager（通用） 新建會話，把工作目錄設爲目標項目，併爲 Manager 配置可用模型。默認模板的開發、審查、測試角色及 Judge 均繼承該模型。
默認示例圍繞 GitHub Issue / PR 工作，運行前需具備 Git、可用的 GitHub 訪問工具（如 gh CLI）和倉庫權限；它會創建 Issue、任務分支，提交、推送並創建 PR，需先獲得相關操作授權，合併另經用戶確認。若只允許只讀操作，應先調整模板，不要直接啓動完整交付流程。
典型用法¶
普通安裝只初始化通用開發流程；複雜流程見倉庫內進階配置示例，不是默認自動安裝項。
檢查與啓動任務¶
先列出工作流、檢查配置（check 只檢查配置，不發送真實模型推理請求），再啓動任務：
/dsh-flow list
/dsh-flow check development-workflow
/dsh-flow start development-workflow 修復指定問題，並完成審查和測試
也可在輸入區點擊「啓動工作流」，選擇配置並描述任務。啓動後用 /dsh-flow status 查看進度。
默認五節點開發流程¶
init 安裝的 development-workflow 是單倉庫、單 Issue、單 PR 流程，節點順序爲：
澄清需求並建 Issue → 開發實現 → 獨立審查 → 獨立測試 → 人工確認後合併
Manager 負責澄清需求、記錄驗收標準，並在最後向用戶確認具體合併候選；開發、審查和測試由相應角色執行，各節點結果還需 Judge 覈驗。審查或測試發現必修問題，或候選修訂發生變化時，會回到實現並重新走審查、測試。最後取得用戶明確確認後，以 squash 合併並覈驗結果、關閉關聯 Issue；默認模板不部署、不發佈、不刪除分支。
更完整的操作可跟隨倉庫文檔 默認工作流任務示例；配置細節見 默認模板源碼 與 模板與配置說明。
適用場景與注意¶
| 場景 | 使用方式 |
|---|---|
| 單倉庫修復 Bug、實現小功能或重構 | 使用默認開發流程，圍繞一個 Issue / PR 完成實現、審查、測試與合併 |
| 補測試、修改文檔等需要獨立檢查的任務 | 使用默認流程，在 Issue 中寫清楚適用檢查與驗收標準 |
| 多個任務按里程碑交付 | 按需採用進階模板，組織拆票、逐票交付和集成驗收 |
| 前後端等跨倉庫聯動 | 按需採用多倉庫模板，並明確各倉庫、分支與操作授權 |
權限與安全。 插件在當前 DSH 進程權限下運行；實際執行會調用模型，並可能執行已獲准的本地或遠端操作（如 git push、gh 等）。安裝與啓用前宜閱讀倉庫源碼與 MIT 許可證，按項目策略評估授權範圍。
生態說明。 DSH 理念是「一切皆插件」；社區插件目錄 SkillHub 上的條目 爲獨立站點，與 DeepSeek / 幻方無官方從屬關係。
結尾¶
dsh-agent-team-workflow 把 Manager、多角色 Actor 與獨立 Judge 寫成可複用的串行 YAML 工作流，適合在 DSH Web 裏按 Issue / PR 節奏做實現—審查—測試—合併，或用可視化編輯器按項目改節點與驗收條件。目錄頁：https://www.skillhub.cn/plugins/huaComPj/dsh-workflow-plugin；源碼與文檔：https://github.com/huaComPj/dsh-workflow-plugin。
