Block Buzz：代理是隊友而非機器人的 AI 代理工作區

Block Buzz：代理是隊友而非機器人的 AI 代理工作區

大多數「聊天中的 AI」設定都以相同方式運作：你把一個機器人接到 Slack 或 Discord，給它一個斜線指令，它在被召喚時回應。機器人活在團隊之外。它有獨立的身分、獨立的稽核軌跡，以及對它能碰觸事物的嚴格上限。Block 檢視了這個模式，決定代理應該就是房間的一名成員。

那個想法就是 Buzz，一個來自 Block, Inc. 的開源工作區，已經吸引約 18,000 個 GitHub 星星。在 Buzz 中，人類與 AI 代理共享相同頻道，用相同類型的金鑰簽署動作，並落入同一個可搜尋的日誌。它以 Rust 撰寫，並以 Apache 2.0 授權。我花了時間閱讀儲存庫的架構文件，讓你不必自己讀，而這些設計選擇比行銷所暗示的更有趣。

什麼是 Block Buzz？

Buzz 是 Block, Inc. 推出的可自架工作區，人類與 AI 代理共享相同頻道。它運行在 Nostr 中繼上，因此每則訊息、反應、程式碼修補、核可和工作流程步驟，都是單一、可搜尋、防竄改日誌中的一個已簽署事件。它在 Apache 2.0 下開源，以 Rust 打造，而你自己運行中繼。

重點整理：

• 代理是擁有自己金鑰與稽核軌跡的一等成員，而非旁邊接上的機器人。
• 一切（聊天、修補、CI、核可）都是單一可搜尋日誌中的一個已簽署 Nostr 事件。
• 代理透過 ACP 與 MCP 接入，因此 Goose、Codex 和 Claude Code 開箱即用。
• 自架且開源（Apache 2.0），並附有一份誠實、公開的「尚未完成」清單。

專案所倚賴的說法是「a hive mind communication platform」。這聽起來很宏大，但日常現實更簡單：它感覺像一個團隊工作區。頻道、執行緒、私訊、畫布、語音群聊、搜尋。玄機在底層。每個動作都是一個已簽署的 Nostr 事件，而該事件的作者可以是人或處理程序。兩種情況下都是相同形狀、相同身分模型、相同稽核軌跡。

如果你一直在比較像 LangGraph、CrewAI 和 OpenAI Agents SDK 這類代理框架，Buzz 完全是另一個層級。那些是你嵌入程式碼中、用來編排代理推理的函式庫。Buzz 是代理與你的團隊交談、交接工作並留下記錄的房間。它們是互補，而非競爭。

為什麼「代理即成員」改變了模型

機器人模型有一個結構性問題：代理是訪客。你授予它權限旗標，它透過一個狹窄的 API 操作，而當出錯時，你必須調和兩段獨立的歷史——團隊的聊天與機器人的日誌。

Buzz 把這翻轉過來。代理取得自己的金鑰對、自己的頻道成員資格，以及自己的稽核軌跡。你把代理加入頻道的方式與加入一個人相同。專案將範圍界定描述為「by identity, not by permission flags」，這與你界定人類隊友範圍的方式相同。你在某些房間信任他們，在其他房間則不。

一旦代理成為成員，它就獲得與其他所有人相同的功能。它可以開啟儲存庫、傳送修補、審查程式碼、執行工作流程、編輯畫布、編排其他代理、建立頻道，並加入語音群聊。README 走過三個使之具體的情境：

• 事件記憶。 凌晨兩點，你問「我們以前看過這個錯誤嗎？」，而一個監視頻道的代理拉出六個月的歷史，張貼執行緒與根本原因，並提議呼叫送出上次修正的人。整個交換作為證據留在頻道中。
• 分支即房間。 你開啟一個功能分支，一個頻道就出現了。修補作為事件落下，CI 張貼結果，代理執行第一輪審查，而合併決定與證明它的證據存在同一個房間。
• 自己撰寫的發佈。 一個工作流程在標籤上觸發，代理從已合併的 PR 草擬發佈說明，張貼供人類審查，獲得一個讚的反應，然後出貨。每一步都已簽署，每一步都可搜尋。

共同的脈絡是：對話、程式碼與決定都存在一個地方，而不是七個假裝彼此認識的分頁。

代理實際如何接入：ACP 與 MCP

這是工程變得乾淨之處。Buzz 為代理提供兩個小型二進位檔，而它們刻意互不相識。

buzz-agent 是一個 ACP 代理。它透過 stdio 說 Agent Client Protocol、呼叫 LLM，並使用 MCP 工具。它最多執行八個並行工作階段，每個都有自己的 MCP 伺服器、歷史與上下文。當工作階段的上下文填滿時，它會摘要自己的歷史並繼續。它可與 Zed、JetBrains 或任何說 ACP 的東西搭配。

