Block Buzz: przestrzeń robocza agentów AI, w której agenci są kolegami z zespołu, nie botami

Block Buzz: przestrzeń robocza agentów AI, w której agenci są kolegami z zespołu, nie botami

Większość konfiguracji „AI w twoim czacie" działa tak samo: doczepiasz bota do Slacka lub Discorda, dajesz mu komendę z ukośnikiem, a on odpowiada, gdy go wezwać. Bot żyje poza zespołem. Ma oddzielną tożsamość, oddzielny ślad audytowy i twardy sufit tego, czego może dotknąć. Block przyjrzał się temu wzorcowi i uznał, że agent powinien po prostu być członkiem pokoju.

Tym pomysłem jest Buzz, open-source'owa przestrzeń robocza od Block, Inc., która przyciągnęła już około 18 000 gwiazdek na GitHubie. W Buzz ludzie i agenci AI dzielą te same kanały, podpisują swoje działania tym samym rodzajem klucza kryptograficznego i trafiają do tego samego przeszukiwalnego logu. Jest napisany w Rust i licencjonowany na Apache 2.0. Spędziłem czas na czytaniu dokumentacji architektury repozytorium, żebyś ty nie musiał, a wybory projektowe są ciekawsze, niż sugeruje marketing.

Czym jest Block Buzz?

Buzz to samo-hostowalna przestrzeń robocza od Block, Inc., w której ludzie i agenci AI dzielą te same kanały. Działa na przekaźniku Nostr, więc każda wiadomość, reakcja, łatka kodu, aprobata i krok przepływu pracy jest jednym podpisanym zdarzeniem w pojedynczym, przeszukiwalnym, odpornym na manipulacje logu. Jest open source na Apache 2.0, zbudowany w Rust, a przekaźnik obsługujesz sam.

Kluczowe wnioski:

• Agenci są pełnoprawnymi członkami z własnymi kluczami i własnym śladem audytowym, nie botami doczepionymi z boku.
• Wszystko (czat, łatki, CI, aprobaty) jest jednym podpisanym zdarzeniem Nostr w pojedynczym przeszukiwalnym logu.
• Agenci podłączają się przez ACP i MCP, więc Goose, Codex i Claude Code działają od razu.
• Samo-hostowany i open source (Apache 2.0), z uczciwą, publiczną listą tego, co jeszcze niegotowe.

Fraza, na której opiera się projekt, to "a hive mind communication platform". Brzmi to górnolotnie, ale codzienna rzeczywistość jest prostsza: czuje się jak przestrzeń robocza zespołu. Kanały, wątki, wiadomości prywatne, kanwa, głosowe huddle, wyszukiwanie. Sęk w tym, co pod spodem. Każde działanie jest podpisanym zdarzeniem Nostr, a autorem tego zdarzenia może być osoba lub proces. Ten sam kształt, ten sam model tożsamości, ten sam ślad audytowy w obu przypadkach.

Jeśli porównywałeś frameworki agentów, takie jak LangGraph, CrewAI i OpenAI Agents SDK, Buzz to zupełnie inna warstwa. To biblioteki, które osadzasz w kodzie, aby orkiestrować rozumowanie agenta. Buzz jest pokojem, w którym agent i twój zespół rozmawiają, przekazują sobie pracę i zostawiają ślad. Uzupełniają się, nie konkurują.

Dlaczego „agenci jako członkowie" zmieniają model

Model bota ma problem strukturalny: agent jest gościem. Przyznajesz mu flagi uprawnień, działa przez wąskie API, a gdy coś pójdzie nie tak, uzgadniasz dwie oddzielne historie — czat zespołu i logi bota.

Buzz to odwraca. Agent dostaje własną parę kluczy, własne członkostwa w kanałach i własny ślad audytowy. Dodajesz agenta do kanału tak samo jak osobę. Projekt opisuje zakresowanie jako "by identity, not by permission flags", co jest tym samym sposobem, w jaki zakresowałbyś ludzkiego kolegę z zespołu. Ufasz im w niektórych pokojach, a w innych nie.

Gdy agent jest członkiem, dostaje te same możliwości co wszyscy. Może otwierać repozytoria, wysyłać łatki, recenzować kod, uruchamiać przepływy pracy, edytować kanwy, orkiestrować innych agentów, tworzyć kanały i dołączać do głosowych huddle. README omawia trzy scenariusze, które to konkretyzują:

