前言¶

DSH 自帶的消息通道是有前提的：send_message 只在直接父子 agent 之間傳，Agent Teams 只在同 Team 成員之間傳，側欄裏兩個普通會話之間沒有路。想做跨會話交接（A 會話讓 B 會話查回歸結果、順手新開會話寫 CHANGELOG），以前只能靠人手動複製粘貼。本插件 tonyzdev/dsh-session-messaging 補的就是這條缺的通路：給每個頂層會話加三個工具，找會話、發消息、開新會話，收到的消息標明來源，對方用同一個工具回覆。下面按功能、安裝、用法、設置、注意事項的順序介紹。

插件身份與來源¶

• 維護者：tonyzdev，社區維護，非 DeepSeek 官方。
• 分類：工作流（社區目錄 SkillHub 歸類）。
• 社區熱度：GitHub 20 stars、4 forks，社區插件規模偏小，功能邊界也小而明確。
• 許可證：MIT。
• 源碼與發佈：https://github.com/tonyzdev/dsh-session-messaging，包名 @tonyzdev/dsh-session-messaging。

本插件不調用模型、不需要額外 API key，價值純粹在「會話之間能說話」這一件事上。安裝前建議先讀一遍 README 和源碼，確認它正是你需要的轉發行爲。

核心功能¶

三個工具，作用正交，不改 DSH 原生會話模型。

1. session_list：按最近活躍列出可發消息的頂層會話，返回 id、運行中/空閒、標題。默認只看當前工作區，也可以列全部工作區或按標題搜索。
2. session_send_message：把消息送到另一個會話。運行中的會話下一步讀到；空閒的會話立即開始新一輪；已存儲（未加載）的會話先恢復再處理。帶 delivery: "queue" 時等對方這一輪結束後再開新一輪。
3. session_create：在側欄新開一個帶標題的會話，並用你的消息開始第一輪。新會話獨立幹活，看不到發起方的對話；想讓它回報，就在消息裏寫清楚。

來源標註是獨立的一環：收到的消息顯示爲用戶側氣泡，上方寫「來自會話「標題」」。模型看到的是一行來源說明——哪個會話發的、由對方的 agent 而不是用戶撰寫、怎麼回覆。說明結尾提醒對方不要只爲確認收到而回復，避免兩個會話來回「收到」「好的」停不下來。

邊界也在功能裏一起說明了，後面會展開。

安裝與啓用¶

前置條件只有一條：DeepSeek Harness 0.2.0+（README 提到已在 macOS 版 0.2.1-rc.5 上實測）。engines 字段寫的是 >=0.2.0-rc.1 <0.3.0-0。

方式一：讓 DSH 自己裝（推薦）¶

把下面這句話直接發給任意 DSH 會話，agent 會自動識別桌面端或網頁端完成安裝並熱加載。bash 與 PowerShell 取 profile 的方式不同，命令裏都寫了。

請幫我在當前 DSH profile 安裝插件 https://github.com/tonyzdev/dsh-session-messaging：若有 plugin_manager 工具請直接調用 install_bundle 安裝並啓用；否則讀取當前 profile 名（bash 爲 $DSH_PROFILE，PowerShell 爲 $env:DSH_PROFILE；爲 desktop 時調用 app.asar 同級 runtime/cli/bin 下的 dsh 或 dsh.cmd，其他情況用 PATH 中的 dsh，受沙箱限制時申請全盤權限審批）執行 dsh plugin --profile <profile> add github:tonyzdev/dsh-session-messaging，不要手改配置文件或重啓宿主。

方式二：界面手動裝¶

側欄打開 插件 → 添加插件，填入完整倉庫地址，點 安裝，再點 立即啓用。如果轉發氣泡樣式還沒出現，按 ⌘R / Ctrl+R 刷新頁面。

https://github.com/tonyzdev/dsh-session-messaging

README 特別提醒：這裏要填完整 GitHub 倉庫地址，不要只填 dsh-session-messaging。npm 上同名無前綴包由其他作者維護，裝錯了不是本插件。

命令行與預打包安裝¶

網頁端走 profile web：

dsh plugin --profile web add github:tonyzdev/dsh-session-messaging

桌面端走應用內置 CLI（路徑與平臺有關）。macOS：

DSH="/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh"
"$DSH" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

Windows（PowerShell）：

& "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

README 註明，裝了 Desktop 的機器上跑 --profile web 只會裝進 profiles/web，不會出現在桌面端界面裏。桌面端要用上面的內置 CLI 指向 --profile desktop，或直接在界面裝。

也可以裝預打包的 Release .tgz，不走完整 Git 拉取：

dsh plugin --profile web add https://github.com/tonyzdev/dsh-session-messaging/releases/download/v0.3.2/tonyzdev-dsh-session-messaging-0.3.2.tgz

本地開發用 link 方式安裝，改代碼直接作用於該副本：

git clone https://github.com/tonyzdev/dsh-session-messaging ~/.dsh/local-plugins/dsh-session-messaging
"$DSH" plugin --profile desktop add link:$HOME/.dsh/local-plugins/dsh-session-messaging

