前言¶
DSH 的內置插件 @deepseek-ai/dsh-session-log-deepseek 只處理走官方適配器的會話。如果你的模型渠道是 ollama-local、pi-ai 或任意 OpenAI 兼容端點，這段會話的日誌永遠不會被上傳，官方收集端缺少這部分數據。
dsh-session-log-upload 就是要補這個缺口。它是第三方項目，維護者是 3418244301q-star，採用 MIT 許可證。它和內置插件共用同一個水位（watermark），因此兩條路徑共存、不重複。
這是什麼¶
一句話：把由非官方渠道驅動的會話產生的規範會話日誌，用你自己配置的 DeepSeek API 憑據，作爲一次最小 chat 請求的頂層字段 dsh_session_log 發往 api.deepseek.com。
隨日誌上傳的內容包含你的提問、模型回覆、工具調用與工具返回、時間戳和會話標識。官方渠道的會話不由它上傳，那部分仍交給內置插件。
它刻意選擇了和內置插件相同的水位寫法 session-log-deepseek/delivery-accepted，兩條路徑摺疊同一個水位，誰先傳誰推進，另一邊自然跳過。代價是：屬於官方窗口的那一段，只有內置插件能推水位，本插件推不動。
核心能力¶
只處理待傳區間內出現過非官方 provider 的會話。判定依據是 request/header 事件的 data.header.config.provider。整段都是 deepseek-official 的會話交給內置插件。
上傳方式不是直連 OTLP 收集端，而是借道一次最小 chat 請求，承載的仍是服務端本來就認識的字段 dsh_session_log，服務端不需要新增解析邏輯。這也是它與同類插件 yihefeikong-rgb/dsh-session-log-universal 的主要取捨：後者全量重傳並各記一份水位，目標是覆蓋面；本插件追求零重複。
觸發檔位三選一：manual 僅手動、deferred 收尾與空閒、realtime 每輪實時。默認 deferred 是爲了不把每次 turn 都換成一次 HTTP 請求。deferred 檔在 turn/end 後起 idleDelayMs 計時，期間有新事件就重置。
失敗處理是至少一次語義：失敗不寫水位，會重試。單段超限只告警一次，水位不前移。全侷限流超限後排隊而非丟棄。
配置¶
cordis.patch.yml 裏給出了默認值，enabled 默認 false，關着就是零網絡活動。
| 鍵 | 默認 | 說明 |
|---|---|---|
enabled |
false |
關着就零網絡活動 |
mode |
deferred |
manual / deferred / realtime |
apiKeyRef |
DEEPSEEK_API_KEY |
走 ctx.credentials；取不到再退回同名環境變量 |
model |
deepseek-flash |
承載請求用的官方模型 |
maxBytes |
8388608 |
單段上限，與內置插件一致 |
idleDelayMs |
600000 |
deferred 檔空閒判定 |
includeSeeded |
false |
是否也傳 seeded 子會話（只傳繼承段之後） |
budget.maxRequestsPerHour |
60 |
全侷限流，超限排隊而非丟棄 |
retry.maxAttempts / baseDelayMs |
3 / 2000 |
指數退避重試 |
安裝¶
README 沒有給出寫死的安裝命令，只說它是 Host 插件，需要 dsh 的插件管理能力或 plugin_manager，安裝到某個 profile。bundle 清單在 cordis.patch.yml，默認 enabled: false。
因此安裝方式取決於你宿主的版本與插件管理方式。從 Release 拿包的話，每個 tag 的 Release 附 dsh-session-log-upload-X.Y.Z.tgz（npm pack 產物），可以直接 pnpm add <文件> 離線安裝，旁邊還有 SHA256SUMS-X.Y.Z.txt 可覈對字節。
安裝後它還帶一個客戶端注入部分，依賴 dsh-client-locale 和 dsh-client-ui-settings。宿主缺少這兩個包時，設置行不會出現，且不報錯。
版本要求：DSH 本體 dsh.engines.dsh: ">=0.2.1-rc.3"，本機實測 0.2.1-rc.5；@deepseek-ai/schemastery 需要 ^3.18.4，用到 .volatile()，舊版會報 ...volatile is not a function。
有一個 semver 盲區值得注意：engines.dsh 寫的是 >=0.2.1-rc.3，node-semver 只有在範圍內存在相同 tuple 上的預發佈比較符時才放行預發佈版本。0.2.2-rc.1 因此會被排除。被排除不是報錯，而是從市場的兼容篩選裏靜默消失。維護動作是每次 DSH 進新的預發佈 minor，把 engines 改成覆蓋該 tuple 的形式，例如：
"engines": { "dsh": ">=0.2.1-rc.3 <0.2.2-0 || >=0.2.2-rc.1" }
典型用法¶
啓用入口在「設置 → 通用」。官方那行「在使用官方模型 API 時上傳 Session Log」（order 90）下面新增一行 order 91：左邊標題加說明，右邊是模式下拉和一個開關。enabled 與 mode 都是 volatile，選完立即生效，不用重啓。
啓用有一道前置檢查和一個風險確認：
- 點擊開關時先查一次有沒有可用的 API key，沒有就取消啓用，並在行裏留一條「未檢測到可用的 API Key」的提醒（帶「重新檢測」）。
- 有 key 時彈官方那個確認框（與「設置 → 權限」切「完全權限」同款組件），裏面寫明日誌去向、不做脫敏、自動觸發與合規責任，勾選「我已瞭解風險，並願意繼續」後才能點「啓用上傳」。關閉不需要確認。
部分檔位的操作：
- 左側文字區下方有「立即上傳」按鈕，只有檔位選「僅手動」時可用，其它檔位爲灰色並給原因提示。點擊後按順序判定插件未開啓 / 已有任務在跑 / 30 秒冷卻 / 當前已是最新 / 未配置 key / 已上傳 N 個會話，結果用一行內聯文字顯示，6 秒後自動消失。
manual檔不註冊定時器、不監聽turn/end，零網絡活動，啓動掃描只打日誌。realtime檔每次turn/end入隊，同會話重複入隊合併。
啓動後 5 秒掃一次活着的會話，補崩潰或強殺漏掉的收尾。卸載時清空隊列與所有定時器。
適用場景與注意¶
適合已經在用非官方模型渠道、又想讓這部分會話日誌進入 DeepSeek 收集端、同時不希望與內置插件重複上報的開發者。
風險方面要逐條看清楚：
- 默認關閉，啓用後纔有網絡活動；插件以自動化方式構造並觸發請求，可能被官方或第三方服務認定爲自動化請求，存在賬戶受限或服務條款風險。
- 不提供脫敏、合規審查、數據授權管理或內容過濾。上傳前是否脫敏、是否取得授權、是否允許轉發，全部由使用者自行負責。
- 依賴 DSH 官方 API 的當前行爲，而該行爲不是正式公開接口，可能隨時變更、失效或被限制。
- 顯式聲明的失效場景包括：水位之後第一個請求走官方渠道且內置插件沒在推水位時該會話會永久停擺；單條事件大於
maxBytes時一個請求都發不出去；API key 缺失或失效時完全不工作，且 401/403 不重試；會話已不活躍時啓動掃描覆蓋不到（非活會話沒有Session對象，無法落水位）。 - 無法證明服務端真的入庫，2xx 是唯一信號。
- 作者不對任何直接或間接損失承擔責任，使用即表示你確認已閱讀並同意相關條款、已取得必要授權、並自行承擔合規與數據風險。
安裝前應檢查源碼與許可證，並確認它依賴的內部契約在你當前的 DSH 核心版本上仍然成立。
結尾¶
這個插件的價值在於補齊而非替代：用與內置插件相同的水位和字段，把非官方渠道那段日誌不重複地送回 DeepSeek。如果你要的是官方會話也留一份完整臺賬並接受重複，那屬於另一類插件的取捨。
目錄頁：https://www.skillhub.cn/plugins/3418244301q-star/dsh-session-log-upload
GitHub：https://github.com/3418244301q-star/dsh-session-log-upload
