前言¶
用 DSH 做多步任務時,常見的做法是在一個聊天會話裏讓模型自己拆步驟、自己執行、再自己檢查。這種做法的問題是上下文會越滾越大:執行細節、中間試探、報錯輸出都和最初的目標混在一起,模型審查自己剛寫的代碼時判斷力明顯下降,而且每一步都要你盯一下。
dsh-local-superagent(倉庫 superchao5717/dsh-local-superagent,維護者 superchao5717)換了個思路:把任務管理做成一張本地看板,執行交給獨立的 worker 會話,審查交給獨立的 supervisor 會話,你只在被提問時回答。下面介紹這個插件的定位、安裝方式和實際使用流程。
這是什麼¶
一個 DSH 本地版 Superagent 任務看板插件。你在自己的 DSH 工作區佈置任務,插件自動派發給獨立執行會話(worker),由主管會話按驗收條件審查結果並決定下一步;只有真正需要你決定時,任務纔會進入「待你決定」。入口在左側導航欄 Superagent。
需要說明的是,它是獨立的社區插件,不是 DeepSeek 官方產品,也不是上游倉庫的 fork 或官方改版。架構參考 DeepSeek 的 dsh-superagent-prototype(注意力經濟學、主從雙 Session、結構化彙報、審查與恢復),但不提供 GitHub/Gitee 自動接單,任務直接來自本地看板,工作區就是本機目錄。
核心功能¶
- 主從雙會話:worker 讀代碼、改文件、驗證;supervisor 不讀代碼、不動手,只對照驗收條件給出結論。兩者上下文互不污染。
- 確定性派發:任務本身即明確授權,接單、排隊、併發控制由 Host 代碼完成,不經過模型,避免「漏接單」和一次額外的模型往返。
- 低打擾人工介入:正常推進不彈窗、不往聊天裏發消息;只有
needs_you才把任務推到「待你決定」,一次只帶一個問題。 - 結構化彙報:worker 只能通過
superagent_report交結果(狀態 + 摘要 + 交付物 + 單個問題),狀態取值爲ready | needs_decision | blocked | failed;彙報內容越界會被 Host 校驗或截斷。 - 模型按會話注入:主管模型與執行模型範圍都可在全局設置裏配置;模型固定到會話,不改動 DSH 的全局默認模型。
- 任務附件(0.5.0 起):新任務和回答都支持圖片、視頻和普通文件,複用 DSH 原生
attachments.saveImages/saveFileStream與fileUploads服務,不另建文件倉庫。 - 補充要求與新會話(0.6.0 起):對進行中或已結束的任務發起「關聯任務」,自動沿用主管、工作區、歷史附件及目標/報告快照,原任務不被中斷或改寫;最多保留 8 層關聯。
- 可恢復:賬本是 Host 端 JSON(原子寫),插件或 DSH 重啓後,運行中的任務重新排隊,審查中的任務重新入隊。
安裝與啓用¶
需要 Node.js >= 22 和 DSH。README 聲明的實機驗證範圍僅爲 Windows / DSH 0.2.1-rc.5,其他平臺和 DSH 版本尚未實機驗證。項目不發佈 npm(private: true),分發方式是 GitHub 源碼及 GitHub Release 的 .tgz,運行代碼是 JavaScript,無需 build 步驟。
DSH Desktop:在插件頁選擇「添加插件」,在「包名或地址」填寫固定版本號:
github:superchao5717/dsh-local-superagent#v0.6.0
DSH Web:在運行 DSH Web 的環境執行下面這條命令,注意 --profile 位於 add 之前:
dsh plugin --profile web add github:superchao5717/dsh-local-superagent#v0.6.0
Desktop profile 由 Electron 專屬管理,不要使用 Web CLI 命令管理 Desktop。安裝後在左側導航欄打開 Superagent,不要手工編輯 profile 的 bundles 或依賴列表。包名保留 @local/dsh-local-superagent 以兼容已有 profile,@local 不代表只能本地安裝。建議安裝或升級後重啓一次 DSH——插件在啓動時輪換自己的主管會話來獲得乾淨的提示詞與工具註冊。
倉庫信息覈對:GitHub 星標 0,許可證 MIT,最新版本 v0.6.0(2026-11-05 發佈,Release 內含 dsh-local-superagent.tgz 與 SHA256SUMS.txt)。
典型用法¶
按 README 的快速開始走一遍:
- 左側導航欄點擊 Superagent;
- 選中一個 Superagent,新任務自動使用它的工作區;也可以先選工作區過濾主管。在主管 rail 點擊 + 創建主管,選中主管旁的 ⋯ 菜單可改名或刪除;
- 使用主管區域下方唯一的 佈置任務 入口,填寫標題、目標/要求、驗收條件(可選)、優先級,確認主管歸屬後 加入隊列;
- 插件自動派發、執行、審查;需要你決定時任務仍在「進行中」並顯示等待標記,可在頂部問答區或任務詳情直接回答,回答後自動繼續。
配置在右上角「設置」裏統一管理,是一份全局配置,對所有主管及 worker 生效,與當前工作區或主管篩選無關。主要項包括:
| 配置 | 作用 |
|---|---|
每位主管併發上限 maxWorkers |
1–4,是每位主管各自的上限,不是全看板共享的總 worker 池 |
| Superagent 模型 | supervisor 會話使用的模型,留空則跟隨 DSH 部署默認模型 |
| 工作代理模型範圍 | worker 允許使用的模型範圍,可多選,第一個是默認執行模型;全部不選時繼承 Superagent 模型 |
| 自動審查 | 開關 |
| 暫停 / 恢復 | 暫停停止派發新任務,運行中的繼續 |
| 超時自主續辦 | 默認關閉;開啓後等待時間 1–1440 分鐘,默認 30 |
關於模型範圍有兩點值得注意:主管審查時可以在 payload 裏看到 worker_models 範圍,判 continue 時可附帶 worker_model,指定下一輪執行會話換一個範圍內的模型(比如小模型沒做出來時升級模型);不在範圍內的模型會被 Host 拒絕並返回可選範圍。執行會話默認使用範圍內的第一個模型,也可以在設置裏把任一已選模型「設爲默認」。
完整執行鏈路如下:
看板佈置任務(工作區 + 標題 + 目標 + 驗收)
│ 確定性調度(Host 代碼,不需要模型參與)
▼
每輪一個全新的 worker Session(工作區目錄、工具集受限、系統提示注入)
│ superagent_report 恰好一次:ready | needs_decision | blocked | failed
▼
所屬 Superagent 的持久 supervisor Session 審查(只判斷、不執行)
│ superagent_review:done | continue | needs_you | fail
├─ done → 已完成
├─ continue → 按容量派發下一輪 worker(攜帶上一輪摘要,最多連續 2 輪)
├─ needs_you → 進入「待你決定」,只帶一個問題
└─ fail → 失敗
止損方面 worker 被要求「驗證點到爲止、同命令失敗兩次即停、單輪儘量 10 分鐘」,Host 另有 45 分鐘超時兜底,超時轉人工決定。worker 會話會出現在所屬工作區的會話列表裏(標題 ⚡ 任務名),可以直接點開看執行過程。
適用場景與注意¶
適合想在 DSH 裏把長任務拆成「執行—審查—人工決策」閉環、又不希望聊天窗口被中間過程淹沒的用戶。也適合需要按驗收條件批量派發改動、人工只做審批節點的團隊。
有幾條限制要提前知道:
- 多主管不等於文件隔離。同一個工作區內的主管訪問同一磁盤目錄,插件不自動提供文件鎖。並行修改同一倉庫前要劃分文件範圍,或用項目自己的獨立 worktree。
- 超時自主續辦不繞過人的權限。暫停時不自動續辦;登錄、認證、權限、付款、新增授權這類必須由人完成的步驟不能借此繞過。每個任務在人回答或手動重試前最多嘗試一次超時自主續辦,後續仍會轉人工。
- 附件上限。單文件/視頻最多 100 MiB,單圖片最多
min(原生限制, 20 MiB);每任務初始及全部回答累計最多 20 個 / 200 MiB。視頻和其它文件通過原生文件工具讀取,插件不自動轉碼或抽幀。圖片需要所選模型支持,否則明確轉人工處理。 - 圖表與狀態頁不改動 DSH 全局默認模型。配置按會話注入,新值隻影響後續審查與派發,不強行中斷當前請求或執行輪。
- 驗證範圍有限。README 聲明的實機驗證只有 Windows / DSH 0.2.1-rc.5,另外 0.6.0 發佈說明註明本版未重新驗收真實模型的完整「附件 → 關聯任務 → 主管審查」閉環。2026-11-05 的記錄顯示包版本仍爲 0.5.0 時完成了 107/107 離線測試和 11 個運行文件語法檢查。
- 升級前備份。0.4.0 遷移到 schema 3 前要備份賬本並等待執行中的任務結束;schema 3 不建議直接用舊版 0.3.0 覆蓋運行,也不承諾自動兼容降級。0.5.0 起的附件功能也不承諾降級後保留。
插件以當前 DSH 進程權限運行,安裝前建議先讀一遍源碼,並覈對許可證(MIT)。
小結¶
它解決的不是模型能力問題,而是上下文污染和注意力分配問題:把執行、審查、人工決策拆到獨立會話裏,看板只負責調度。如果你的工作流需要在本地目錄上跑多輪驗證、由一個「主管」按驗收條件把關、只在關鍵節點問你一次,這個插件的結構是對口的;如果需要 GitHub/Gitee 自動接單或跨機器任務池,它目前不提供。