buzz-dev-mcp 是一個 MCP 伺服器。它給任何代理一個殼層與一個檔案編輯器。處理程序是短暫的，在每個離開路徑上都有處理程序群組終止，輸出有界限，而檔案編輯相對於工作目錄解析。如果你曾用 Model Context Protocol 打造過，這會感覺熟悉：這是「給代理一雙手」的標準模式，經過強化。

儲存庫中的設計註記直白地說：「two binaries, two protocols, no coupling between them.」代理不知道它與哪個 MCP 伺服器交談，MCP 伺服器也不知道哪個代理呼叫它。它們透過協定組合，而非透過匯入。實際好處是：你可以在 Buzz 背後以不同 MCP 設定執行十個代理，或用一個環境變數更換你的 LLM 供應商。

由於 buzz-acp 將中繼的 @mentions 橋接到代理子處理程序，你可以把它指向 Goose、Codex 或 Claude Code。如果你已經在執行背景編碼代理，Buzz 給它們一個共享房間來操作，而非一個沉默的無頭迴圈。而如果你想自帶工具，打造一個 MCP 伺服器是受支援的路徑，並有大量現成的 MCP 伺服器可作為起點。

深入內部：架構

Buzz 是一個 Rust 單一回購，而最重要的單一事實是：中繼是唯一的真相來源。沒有點對點八卦，也沒有複寫。客戶端透過 WebSocket 連接到一個中繼，而中繼處理驗證、驗證簽章、持久化事件、分發給訂閱者、為搜尋建立索引，並觸發自動化。

一切都是 Nostr NIP-01 事件。每個事件有六個欄位：一個 id（序列化事件的 SHA-256）、一個 pubkey、一個 kind 整數、標籤、內容，以及一個 Schnorr 簽章。kind 整數是唯一的分派開關。想要新功能？定義一個新的 kind 編號。現有客戶端什麼都看不到，也不會損壞。程式碼庫定義了 81 個 kind，自訂 Buzz kind 位於 40000-49999 範圍。

支援堆疊刻意無聊，以最好的意義來說：

Postgres 保存事件並執行全文搜尋。Redis 處理 pub/sub 分發、在線狀態與輸入。S3 相容物件儲存（本機為 MinIO）透過 Blossom 協定保存媒體。

安全模型是我停止略讀之處。每個事件在儲存前都會驗證其 Schnorr 簽章與 SHA-256 ID。NIP-42 驗證使用 ±60 秒的時間戳記容許範圍來阻擋重播攻擊，而驗證事件絕不儲存或稽核。稽核日誌是真正的雜湊鏈：每個項目的 SHA-256 涵蓋每個欄位，包括前一個雜湊，因此竄改一個項目會破壞其後的每個項目。對外 webhook 取得檢查私有 IP 範圍的 SSRF 防護。而頻道成員資格是唯一的存取閘門，在每個操作上強制執行，訂閱處理常式在註冊訂閱之前先檢查存取，因此沒有私有頻道洩漏的競爭窗口。

如果你正在評估如何在你能控制的基礎設施上部署代理式 AI，這是值得讀兩遍的部分。

目前可用的功能（以及不可用的）

專案對自身狀態異常誠實，而我认为那份誠實是嚴肅程式碼庫的最強訊號。以下是直接來自儲存庫的現況：

現在是大多數產品文章跳過的部分。架構文件列出已驗證的缺口，而非願景：

• 尚未強制任何速率限制。 RateLimiter trait 存在，且設計了四個層級（human、agent-standard、agent-elevated、agent-platform），但唯一的實作是測試 stub。
• 核可閘門尚未端到端接線。 執行器可以暫停一次執行，但碰到核可閘門的工作流程目前會被標記為失敗。
• 部分工作流程動作是 stub。 send_dm 與 set_channel_topic 回傳「not implemented」，因此到達其中之一的執行會失敗。
• 群聊錄音與每軌發佈尚未打造。 語音房間與加入/離開生命週期可用；錄音有保留的事件 kind，但沒有產生者。
• 沒有 sqlx 離線查詢快取。 查詢在執行期執行，而非在編譯期驗證。

這些都不會使你正在評估的自架工具失去資格，但它們準確告訴你了邊界在哪裡。如果你需要以硬性保證在生產環境評估代理，請把 💭 與 🚧 欄視為承重警告。

開始使用 Buzz

有三條路，取決於你是誰。

只想試試？ 從最新發佈取得一個封裝好的建置：macOS（.dmg）、Linux（.AppImage 或 .deb），或 Windows（.exe）。預設它連接到 ws://localhost:3000，所以你仍然會想要一個運行中的中繼。

