前言¶

用 DSH 做多任務開發時，常見的做法是手工開多個會話，每個會話寫一段指令，然後逐個盯着。任務一多，注意力就被「哪個會話卡住了、該給誰發消息、產物回來沒有」耗掉，真正要你做的判斷沒有時間做。

dsh-leader-agent 換一個組織方式：你只跟一個 Leader 會話說目標，Leader 拆卡、派工、盯每個 worker 完成、驗證產物並組織 Review，worker 在後臺各自幹活並自動回報，任務事實落在按項目組織的看板上。它不是「一段更聰明的 prompt」，而是靠會話身份、機制側完成結算和常駐 worker 會話三件事撐起來的編排 bundle。

下面介紹這個插件：它是什麼、怎麼裝、怎麼跑、有什麼限制。

這是什麼¶

fengshenx/dsh-leader-agent，由 fengshenx 維護，MIT License，倉庫語言 JavaScript，分類屬於工作流。GitHub 描述是「DSH leader/worker orchestration bundle: project tree, delivery board, worker sessions」。

一句話定位：給 DeepSeek Harness（dsh）加一層 Leader/worker 編排，外加一個交付看板和項目樹。

解決的問題是單個 DSH 會話只能盯一件事：拆出去的任務沒有統一登記、沒有驗收錨點、worker 完成了也不知道，只能靠人逐個查會話。這個 bundle 把拆卡、派工、回報、驗收收進一套機制裏，目標是一個人同時推進多個任務而不必逐個陪跑。README 給出的目標規模是一次並行開發 10 個 feature。

• 版本：0.3.1，狀態 developer preview（來自倉庫 package.json 與 README 徽標）。
• 運行要求：dsh >=0.2.1-rc.2 <0.3.0，Node >=24.9.0（engines 字段）。
• 倉庫數據：1 個 star，0 fork，4 個 open issue（取自 GitHub 倉庫頁面，2026-11-06）。

注意：README 明確「一人一個 worktree 是本倉庫的約定，不是 bundle 的硬性要求」，不要把它當成安裝前提。

核心功能¶

1、Leader 統一驅動開發與 Review¶

你只聲明目標，Leader 負責拆卡、派工、盯住每個 worker 到完成、驗證交付物、組織 Review。人的注意力回到「要什麼」，而不是「哪個 agent 卡住了」。

支撐這一點的是工具面的裁剪，而不是提示詞：Leader 會話拿得到 spawn_worker / message_worker，worker 拿不到；工具面在會話創建時由宿主裁剪。

2、項目樹與右欄交付看板¶

左欄是項目與每個 Leader 派出的 worker；右欄 SidePanel 是交付看板，一卡一件事，卡面顯示執行者槽位與實時信號燈，說明按 Markdown 渲染，鏈接可在詳情浮層裏直接編輯。

點卡面看詳情（目標、範圍、驗收、鏈接，其餘只讀），點槽位 chip 直接下鑽到那個 worker 的會話接着聊，不需要經過 Leader。worker 的回報渲染成氣泡，同樣支持 Markdown。

項目之間互相隔離：一個項目綁定一個 Leader 會話，刪除項目只刪記錄，文件夾與會話保留（dsh 工作區不受影響）；換 Leader 時，原班 worker 與未投遞的回報一併改投新會話。

3、規則寫在 LEADER.md 與 SLOTS.md¶

編排規則不寫進死提示詞，而是寫進兩個文件：

兩個文件在每次模型請求前求值、正文變化才追加，改文件即在下一個請求生效，不用重建會話。沒寫 SLOTS.md 的項目回落默認兩角色 dev / review。項目初始化由 init-leader-agent skill 負責：先把倉庫工程約定併入目標項目 AGENTS.md 的受管區塊，再按包內骨架寫 LEADER.md 與 SLOTS.md。

leader-mode skill 是給 Leader 的編排協議，按技術討論 → 設計 → 實現交付 → 審查 → 合入分階段給 playbook，另有並行協作與交接規範。它靠模型按需調 skill 工具加載，不是配置文件。

4、回看 worker 的會話過程，不喚醒它¶

read_worker_session 直讀 worker 的會話日誌，給出每輪的任務、正文、調過哪些工具與失敗原因。它是隻讀的：不喚醒 worker、不產生模型調用。完成通知負責說明「產物是什麼」，這個工具負責說明「過程是怎樣的」，排查不必再開一輪。

5、完成由機制結算並自動喚醒 Leader¶

worker 那一輪結束時，Leader 自動收到一條回報，不輪詢、不靠 worker 自覺。worker 是常駐根會話，能同時跑多個，進程重啓後可以冷恢復。

安裝與啓用¶

Web 版¶

從 npm 安裝（包名 dsh-leader-agent）：

dsh plugin --profile web add dsh-leader-agent
dsh web

profile 名必須用 web。自定義名不在 PROFILE_TEMPLATES 裏，裝出來缺 web-app bundle，客戶端半邊不加載。需要 dsh >=0.2.1-rc.2 <0.3.0，engines.dsh 不滿足時安裝與啓動被拒絕。

