為 DeepSeek Harness 接入 Buzz 協作平台：構建自託管 Nostr 訊息閘道的完整實踐

DeepSeek Harness（DSH）的官方外掛程式 dsh-message-gateway，能夠將 DeepSeek Harness 助理無縫延伸至 Discord、Telegram、WeChat 等多種主流即時通訊平台。該外掛程式倉庫已被 Fork 並進行了二次開發，旨在將 自建 Block 旗下 Buzz 協作平台：輕鬆構建人類與 AI 智能體高效協同工作的全新共享工作空間 納入支援清單。Fork 後的開原始碼倉庫位於 GitHub：https://github.com/Tech-Voyage-Dev/dsh-message-gateway 。

前置準備指南

自建 Block 旗下 Buzz 協作平台：輕鬆構建人類與 AI 智能體高效協同工作的全新共享工作空間

本教學將手把手帶您在 Ubuntu VPS 上部署自託管的 Block 旗下 Nostr 中繼 Buzz，並配置 Cloudflare DNS 安全網路。我們將幫助您搭建起一個安全性的共享工作空間，讓您的團隊成員與多個 AI 智能體（如 Claude、Kimi）能夠基於加密身份進行高效溝通、共享專案上下文並實現無縫協作。

12 分鐘閱讀

DSH 助理作為一個全功能成員加入 Buzz Nostr 中繼伺服器，既能接收私人訊息（DM），也能接收被 @mention 提及的頻道訊息，並透過與 Web UI 完全相同的獨立工作階段智能體管線輸出回應。

dsh-message-gateway 外掛架構剖析

dsh-message-gateway 外掛的系統架構清晰劃分為主機端與用戶端兩大部分：

