Buzz 做到了，但这只是开始…

摘要

實測開源專案 Buzz（Block 開源，GitHub 約三萬星），一個把人類與多個異構 AI agent（Claude Code、Codex、Goose 等）拉進同一個類 Slack 聊天空間的協作平台，核心建立在 Nostr 協定之上，每則訊息都由對應身份的密鑰簽署，可驗證訊息真偽來源。作者將其與自己原本使用的 Google Drive 會議室模式相比較：Buzz 提供的是即時廣播，Drive 模式則是異步廣播；Buzz 的理念雖然漂亮，但接入不同來源 agent 的工程摩擦仍明顯偏高，尤其一旦把人類放進協作迴圈，等待感會被放大。內容原生為繁體中文影片，語言已符合正體字規範，僅小幅用語校正。

重点

• Buzz 建立在 Nostr 協定與 WebSocket relay 之上，每則訊息由對應身份的密鑰簽署，可驗證這句話到底是誰說的，Redis 主要承擔 pub sub、在線狀態等基礎服務
• 可同時接入不同來源的 agent runtime，且底層即使只接一個 Codex，也能在介面上組織出多個不同身份、不同任務分工的 Bot
• Buzz 與作者自製的 Google Drive 會議室模式核心差異在於廣播方式：Drive 是異步廣播，訊息落盤後誰下次進入誰讀取；Buzz 是即時廣播，同頻道所有已在場的 agent 立即同步看到訊息，但預設仍需要標註才會響應，避免多個 agent 同時搶話
• 作者過往經驗發現：純 Agent 對 Agent 協作不太在意等待時間，但一旦把人類放進協作迴圈，經過 relay、harness、任務調度的等待感會被明顯放大，這是 Buzz 接下來最需要優化的體驗問題
• 加入組織被拆解為兩層：access 能不能進入會議室、procedure 知不知道怎麼開會怎麼記錄什麼情況算人類已拍板，有讀寫權限不等於完成入職，需要由既有 agent 對新加入的 agent 做入職培訓
• 作者認為 Buzz 與 Drive 並非互斥，可以互補：Buzz 負責即時廣播與簽名來源驗證，Drive 或未來其他共享知識庫負責長期沉澱重要結論
• 紅隊測試中提出的關鍵提問：為什麼組織記憶一定要住在某一個軟體裡，作者認為真正重要的是能否留下最後決定了什麼、為什麼這麼決定、當時有什麼不同意見、證據是什麼，而非哪個工具承載了聊天記錄

金句