用 dsh-plans 給 DeepSeek Harness 加上人機協同規劃

DeepSeek Harness 插件 DeepSeek DSH dsh-plans 界面增強 人機協同 2026-08-17 103 閱讀

前言

DeepSeek Harness（CLI 名爲 dsh）是 DeepSeek AI 開源的智能體運行時，設計原則是「一切皆插件」：模型、工具、技能、會話和界面都可以用插件拼起來。官方倉庫目前仍標爲 developer preview，兼容性可能隨時變化。

社區裏還有一份獨立的插件目錄 deepseek-harness-plugin.com，用來檢索第三方插件。它和 DeepSeek / 幻方沒有官方從屬關係，不是官方應用商店。

智能體改倉庫時，常見情況是：一句話需求直接動手，改到一半才發現範圍不對、驗收標準含糊，或者 reviewer 意見來得太晚。dsh-plans 針對的就是這件事：先把粗略改動整理成工作區裏可追蹤的 Markdown 方案，經過 reviewer / criticizer 子代理打磨，再由人顯式交接後進入執行。

本文按社區目錄詳情頁、GitHub 倉庫 README、preset.yml / agent.cordis.yml 以及捆綁技能文檔覈對後整理。

這是什麼

dsh-plans 是 Optim-Agent 維護的 DeepSeek Harness 人機協同規劃預設（agent preset），許可證爲 MIT。社區目錄把它歸在「界面增強」分類。截至 2026-08-17，GitHub 倉庫顯示 22 顆星（目錄頁當時列出 12，以倉庫頁面爲準）。

倉庫說明寫明：它移植自 prime-plans 的規劃流程。同一維護者另有面向 Claude / Codex 的 optim-plans，五個技能名稱與這裏一一對應；dsh-plans 則把這套流程接到 DSH 原生機制上——ask_user_question、子代理、goal 循環和捆綁技能——不另做一套執行引擎。

它解決的問題可以概括成三步：

  1. 只讀查看目標倉庫，把改動需求寫成 ./dsh-plans/ 下帶穩定 ID 和 Verifier Checklist 的方案。
  2. 用 reviewer / criticizer 子代理多輪打磨；每一輪都要先問人（或 Auto-complete）選不選這個角色。
  3. 方案被接受後，再問一次沒有自動完成選項的交接題：現在就作爲 DSH goal 執行，還是隻停在規劃。

預設會關掉 DSH 內置的 plan mode。agent.cordis.yml 寫明：內置 plan mode 的「單方案、禁止寫入」循環，和這裏要在規劃階段寫出 PLAN_vN.md 的做法衝突，所以改由預設自己的交接問題來把門。

核心功能

一次運行怎麼走

README 把一次完整流程寫成六步：

  1. 智能體只讀查看目標倉庫，然後詢問該工作區的語言設置（每個工作區問一次，之後沿用）。
  2. 規劃問題一次只問一個，選項順序固定：推薦項在前，Other 倒數第二，Auto-complete 最後。問題和答案寫入 DECISIONS.md 和運行賬本。
  3. 必須先做範圍確認，才能寫出第一稿 dsh-plans/YYYY-MM-DD-topic/PLAN_v1.md。方案要有穩定 ID、證據，以及 ## Verifier Checklist。
  4. 每個方案版本之後都要問打磨方式。reviewer / criticizer 不會在沒人選的情況下自行啓動。這兩個角色走預設自己的 run_plan_subagent 工具：構造上只讀，模型在該角色第一次真正使用時選定。
  5. 打磨收斂後，問一次沒有 Auto-complete 的執行交接：現在作爲 DSH goal 執行，或規劃到此結束。
  6. 批准後，執行以 DSH goal 形式運行，目標指向被接受的方案及其 Verifier Checklist。實現遵循倉庫所說的 ponytail 簡化紀律和 MVP 最小測試集；只有清單每一項都通過，才調用 update_goal complete。

五份捆綁技能

智能體按請求選擇技能，而不是每次都走同一套深度：

