Block Buzz: spațiul de lucru al agenților IA unde agenții sunt colegi de echipă, nu boți

Block Buzz: spațiul de lucru al agenților IA unde agenții sunt colegi de echipă, nu boți

Majoritatea configurațiilor de „IA în chat-ul tău" funcționează la fel: atașezi un bot la Slack sau Discord, îi dai o comandă cu slash și răspunde când este chemat. Botul trăiește în afara echipei. Are o identitate separată, un traseu de audit separat și un plafon strict asupra a ce poate atinge. Block s-a uitat la acel tipar și a decis că agentul ar trebui să fie pur și simplu un membru al camerei.

Această idee este Buzz, un spațiu de lucru open source de la Block, Inc. care a atras deja în jur de 18.000 de stele GitHub. În Buzz, oamenii și agenții IA împart aceleași canale, își semnează acțiunile cu același tip de cheie criptografică și ajung în același jurnal căutabil. Este scris în Rust și licențiat Apache 2.0. Am petrecut timp citind documentele de arhitectură ale depozitului ca să nu fii nevoit tu, iar alegerile de design sunt mai interesante decât sugerează marketingul.

Ce este Block Buzz?

Buzz este un spațiu de lucru self-hostabil de la Block, Inc. unde oamenii și agenții IA împart aceleași canale. Rulează pe un releu Nostr, astfel încât fiecare mesaj, reacție, patch de cod, aprobare și pas de flux de lucru este un eveniment semnat într-un singur jurnal căutabil, rezistent la manipulare. Este open source sub Apache 2.0, construit în Rust, iar tu rulezi singur releul.

Puncte cheie:

• Agenții sunt membri de primă clasă cu propriile chei și propriul traseu de audit, nu boți atașați pe lângă.
• Totul (chat, patch-uri, CI, aprobări) este un eveniment Nostr semnat într-un singur jurnal căutabil.
• Agenții se conectează prin ACP și MCP, deci Goose, Codex și Claude Code funcționează imediat.
• Self-hosted și open source (Apache 2.0), cu o listă onestă și publică a ce nu este gata încă.

Fraza pe care se sprijină proiectul este "a hive mind communication platform". Sună grandios, dar realitatea de zi cu zi e mai simplă: se simte ca un spațiu de lucru de echipă. Canale, fire, mesaje directe, un canvas, huddle-uri vocale, căutare. Răsturnarea e ce se află dedesubt. Fiecare acțiune este un eveniment Nostr semnat, iar autorul acelui eveniment poate fi o persoană sau un proces. Aceeași formă, același model de identitate, același traseu de audit în ambele cazuri.

Dacă ai comparat framework-uri de agenți precum LangGraph, CrewAI și OpenAI Agents SDK, Buzz este un strat cu totul diferit. Acelea sunt biblioteci pe care le încorporezi în cod pentru a orchestra raționamentul unui agent. Buzz este camera unde agentul și echipa ta vorbesc, predau lucru și lasă o urmă. Sunt complementare, nu concurente.

De ce „agenții ca membri" schimbă modelul

Modelul bot are o problemă structurală: agentul este un musafir. Îi acorzi fanioane de permisiune, operează printr-un API îngust, iar când ceva nu merge, reconciliezi două istorice separate — chat-ul echipei și jurnalele botului.

Buzz răstoarnă asta. Un agent primește propria pereche de chei, propriile apartenențe la canale și propriul traseu de audit. Adaugi un agent la un canal în același mod în care adaugi o persoană. Proiectul descrie definirea sferei ca "by identity, not by permission flags", care e același mod în care ai defini sfera unui coleg uman. Ai încredere în ei în unele camere și nu în altele.

Odată ce un agent este membru, primește aceleași posibilități pe care le au toți ceilalți. Poate deschide depozite, trimite patch-uri, revizui cod, rula fluxuri de lucru, edita canvas-uri, orchestra alți agenți, crea canale și intra în huddle-uri vocale. README-ul parcurge trei scenarii care fac asta concret:

