前言¶
DSH 跑一段時間後，左側對話列表裏往往堆着一堆會話：跑完沒關的、跑掛了半途的、幾週沒碰但上下文還熱着的。原生列表只回答”有哪些會話”，不回答”哪個最燒 token”“哪個快到上下文上限”“我想把一句話派給那個跑了一半的會話，怎麼派”。日常做法是逐個點開看狀態，或者靠標題和目錄名腦子裏記，規模一大就不現實。
onlyinliu/dsh-session-console 是社區維護的客戶端插件，維護者 onlyinliu，分類”客戶端”。它把這張列表擴展成一張覆蓋全部會話的儀表盤：讀全局狀態、用一句自然語言定位某個會話，並把一句任務投遞到那個會話裏並讀回結果。下面介紹它實際暴露的能力、安裝方式和用法。
這是什麼¶
插件在 DSH 側欄放一個圖標，點開是主面板。README 的定位是”左側對話管理員”。它解決三個本來要手工完成的動作：翻會話看狀態、憑目錄名找會話、切到別的對話裏發話。
插件市場條目（awesome-dsh-plugin）把它的簡介寫成：覆蓋每個會話的儀表盤、自然語言會話定位、跨會話任務投遞。倉庫當前 10 個文件在 main，topics 含 dsh-plugin；npm 包名 dsh-session-console，當前 latest 爲 0.1.1（2026-11-04 發佈，內容是兼容性修復）。插件市場目錄頁給的星標數是 0。這個插件是社區自發維護的，與 DeepSeek / 幻方沒有官方從屬關係。
儀表盤：讀全局¶
主面板列出全部會話，每行顯示一批指標：
| 指標 | 含義 |
|---|---|
| 會話總數 / 運行中 / 冷會話 / 空白 | 全局狀態分佈 |
| 累計 token（輸入 / 輸出 / 緩存讀 / 緩存寫） | 來自 tokenUsage projection，不掃描歸檔 |
| 緩存命中率 | cacheRead ÷ (input + cacheRead + cacheWrite) |
| 今日活躍 / 本週活躍 | 按會話最後活躍時間分桶 |
| 上下文壓力 | 來自 contextPressure projection，顯示 pressureTokens ÷ contextWindow 的百分比 |
| 模型 | 來自 modelSelection projection 的 next（已合併 pending），顯示 provider/model |
| 熱度 | 100/(1+靜默小時/6) + log10(1+token)*8 + log10(1+事件)*5 + 運行中40 |
| 最熱 / 按工作區聚合 | 誰在燒 token、哪個目錄最忙 |
列表支持 全部 / 運行中 / 今日 / 冷會話 / 空會話 過濾，可按熱度、消耗、最近排序，並提供標題與路徑的即時過濾。數據來自 DSH 已有的 projection 與 session header，不做歸檔掃描，開銷集中在本進程。
指代：用一句人話定位會話¶
“指代與派任務”輸入框裏輸入一句自然語言，例如 示例項目的相關內容怎麼樣了，插件的處理分四步：
- 剝掉「怎麼樣了 / 情況 / 進度 / 相關 / 內容 / 幫我 / 看看」這類口頭語，留下主語
示例項目； - 拿主語比對每個會話的標題、
cwd、目錄末段、agent preset、會話 id，權重分別爲 6 / 4 / 3 / 1 / 1； - 子串命中給滿權重加成，其餘用 CJK bigram 加拉丁詞的 Dice 相似度；
score ≥ 40且不存在跨工作區的同分對手纔算”鎖定”，否則列出候選讓你點。
比對用的是會話 header 裏的真實 cwd，不是歸檔目錄那串 ~6570~636E~… 編碼名，所以目錄叫 示例項目-v2 時，一句「示例項目」也能對上。同工作區裏分數相同的兄弟會話不算歧義，直接取熱度最高的一個；只有跨工作區出現同分對手才判爲歧義並列出候選。
派任務：把一句話寫進別的對話¶
選定目標後寫一句話，兩種投遞方式：
queue（排隊）：作爲下一輪輸入排進去，目標對話空閒時立刻跑；steer（打斷插入）：如果它正在跑，就把這句插進當前這一輪。
走的是 UI 輸入框同一條通道（sessionController.prompt），所以冷會話會自動恢復，消息也會持久化。派完後可以在詳情卡里讀最近的用戶 / 助手消息、輪次 / 工具調用 / 工具失敗 / 異常輪次統計、最後一次失敗原因，也可以一鍵跳到那個對話看完整上下文。
安裝與啓用¶
已發佈到 npm：
plugin_manager install_bundle target=dsh-session-console
也可以直接從 GitHub 裝：
plugin_manager install_bundle target=github:onlyinliu/dsh-session-console
開發時從本地目錄裝（改動即時生效）：
plugin_manager install_bundle target=D:\create\dsh-session-console
裝完重開一次 DSH，側欄纔會出現圖標。包名和 github: 兩條來自 README 原文，不要憑插件名自己拼接命令。
兩個已知安裝問題，README 對原因有說明：
- 按包名裝報
declares no dsh.bundle：鏡像還沒同步到最新版，解析到了 npm 側發佈時留下的0.0.0-stage佔位版本。解法是把安裝源切到 npm 官方源，或改用github:onlyinliu/dsh-session-console。鏡像的latest同步到0.1.1後重試即可。 - 裝的時候報
incompatible-version：裝到的是0.1.0。它的engines.dsh上界寫成<0.2.2-0，按 semver 預發佈規則0.2.2-rc.1大於0.2.2-0，於是被判不兼容；0.1.1已把上界放寬到<0.3.0-0。
0.1.1 的聲明是：
"engines": { "node": ">=18", "dsh": ">=0.2.0-rc.2 <0.3.0-0" }
需要留意 DSH 裝載插件時的判定行爲：只要清單聲明瞭 engines.dsh 就只認它，peerDependencies 裏那些 @deepseek-ai/dsh-* 會被忽略，比較時帶 includePrerelease: true。所以上界寫成 <0.2.2-0 這種帶 -0 的形式，等於每次 DSH 發新 rc 都會被判成不兼容，這正是 0.1.0 在 0.2.2-rc.1 上裝不上的原因。已有舊版想升級：當初用包名裝的可以在設置 → 插件 → 條目詳情頁用「更新」；從本地目錄 / link: / github: / tarball 裝的沒有「更新」入口，先移除再重新添加。README 也說明，已裝同名包時 install_bundle 直接報 already-installed，寫精確版本繞不過去，必須先移除再裝。倉庫裏的 tools/compat-check.mjs 可以脫離 DSH 復刻這個判定：
node tools/compat-check.mjs package.json
# dsh-session-console@0.1.1 engines.dsh = ">=0.2.0-rc.2 <0.3.0-0"
# dsh 0.2.2-rc.1 compatible
# ...
# ALL_COMPATIBLE
典型用法¶
下面這段是 README 給的流程，可以理解成一次完整操作。
- 打開側欄圖標進入面板，用過濾和排序找到目標會話；不確定是哪個時，在「指代與派任務」輸入一句自然語言，例如
示例項目的相關內容怎麼樣了，看候選是否鎖定。 - 鎖定後寫一句要說的話，選擇
queue或steer。目標會話如果處於冷狀態會自動恢復。 - 在詳情卡里讀最近的用戶 / 助手消息和輪次 / 工具調用 / 工具失敗 / 異常輪次統計，失敗時看最後一次失敗原因。需要完整上下文就點跳轉到那個對話。
Host 側暴露了同源 HTTP 路由（僅迴環地址可訪問）和聚合入口，客戶端面板通過這些路由取數。除了側欄面板，插件還註冊了 5 個給 agent 用的 tool，具體名稱和參數以倉庫 lib/index.js 爲準。
適用場景與注意¶
適合手裏同時開着多個 DSH 會話、需要按工作區或主題快速定位、並且希望臨時往別的會話裏派活的開發者。它的讀操作覆蓋全局 token 用量和上下文壓力，可以減少逐個點開看狀態的負擔；派任務走的是 UI 輸入通道，冷會話會恢復，消息持久化。
用之前要清楚兩點：
- 插件以當前 DSH 進程的權限運行，能看到全部會話的統計信息，也能向別的會話投遞輸入。安裝前應先讀一遍源碼，確認路由和 tool 的暴露範圍符合預期。
- 許可證是 MIT（來自
package.json），發佈憑據和內部 token 都不在倉庫裏，不屬於本插件引入的內容。
另外注意發佈節奏：插件市場的國內區域優先讀 npm 包 dsh-plugin-catalog，它只在 build-site 的 schedule / workflow_dispatch 分支發佈，所以國內目錄最遲可能滯後到次日夜間。急着看可以在「市場設置 → 下載區域」切「全球」，或直接把安裝源寫成 npm 官方源。
結尾¶
這個插件的價值在於把”翻列表找會話”這件高頻小事做成一張靜態總覽，再配一句自然語言定位和一條跨會話投遞通道。好處是顯見的：少點幾次、少切幾次窗口。不適合的場景也清楚：只需要一兩個會話、或者工作流本來就靠命令行管理的，收益有限。
