前言¶
DeepSeek Harness（DSH）裏，Session Controller 本來就能新建會話、往會話裏發消息——Web 界面走的就是這套能力。但這些能力沒有暴露成模型可調用的工具。模型若只能用 subagent 一類「一次性任務」代理，就難以把活丟進獨立、持久、用戶可見可接管的工作區會話，也難以在任務跑着的時候先幹別的，事後再回來讀結果，或用 steer 給正在跑的回合追加指令。
dsh-session-dispatch 由維護者 919703505hackiv-boop 發佈，把工作區會話的創建、發消息、等待、讀回覆和列舉，收成同進程內五個模型面向的工具調用。創建的會話是真正的頂層 Session，會出現在工作區會話列表裏，用戶可以直接打開繼續聊。
這是什麼¶
npm 包名 dsh-session-dispatch，當前版本 0.1.0，許可證 MIT。兼容 DSH >=0.2.0 <0.3.0、Node.js >=22。
插件定位：給模型用的「會話派發」——新開工作區會話、發指令、等回合結束、讀回覆，把子任務放進獨立上下文裏跑，而不是塞進 subagent 的一次性上下文。
社區目錄頁：https://www.skillhub.cn/plugins/919703505hackiv-boop/dsh-session-dispatch
源碼與說明：https://github.com/919703505hackiv-boop/dsh-session-dispatch
核心功能：五個 conversation_* 工具¶
下面介紹五個工具各自做什麼，以及典型串聯方式。
| 工具 | 作用 | 關鍵點 |
|---|---|---|
conversation_create |
新建頂層會話，返回 sessionId |
cwd 默認繼承調用方；可傳 agentPreset |
conversation_send |
往會話裏發文本 | 默認排隊起新一輪；mode: "steer" 注入當前輪 |
conversation_wait |
等當前/下一輪 assistant 回合結束 | 返回 state: "idle" \| "timeout"、lastReason（永遠是字符串）、running |
conversation_read |
讀最近回覆和回合狀態 | 返回 live、running、turns、lastTurnReason、text、truncated |
conversation_list |
列出本進程內存活會話 | 可按絕對路徑 cwd 過濾 |
典型流程如下。先做創建，再發任務，等待回合結束，最後讀回覆：
conversation_create({ cwd })
→ conversation_send({ sessionId, text: "把 xxx 做完" })
→ conversation_wait({ sessionId })
→ conversation_read({ sessionId })
插件不寫自己的數據庫，不改會話日誌格式；可選調試日誌是唯一落盤行爲。
安裝與啓用¶
npm 發佈之後，在 Web profile 下安裝：
dsh plugin --profile web add dsh-session-dispatch
安裝後重啓 DSH，五個工具纔會出現在模型工具表裏。安裝會把包加進 profile 的 dsh.profile.bundles，並應用包內的 cordis.patch.yml 層。
本地目錄調試（包未發佈時）：
dsh plugin --profile web add ./plugins/dsh-session-dispatch
檢查層是否生效：
dsh --profile web --dump-config # 應出現 "# == dsh-session-dispatch" 層
若 profile 裏仍留着舊版 dsh-session-dispatch3（row id tool-session-dispatch3），應先刪掉再裝本包。兩個插件註冊同名工具，同時啓用會因工具名重複而失敗。
cordis.patch.yml 只做一件事：把插件行插進 profile，name 必須與 npm 包名完全一致：
- insert:
- id: tool-session-dispatch
name: dsh-session-dispatch
沒有其它必填配置。可選環境變量：
| 變量 | 默認 | 說明 |
|---|---|---|
DSH_DISPATCH_LOG |
os.tmpdir()/dsh-session-dispatch.log |
調試日誌路徑；off / 0 / none 關閉 |
DSH_DISPATCH_TZ |
系統時區 | 寫進用戶消息 source 的 clientTimeZone |
DSH_DISPATCH_START_GRACE_MS |
8000（最小 5） |
conversation_wait 發現會話已空閒時，等待新回合的寬限時間 |
自測與源碼結構¶
不依賴 DSH 運行時，可在插件目錄用純 Node 自測：
node plugins/dsh-session-dispatch/test.mjs
# 18/18 通過
node --check plugins/dsh-session-dispatch/index.js
主要文件：index.js（五個工具實現）、cordis.patch.yml（bundle 層）、test.mjs（18 項自測）。
適用場景與注意¶
適合誰： 需要在 DSH Web/Desktop 宿主裏，讓主會話模型把子任務派到獨立工作區會話、異步等待結果、必要時 steer 正在跑的回合的開發者與高級用戶。
權限與 profile： 插件以當前 DSH 進程權限運行；conversation_create 默認繼承調用方工作區，跨工作區需顯式傳絕對 cwd，仍受 DSH 審批與權限策略約束。安裝前應閱讀源碼與 MIT 許可證，確認符合你的環境策略。
依賴宿主服務： 插件 inject 了 tools、sessionController、sessions、agents；沒有這些服務的 headless profile 會加載失敗。
進程內會話： conversation_read 返回 live: false 表示該會話不在當前進程（可能在別的 DSH 實例裏），只能讀到空結果。五個 conversation_list 列出的也是本 host 進程內存活的會話。
開發與升級坑： 改完 index.js 必須重啓 DSH，HMR 不會重載 host 插件。同名同版本不會因原地改文件而重新生效；可靠做法是換包名或先 remove 再 add，並重啓。conversation_wait 默認 timeoutMs 120000、上限 600000，不宜用超大 timeout 佔住工具調用。
DSH 生態強調「一切皆插件」；SkillHub 等社區目錄是獨立站點，與 DeepSeek / 幻方無官方從屬關係。
結尾¶
dsh-session-dispatch 把 Session Controller 的能力暴露成模型工具，讓派發子任務、獨立上下文、用戶可見會話成爲可編排的一步流程。目錄頁見 https://www.skillhub.cn/plugins/919703505hackiv-boop/dsh-session-dispatch，細節與發佈說明見 https://github.com/919703505hackiv-boop/dsh-session-dispatch。
