Nous Research 為 Hermes Agent 與 Block 的開源 Nostr 工作區 Buzz 推出三條集成路徑

Nous Research 今日宣佈，Hermes Agent 現已支持 Buzz——Block 推出的開源、可自託管工作區。Buzz 基於 Nostr 協議構建，人類與 AI 代理可以在同一頻道中協作。在 Buzz 中，每條消息都是發送到你自有中繼（relay）上的簽名事件，每個參與者（無論是人還是代理）都擁有自己的密鑰對。這一設計取消了傳統的機器人令牌模式，代理因此獲得獨立身份、頻道成員資格和完整審計軌跡。

部署方面，兩側目前均可自託管。Buzz 採用 Apache-2.0 許可，GitHub 上有 18.8k star；Hermes Agent 使用 MIT 許可。獨立開發者和小型工程團隊可以通過 Buzz Desktop 直接運行，無需額外配置。中端平台團隊是最契合的使用者，因為其中繼依賴 Postgres、Redis 和 S3/MinIO。企業則更適合先做試點，因為移動客户端和工作流審批門控仍在完善中。實際應用場景包括基於頻道歷史的事故記憶、以分支為房間的代碼審查、代理起草的發佈説明，以及定時投遞報告。

官方文檔列出了三種連接方式。第一種是 Buzz Desktop 託管運行時：Buzz 在本地以預設 harness 方式拉起 Hermes。用户打開 Settings → Runtimes，Hermes 會自動出現；發現機制會解析登錄 shell PATH 中的 hermes-acp 啓動器，安裝程序會將其寫入 ~/.local/bin，入站通信使用基於 stdio 的 ACP。第二種是中繼橋接：適合託管代理身份。Buzz 的 buzz-acp harness 將頻道橋接到 hermes acp（通過 stdio），再經 WebSocket 連接中繼。這屬於傳輸層集成，無需二次安裝，生成的子進程與主機上的 hermes 共享同一套配置、憑據、記憶、技能和狀態。第三種是原生網關平台，集成深度最高：隨附的 Buzz 插件讓 Buzz 成為與 Telegram、Discord 並列的常規 Hermes 消息平台，支持頻道、私信、提及門控、線程回覆、表情回應、圖片和 cron 定時投遞，同時 Hermes 繼續保留自己的審批、記憶和會話管理。初始化命令為 hermes gateway setup。

在網關路徑上，入站消息通過持久化的 NIP-42 認證 Nostr WebSocket 到達，使用無依賴的 BIP-340 簽名，並會自動回退到 CLI 輪詢。出站消息始終通過 buzz CLI 發送。傳輸設置支持 auto、websocket 或 poll，poll_interval 默認為 4 秒。默認配置強調隱私：require_mention 為 true，代理僅在頻道中被點名時回答，私信則始終響應；allow_all_users 為 false，只允許列表中 npub 或十六進制公鑰訪問；interim_assistant_messages 為 false，tool_progress 為 off，避免工具日誌進入頻道。事件會按事件 ID 與頻道內高水位標記去重，代理自身消息也按公鑰過濾。

需要特別注意的是，Buzz Desktop 會自動批准工具權限，因此建議務必將代理設置為僅限所有者使用。更多信息可參閲集成文檔、Buzz 適配器參考和 GitHub 倉庫。本文首發於 MarkTechPost。