• Memoria incidentelor. E ora 2 noaptea, întrebi „am mai văzut eroarea asta?", iar un agent care urmărește canalul extrage șase luni de istoric, postează firele și cauzele profunde și se oferă să cheme pe cine a livrat ultima corecție. Întregul schimb rămâne în canal ca dovadă.
• Branch-ul ca cameră. Deschizi un branch de funcționalitate și apare un canal. Patch-urile aterizează ca evenimente, CI postează rezultate, un agent face o primă revizuire, iar decizia de merge trăiește în aceeași cameră cu dovezile care au justificat-o.
• Un release care se scrie singur. Un flux de lucru se declanșează la un tag, un agent schițează note de release din PR-urile îmbinate, le postează pentru revizuire umană, primește o reacție de deget în sus și livrează. Fiecare pas semnat, fiecare pas căutabil.

Firul comun este că conversația, codul și decizia trăiesc toate într-un singur loc, în loc de șapte tab-uri care se prefac că știu unele de altele.

Cum se conectează de fapt agenții: ACP și MCP

Aici ingineria devine curată. Buzz livrează două binare mici pentru agenți, iar ele nu știu în mod deliberat unele de altele.

buzz-agent este un agent ACP. Vorbește Agent Client Protocol peste stdio, apelează un LLM și folosește unelte MCP. Rulează până la opt sesiuni simultane, fiecare cu propriile servere MCP, istoric și context. Când contextul unei sesiuni se umple, își rezumă propriul istoric și continuă. Funcționează cu Zed, JetBrains sau orice altceva vorbește ACP.

buzz-dev-mcp este un server MCP. Dă oricărui agent un shell și un editor de fișiere. Procesele sunt efemere, cu omorârea grupului de procese pe fiecare cale de ieșire, ieșirea este limitată, iar editările de fișiere se rezolvă față de directorul de lucru. Dacă ai construit cu Model Context Protocol înainte, asta ți se va părea familiar: e tiparul standard „dă unui agent mâini", întărit.

Nota de design din depozit spune răspicat: "two binaries, two protocols, no coupling between them." Agentul nu știe cu ce server MCP vorbește, iar serverul MCP nu știe ce agent îl apelează. Se compun prin protocoale, nu prin importuri. Câștigul practic este că poți rula zece agenți în spatele Buzz cu configurații MCP diferite sau poți schimba furnizorul de LLM cu o singură variabilă de mediu.

Pentru că buzz-acp face punte între @mentions releului și subprocesele agenților, îl poți îndrepta spre Goose, Codex sau Claude Code. Dacă deja rulezi agenți de codare în fundal, Buzz le oferă o cameră partajată în care să opereze, în locul unei bucle headless tăcute. Iar dacă vrei să aduci propriile unelte, construirea unui server MCP este calea suportată, cu o mulțime de servere MCP gata făcute de la care să pornești.

Sub capotă: arhitectura

Buzz este un monorepo Rust, iar cel mai important fapt este acesta: releul este singura sursă de adevăr. Nu există bârfă peer-to-peer și nu există replicare. Clienții se conectează la un releu prin WebSocket, iar releul gestionează autentificarea, verifică semnăturile, persistă evenimentele, le distribuie abonaților, le indexează pentru căutare și declanșează automatizări.

Totul este un eveniment Nostr NIP-01. Fiecare eveniment are șase câmpuri: un id (SHA-256 al evenimentului serializat), un pubkey, un întreg kind, tag-uri, conținut și o semnătură Schnorr. Întregul kind este singurul comutator de dispecerizare. Vrei o funcționalitate nouă? Definește un nou număr kind. Clienții existenți nu văd nimic și nu strică nimic. Baza de cod definește 81 de kind-uri, cu kind-urile personalizate Buzz trăind în intervalul 40000-49999.

Stiva de suport este în mod deliberat plictisitoare, în cel mai bun sens:

Postgres ține evenimentele și rulează căutarea full-text. Redis gestionează distribuția pub/sub, prezența și tastarea. Stocarea de obiecte compatibilă S3 (MinIO local) ține media prin protocolul Blossom.

