---
title: "为 DeepSeek Harness 接入 Buzz 协作平台：构建自托管 Nostr 消息网关的完整实践"
description: "深入解析如何通过 Nostr 协议将 DeepSeek Harness 接入 Block Buzz 协作平台：手把手配置 NIP-42 鉴权认证、基于 40003 事件的原位流式编辑输出、频道独立会话管理与本地工作区指令联动，为开发团队构建起安全可控、开箱即用的人机协同智能体开发环境与全新工作流程。"
canonical_url: "https://techvoyage.dev/zh/article/bringing-buzz-to-deepseek-harness"
last_updated: "2026-10-20T09:53:51.713Z"
---

![DeepSeek Harness 消息网关连接至 Block Buzz 频道的运行概览](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-nostr-gateway-overview.webp)

DeepSeek Harness（DSH）的官方插件 **dsh-message-gateway**，能够将 DeepSeek Harness 助手无缝扩展至 Discord、Telegram、微信等多种主流即时通讯平台。该插件仓库已被 Fork 并进行了二次开发，旨在将 **自建 Block 旗下 Buzz 协作平台：轻松构建人类与 AI 智能体高效协同工作的全新共享工作空间** 接入支持列表。Fork 后的开源代码仓库位于 GitHub：[https://github.com/Tech-Voyage-Dev/dsh-message-gateway](https://github.com/Tech-Voyage-Dev/dsh-message-gateway) 。

<article-card description="本教程将手把手带您在 Ubuntu VPS 上部署自托管的 Block 旗下 Nostr 中继服务 Buzz，并配置 Cloudflare DNS 安全网络。我们将帮助您搭建起一个安全性的共享工作空间，让您的团队成员与多个 AI 智能体（如 Claude、Kimi）能够基于加密身份进行高效沟通、共享项目上下文并实现无缝协作。" image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/ZH-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="一张高颜值的 16:9 科技质感卡片，具有深蓝色和橙色色调，插图展示如何在 Ubuntu VPS 上部署自托管的 Block 旗下 Buzz 协作中继服务器，其中包含一个带有居中文字的毛玻璃微动质感面板。" label="前置准备指南" min-read="12" title="自建 Block 旗下 Buzz 协作平台：轻松构建人类与 AI 智能体高效协同工作的全新共享工作空间" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues">



</article-card>

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 协议规范标准：

<table>
<thead>
  <tr>
    <th>
      <strong>
        维度 / 阶段
      </strong>
    </th>
    
    <th>
      协议实现规范与技术细节
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        底层传输（Transport）
      </strong>
    </td>
    
    <td>
      单条经过 NIP-42 鉴权认证的 WebSocket 链路；默认中继连接地址为 <code>
        ws://localhost:3000
      </code>
      
      ；输入的 <code>
        http(s)://
      </code>
      
       会自动规整为 <code>
        ws(s)://
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        鉴权认证（Auth）
      </strong>
    </td>
    
    <td>
      AUTH 事件 <code>
        kind 22242
      </code>
      
      ，携带标签 <code>
        [["relay", url], ["challenge", challenge]]
      </code>
      
      ，内容为空字符串，由 Agent 的私钥完成签名
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        订阅机制（Subs）
      </strong>
    </td>
    
    <td>
      <strong>
        严格基于频道隔离
      </strong>
      
      ：<code>
        REQ {"kinds":[9], "#h":[<uuid>]}
      </code>
      
       — 每个频道独立建立一条订阅。全局性的 <code>
        kinds:[9]
      </code>
      
       虽能收到 EOSE 但绝不广播推送；多值 <code>
        #h
      </code>
      
       标签过滤在协议中<strong>
        无法正常分发
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        频道发现（Discovery）
      </strong>
    </td>
    
    <td>
      历史元数据回溯查询 <code>
        REQ {kinds:[39000]}
      </code>
      
       提取频道详情（其中 <code>
        type == "dm"
      </code>
      
       用于标记单聊私信频道）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        成员变动订阅
      </strong>
    </td>
    
    <td>
      实时长连接订阅 <code>
        REQ {kinds:[44100,44101], "#p":[Agent 公钥], since: now-60s}
      </code>
      
       — 44100 为入群，44101 为被移出，均附带 <code>
        p
      </code>
      
      +<code>
        h
      </code>
      
      ；成员关系变更时<strong>
        无需重连
      </strong>
      
      即可动态热更新订阅状态
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        即时聊天事件
      </strong>
    </td>
    
    <td>
      <code>
        kind 9
      </code>
      
       事件，携带 <code>
        ["h", channel]
      </code>
      
       频道标签，可选附带 <code>
        ["e", replyTo]
      </code>
      
       回复目标与 <code>
        ["p", mention]
      </code>
      
       被提及者标签
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        原位更新编辑
      </strong>
    </td>
    
    <td>
      <code>
        kind 40003
      </code>
      
       事件，附带 <code>
        h
      </code>
      
       与 <code>
        e
      </code>
      
       目标标签；内容完全替换；中继单包上限 64 KB → 严控载荷 ≤ 60,000 B；超长回复分块处理 — 首块用于原位编辑替换，超出部分作为回复串线程的 <code>
        kind 9
      </code>
      
       消息追加
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CLOSED 异常帧处理
      </strong>
    </td>
    
    <td>
      鉴权未完成前收到 <code>
        auth-required
      </code>
      
       属于正常引导阶段（完成 AUTH 后重新拉起订阅）；鉴权完成后遇断连 → 阶梯式限次重试（最多 3 次，间隔 0/1/2 秒退避）；整链重连时全量重构上下文
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        中继拉取上限
      </strong>
    </td>
    
    <td>
      每次订阅最多拉取 2000 条历史事件，即使配置了 <code>
        since
      </code>
      
       过滤参数，中继仍按自最新向过去的时间倒序返回
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        消息命中判定
      </strong>
    </td>
    
    <td>
      仅当满足以下任一条件时才激活处理入站 <code>
        kind 9
      </code>
      
      ：(a) <code>
        p
      </code>
      
       标签明确包含自身公钥，(b) 处于 DM 私信频道，(c) 回复关联的 <code>
        e
      </code>
      
       根事件为自身发出的消息。自动过滤自身公钥发送的内容（彻底杜绝自环）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        出站 @ 提及
      </strong>
    </td>
    
    <td>
      出站内容按纯文本原样发布 — 中继端不对正文中的 <code>
        @
      </code>
      
       符号进行预校验；<code>
        p
      </code>
      
       标签填入当前对话原作者以及至多 7 位其他被提及者的公钥（单条上限 8 位）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        私聊消息（DM）
      </strong>
    </td>
    
    <td>
      依赖中继作用域内的明文受限频道（元数据标注 <code>
        type: "dm"
      </code>
      
      ） — 当前桥接实现中未引入 NIP-04/44 复杂非对称端到端加密
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        媒体附件（入站）
      </strong>
    </td>
    
    <td>
      NIP-92 <code>
        imeta
      </code>
      
       规范（<code>
        url
      </code>
      
      , <code>
        sha256
      </code>
      
      , <code>
        m
      </code>
      
      ）→ 常规 HTTP(S) 流式下载，本地校验 SHA-256 完整性，单文件限制 20 MB，每条消息最多 4 张；出站图片发布暂无官方中继协议路径，现阶段不支持出站图片
    </td>
  </tr>
</tbody>
</table>

Buzz 适配网关的启动引导时序图如下：

![展示 Buzz 网关引导连接与 NIP-42 协议身份鉴权流程的时序图](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-bootstrap.webp)### 基于 Nostr 40003 事件原位编辑实现的实时流式输出

Nostr 协议缺乏原生打字中（Typing）状态通知，且底层事件设计为严格只增不改。为了让对话过程具备行云流水的实时交互感，Buzz 适配网关**通过原位编辑巧妙模拟了流式打字输出**：

![基于 kind 40003 事件原位编辑模拟打字流式响应的逻辑流程图](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-reply.webp)- *网关首先秒级发出一条 kind 9 占位消息，随后在 Agent 推理过程中按设定的节流阈值连续发射 kind 40003 原位编辑事件逐步追加渲染内容，并在推理终点落定最终文本。这一设计思路与 Telegram、Discord 桥接器的实现方式一脉相承。*

### 通过聊天指令打通 DeepSeek Harness 本地工作区

DSH Web 界面所支持的“工作区（Workspaces）”核心能力依赖于底层 `@deepseek-ai/dsh-workspace` 模块中的 `workspaceRegistry` 服务：

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

Buzz 桥接器通过引入全新的聊天斜杠指令 `/workspace <目录路径>`，允许在群聊中直接向 DSH 注册并绑定本地现存的文件夹。在此之后，该会话下的所有交互都将牢牢锚定在此目录中，并能实时无缝同步在 DSH Web UI 端查看。

![通过网关聊天指令动态注册并绑定 DeepSeek Harness 本地工作区的架构示意图](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace.webp)开发与使用过程中需重点明确的三大设计机制：

- **变更目录等同于开启全新会话**：会话的工作目录（`cwd`）在初始化生成 Session Header 时即完成写入，后续在生命周期内不可直接原地篡改。
- **目标本地目录必须预先存在**：底层 `create` 注册函数会对路径进行强校验，若路径在宿主机不存在将直接抛出异常拒绝绑定。
- **高度安全敏感指令**：通过网关衍生的会话均赋予 **auto-approve**（自动批准命令执行）特权，拥有对目标文件夹直接进行读写和工具操作的完全访问权。

## 安装与配置全流程指南

1. 在终端运行以下指令完成插件拉取与启动：

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

# Start DSH web
dsh web
```

1. 待 DSH Web 界面启动并用浏览器打开后，点击界面侧边栏中的“**Message platforms**”图标：

![DeepSeek Harness Web UI 侧边栏高亮显示的 Message platforms 配置菜单项](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-message-platforms-sidebar-icon.webp)

1. 在左侧平台列表中选择“**Buzz**”：

![DeepSeek Harness 消息网关内的 Buzz 协议参数与密钥对配置面板](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-message-gateway-buzz-config-panel.webp)

1. 点击“**Generate keypair**”按钮即时生成全新的 Nostr 身份密钥对。请务必将生成的 `npub` 公钥妥善复制暂存，后续步骤将作为关键身份凭证。
2. 准确填入您的 **Relay URL**（中继地址）以及需要监听订阅的 **Channels**（允许访问的频道 UUID 白名单列表）。
3. 点击底部的“**Save**”按钮完成保存。

表单提交后，系统将持久化保存配置并**立即启动 Buzz 网关服务**。私钥 `nsec` 作为最高机密凭证被自动保护，仅独立存放在宿主机本地的 `~/.dsh/gateway.json` 文件中。

### 将 DSH 智能体注册至 Buzz Nostr 中继服务

**将 DSH 助手作为新成员注册加入中继**。此处公钥填入上文所生成的 `npub` 字符串：

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

**将 DSH 助手加入特定的沟通频道**。仅加入中继并不会让助手自动出现在频道成员列表中。需要通过 `buzz-cli` 进一步执行入群操作。注意此处 `--pubkey` 参数必须使用 **HEX 16 进制公钥**格式，而非 npub 格式（在上一步执行 `buzz-admin add-member` 时，终端输出中会打印对应的 HEX 公钥）：

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

<article-card description="手把手教您安装和配置 buzz-cli，以便在 Nostr 中继上管理频道、成员密钥以及 AI 智能体的角色权限。" image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/ZH-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="一张高颜值的 16:9 科技质感卡片，具有深蓝色和橙色色调，插图展示如何在 Ubuntu VPS 上部署自托管的 Block 旗下 Buzz 协作中继服务器，其中包含一个带有居中文字的毛玻璃微动质感面板。" label="CLI 指南" min-read="5" title="如何安装并使用 buzz-cli" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues#install-buzz-cli">



</article-card>

随后可通过 `buzz-cli` 灵活更新 DSH 助手在 Nostr 中继中的公开资料，设置更具辨识度的昵称：

![使用 buzz-cli 命令行工具更新 DSH 助手在 Nostr 中继上的公开个人资料](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-assistant-buzz-cli-profile-update.webp)

在客户端向 DSH 助手发送一次 **Wave**（Buzz 平台独特的 DM 私信打招呼动作）。助手随后返回回复，代表网关通讯已完全就绪：

![在 Buzz 客户端向 DeepSeek Harness 助手发送 Wave 私信进行连通性验证](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-dm-wave-greeting-reply.webp)

*向 DSH 助手发送 Wave 私信打招呼 — 桥接网关正常秒级响应。*

### 通过 `/workspace` 指令开启本地工作区联动

由于 `allowWorkspace` 配置项出于环境安全考虑默认处于禁用（`false`）状态，未经配置直接向助手发送 `/workspace` 命令会被系统拦截拒绝：

![在未开启 allowWorkspace 权限时发送 /workspace 命令被系统安全拦截的提示](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-rejected-error.webp)

打开配置文件 `~/.dsh/profiles/web/cordis.patch.yml` 添加开关配置，随后重启 `dsh web` 服务即可：

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

配置生效并重启后即可顺利绑定：

![在 Buzz 频道成功执行 /workspace 命令完成本地工作区绑定的确认消息](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-success-confirmation.webp)

实用贴士：此命令默认假设工作区目录名（例如截图中的 `TechVoyage`）直接位于当前用户的个人主目录之下；若目录处于其他深层路径，请务必传入完整绝对路径。通过 Buzz 频道中注册绑定好的新会话，也都会完全同步在 DeepSeek Harness Web 界面上显示。

![DeepSeek Harness Web UI 中展示从 Buzz 频道自动同步关联的活跃工作区会话](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-synced-workspace-session.webp)

### Buzz 频道支持的完整可用指令

其他平台支持的几乎全部原生功能在 Buzz 中均可顺畅运行：

<table>
<thead>
  <tr>
    <th>
      指令语法
    </th>
    
    <th>
      功能说明
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /workspace <folder>
      </code>
    </td>
    
    <td>
      将本地已存在的文件夹注册绑定为当前对话专属的工作区环境（受配置项开关保护）
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /help
      </code>
    </td>
    
    <td>
      打印并列出所有支持的命令清单
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /time
      </code>
    </td>
    
    <td>
      获取并输出当前服务器系统时间
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /new
      </code>
    </td>
    
    <td>
      丢弃旧上下文，原地重置开启全新会话
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /clear
      </code>
    </td>
    
    <td>
      清空当前上下文所有历史对话流
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /status
      </code>
    </td>
    
    <td>
      查看当前 Buzz 消息桥接器的实时在线状态
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /stats
      </code>
    </td>
    
    <td>
      查看当前系统活跃会话总量及所有接入平台（包含 Buzz）的桥接连接详细状态
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /commands
      </code>
    </td>
    
    <td>
      输出全量指令的底层规范与参数描述文档
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        @path/to/file
      </code>
    </td>
    
    <td>
      与 Web 端的 <code>
        @
      </code>
      
       文件提及功能完全一致：Agent 自动相对于工作区读取文件内容；单独发送 <code>
        @
      </code>
      
      、<code>
        @前缀
      </code>
      
       或使用 <code>
        /files <前缀>
      </code>
      
       可返回文件/文件夹列表
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /model
      </code>
    </td>
    
    <td>
      <code>
        [provider model effort]
      </code>
      
       — 校验有效后实时切换该会话的底层推理大模型与思考深度；单独输入 <code>
        /model
      </code>
      
       显示支持的候选列表，<code>
        /model reset
      </code>
      
       恢复系统默认设置
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /effort
      </code>
    </td>
    
    <td>
      <code>
        <id>
      </code>
      
       仅针对支持思考深度的模型调整 reasoning effort；<code>
        /effort reset
      </code>
      
       恢复默认推理深度配置
    </td>
  </tr>
</tbody>
</table>

### 核心安全架构总结

- **私钥资产隔离保护**：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](https://github.com/a792883583/dsh-message-gateway/blob/main/docs/architecture.md) — 官方网关架构指南、扩展实践与安全规范
- [nostr-tools](https://github.com/nbd-wtf/nostr-tools) — 底层调用的核心 Nostr JavaScript 客户端库
- [deer-flow IM channel connections](https://github.com/bytedance/deer-flow/blob/main/backend/docs/IM_CHANNEL_CONNECTIONS.md) — 即时通讯平台多通道连接架构设计参考