前言¶
在 DeepSeek Harness（DSH）裏開多個會話並行做事時，常見做法是人爲切換窗口、複製粘貼上下文，或等某個會話跑完再口頭交代下一步。同一 DSH 進程裏，會話 A 裏的智能體無法直接給會話 B 注入一條「用戶消息」並喚醒 B 繼續一輪推理。
dsh-peer-message 是 respawnlife 維護的 Host-only 插件，在同一 DSH 進程內向其他會話投遞消息並喚醒目標會話。下面介紹它的定位、工具參數、安裝方式、典型用法與安全邊界。
這是什麼¶
- 名稱：dsh-peer-message（npm 包名一致，當前版本 0.1.1，MIT 許可證）
- 維護者：respawnlife
- 倉庫：https://github.com/respawnlife/dsh-peer-message
- 能力：通過
peer_list、peer_send兩個工具，讓當前會話把文本消息投到另一會話，並按目標狀態選擇followup（新開一輪）或steer（在運行中的下一步邊界插入）；不向公網發請求，不讀寫工作區文件，只讀會話元數據（id、標題、工作目錄、狀態）。
DSH 0.2.x 自帶 team-message / agent-message 等消息源；本插件是獨立的進程內實現，只走 agents 服務，不接入官方 team 通道，可與內置能力共存。
核心功能¶
投遞流程（概念）¶
Conversation A（用戶正在對話的會話）
└─ peer_send(to: "report session", message: "take care of xxx")
└─ agents.get(sessionId).followup(userMessage)
└─ Conversation B 收到一條用戶消息並開啓新回合
典型用途包括：並行會話間委派或交接任務、讓另一會話做校驗、任務完成後向其他會話彙報。
工具一覽¶
| 工具 | 參數 | 作用 |
|---|---|---|
peer_list |
query?、scope?（workspace / all）、limit?（默認 30，最大 100） |
列出可投遞的會話（id、標題、工作目錄、是否已加載/運行），並標記當前會話；默認僅當前 workspace |
peer_send |
to（會話 id / id 前綴 / 標題）、message、mode?（auto / steer / followup） |
投遞消息並喚醒目標；成功時返回目標會話、實際使用的 mode、是否已喚醒 |
mode 含義：
auto（默認）：目標空閒 →followup新開一輪；目標運行中 →steer在下一步插入。steer：強制插入（僅目標運行中才有步驟邊界）。followup：強制新開一輪；若目標正在運行則降級爲steer，避免消息被吞掉。
限制：不能發給自己；單條消息正文上限 20000 字符；目標未加載時會先喚醒再投遞。
消息在界面上的表現¶
正文會加上前綴 【跨會話消息 · 來自 DSH 會話"標題"(id)】，便於在日誌裏辨認來源；UI 仍按普通用戶消息渲染，無單獨卡片或來源徽章。
環境與依賴¶
- DSH：
>=0.2.2-rc.1 <0.3.0-0（0.2.x 線，含 prerelease；在0.2.2-rc.1上測試過；上界排除 0.3 prerelease） - Node.js：
>=22（與 DSH 捆綁運行時一致即可） - 無 npm 運行時依賴，無構建步驟；Host-only bundle
安裝與啓用¶
安裝前請確認 DSH 版本落在上述區間。官方 README 給出兩條路徑，按你當前 DSH 支持的能力二選一。
1. 用插件管理器安裝目錄（常規 Host-only 方式）¶
使用 plugin_manager 的 install_bundle，將 target 設爲該插件目錄的絕對路徑。
2. 本地開發 link¶
- 在 profile 的
package.json的dependencies中加入："dsh-peer-message": "link:/path/to/dsh-peer-message"（將路徑換成你本機克隆或解壓後的目錄）。 - 在
dsh.profile.bundles中加入dsh-peer-message。 - 讓插件管理器完成安裝；不要手寫 profile 的 patch 文件。
安裝完成後，該 profile 下的每個會話都會獲得 peer_list / peer_send，重啓後仍保留。
卸載¶
- 用插件管理器
remove_bundle，或set_plugin且enabled: false；或 - 從 profile 的
package.json的dependencies和dsh.profile.bundles中移除，然後重啓 DSH。
卸載後兩個工具消失，不再注入新消息；已投遞到目標會話的消息不會撤回。
典型用法思路¶
- 在當前會話調用
peer_list，必要時用query過濾、scope: "all"看全進程會話（列表過濾不等於權限邊界）。 - 用返回的 id、id 前綴或標題作爲
peer_send的to。 - 寫好
message；需要強制行爲時指定mode。 - 在目標會話中把這條消息當作用戶輸入處理，繼續原有工作流。
README 中的示例語義：peer_send(to: "report session", message: "take care of xxx")，表示從會話 A 向標題或標識爲 report session 的會話 B 投遞任務說明。
安全邊界（安裝前建議通讀）¶
peer_send 是模型可自行觸發的有副作用操作，效力等價於在進程內跨會話寫入一條用戶消息：
- 無需人工確認：運行中的智能體可在同一 DSH 進程內向任意會話投遞消息；若需人工把關，應通過 DSH 的工具審批 / 權限策略限制該工具。
- 接收方視爲用戶消息：目標會話按你的輸入處理，存在提示注入橫向移動風險；
workspace僅影響列表範圍，不是隔離邊界。 - 喚醒消耗配額：未加載的會話會通過 host 的
sessionController.resolveAgent()喚醒並可能開啓新回合，觸發模型調用、token 與工具副作用。 - 範圍：僅當前 DSH 應用進程；無跨進程、跨機器、無網絡。
- 信任環境：建議在可信的單用戶環境啓用；不要把
peer_send暴露給不可信的提示來源（例如自動抓取的網頁或外部消息通道）。
插件以當前 DSH 進程的權限運行；安裝前請自行查看源碼與 MIT 許可證條款。
實現要點（供排查兼容問題時參考）¶
Host 側複用進程內已有服務：agents（get / list、followup / steer）、sessionQuery / sessions 列會話與標題、sessionController.resolveAgent 喚醒未加載會話。消息結構爲進程內 user 消息，source.kind 爲 plugin:peer-messaging。工具通過 DSH Host 插件形式 export function apply(ctx, config) 註冊。
與 DSH 內部 API 的耦合無公開穩定性承諾；engines.dsh 在 package.json 中聲明爲 >=0.2.2-rc.1 <0.3.0-0。
結尾¶
dsh-peer-message 解決的是同一 DSH 進程內「會話 A 通知並喚醒會話 B」的落地問題，適合並行多會話協作、校驗與回報類工作流。社區目錄頁：https://www.skillhub.cn/plugins/respawnlife/dsh-peer-message；源碼與完整說明：https://github.com/respawnlife/dsh-peer-message。
