前言¶
在 DeepSeek Harness（DSH）裏，多個子智能體往往以獨立的 Cordis 會話並行跑在同一份任務上。彼此看不到對方的中間產物，也缺少統一的「等人就緒再繼續」機制，常見結果是接口約定重複起草、切片之間對不齊，或者爲了等依賴而用輪詢浪費模型回合。
下面介紹社區插件 dsh-subagent-comms（倉庫 SBBW512/DSH-Subagent-Comms，目錄頁 SkillHub）。它在當前 DSH 工作區內提供內存級發佈/訂閱與黑板存儲，讓兄弟子智能體可以交接契約、阻塞等待依賴、讀取共享狀態，以及廣播輕量進度——不依賴外部消息隊列，運行時零第三方依賴（僅使用 Node 標準庫 node:events）。
這是什麼¶
- npm 包名：
dsh-subagent-comms（當前資料版本 1.0.1） - Cordis 插件名：
peer-sync（通過dsh.bundle.patch加載./cordis.patch.yml） - 維護者：SBBW512
- 許可證：MIT（見倉庫
package.json） - 分類：工作流（社區目錄歸類）
安裝並重啓 DSH 後，智能體工具列表中會出現四個固定名稱的工具：peer_publish、peer_read、peer_await、peer_broadcast。
核心功能¶
進程內 Pub/Sub 與黑板¶
每個 topic + key 對應一條可覆蓋寫入的記錄；同鍵再次 peer_publish 按後寫覆蓋更新，並重新計算 TTL。訂閱側通過 peer_await 在內存裏等待指定鍵發佈，無需輪詢循環，也無需額外消耗 LLM token 去「盯着」是否就緒。
四個工具的分工¶
| 工具 | 作用（據 README） |
|---|---|
peer_publish |
向某 topic:key 寫入載荷（可用 payload_json 傳入 JSON 結構） |
peer_await |
阻塞等待指定 topic:key 被髮布，支持 timeout_ms |
peer_read |
隨時讀取黑板上當前值及 published_at 等元數據 |
peer_broadcast |
向主題的滾動廣播環緩衝投遞輕量進度/狀態消息 |
工作區隔離¶
存儲與事件按 exec.agent.workspaceId 劃分；若無 workspace id 則回退爲字面量 default。不同 workspace 下相同的 topic:key 互不可見。每個 workspace 擁有獨立的鍵值表、EventEmitter 與廣播緩衝。
TTL 與體量限制¶
peer_publish 可選 ttl_seconds，默認 3600 秒；後臺約每 60 秒清掃過期項。過大載荷會被拒絕而非截斷（README 有說明）。初始化失敗時以 [peer-sync] 前綴記錄日誌，而不拖垮宿主。
運行環境¶
- Node.js：
^22.19.0 || >=24.0.0 - DSH 機制：通過
ctx.tools.register註冊工具，經標準 bundle patch 加載；README 寫明僅在當前打包 DSH 構建上做過驗證，其他版本未測試。
安裝與啓用¶
新裝插件或工具後必須重啓 DSH，四個 peer 工具纔會出現在註冊列表中。資料給出三條路徑；生產或常規使用可優先 npm 或 手動複製（下文不展開 git 本地鏈接流程）。
方式一：npm（資料 Route 2，包發佈後適用）¶
進入目標 profile 目錄，例如：
cd ~/.dsh/profiles/<name>
安裝包：
npm install dsh-subagent-comms
在同一 profile 的 package.json 中，把 bundle 名稱加入 dsh.profile.bundles：
"dsh": {
"profile": {
"bundles": [
"dsh-subagent-comms"
]
}
}
然後重啓 DSH。
方式二：手動安裝（資料 Route 3）¶
- 將
dsh-subagent-comms目錄放到profiles/<name>/node_modules/dsh-subagent-comms。 - 在 profile 的
package.json的dependencies中加入"dsh-subagent-comms": "*"。 - 同樣在
dsh.profile.bundles中加入"dsh-subagent-comms"。 - 重啓 DSH。
典型用法：四個步驟的協作模式¶
README 用「垂直切片」場景演示：Worker A 發佈接口契約，Worker B 等待並實現客戶端，雙方還可廣播進度。下列 JSON 爲工具調用參數示例，可直接對照智能體側 tool 調用格式。
步驟 1：Worker A 發佈契約或構件
{
"topic": "contracts",
"key": "AuthService",
"payload_json": "{\"version\":\"1.0.0\",\"endpoints\":[\"/login\",\"/logout\",\"/refresh\"]}"
}
步驟 2：Worker B 用 peer_await 等待，無需輪詢
# 工具名：peer_await
{
"topic": "contracts",
"key": "AuthService",
"timeout_ms": 60000
}
A 發佈後，peer_await 以 resolved 狀態返回載荷。
步驟 3：Worker B 用 peer_read 查閱黑板
{
"topic": "contracts",
"key": "AuthService"
}
返回示例（README）：
{
"found": true,
"topic": "contracts",
"key": "AuthService",
"payload": {
"version": "1.0.0",
"endpoints": ["/login", "/logout", "/refresh"]
},
"published_at": "2026-11-07T00:00:00.000Z"
}
步驟 4：任一方 peer_broadcast 進度
{
"topic": "contracts",
"sender": "worker-A",
"message": "AuthService contract published and ready for consumption"
}
經過上面的步驟，並行子智能體可以在同一 workspace 內完成「發佈—等待—讀取—通告」閉環，而無需把中間狀態寫進各自孤立的會話上下文。
適用場景與注意¶
適合誰
- 在同一 DSH workspace 內跑多個子智能體，需要共享接口契約、構建產物描述或階段性結論。
- 希望依賴方用
peer_await做確定性等待，而不是用提示詞輪詢或重複推理。 - 接受進程內、易失存儲：重啓宿主或 TTL 過期後數據不再保留，不適合當作持久化數據庫或跨機器總線。
安全與權限
插件隨當前 DSH 進程權限運行，數據停留在該進程內存中。安裝前應閱讀倉庫源碼與 MIT 許可證，確認與組織策略一致。社區目錄 SkillHub 與 DeepSeek / 幻方無官方從屬關係；DSH 生態強調「一切皆插件」，本包是第三方工作流擴展，而非官方應用商店內置能力。
存儲語義備忘
payload_json會解碼爲結構；純字符串按原文存儲，即使形如 JSON 也不會被自動解析。topic、key必須爲字符串，否則peer_publish/peer_await會返回描述性錯誤。- 複合鍵在實現上做了長度前綴，避免
:等字符造成別名混淆。
結尾¶
dsh-subagent-comms 用最小依賴補上 DSH 子智能體之間「看不見彼此中間狀態」的缺口：四個 peer 工具覆蓋寫入、等待、讀取與廣播，並按 workspace 隔離。若你正在編排並行子任務，可把 npm 包加入 profile bundle、重啓 DSH 後，用 README 中的四步模式試跑一條 contracts 主題鏈路。
- 目錄頁：https://www.skillhub.cn/plugins/SBBW512/DSH-Subagent-Comms
- 源碼與文檔：https://github.com/SBBW512/DSH-Subagent-Comms