移除方式：

"$DSH" plugin --profile desktop remove @tonyzdev/dsh-session-messaging

打個補丁配置項¶

改配置走 profile 補丁文件，不要手改其他配置。桌面版補丁路徑是 ~/.dsh/profiles/desktop/cordis.patch.yml，只寫要改的字段，沒寫的用默認值：

- id: session-messaging
  config:
    crossWorkspace: false

保存後生效；沒生效就重啓 DeepSeek Harness。

典型用法¶

不需要背工具名，直接告訴 agent 要做什麼。下面三句都來自 README 示例，可直接複製到會話裏試：

問問「修復登錄超時」那個會話：bug 修好了嗎？改了什麼？

告訴「前端重構」那個會話：接口字段 user_id 改名爲 uid 了。

開一個新會話，讓它把這條修復寫進 CHANGELOG.md，寫完告訴我。

對應到工具參數，對照這張表更清楚：

有一點要明確：工具只返回送達確認，不返回對方的回答。回答會作爲一條新消息回到發送方會話，從氣泡或下一輪裏讀。

設置項¶

README 給出四個可配項，默認值如下：

想收緊跨工作區訪問，把 crossWorkspace 設爲 false 即可，這是默認值唯一可能想動的項。

實現方式（簡要）¶

說明實現，是爲了解釋爲什麼有些限制存在，也幫你判斷能否擴展。

消息轉發走 sessionController.resolveAgent，和網頁端發送 prompt 是同一條路徑，必要時從存儲冷恢復會話。消息帶 DSH 內置的轉發來源 { kind: 'agent-message', form: 'relay', senderSessionId }，寫進對方的會話日誌。瀏覽器端覆蓋 Chat 的 turn-trigger 渲染器，只接管本插件轉發的消息，複用 DSH 自帶的 conversation.chat.user.content 氣泡；目標、定時任務、子 agent 等其他觸發消息仍走原生卡片。所以模型收到的內容不變，只改顯示。

開新會話走 sessionController.create({ workspaceId })，也就是網頁端「新對話」的路徑。第一輪開始前會先改好標題，因爲轉發消息不觸發 DSH 的自動起標題——這也解釋了爲什麼 session_create 設的標題之後不會被自動改寫。

主要文件對應關係：

子 agent 在 agent/created 時用 agent.ctx.tools.restrict({ deny }) 隱藏這三個工具，所以子 agent 無法經這條通道收到回覆。

已知限制與防範¶

這些是 README 明確列出的，決定了你把它用在什麼場景合適。

1. 被喚醒或新開的會話按自己的設置運行。新開的會話用默認模型和默認審批策略（README 提到實測爲 ask），不繼承發起會話的設置。它若需要審批，審批請求停在那裏，可能沒人看。
2. 只在頂層會話之間通信；子 agent 和 Team 成員仍用 DSH 自帶的 send_message。
3. 「送達」只代表對方收件箱接受了消息，不代表已處理；沒有重試、去重或已讀回執。
4. 對方正在運行時收到的消息併入它這一輪，模型能收到，但不顯示成氣泡；只有喚醒會話的消息顯示爲氣泡。
5. 氣泡不渲染 Markdown，也不折疊很長的消息。
6. 發消息沒有頻率限制；防來回客套靠來源說明裏的提示。createLimit 存在內存裏，插件重載或重啓後清零，也不限制「A 開 B、B 再開 C」這樣的鏈條。
7. session_create 設的標題像手動改名一樣固定，DSH 之後不再自動改。

適用場景¶

適合這些情況：

• 需要跨會話交接的頂層 agent。比如一個會話專做代碼改動，另一個會話專做發佈整理，前者把結果寫進消息，後者醒來讀取。
• 想要派生獨立任務。主會話開一個新會話寫文檔或跑一次獨立驗證，不想暴露自己的對話上下文。
• 想用自然語言而不是工具調用去編排：「問問那個會話有沒有修好」。

不適合這些情況：

• 需要可靠回覆保證的流程。沒有重試和去重，消息可能丟了或只到達對方某一輪的中間。
• 子 agent 之間需要收發消息。這條通路不覆蓋子 agent，仍是 DSH 原生 send_message。
• 需要審批隔離的場景要謹慎。被喚醒的會話用默認審批策略，可能停下等人。

收尾¶

一句話回顧：tonyzdev/dsh-session-messaging 在 DSH 頂層會話之間補了一條甘草通路，加了三個工具，把跨會話交接從手動複製降級爲一句自然語言，代價是保留了 DSH 原有的頂層邊界，並帶來幾條明確的能力邊界。如果你的工作流裏確實需要「A 問 B、B 派生 C」，先按上面的安裝方式熱裝試一輪，確認限制與你預期一致再納入常規流程。

• 目錄頁：https://www.skillhub.cn/plugins/tonyzdev/dsh-session-messaging
• GitHub：https://github.com/tonyzdev/dsh-session-messaging