前言¶
做智能體編排時常見的麻煩是：專家的人設、分工和上報規則散落在提示詞和代碼裏，想換一個評審陣容就得改引擎。dsh（DeepSeek Harness）的理念是「一切皆插件」，libinyam/dsh-experts 沿着這個思路把「專家團」做成了用戶可寫的數據目錄：每個團隊自動註冊爲模型可路由的 skill（experts-<團隊名>），引擎與陣容分離。下面介紹它的設計、安裝和用法。
這是什麼¶
dsh-experts 是 libinyam 維護的 dsh 多專家插件，MIT 協議。一句話定位：把專家人設清單變成 dsh 原生 skills——團隊發現、校驗和工作流協議在插件裏，專家人設與升級路由在團隊目錄裏。設計參照 Qoder 專家團 / WorkBuddy Expert Teams 的產品形態，協作協議繼承自作者此前的 github-project-review-skill（升級路由矩陣、數據門控決策、分層輸出深度），改建於 dsh 原生能力（skills provider、可繼續 child、嵌套 subagent、消息和 report 通道）之上。
工作原理¶
插件按 rank 分層掃描團隊目錄，同名團隊就近覆蓋：
1、項目 .dsh/experts/（rank 100）
2、config.teamDirs（rank 300）
3、<dshHome>/experts（rank 400）
4、隨包 teams/（rank 600，示例團隊）
發現之後對每個團隊的 team.json 做嚴格校驗（fail loud），通過後組裝工作流模板、花名冊、人設卡與升級矩陣，skill 目錄出現 experts-<團隊名>，模型即可路由到該團隊。
運行期的動作分兩步：當前會話先啓動真實的 lead child，lead 再按任務動態啓動 specialist child——相關的專家才啓動，並且可以繼續或追加派遣。
想魔改官方示例，標準動作是把隨包示例目錄拷到 <dshHome>/experts/ 下改，項目層的同名團隊會自動遮蔽隨包版本。
團隊目錄怎麼寫¶
一個團隊就是一個目錄：
my-team/
├── team.json # 機器接線：名稱/描述/工作流/專家/升級路由
├── TEAM.md # 團隊級約定（可選，注入技能 body）
└── experts/ # 人設卡，由 lead 在 specialist prompt 中全文注入
├── lead.md
└── coder.md
team.json 裏的幾個關鍵字段：
experts[]：1-8 位專家，{id, role: coordinator|specialist, card, modelHint?}，恰好一位 coordinator 作爲 lead child 啓動；escalations[]：升級路由{from, to, when, priority(P0|P1|P2)}，from/to 必須引用專家 id 且不許自指；TEAM.md：團隊級約定，可選，注入技能 body；experts/*.md人設卡由 lead 在 specialist prompt 中全文注入；reportLanguage：zh（默認）或en。
校驗是 fail loud 的，下面這些都會被直接拒絕：未知字段、路徑逃逸（../、絕對路徑、盤符、符號鏈接出目錄、NUL）、懸空升級引用、多位協調者、自由文本含換行或管道符（防 markdown 結構注入）、卡片含 4+ 反引號圍欄、TEAM.md 超 64KB 等。錯誤消息帶精確文件路徑與字段名。同名團隊先按名字去重再對勝者全量校驗——有效的低 rank 團隊可以遮蔽同名的壞團隊；沒有遮蔽時，任何一個壞團隊都會讓本提供方整體報錯，修復該團隊即恢復。
安裝與啓用¶
推薦方式是加入 dsh profile：在 profile 的 package.json 中把本包加入 dependencies 與 bundles。
{
"dependencies": {
"dsh-experts": "github:libinyam/dsh-experts"
},
"dsh": {
"profile": {
"bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-experts"]
}
}
}
本地開發可用 "dsh-experts": "file:<到本倉庫的路徑>"。
方式二是手動放置：克隆本倉庫到 profile 的 node_modules/dsh-experts，並把 "dsh-experts" 追加進 bundles 列表。插件無外部依賴，無需安裝步驟。
環境要求：Node ≥18；零運行時依賴、零 devDependencies；plain ESM JavaScript，無構建步驟。
典型用法¶
安裝後 skill 目錄會出現內置示例團隊 experts-web-review（5 位專家：協調者 tech-lead + 前端 + 後端 + 測試 + 安全）。對 dsh 說：
用 experts-web-review 評估 owner/repo 的推廣就緒度
創建自己的團隊，用配套腳本從內置 web-review 複製：
node node_modules/dsh-experts/scripts/new-team.mjs --name my-team
默認複製到 <dshHome>/experts/my-team。編輯 my-team/team.json（描述、專家、升級路由）和 experts/*.md 人設卡，然後離線校驗：
node node_modules/dsh-experts/scripts/validate-team.mjs <dshHome>/experts/my-team
校驗通過後，skill 目錄會自動多出 experts-my-team。注意 v0.1 沒有文件 watcher，新增或修改團隊後需要重載插件刷新目錄。
開發側的常用命令：
npm test # 全量測試（單元 + 守護）
npm run guard # 只跑憲法守護測試
npm run validate-team teams/web-review # 校驗內置示例團隊
配置¶
配置寫在 cordis.patch.yml，全部可選：
| 鍵 | 默認 | 說明 |
|---|---|---|
providerName |
dsh-experts |
skills 註冊表中的提供方名 |
includeDefaultRoots |
true |
是否掃描項目/用戶根（關閉後僅 teamDirs + 隨包） |
dshHome |
$DSH_HOME 或 ~/.dsh |
覆蓋 dsh 主目錄 |
teamDirs |
[] |
額外團隊根（rank 300） |
includeBundledTeams |
true |
是否暴露隨包示例團隊 |
等價的環境變量：DSH_EXPERTS_PROVIDER_NAME、DSH_EXPERTS_INCLUDE_DEFAULT_ROOTS=0、DSH_HOME、DSH_EXPERTS_TEAM_DIRS（分號/逗號分隔）、DSH_EXPERTS_INCLUDE_BUNDLED_TEAMS=0。
已知問題（v0.1）¶
- 無文件 watcher：新增/修改團隊需重載插件。
- 每次
list()全量重掃並重校驗所有團隊（無緩存），團隊數量上千時目錄刷新開銷可觀。 - 僅
review工作流模板；develop模板（patch 化輸出 + 綠燈門禁 + 人工 PR）在路線圖上。 - 未掃描
.agents系根目錄。 modelHint只是模板提示，不強制路由模型。
適用場景與注意事項¶
適合需要在 dsh 裏搭多專家評審流程、希望陣容像數據一樣可版本化可魔改、不想爲換人設改引擎的智能體開發者。
用之前留意幾點：
- 一個壞團隊（且無低 rank 同名遮蔽）會讓本提供方整體報錯，這是 fail loud 設計，按錯誤消息修復即恢復。
- 無 subagent 或 report 工具時，插件會明確標記團隊運行時不可用，不會僞裝成專家已經工作。
- 排查入口：dsh 控制檯日誌看
skills.registerProvider相關錯誤，或跑scripts/validate-team.mjs <目錄>離線定位。 - 插件以當前 dsh 進程權限運行，安裝前建議自行檢查源碼與許可證（MIT）。
結語¶
dsh-experts 的價值在於把「換陣容」從改代碼變成改目錄：嚴格校驗兜住低級錯誤，rank 分層支持就地覆蓋，skill 自動註冊讓模型按需路由。倉庫與目錄頁：
- GitHub：https://github.com/libinyam/dsh-experts
- 目錄頁：https://www.skillhub.cn/plugins/libinyam/dsh-experts（社區站點，與 DeepSeek / 幻方無官方從屬關係）