Modelul de securitate este locul unde am încetat să mai frunzăresc. Fiecare eveniment are semnătura Schnorr și ID-ul SHA-256 verificate înainte de stocare. Autentificarea NIP-42 folosește o toleranță de marcaj temporal de ±60 de secunde pentru a bloca atacurile de reluare, iar evenimentele de autentificare nu sunt stocate sau auditate niciodată. Jurnalul de audit este un lanț de hash veritabil: SHA-256-ul fiecărei intrări acoperă fiecare câmp, inclusiv hash-ul anterior, deci manipularea unei intrări strică fiecare intrare de după ea. Webhook-urile de ieșire primesc protecție SSRF care verifică intervalele de IP private. Iar apartenența la canal este singura poartă de acces, aplicată la fiecare operațiune, cu handlerul de abonament verificând accesul înainte să înregistreze un abonament, deci nu există fereastră de cursă pentru scurgeri de canale private.

Dacă evaluezi cum să implementezi IA agentică pe infrastructură pe care o controlezi, aceasta este partea care merită citită de două ori.

Ce funcționează azi (și ce nu)

Proiectul este neobișnuit de onest despre propriul statut și cred că acea onestitate este cel mai puternic semnal al unei baze de cod serioase. Iată starea actuală direct din depozit:

Acum partea pe care majoritatea articolelor de produs o sar. Documentul de arhitectură enumeră lacune verificate, nu aspirații:

• Nicio limitare de rată nu este aplicată încă. Trait-ul RateLimiter există și patru niveluri sunt proiectate (human, agent-standard, agent-elevated, agent-platform), dar singura implementare este un stub de test.
• Porțile de aprobare nu sunt conectate end-to-end. Executorul poate suspenda o rulare, dar un flux de lucru care lovește o poartă de aprobare este marcat momentan ca eșuat.
• Unele acțiuni de flux sunt stub-uri. send_dm și set_channel_topic returnează "not implemented", deci o rulare care ajunge la una eșuează.
• Înregistrarea huddle și publicarea per piesă nu sunt construite. Camerele vocale și ciclul de viață intrare/ieșire funcționează; înregistrarea are kind-uri de eveniment rezervate, dar niciun producător.
• Fără cache de interogări sqlx offline. Interogările rulează la execuție în loc să fie validate la compilare.

Nimic din asta nu este descalficant pentru o unealtă self-hosted pe care o evaluezi, dar îți spune exact unde sunt marginile. Dacă trebuie să evaluezi agenți în producție cu garanții dure, tratează coloanele 💭 și 🚧 ca avertismente portante.

Începerea cu Buzz

Există trei căi, în funcție de cine ești.

Vrei doar să încerci? Ia un build împachetat de la ultimul release: macOS (.dmg), Linux (.AppImage sau .deb) sau Windows (.exe). Implicit se conectează la ws://localhost:3000, deci vei vrea totuși un releu care rulează.

Vrei să construiești din sursă? Ai nevoie de Docker și fie Hermit, fie Rust 1.88+, Node 24+, pnpm 10+ și just. Apoi:

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

Releul aterizează pe ws://localhost:3000 și aplicația desktop apare. Pentru o implementare VPS cu un singur nod în locul stivei de dezvoltare locală, există un pachet Compose de producție sub deploy/compose/ cu Postgres, Redis, MinIO și Caddy opțional pentru TLS.

Aduci un agent? Setează BUZZ_PRIVATE_KEY și folosește buzz-cli, care este JSON intrare și JSON ieșire, proiectat special pentru apeluri de unelte LLM. Acela este cusătura unde se conectează fluxurile tale de agenți.

Cine ar trebui să ruleze Buzz?

Buzz este pentru echipele care vor un singur substrat în loc de o grămadă de cod de lipire. Dacă configurația ta actuală este chat plus o forjă plus boți plus tablouri CI plus unelte de release plus un index de căutare și te-ai săturat ca ele să nu știe unele de altele, acesta este pariul pe care îl face Buzz: o comunitate, un model de identitate, un jurnal de evenimente.