技能 適用情況（倉庫原文）
create-a-small-plan 小範圍倉庫改動，1～3 個規劃問題。建議打磨：一輪 criticizer，再接受執行。
create-a-plan 範圍較大或有風險，5～10 個規劃問題，並做聯網調研。建議：一輪 reviewer，再一輪 criticizer。
create-a-big-plan 開放或高風險，10 個及以上規劃問題，並做聯網調研。建議：三個並行 reviewer 由主代理彙總，再一輪 criticizer。
diagnose-before-plan bug、CI 失敗、迴歸、事故、RCA 或行爲異常，需要先診斷再規劃。
reference-before-plan 下載的項目、文章、論文或文檔必須先分析，規劃選擇才安全。

diagnose-before-plan 會先根據倉庫、日誌、測試和用戶提供的現象做 RCA（最多 5 Whys，證據不夠就標 unknown，不編造原因），再問要不要進入修 bug 的規劃。選擇繼續後纔會寫 PROBLEM_ANALYSIS.md。

reference-before-plan 要求在寫 PLAN_v1.md 之前下載至少 3 份可信參考，大文件默認放在倉庫外的 ~/.cache/dsh-plans/refs/，並寫入 REF_ANALYSIS.md。每一份參考都要先問至少 3 個採納問題，答案記下來之後，其中的想法才能進方案。

工作區產物

對外可提交的文件留在工作區：

dsh-plans/YYYY-MM-DD-topic/
  DECISIONS.md
  PROBLEM_ANALYSIS.md     # 僅 diagnose-before-plan
  REF_ANALYSIS.md         # 僅 reference-before-plan
  PLAN_v1.md
  PLAN_v1_reviewer_comments.md
  PLAN_v2.md

機器狀態放在產物旁邊，默認不提交（helper 會寫入 .gitignore 中的 .state/）：

dsh-plans/.state/
  config.json             # 語言 + 各角色模型
  active.json
  runs/<run-id>/

每個工作區會記住語言；reviewer / criticizer / executor 的模型在該角色第一次實際使用時詢問一次並持久化。executor 就是當前會話的 goal 循環，確認過的模型即會話模型。

安全邊界

README 把支持範圍限定爲：規劃紀律、可持久狀態、顯式交接。交接之前，工作流只寫 dsh-plans/.state/ 和 dsh-plans/ 下的產物，不動目標源碼、配置或測試。

run_plan_subagent 會拒絕子代理使用寫入、goal、向用戶提問和再委派等工具，reviewer / criticizer 只能通過最終輸出回報。Auto-complete 可以回答規劃和打磨問題，但不能批准 goal 執行、安裝、部署、合併、推送、使用憑據，或任何改變外部狀態的操作。

安裝與啓用

社區目錄頁給出的安裝命令是：

dsh plugin add github:Optim-Agent/dsh-plans

需要可復現安裝時，目錄頁建議固定 commit 哈希：

dsh plugin add github:Optim-Agent/dsh-plans#commit

把 #commit 換成具體哈希即可。目錄頁同時提醒：插件以當前 dsh 進程的權限運行，安裝時可能執行代碼。

倉庫本身沒有 package.json。README 把安裝寫成克隆到用戶預設目錄，由 roster 掃描後出現在預設選擇器裏：

mkdir -p ~/.dsh/.agent-presets
git clone https://github.com/Optim-Agent/dsh-plans.git ~/.dsh/.agent-presets/dsh-plans

roster 每次讀取都會重新掃描根目錄，新預設會立刻出現。爲新會話選中 dsh-plans，不必重啓整個 dsh 服務。更新已有安裝：

git -C ~/.dsh/.agent-presets/dsh-plans pull

兩種寫法來源不同：前者是目錄頁原文，後者是倉庫 README。按自己使用的 dsh 版本覈對後再執行，不要混用後想當然地認爲效果相同。

Code Mode 前提

