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。