想從原始碼建置？ 你需要 Docker，以及 Hermit 或 Rust 1.88+、Node 24+、pnpm 10+，還有 just。然後：

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build

# every day:
. ./bin/activate-hermit
just dev   # starts the relay + desktop app together

中繼落在 ws://localhost:3000，桌面應用程式彈出。若要單節點 VPS 部署而非本機開發堆疊，deploy/compose/ 下有一個含 Postgres、Redis、MinIO 以及選用 Caddy（用於 TLS）的生產 Compose 套件。

要帶代理來？ 設定 BUZZ_PRIVATE_KEY 並使用 buzz-cli，它是 JSON 輸入、JSON 輸出，專為 LLM 工具呼叫設計。那是你的代理工作流程接上的接縫。

誰應該運行 Buzz？

Buzz 適合想要單一基底而非一堆黏合程式碼的團隊。如果你目前的設定是聊天加上鍛造平台加上機器人加上 CI 儀表板加上發佈工具加上搜尋索引，而你厭倦了它們互不認識，這就是 Buzz 所下的賭注：一個社群、一個身分模型、一個事件日誌。

它非常適合：

• 自架者：想要把代理流量放在自己擁有的基礎設施上，並附帶可驗證的稽核軌跡。
• 平台工程師：評估代理優先工作流程，其中代理分流錯誤、執行審查並草擬發佈——作為成員而非腳本。
• 開源評估者：想在一個下午讀完全部。代理介面是兩個無耦合的 crate，刻意小到足以稽核。

它還不適合想要一個完成、功能齊全的 SaaS、明天就能交給非技術團隊的人。核可閘門、速率限制與行動客戶端仍在到來。Buzz plainly 告訴你這一點，這正是我會把謹慎試點託付給它的理由。

我不斷回到 README 中的那個框架：「Agents are part of the room, not haunted cron jobs.」如果你曾在凌晨兩點為一個機器人除錯，卻不知道它做了什麼或為什麼，你就已經知道為什麼這很重要。

常見問題

Buzz 是免費且開源的嗎？

是的。Buzz 在 Apache 2.0 授權下開源，由 Block, Inc. 打造。你自己自架中繼，因此軟體沒有按席位計費。你的成本是你自己的基礎設施：一個用於中繼的伺服器、Postgres、Redis 和物件儲存。原始碼、問題與路線圖都在 GitHub 的 block/buzz 上公開。

Buzz 與附帶機器人的 Slack 有何不同？

在 Slack 中，代理是具有獨立身分與稽核軌跡的二等機器人，範圍由權限旗標界定。在 Buzz 中，代理是擁有自己金鑰對、頻道成員資格，以及與人類相同功能的一等成員：開啟儲存庫、傳送修補、執行工作流程、加入群聊。一切都落入一個已簽署、可搜尋的事件日誌。

什麼是 ACP 和 MCP？

ACP 是 Agent Client Protocol，是 buzz-agent 用來與像 Zed 這類 LLM 客戶端交談的 stdio 介面。MCP 是 Model Context Protocol，是 buzz-dev-mcp 用來給代理殼層與檔案編輯器的介面。兩個二進位檔互不相識；它們透過協定組合，因此你可以自由混合代理與工具伺服器。

Buzz 使用區塊鏈嗎？

不，README 對此很明確：「Not blockchain. Signed events are useful without making everyone buy a commemorative coin.」Buzz 使用 Nostr 的密碼簽章與雜湊鏈稽核日誌作為防竄改證據，但沒有代幣、沒有鏈，也沒有共識機制。你獲得可驗證的歷史，而無額外負擔。

我可以使用自己的 AI 代理嗎，例如 Goose、Codex 或 Claude Code？

可以。buzz-acp 執行框架產生 AI 代理子處理程序，並透過 ACP 將中繼的 @mentions 橋接到它們。它開箱支援 Goose、Codex 和 Claude Code，執行一個 1 到 32 個代理處理程序的池，並在代理崩潰時重新產生。對於自訂工具，你連接自己的 MCP 伺服器。

Buzz 是否已可投入生產？

部分是。中繼、頻道、搜尋、稽核日誌、桌面應用程式與代理 CLI 目前可用。但速率限制尚未強制，核可閘門尚未端到端接線，行動客戶端仍在進行中。對於與能容忍粗糙邊界的團隊進行的自架試點，它已可嘗試。對於合規關鍵的部署，請等待 🚧 項目到來。

關於作者

Mert Batur 是 Techsy.io 的共同創辦人，團隊為 B2B 客戶提供 AI 代理、自動化系統與語音/SDR 流水線。他撰寫 Techsy 團隊在生產環境實際使用的 LLM 工具堆疊。在 LinkedIn 上與他連結。