• Pamięć incydentów. Jest 2 w nocy, pytasz „czy widzieliśmy już ten błąd?", a agent obserwujący kanał wyciąga sześć miesięcy historii, publikuje wątki i przyczyny źródłowe, i proponuje wezwanie osoby, która wysłała ostatnią poprawkę. Cała wymiana zostaje w kanale jako dowód.
• Gałąź jako pokój. Otwierasz gałąź funkcji i pojawia się kanał. Łatki lądują jako zdarzenia, CI publikuje wyniki, agent robi pierwszy przegląd, a decyzja o scaleniu żyje w tym samym pokoju co dowody, które ją uzasadniły.
• Wydanie, które pisze się samo. Przepływ pracy odpala się na tagu, agent szkicuje notatki wydania ze scalonych PR-ów, publikuje je do ludzkiego przeglądu, dostaje reakcję kciuka w górę i wysyła. Każdy krok podpisany, każdy krok przeszukiwalny.

Wspólnym wątkiem jest to, że rozmowa, kod i decyzja żyją w jednym miejscu zamiast w siedmiu kartach udających, że się znają.

Jak agenci naprawdę się podłączają: ACP i MCP

Tu inżynieria staje się czysta. Buzz dostarcza dwa małe pliki binarne dla agentów i celowo nie wiedzą one o sobie nawzajem.

buzz-agent to agent ACP. Mówi Agent Client Protocol przez stdio, wywołuje LLM i używa narzędzi MCP. Prowadzi do ośmiu równoczesnych sesji, każda z własnymi serwerami MCP, historią i kontekstem. Gdy kontekst sesji się zapełnia, podsumowuje własną historię i działa dalej. Działa z Zed, JetBrains lub czymkolwiek, co mówi ACP.

buzz-dev-mcp to serwer MCP. Daje każdemu agentowi powłokę i edytor plików. Procesy są efemeryczne z zabiciem grupy procesów na każdej ścieżce wyjścia, wyjście jest ograniczone, a edycje plików rozwiązują się względem katalogu roboczego. Jeśli budowałeś wcześniej z Model Context Protocol, to będzie znajome: to standardowy wzorzec „daj agentowi ręce", utwardzony.

Notatka projektowa w repozytorium mówi wprost: "two binaries, two protocols, no coupling between them." Agent nie wie, z którym serwerem MCP rozmawia, a serwer MCP nie wie, który agent go wywołuje. Komponują się przez protokoły, nie przez importy. Praktyczna korzyść jest taka, że możesz uruchomić dziesięciu agentów za Buzzem z różnymi konfiguracjami MCP albo zmienić dostawcę LLM jedną zmienną środowiskową.

Ponieważ buzz-acp mostkuje @mentions przekaźnika do podprocesów agentów, możesz skierować go na Goose, Codex lub Claude Code. Jeśli już uruchamiasz agentów kodujących w tle, Buzz daje im wspólny pokój do działania zamiast cichej bezgłowej pętli. A jeśli chcesz przynieść własne narzędzia, zbudowanie serwera MCP jest wspieraną ścieżką, z mnóstwem gotowych serwerów MCP na start.

Pod maską: architektura

Buzz to monorepo Rust, a najważniejszy fakt jest taki: przekaźnik jest jedynym źródłem prawdy. Nie ma plotkowania peer-to-peer ani replikacji. Klienci łączą się z jednym przekaźnikiem przez WebSocket, a przekaźnik obsługuje uwierzytelnianie, weryfikuje podpisy, utrwala zdarzenia, rozsyła je do subskrybentów, indeksuje do wyszukiwania i wyzwalą automatyzacje.

Wszystko jest zdarzeniem Nostr NIP-01. Każde zdarzenie ma sześć pól: id (SHA-256 serializowanego zdarzenia), pubkey, liczbę całkowitą kind, tagi, treść i podpis Schnorr. Liczba całkowita kind jest jedynym przełącznikiem dyspozytacji. Chcesz nową funkcję? Zdefiniuj nowy numer kind. Istniejący klienci nic nie widzą i nic nie psują. Baza kodu definiuje 81 kind, a niestandardowe kind Buzza żyją w zakresie 40000-49999.

Stos wspierający jest celowo nudny, w najlepszym sensie:

Postgres trzyma zdarzenia i uruchamia wyszukiwanie pełnotekstowe. Redis obsługuje rozsyłanie pub/sub, obecność i pisanie. Magazyn obiektów kompatybilny z S3 (lokalnie MinIO) trzyma media przez protokół Blossom.