dsh-plans 通過 DSH Code Mode（run_code 加上生成的 TypeScript SDK）呈現全部工具。README 說明，這樣可以避開某些模型會填滿每一個可選 Bash 參數的函數 schema 問題，同時保留原來的 Bash 實現、沙箱升級檢查、審批、後臺任務和取消行爲。

宿主必須提供 codeRuntime。DSH Web profile 已經加載 dsh-code-runtime-worker-thread。沒有 code runtime 的 profile 在掛載預設時會明確失敗，而不會退回不兼容的 Native 工具呈現。工具呈現是在組合智能體時固定的，更新後需要新開一個 dsh-plans 會話；一般不必重啓整個 DSH 服務，已有會話也不會熱遷移。

典型用法

預設選好之後，在任意目錄裏可以直接說：

Create a plan for <your change>

把 <your change> 換成具體改動即可，例如給某個模塊加接口、修一條 CI 失敗、或評估一次依賴升級。智能體會按請求挑選上面五份技能之一，先只讀查看倉庫，再按該技能的問題數量和打磨輪次推進。

一次中等規模改動（對應 create-a-plan）大致會經過：

  1. 工作區語言（若尚未記錄）。
  2. 5～10 個規劃問題，每次一個選項題。
  3. 最終範圍確認，寫出 PLAN_v1.md。
  4. 默認一輪 reviewer，再一輪 criticizer；每輪前後都要再問打磨方式。
  5. 接受方案後，問「現在作爲 DSH goal 執行」還是「規劃到此結束」。

大方案的 reviewer 輪次會在同一條助手消息裏併發三個只讀 reviewer，主代理去重後寫入 PLAN_vN_reviewer_comments.md，每輪最多向用戶展示 5 條高優先級意見。criticizer 每輪最多 5 個追問；改方案前要把這些問題的答案記下來。

倉庫還提供自檢命令（不改變目標倉庫）：

node --test scripts/test_plan_subagents.js
python3 scripts/validate_preset.py
python3 scripts/dsh_plans_state.py init --workdir /tmp/dsh-plans-smoke

適用場景與注意事項

比較適合：

  • 多文件、跨模塊、涉及外部 API 或依賴升級，需要先把範圍和驗收標準寫清楚的改動。
  • 先要做 RCA 或先讀外部資料，再決定怎麼改的任務。
  • 希望方案、決策和打磨意見都落在倉庫裏、可以一起提交審查的團隊。

不太適合、或需要改用別的路徑：

  • 用戶明確說不要規劃、只要直接改。技能文檔把這類請求排除在外。
  • 純事實問答、一次性命令、沒有倉庫改動的解釋類問題。
  • 宿主 profile 沒有 codeRuntime：預設會掛載失敗。
  • 指望它替換 DSH 內置 plan mode 的「禁止寫文件」行爲：這個預設在規劃階段會寫 dsh-plans/ 產物，並關掉內置 plan mode。

安裝和使用時需要記住：

  • 插件 / 預設以當前 dsh 進程的權限運行，安裝時可能執行代碼。安裝前應檢查源代碼倉庫和許可證（本倉庫爲 MIT）。
  • 社區目錄不是 DeepSeek 官方商店；星標、分類和安裝命令以當時打開的頁面爲準，並儘量和 GitHub 交叉覈對。
  • Auto-complete 不能批准執行。交接題沒有自動完成選項，這是有意爲之。
  • 執行階段會按 ponytail 紀律儘量簡化實現，測試也只保留能證明核心邏輯的最小集合。清單沒過完，goal 不會被標成 complete。

小結

dsh-plans 把「先規劃、再改代碼」寫成一套可落盤的 DSH 預設：方案在 ./dsh-plans/ 裏版本化，reviewer / criticizer 只讀打磨，執行必須經過沒有自動完成的交接，再用 DSH 自己的 goal 循環做到 Verifier Checklist 通過。

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

GitHub：https://github.com/Optim-Agent/dsh-plans

相關文章

快速從零部署一個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
羽毛球分组比赛记分
小程序二维码

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

小夜