• 主機端（Node 環境）：gateway-store（憑證與設定持久化儲存，位於 ~/.dsh/gateway.json）、platforms.ts（支援平台定義與連線測試）、routes.ts（對外暴露的 /gateway/* 路由端點）以及 bridge-manager.ts（常駐閘道橋接器：負責按對話維護獨立 Agent 執行個體並統一管理串流回應推送）。
• 用戶端（瀏覽器前端）：側邊欄的「Message platforms」視覺化設定頁面，負責填寫金鑰參數、發起連線測試以及直觀監視閘道即時在線狀態。

為閘道接入一個全新通訊平台通常需要經歷以下三步：

1. 實作 Bridge 橋接類別：提供 start/stop/status 生命週期方法以及 onText(text, frame) 訊息回呼，結構規範與現有的 wecom-bridge.ts 完全一致。
2. 接入 bridge-manager 排程器：複用既有的多工作階段排程管線（ensureAgentForKey + pendingMap），並將底層文字輸出串流掛載至該平台的專用回覆接收器。
3. 對接持久化儲存與設定路由：在 /gateway/save 與 /gateway/delete 邏輯中實作：儲存設定即自動啟動橋接服務，刪除設定則優雅停止橋接服務，配合 autoStartXxx 狀態旗標確保 dsh web 守護行程開機自動重新連線。

Buzz 閘道橋接實作：Nostr 協定標準與事件生命週期

本次接入直接使用 DeepSeek Harness 自行編寫完成了完整的 Buzz 適配橋接器。底層嚴格遵循了如下 Nostr 協定規範標準：

Buzz 適配閘道的啟動引導時序圖如下：

基於 Nostr 40003 事件原位編輯實現的即時串流輸出

Nostr 協定缺乏原生鍵入中（Typing）狀態通知，且底層事件設計為嚴格只增不改。為了讓對話過程具備流暢的即時互動感，Buzz 適配閘道透過原位編輯巧妙模擬了串流打字輸出：

• 閘道首先秒級發出一條 kind 9 預留位置訊息，隨後在 Agent 推理過程中按設定的節流閥值連續發射 kind 40003 原位編輯事件逐步追加渲染內容，並在推理終點落定最終文字。這一設計思路與 Telegram、Discord 橋接器的實作方式一脈相承。

透過聊天指令打通 DeepSeek Harness 本地工作區

DSH Web 介面所支援的「工作區（Workspaces）」核心能力依賴於底層 @deepseek-ai/dsh-workspace 模組中的 workspaceRegistry 服務：

const existing = await ctx.workspaceRegistry.resolveByPath(request.path);

Buzz 橋接器透過引入全新的聊天斜線指令 /workspace <目錄路徑>，允許在群聊中直接向 DSH 註冊並綁定本地現存的資料夾。在此之後，該工作階段下的所有互動都將牢牢錨定在此目錄中，並能即時無縫同步在 DSH Web UI 端查看。

開發與使用過程中需重點明確的三大設計機制：

• 變更目錄等同於開啟全新工作階段：工作階段的工作目錄（cwd）在初始化生成 Session Header 時即完成寫入，後續在生命週期內不可直接原地竄改。
• 目標本地目錄必須預先存在：底層 create 註冊函式會對路徑進行嚴格驗證，若路徑在主機上不存在將直接擲出例外狀況拒絕綁定。
• 高度安全敏感指令：透過閘道衍生的工作階段均賦予 auto-approve（自動核准命令執行）特權，擁有對目標資料夾直接進行讀寫和工具操作的完全存取權。

安裝與設定全流程指南

1. 在終端機執行以下指令完成外掛程式下載與啟動：

dsh plugin --profile web add https://github.com/Tech-Voyage-Dev/dsh-message-gateway.git

# Start DSH web
dsh web

2. 待 DSH Web 介面啟動並用瀏覽器開啟後，按一下介面側邊欄中的「Message platforms」圖示：

3. 在左側平台清單中選擇「Buzz」：

4. 按一下「Generate keypair」按鈕即時生成全新的 Nostr 身分金鑰對。請務必將生成的 npub 公鑰妥善複製暫存，後續步驟將作為關鍵身分憑證。
5. 準確填入您的 Relay URL（中繼位址）以及需要監聽訂閱的 Channels（允許存取的頻道 UUID 白名單清單）。
6. 按一下底部的「Save」按鈕完成儲存。

表單提交後，系統將持久化儲存設定並立即啟動 Buzz 閘道服務。私密金鑰 nsec 作為最高機密憑證被自動保護，僅獨立存放在主機本地的 ~/.dsh/gateway.json 檔案中。

將 DSH 智能體註冊至 Buzz Nostr 中繼服務

將 DSH 助理作為新成員註冊加入中繼伺服器。此處公鑰填入上文所生成的 npub 字串：

docker compose exec relay buzz-admin add-member --pubkey npub123123123

將 DSH 助理加入特定的溝通頻道。僅加入中繼並不會讓助理自動出現在頻道成員清單中。需要透過 buzz-cli 進一步執行入群操作。注意此處 --pubkey 參數必須使用 HEX 16 進位公鑰格式，而非 npub 格式（在上一步執行 buzz-admin add-member 時，終端機輸出中會印出對應的 HEX 公鑰）：

buzz channels add-member --channel <CHANNEL_UUID> --pubkey <AGENT_HEX> --role member

CLI 指南

如何安裝並使用 buzz-cli

手把手教您安裝與設定 buzz-cli，以便在 Nostr 中繼伺服器上管理頻道、成員金鑰以及 AI 智能體的角色權限。

5 分鐘閱讀

隨後可透過 buzz-cli 靈活更新 DSH 助理在 Nostr 中繼伺服器中的公開設定檔，設定更具識別度的暱稱：

在用戶端向 DSH 助理傳送一次 Wave（Buzz 平台獨特的 DM 私訊打招呼動作）。助理隨後傳回回覆，代表閘道通訊已完全就緒：

向 DSH 助理傳送 Wave 私訊打招呼 — 橋接閘道正常秒級回應。

透過 /workspace 指令開啟本地工作區聯動

由於 allowWorkspace 設定項目出於環境安全考量預設處於停用（false）狀態，未經設定直接向助理發送 /workspace 命令會被系統攔截拒絕：

開啟設定檔 ~/.dsh/profiles/web/cordis.patch.yml 新增開關設定，隨後重新啟動 dsh web 服務即可：

- id: ui-message-gateway
  config:
    allowWorkspace: true

設定生效並重新啟動後即可順利綁定：

實用提示：此命令預設假設工作區目錄名（例如截圖中的 TechVoyage）直接位於當前使用者的個人主目錄之下；若目錄處於其他深層路徑，請務必傳入完整絕對路徑。透過 Buzz 頻道中註冊綁定好的新工作階段，也都會完全同步在 DeepSeek Harness Web 介面上顯示。

Buzz 頻道支援的完整可用指令

其他平台支援的幾乎全部原生功能在 Buzz 中均可順暢運作：

核心安全架構總結

• 私密金鑰資產隔離保護：Agent 專屬的私密金鑰 nsec 僅保存在主機的 ~/.dsh/gateway.json 中（0600 檔案唯讀權限，不可部分完成寫入機制） — 永遠不會透過 API 端點對外暴露，也不會印至日常除錯記錄中。
• 全鏈路加密簽章驗章：每一個入站的 Nostr 事件在投遞給 Agent 執行之前，都會嚴密執行密碼學數位簽章檢驗（verifyEvent）、訊息防重送判重、自發自收迴圈過濾以及 @提及權限驗證。
• 本地工作區指令受限保護：由於閘道工作階段預設開啟特權自動核准機制，/workspace 目錄註冊能力預設處於停用狀態，必須由開發者在設定檔中明確開啟（allowWorkspace: true），嚴防非預期提權暴露敏感目錄。

結語：擁抱 Buzz 去中心化人機協同時代

在將 Buzz 接入 dsh-message-gateway 的探索過程中，最大的技術挑戰在於嚴密契合 Nostr 協定的去中心化事件生命週期與事件約束規範。所幸外掛程式本身優秀的架構底座已經將多 Agent 工作階段管理與命令分發高度抽象，一旦建立起可靠的事件監聽與原位串流編輯鏈路，整個橋接閘道便能呈現出超預期的流暢度與生產級穩定性。

參考文獻與資料：

• dsh-message-gateway architecture guide — 官方閘道架構指南、擴充實踐與安全規範
• nostr-tools — 底層呼叫的核心 Nostr JavaScript 用戶端程式庫
• deer-flow IM channel connections — 即時通訊平台多通道連線架構設計參考