Model bezpieczeństwa to miejsce, w którym przestałem pobieżnie czytać. Każde zdarzenie ma zweryfikowany podpis Schnorr i ID SHA-256 przed zapisem. Uwierzytelnianie NIP-42 używa tolerancji znacznika czasu ±60 sekund, aby blokować ataki powtórzeniowe, a zdarzenia uwierzytelniające nigdy nie są zapisywane ani audytowane. Log audytowy jest prawdziwym łańcuchem skrótów: SHA-256 każdego wpisu obejmuje każde pole, w tym poprzedni skrót, więc manipulacja jednym wpisem psuje każdy wpis po nim. Wychodzące webhooki dostają ochronę SSRF sprawdzającą prywatne zakresy IP. A członkostwo w kanale jest jedyną bramą dostępu, egzekwowaną przy każdej operacji, przy czym handler subskrypcji sprawdza dostęp przed zarejestrowaniem subskrypcji, więc nie ma okna wyścigu dla wycieków prywatnych kanałów.

Jeśli oceniasz, jak wdrażać agentową AI na infrastrukturze, którą kontrolujesz, to jest część warta przeczytania dwa razy.

Co działa dziś (a co nie)

Projekt jest niezwykłe uczciwy co do własnego stanu i uważam, że ta uczciwość to najsilniejszy sygnał poważnej bazy kodu. Oto aktualny stan prosto z repozytorium:

Teraz część, którą większość wpisów produktowych pomija. Dokument architektury wymienia zweryfikowane luki, nie aspiracje:

• Żadne ograniczanie przepływności nie jest jeszcze egzekwowane. Trait RateLimiter istnieje i zaprojektowano cztery poziomy (human, agent-standard, agent-elevated, agent-platform), ale jedyna implementacja to testowy stub.
• Bramki aprobaty nie są spięte end-to-end. Wykonawca może zawiesić przebieg, ale przepływ pracy, który trafia na bramkę aprobaty, jest obecnie oznaczany jako nieudany.
• Niektóre akcje przepływu pracy są stubami. send_dm i set_channel_topic zwracają "not implemented", więc przebieg, który do nich dotrze, zawodzi.
• Nagrywanie huddle i publikowanie per ścieżka nie są zbudowane. Pokoje głosowe i cykl życia dołącz/wyjdź działają; nagrywanie ma zarezerwowane kind zdarzeń, ale brak producenta.
• Brak offline'owej pamięci zapytań sqlx. Zapytania działają w czasie wykonania zamiast być walidowane w czasie kompilacji.

Nic z tego nie dyskwalifikuje samo-hostowanego narzędzia, które oceniasz, ale mówi dokładnie, gdzie są krawędzie. Jeśli musisz oceniać agentów w produkcji z twardymi gwarancjami, traktuj kolumny 💭 i 🚧 jako nośne ostrzeżenia.

Rozpoczęcie pracy z Buzz

Są trzy ścieżki, w zależności od tego, kim jesteś.

Chcesz tylko wypróbować? Weź spakowaną wersję z najnowszego wydania: macOS (.dmg), Linux (.AppImage lub .deb) albo Windows (.exe). Domyślnie łączy się z ws://localhost:3000, więc i tak będziesz chciał mieć uruchomiony przekaźnik.

Chcesz budować ze źródeł? Potrzebujesz Dockera oraz Hermita lub Rust 1.88+, Node 24+, pnpm 10+ i just. Potem:

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

Przekaźnik ląduje na ws://localhost:3000 i wyskakuje aplikacja desktopowa. Dla jednoodzłowego wdrożenia VPS zamiast lokalnego stosu dev, jest produkcyjny pakiet Compose pod deploy/compose/ z Postgres, Redis, MinIO i opcjonalnym Caddy dla TLS.

Przynosisz agenta? Ustaw BUZZ_PRIVATE_KEY i użyj buzz-cli, który jest JSON wejście i JSON wyjście, zaprojektowany specjalnie dla wywołań narzędzi LLM. To jest szew, w którym łączą się twoje przepływy pracy agentów.

Kto powinien uruchamiać Buzza?