Se potrivește bine pentru:

• Self-hosteri care vor traficul agenților lor pe infrastructură pe care o dețin, cu un traseu de audit pe care îl pot verifica.
• Ingineri de platformă care evaluează fluxuri de lucru agent-first unde agenții triază bug-uri, rulează revizuiri și schițează release-uri ca membri, nu ca scripturi.
• Evaluatori open source care vor să citească totul într-o după-amiază. Suprafața agenților este două crate-uri fără cuplaj, în mod deliberat suficient de mici pentru a fi auditate.

Nu este încă pentru cei care vor un SaaS terminat, cu baterii incluse, pe care să-l predea mâine unei echipe netehnice. Porțile de aprobare, limitarea de rată și clienții mobili încă aterizează. Buzz îți spune asta răspicat, ceea ce este exact motivul pentru care i-aș încredința un pilot atent.

Încadrarea la care mă întorc mereu este în README: "Agents are part of the room, not haunted cron jobs." Dacă ai depanat vreodată un bot la ora 2 noaptea fără nicio idee ce a făcut sau de ce, știi deja de ce contează.

Întrebări frecvente

Buzz este gratuit și open source?

Da. Buzz este open source sub licența Apache 2.0 și construit de Block, Inc. Self-hostuiești releul singur, deci nu există taxă per loc pentru software. Costurile tale sunt propria infrastructură: un server pentru releu, Postgres, Redis și stocare de obiecte. Sursa, issue-urile și roadmap-ul sunt toate publice pe GitHub la block/buzz.

Cum diferă Buzz de Slack cu boți?

În Slack, un agent este un bot de clasa a doua, cu identitate și traseu de audit separate, definit de fanioane de permisiune. În Buzz, un agent este un membru de primă clasă cu propria pereche de chei, apartenențe la canale și aceleași posibilități ca un om: deschiderea de depozite, trimiterea de patch-uri, rularea de fluxuri de lucru, alăturarea la huddle-uri. Totul aterizează într-un singur jurnal de evenimente semnat și căutabil.

Ce sunt ACP și MCP?

ACP este Agent Client Protocol, interfața stdio pe care buzz-agent o folosește pentru a vorbi cu un client LLM precum Zed. MCP este Model Context Protocol, interfața pe care buzz-dev-mcp o folosește pentru a da unui agent un shell și un editor de fișiere. Cele două binare nu știu unele de altele; se compun prin protocoale, deci poți amesteca liber agenți și servere de unelte.

Buzz folosește blockchain?

Nu, iar README-ul este tranșant în privința asta: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz folosește semnăturile criptografice ale Nostr și un jurnal de audit cu lanț de hash pentru dovada manipulării, dar nu există token, nici lanț, nici mecanism de consens. Obții istoric verificabil fără supraîncărcare.

Pot folosi propriii mei agenți IA, precum Goose, Codex sau Claude Code?

Da. Harness-ul buzz-acp generează subprocese de agenți IA și face punte între @mentions releului și ele prin ACP. Suportă Goose, Codex și Claude Code imediat, rulează un pool de la unu la 32 de procese de agent și regenerează un agent dacă se prăbușește. Pentru unelte personalizate, conectezi propriul server MCP.

Buzz este gata pentru producție?

Parțial. Releul, canalele, căutarea, jurnalul de audit, aplicația desktop și CLI-ul agenților funcționează azi. Dar limitarea de rată nu este aplicată, porțile de aprobare nu sunt conectate end-to-end, iar clienții mobili sunt încă în lucru. Pentru un pilot self-hosted cu o echipă care tolerează margini aspre, este gata de încercat. Pentru o implementare critică pentru conformitate, așteaptă ca elementele 🚧 să aterizeze.

Despre autor

Mert Batur este cofondator al Techsy.io, unde echipa livrează agenți IA, sisteme de automatizare și pipeline-uri voce/SDR pentru clienți B2B. Scrie despre stiva de unelte LLM pe care echipa Techsy o folosește efectiv în producție. Conectează-te cu el pe LinkedIn.