指定版本、卸載、開發期安裝的寫法見倉庫 docs/development.md。不裝 profile 直接試跑，可在 dsh 源碼目錄執行：

pnpm dsh web --patch <本倉>/cordis.patch.yml

桌面版¶

桌面版使用獨立 profile（$DSH_HOME/profiles/desktop），與 web 互不相通。圖形界面安裝：左側 SidePanel 打開「插件」，點右上角「添加插件」，在包名框填 dsh-leader-agent 後點「安裝」。

命令行安裝要用桌面安裝自帶的 CLI，系統 dsh 拒絕管理 desktop profile：

# 先完全退出應用（關窗口只是隱藏）
"/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh" \
  plugin --profile desktop add dsh-leader-agent

Windows / Linux 換成安裝目錄裏對應的 runtime/cli/bin/dsh。DSH_HOME 要用絕對路徑或 ~/ 寫法。會話、項目與卡片數據與 web 共享，插件包與激活狀態各自一份。

在本倉庫內開發時改用 npm run desktop：掛當前工作樹、重建產物並拉起應用，-- --remove 摘除。

從 dsh-leader-kit 升級¶

包名改成 dsh-leader-agent，不提供兼容路徑。dsh plugin add 寫進 dsh.profile.bundles 的是包名，舊條目升級後仍在，兩個 bundle 都會生效，結果是工具註冊兩次、agent/created 訂閱兩次、兩個 dispatcher 各結算同一個 turn/end。先刪掉舊條目：

dsh plugin --profile web remove dsh-leader-kit
dsh plugin --profile web add dsh-leader-agent

數據目錄隨包名改爲 $DSH_HOME/dsh-leader-agent，不遷移：升級後看板是空的，worker 登記表首次啓動重建。

典型用法¶

按 README 的五步走一遍。

1、加項目。左欄「項目」區塊點「加項目」，選一個目錄。項目當場建好並綁定一個 Leader 會話，點項目行就是打開這個 Leader。

2、加載協議。在 Leader 會話裏讓模型加載 leader-mode，先讀 playbooks/program.md，再按階段讀對應 playbook。

3、派工。spawn_worker 只要求 name（角色-任務短名），可帶 cardId + slot 一次把卡槽位綁好；工具立即返回會話 id，此時 worker 還沒開工。用 message_worker 投遞任務正文（sessionId + message，可順手 rename），第一條消息纔開工。

4、記任務事實。create_card 建卡（title 必填），update_card 改卡（改內容帶 expectedRevision 做樂觀併發），list_cards 查卡。卡片按項目歸屬，編號全局遞增，跨項目改卡會被拒絕。list_cards 與 create_card 只給 Leader，update_card Leader 與 worker 都有，但 worker 只能改自己掛着的卡，且只能掛 links 這類派生字段，title / spec / status / slots 都歸 Leader。

5、看看板。右欄「看板」Tab，按當前會話所屬項目拉卡片。Leader 建卡後自動打開；點卡片看詳情，點槽位 chip 打開執行者會話。

經過上面的步驟，Leader 側的循環是：建卡 → 派工 → worker 後臺執行 → turn 結束由機制結算並喚醒 Leader → 看板信號燈更新 → 人可以直接打開任一 worker 接着聊。

適用場景與注意¶

適合的場景：一個 DSH 實例裏同時推進多個相對獨立的編碼任務，希望有人統一拆任務、盯完成、做驗收；或者希望按項目把會話和任務事實整理起來，而不是散落在一堆平級會話裏。

需要先接受的前提：

• worker 在後臺跑，Leader 沒有中止 worker 的手段（interrupt_agent 對它無效並會返回假成功回執）。worker 卡住或跑偏，只能由人去那個會話裏處理。
• worker 的沙箱模式與審批策略在派工那一刻從 Leader 繼承，此後不再跟隨 Leader 的 preset 變化。後臺 worker 的 ask 沒人應答，一律落到 unavailable，需要審批的調用會被直接拒絕。
• 後臺編排只適用於長駐組合（web / desktop / sdk）。headless 是一次性 CLI，會話在 turn 結束後銷燬，沒有載體接收完成通知。
• LEADER.md / SLOTS.md 改動只在下一次模型請求生效，正在跑的那一輪不變。
• 插件代碼運行在當前 dsh 進程內，以當前進程權限執行，並會註冊會話事件等宿主擴展。安裝前建議先讀一遍源碼與許可證（MIT）再決定是否引入。
• 項目當前處於 developer preview，README 也寫了「項目還缺少一些初始化機制」，實際使用需要在項目內初始化 LEADER.md 與 SLOTS.md。

結尾¶

dsh-leader-agent 的價值在於把「多會話併發」這件事變成有登記、有驗收、有回報的編排：Leader 負責拆與驗，worker 負責幹，看板負責讓你一眼看到誰在工作、產物到哪一步。它解決的是注意力問題，不是模型能力問題，因此合理的預期是幫你管理併發，而不是降低任務本身的複雜度。

目錄頁：https://www.skillhub.cn/plugins/fengshenx/dsh-leader-agent
GitHub：https://github.com/fengshenx/dsh-leader-agent