Buzz jest dla zespołów, które chcą jednego podłoża zamiast stosu kodu klejącego. Jeśli twoja obecna konfiguracja to czat plus kuźnia plus boty plus dashboardy CI plus narzędzia wydań plus indeks wyszukiwania, i masz dość tego, że się nie znają, oto zakład, który robi Buzz: jedna społeczność, jeden model tożsamości, jeden log zdarzeń.

Jest mocnym dopasowaniem dla:

• Samo-hostujących, którzy chcą ruchu swoich agentów na własnej infrastrukturze, ze śladem audytowym, który mogą zweryfikować.
• Inżynierów platform oceniających przepływy pracy agent-first, w których agenci triage'ują błędy, prowadzą przeglądy i szkicują wydania jako członkowie, a nie skrypty.
• Oceniających open source, którzy chcą przeczytać całość w jedno popołudnie. Powierzchnia agentowa to dwa crate'y bez sprzężenia, celowo dość małe, by je audytować.

Nie jest jeszcze dla ludzi, którzy chcą gotowego, z bateriami w zestawie SaaS, które mogą jutro przekazać nietechnicznemu zespołowi. Bramki aprobaty, ograniczanie przepływności i klienci mobilni wciąż lądują. Buzz mówi ci to wprost, co jest dokładnie powodem, dla którego powierzyłbym mu ostrożny pilotaż.

Ramowanie, do którego wciąż wracam, jest w README: "Agents are part of the room, not haunted cron jobs." Jeśli kiedykolwiek debugowałeś bota o 2 w nocy, nie mając pojęcia, co zrobił ani dlaczego, już wiesz, dlaczego to ma znaczenie.

FAQ

Czy Buzz jest darmowy i open source?

Tak. Buzz jest open source na licencji Apache 2.0 i zbudowany przez Block, Inc. Samo-hostujesz przekaźnik, więc nie ma opłaty za miejsce za oprogramowanie. Twoje koszty to twoja własna infrastruktura: serwer dla przekaźnika, Postgres, Redis i magazyn obiektów. Źródło, issues i roadmapa są wszystkie publiczne na GitHubie pod block/buzz.

Czym Buzz różni się od Slacka z botami?

Na Slacku agent jest drugorzędnym botem z oddzielną tożsamością i śladem audytowym, zakresowanym flagami uprawnień. W Buzz agent jest pełnoprawnym członkiem z własną parą kluczy, członkostwami w kanałach i tymi samymi możliwościami co człowiek: otwieranie repozytoriów, wysyłanie łatek, uruchamianie przepływów pracy, dołączanie do huddle. Wszystko ląduje w jednym podpisanym, przeszukiwalnym logu zdarzeń.

Czym są ACP i MCP?

ACP to Agent Client Protocol, interfejs stdio, którego buzz-agent używa do rozmowy z klientem LLM jak Zed. MCP to Model Context Protocol, interfejs, którego buzz-dev-mcp używa, by dać agentowi powłokę i edytor plików. Dwa pliki binarne nie wiedzą o sobie; komponują się przez protokoły, więc możesz swobodnie mieszać agentów i serwery narzędzi.

Czy Buzz używa blockchaina?

Nie, i README jest w tym stanowczy: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz używa kryptograficznych podpisów Nostr i łańcucha skrótów logu audytowego dla dowodu manipulacji, ale nie ma tokena, łańcucha ani mechanizmu konsensusu. Dostajesz weryfikowalną historię bez narzutu.

Czy mogę używać własnych agentów AI, takich jak Goose, Codex czy Claude Code?

Tak. Harness buzz-acp uruchamia podprocesy agentów AI i mostkuje @mentions przekaźnika do nich przez ACP. Wspiera Goose, Codex i Claude Code od razu, prowadzi pulę od jednego do 32 procesów agentów i restartuje agenta, jeśli się zawiesi. Dla własnych narzędzi podłączasz własny serwer MCP.

Czy Buzz jest gotowy do produkcji?

Częściowo. Przekaźnik, kanały, wyszukiwanie, log audytowy, aplikacja desktopowa i CLI agenta działają dziś. Ale ograniczanie przepływności nie jest egzekwowane, bramki aprobaty nie są spięte end-to-end, a klienci mobilni są wciąż w toku. Dla samo-hostowanego pilotażu z zespołem tolerującym szorstkie krawędzie, jest gotowy do wypróbowania. Dla wdrożenia krytycznego ze względu na zgodność, poczekaj, aż wylądują elementy 🚧.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i potoki głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Połącz się z nim na LinkedIn.