前言¶
跑一個長時間的 DSH 會話，最麻煩的不是任務慢，而是它悄悄停下來等你：模型調了 ask_user_question 在等回答、工具在申請沙箱升級等審批、輪次因爲模型 4xx 錯誤直接結束——而你在做別的事，十幾分鍾後回來看才發現它早就停了。
dsh-lark-bridge 解決的就是這個問題：它在 DSH 會話停止工作時即時調用 lark-cli 發飛書/Lark 通知，目標是做到「DSH 停止工作 = 必收到通知」。對比已有的做法（輪詢看屏幕、或者只覆蓋單一事件的腳本），它把等待交互、任務結束、被阻塞、請求退避、進程停滯、進程死亡這些情況都納入了同一套通知體系。
這是什麼¶
dsh-lark-bridge 是一個 DeepSeek Harness 插件，由 leo-lab-2026 維護，許可證爲 MIT，當前版本 0.3.0-beta.0。它是一個純只讀觀察者：只監聽 DSH 持久事件流與 agent/status 生命週期，不攔截任何執行鏈、不代答任何審批/提問。lark-cli 缺失或發送失敗時 fail-soft——只告警，絕不影響 DSH 本身。
覆蓋了哪些「停止工作」的場景¶
| 類別 | 觸發 | 通知時機 |
|---|---|---|
| 權限申請 | 工具申請審批（如沙箱升級） | 等待審批期間（約 0.5s 寬限期內被秒批則不打擾） |
| 向用戶提問 | 模型調用 ask_user_question（含 plan mode 計劃評審） |
等待回答期間 |
| 錯誤致停 | 輪次以致命錯誤結束（模型 400/401/403/配額/重試耗盡等 4xx-5xx） | 立即，每會話 5 分鐘節流 |
| 任務完成 | 輪次 completed 結束且 agent 進入 idle（5s 寬限期過濾 goal 自動續輪//loop） |
idle 寬限後，每會話 30 分鐘節流 |
| 目標阻塞 | turn/end blocked（goal 阻塞 / 預步驟拒絕） |
idle 寬限後 |
| 令牌上限 | turn/end max-tokens |
idle 寬限後 |
| 輪次中止 / 異常中斷閉合 | turn/end aborted 與 interrupted（崩潰孤兒輪在重載時閉合） |
idle 寬限後 |
| 請求退避 | llm/retry 事件達到重試閾值（默認第 2 次起） |
達到閾值即發，每會話 5 分鐘節流 |
| 無進展停滯 | agent 保持 running 但默認 10 分鐘無任何事件 |
判定即發，默認 60 分鐘重複提醒 |
| 正常退出 | 插件 dispose（僅整個應用樹卸載時，HMR/重載不誤報） | 退出時告別通知 |
| 進程死亡 | 心跳文件 + 進程外監督者檢測心跳丟失 | 心跳超時即發 |
所有通知類別都有獨立開關，默認全部開啓，噪音由寬限窗口與節流控制。通知首行默認顯示 工作區: {workspace}，多個項目並行時能一眼分辨來源。
安裝與啓用¶
前置要求：Node ^22.19 || >=24、pnpm、DeepSeek Harness（dsh）。
dsh plugin --profile <name> add dsh-lark-bridge
也可以從 GitHub 源碼安裝（需要授權構建腳本）：
dsh plugin --profile <name> add github:<you>/dsh-lark-bridge#<sha>
裝完先驗證，再重啓：
dsh --profile <name> --dump-config # 輸出中應出現 dsh-lark-notify 行
更新時注意：同 semver 範圍內的小版本/補丁用 update；跨版本或裝預發佈版（比如當前 0.3.0-beta.0）用帶顯式版本號的 add：
dsh plugin --profile <name> list dsh-lark-bridge # 查看當前安裝版本
dsh plugin --profile <name> update dsh-lark-bridge # 範圍內更新
dsh plugin --profile <name> add dsh-lark-bridge@0.2.0-beta.1 # 跨版本/預發佈升級
更新插件後需重啓 dsh 生效。
首次配置（三步）¶
1、準備飛書應用與 lark-cli¶
- 在飛書開放平臺創建企業自建應用，拿到 App ID 與 App Secret，在「應用能力」裏啓用機器人；
- 在「權限管理」開通發消息權限（
im:message或im:message:send_as_bot）；若想用setup自動配置，還需開通im.message.receive_v1事件訂閱及im:message.p2p_msg:readonly等權限； - 安裝並配置 lark-cli（憑據存於 lark-cli 自身，插件從不接觸 App Secret）：
npx @larksuite/cli@latest install
lark-cli config init
lark-cli auth status -- --verify
2、配置通知目標¶
插件安裝後默認無通知目標，需要指定一次並持久化到 settings.yaml。推薦在 DSH 會話裏運行：
/lark-notify setup
然後去飛書給機器人發任意一條消息（默認 3 分鐘窗口），插件會自動捕獲會話 chat_id 並寫入設置，同時發一條測試通知確認鏈路。也可以在 DSH Web 設置面板手動填 chatId，或在 profile 的 cordis.patch.yml 寫 YAML 作爲部署默認值。配置優先級：Web 設置面板（用戶層）> YAML（部署層）> 默認值。
3、驗證¶
/lark-notify test 你好 # 發送測試通知
/lark-notify status # 一鍵診斷：通知目標、lark-cli 狀態、發送統計、啓用類別
再真實觸發一兩個場景（讓模型申請一次審批、調用 ask_user_question、製造一次重試退避），飛書應收到對應通知。
按工作區路由通知（可選）¶
一個項目對應一個飛書羣時，可以讓每個工作區的通知發到各自的羣。在目標工作區對應的 DSH 會話裏輸入：
/lark-notify route
然後去目標飛書羣給機器人發任意一條消息（機器人需先被拉進該羣，默認 3 分鐘窗口），插件即完成「當前工作區 → 該羣」的綁定並回發測試通知。CI/批量場景可在 cordis.patch.yml 寫 routing 映射，按工作區標題精確匹配、回退路徑匹配；未綁定的通知走全局默認目標，不丟失。
進程死亡看門狗（可選）¶
進程內觀察者無法報告自己的死亡（OOM/崩潰/誤殺）。插件支持寫心跳文件，配合進程外監督者腳本覆蓋這種情況：
config:
watchdog:
enabled: true
heartbeatFile: '/tmp/dsh-heartbeat' # 插件每 5s 更新一次
監督者腳本有兩種運行方式：
# 常駐模式（默認每 staleMs/4 檢查一次）
node scripts/lark-watchdog.mjs --heartbeat-file /tmp/dsh-heartbeat --stale-ms 60000 --chat-id oc_xxx
# 定時任務模式（cron / systemd timer）
node scripts/lark-watchdog.mjs --heartbeat-file /tmp/dsh-heartbeat --stale-ms 60000 --chat-id oc_xxx --once
心跳丟失超過 stale-ms 即發「DSH 進程死亡」通知，同一死亡事件按 --repeat-ms（默認 60 分鐘）去重。
適用場景與注意¶
適合把 DSH 當長時間後臺工人用的人：掛着一堆會話跑任務、多工作區並行、或在無人值守環境裏跑批。通知內容支持模板變量（sessionId、workspace、time、tool、reason、errorLabel 等），可按需調整格式。
使用前幾點注意：
- 插件以當前
dsh進程的權限運行，安裝第三方插件前建議先檢查其源碼與許可證（本插件爲 MIT）； - 需要自建飛書應用並開通對應權限，lark-cli 憑據由 lark-cli 自行保管，插件不接觸 App Secret；
- 發送鏈路是 fail-soft 的，lark-cli 出問題只告警，不會拖垮 DSH 會話。
結尾¶
dsh-lark-bridge 把「會話停了沒人知道」變成「一停就收到飛書通知」，覆蓋從等待審批到進程死亡的完整鏈路，且以只讀觀察者的方式接入，不影響 DSH 本身的執行。
- 插件目錄頁：https://www.skillhub.cn/plugins/leo-lab-2026/dsh-lark-bridge（社區維護的獨立目錄站點，與 DeepSeek / 幻方無官方從屬關係）
- 源碼倉庫：https://github.com/leo-lab-2026/dsh-lark-bridge
