前言¶
用 DSH 跑多個任務時，一個常見的失控是消息路由錯了：用戶本意是給 A 任務補充需求，消息卻進了 B 會話，模型照着 B 的上下文繼續執行，產出一堆和當前任務無關的操作。等到發現時，有的寫入已經發生，很難判斷哪些動作屬於這次誤路由、哪些是早前正常執行的。已有的做法要麼靠人盯住對話，要麼事後翻日誌人工歸因，成本高且容易漏。
下面介紹的 myboker/dsh-conversation-guard 就是針對這一處做攔截和留痕的社區插件，屬於「工作流」分類。它不替代 DSH 的權限體系，而是在消息進入模型前做一次任務歸屬判斷。
這是什麼¶
dsh-conversation-guard 是 DeepSeek Harness 的獨立社區插件，維護者爲 myboker，許可證 MIT。它的位置是：給會話確立一個任務身份，用分類模型判斷新進來的一批消息是否屬於該身份；若疑似誤路由、顯式切換任務或信息不足，就在執行前暫停，由人來確認；如果已經在錯誤會話裏做了工作，插件可以把這段工作的摘要和證據索引導出成一份可複查的交接記錄。
它明確不是官方組件，也不承諾兼容其他 DSH 預發佈版本。當前社區預覽版本是 0.1.0-rc.3。
核心功能¶
1、任務身份綁定。會話裏第一條人類消息確立任務身份；也可以顯式用 /guard task Fix the web-auth login form 指定。後續的可疑消息無法悄悄改寫這個身份。建議每個任務使用單獨會話，在既有長會話裏啓用插件時先顯式設置任務。
2、批量消息准入。插件把「當前任務、候選消息、以及最多四個已接受批次的有限上下文」交給分類模型。默認分類模型是 deepseek-v4-pro，接口地址 https://api.deepseek.com。確認是按批進行的，不支持把批次裏某一條消息單獨拆出來放行。
3、審批不等於授權。放行只說明這批消息屬於本會話，不擴大既有權限、工作目錄或 Super-agent Mandate。檢查失敗、附件、超大消息一律需要人工複覈。
4、回調與交接。模型確認前，插件先把整批消息落庫；之後可用命令複查。當用戶發現工作其實做錯了會話，Agent 可調 conversation_guard_handoff 記錄摘要、已執行動作、產物、驗證情況、外部影響或後臺任務、剩餘工作，並導出帶證據引用的本地 Markdown。
5、證據有邊界。證據通過原始消息 ID、真實模型調用邊界、步驟、工具調用 ID、任務創建關係來定位，排除之後無關請求。模型一個步驟處理多個請求或舊日誌缺少調用邊界時，記錄標記爲 mixed。沒有記錄到關係的活動不會按時間順序臆斷歸屬。導出會凍結證據清單，後到的日誌不會偷偷改掉報告。
安裝與啓用¶
插件以 tgz 形式發佈。先下載 GitHub Release 中的 dsh-conversation-guard-0.1.0-rc.3.tgz，再按下面命令安裝並檢查配置。安裝會基於 DSH 基礎模板創建一個 profile（guard-demo），請使用未佔用的名字，--from-default-profile 會覆蓋同名 profile。
dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz
dsh --profile guard-demo --dump-config
若需要交互界面，先從官方 web 或 tui 模板創建 profile，再裝插件：
dsh --profile guard-demo --from-default-profile web --dump-config
dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz
吊銷分類模型的 Key 由環境變量在啓動時讀取，不寫進插件配置。要在啓動 DSH 的進程環境裏設置 DEEPSEEK_API_KEY，再運行 dsh --profile guard-demo。在 DSH 的 Models 頁面保存 Key 並不會設置分類器用的環境變量。
分類器相關配置寫在 profile 的 cordis.patch.yml 中，可覆蓋的字段如下：
- id: conversation-guard
config:
stateDirectory: /absolute/private/path/conversation-guard
apiKeyEnv: DEEPSEEK_API_KEY
model: deepseek-v4-pro
baseUrl: https://api.deepseek.com
timeoutMs: 30000
questionTimeoutMs: 45000
環境要求：Node.js 24.9 及以上，DSH 0.2.2-alpha.3 或 0.2.2-rc.1（package.json 的 engines 字段與 README 表述一致）。
典型用法¶
啓用插件後，第一批讓模型執行前發生可疑判斷的消息會先被整批保存，支持原生提問的界面會彈出確認提示。若沒有提問界面或提示超時，消息仍然保留，可以用命令處理：
| 命令 | 行爲 |
|---|---|
/guard status |
顯示當前任務、該批消息預覽和確認 token |
/guard review |
重新打開該批的原生確認提示 |
/guard allow TOKEN |
明確允許該批在當前會話繼續 |
/guard cancel TOKEN |
取消整批，同時保留記錄 |
/guard history |
列出本會話已保存的批次 ID |
/guard handoff BATCH_ID |
導出摘要和引用，生成本地 Markdown |
/guard evidence HANDOFF_ID [CURSOR] |
查看證據索引或按游標讀取片段 |
/guard task NEW_GOAL |
在無待審批批次時改變普通會話的任務身份 |
只發一句“繼續”、一段工具輸出、一段引用文本或來自別的會話的確認 token，都不能放行某批消息。批次掛起期間收到的新消息會合並進該批，並替換它的確認 token，從而保留“按我上面說的做”這類依賴關係。要切換任務，先取消掛起批次，再設定新目標並提交新任務。
交接記錄的證據瀏覽支持分頁：
/guard evidence HANDOFF_ID
/guard evidence HANDOFF_ID index:20
/guard evidence HANDOFF_ID 3:0
第一條顯示索引，index:20 翻到下一頁索引。記錄的 read_cursor 指向正文，next_cursor 指向下一段。每頁正文最多 4000 字符，長輸出可以分頁讀完，不必截尾。索引頁最多 20 條。原始完整日誌仍留在 DSH，插件存引用而不是複製整段轉寫。證據只能從來源會話查詢，且需要同時具備原始 DSH 日誌和插件數據庫；被刪除或改動的記錄會報告爲不可用。
適用場景與注意¶
適合在多任務並行、單個會話長期承接不同目標時使用，尤其是誤路由後需要界定“哪些動作是哪次請求引起的”場景。它的交接導出給出了可複查的摘要和證據引用，而不是完整轉寫。README 中記錄的 Demo 明確說明：運行時和插件是真實運行的，分類器和 worker 的響應是腳本化的，因此這不是模型準確率演示。
使用前注意幾點：插件以當前 DSH 進程的權限運行，放行只確認消息歸屬，不改變權限邊界；它在設計上要求會話中按任務區分清楚，啓用插件的既有長會話應先顯式設定任務；重啓後殘留消息不會自動執行，需要回到原會話用 /guard status 判斷。測試數據爲合成數據，插件只聲明兼容上述兩個 DSH 預發佈版本和 Node.js 24.9+。安裝前應檢查插件源碼與許可證。
結尾¶
dsh-conversation-guard 解決的問題很具體：會話消息屬於哪個任務、誤路由後如何交接。它把“判斷是否放行”和“留一份可複查的證據”這兩件事放進同一套命令裏，不需要改變 DSH 本身或現有工作流。項目目錄頁在 https://www.skillhub.cn/plugins/myboker/dsh-conversation-guard ，源碼與 Release 在 https://github.com/myboker/dsh-conversation-guard 。
