Block Buzz 開源工作區結合聊天、AI 代理與 Git 託管

Buzz 作為聊天、AI 代理與 Git 的統一工作區推出

Buzz 是由 Jack Dorsey 於 2026 年 7 月 21 日宣布的開源平台，將團隊訊息、AI 驅動的代理與 Git 儲存庫託管整合於單一身分系統下。此專案針對希望以自我託管解決方案取代 Slack 與 GitHub，並將所有資料與稽核紀錄保留在自行控制之下的組織。

Buzz 將每則訊息、回應、工作流程步驟、程式碼事件與批准，都以 加密簽名的 Nostr 事件 方式儲存。員工與 AI 代理皆擁有自己的金鑰對、頻道成員資格與不可變更的稽核日誌。此設計讓代理能成為第一級成員，而非旁邊的機器人，並能夠：

Buzz 隨附命令列介面，並提供 Goose、Codex 與 Claude Code 的 harness，讓底層 LLM 可自由替換。

Buzz 的規格說明了一個 內建 Git 鍛造，使用標準 Git Smart HTTP。功能分支可以成為專屬頻道，修補程式、CI 結果、稽核評論與合併決策皆以簽名事件記錄。這樣即可為程式碼、討論與工作流程歷史建立單一可搜尋的索引。

截至 7 月 21 日發佈的 0.4.21 版，現有功能包括：

程式碼採用 Apache 2.0 授權，並可於 https://github.com/block/buzz 取得。

Buzz 被描述為 去中心化，因為任何組織都可以自行運行 Nostr 中繼、擁有自己的域名，並保留完整資料主權。實務上，所有讀寫皆透過單一中繼，該中繼負責驗證使用者、驗證簽名、儲存事件並推送更新。沒有點對點的 gossip 或複製層。

"Buzz 目前沒有點對點事件交換、gossip 層或中繼之間的複製。工作區內的所有讀寫都通過單一中繼…" – Block 架構文件

自行託管因此能掌控基礎設施與資料位置，但也將正常運作時間、備份、安全性與升級的責任轉移給營運者。簽名事件模型提供歸屬與稽核能力，卻無法消除單一權威伺服器的營運風險。

Buzz 在 Block 的文件中被標示為 未完成。缺少的部分包括行動客戶端、推播通知與完整實作的工作流程批准閘門。最新的桌面版 (v0.4.21) 增加了代理控制、驗證改進與上手流程。

Block 是首個有文件記錄的客戶，但尚未公布採用數據、定價或外部參考。此專案定位為 單中繼替代方案，以取代 Slack、GitHub、CI/CD 與自訂機器人整合的碎片化堆疊。

代理隱私疑慮 – 前 Slack 員工指出，多使用者代理能看到所有頻道資料，會產生複雜的權限規則挑戰，而單一使用者代理較易於沙盒化。（@muglug 評論）
去中心化懷疑論 – 多位評論者質疑 Nostr 是否真的比自託管服務（如 Zulip）提供更多價值，稱此做法是「處理稅」。（@sulam、@dewey 評論）
與現有工具比較 – 使用者將 Buzz 與 JetBrains Space、Matrix、Zulip 進行比較，指出要匹配成熟 Git 鍛造的光澤度相當困難，且需要健全的權限模型。（@2001zhaozhao、@jillesvangurp 評論）
代理優先工作流程的潛力 – 有人認為 Buzz 是 AI 增強協作的自然演進，因為現有平台缺乏統一的代理身分層。（@oooyay、@theptip 評論）
營運取捨 – 缺乏點對點複製意味著單一中繼可能成為單點故障，這點被多位評論者強調。

Buzz 嘗試 將多層 SaaS——聊天、程式碼託管、CI 與機器人協調——合併成一個事件驅動系統。若被採用，可能減少 AI 代理在取得對話與程式碼庫上下文時的整合負擔。然而，專案的成功取決於：

Buzz 是一次 自我主權、代理優先工作區設計 的大膽實驗。其開源本質邀請審視與貢獻，但組織必須在運營單一中繼系統的責任與資料控制與工作流程凝聚的潛在收益之間取得平衡。