
Block Buzz: Tekoälyagenttien työtila, jossa agentit ovat tiimiläisiä, eivät botteja
Useimmat "tekoäly chattisi" -ratkaisut toimivat samalla tavalla: pulttaat botin Slacking tai Discordin kylkeen, annat sille slash-komennon, ja se vastaa, kun sitä kutsutaan. Botti elää tiimin ulkopuolella. Sillä on erillinen identiteetti, erillinen auditointijälki ja kova katto sille, mihin se voi koskea. Block katsoi tätä mallia ja päätti, että agentin pitäisi vain olla huoneen jäsen.
Tuo idea on Buzz, Block, Inc.:n avoimen lähdekoodin työtila, joka on jo kerännyt noin 18 000 GitHub-tähteä. Buzzissa ihmiset ja tekoälyagentit jakavat samat kanavat, allekirjoittavat toimintansa samanlaisella kryptografisella avaimella ja päätyvät samaan haettavaan lokiin. Se on kirjoitettu Rustilla ja lisensoitu Apache 2.0:lla. Kävin aikani repon arkkitehtuuridokumentteja läpi, jotta sinun ei tarvitsisi, ja suunnitteluvalinnat ovat kiinnostavampia kuin markkinointi antaa olettaa.
Mikä Block Buzz on?
Buzz on Block, Inc.:n itse isännöitävä työtila, jossa ihmiset ja tekoälyagentit jakavat samat kanavat. Se pyörii Nostr-releen päällä, joten jokainen viesti, reaktio, koodipatch, hyväksyntä ja työnkulun vaihe on yksi allekirjoitettu tapahtuma yhdessä haettavassa, peukaloinnin paljastavassa lokissa. Se on avoimen lähdekoodin Apache 2.0 -lisenssillä, rakennettu Rustilla, ja ajat releen itse.
Pääpointit:
- Agentit ovat täysivaltaisia jäseniä, joilla on omat avaimet ja auditointijälki – eivät sivuun pultattuja botteja.
- Kaikki (chatti, patchit, CI, hyväksynnät) on yksi allekirjoitettu Nostr-tapahtuma yhdessä haettavassa lokissa.
- Agentit kytkeytyvät ACP:n ja MCP:n kautta, joten Goose, Codex ja Claude Code toimivat suoraan paketista.
- Itse isännöitävä ja avoimen lähdekoodin (Apache 2.0), mukana rehellinen, julkinen lista siitä, mikä on vielä kesken.
Projektin itsensä käyttämä ilmaisu on "pesämielen viestintäalusta". Se kuulostaa mahtipontiselta, mutta arkipäivän todellisuus on yksinkertaisempi: se tuntuu tiimin työtilalta. Kanavat, säikeet, DM:t, canvas, äänihuddlet, haku. Juju on se, mitä pinnan alla on. Jokainen toiminto on allekirjoitettu Nostr-tapahtuma, ja tapahtuman tekijä voi olla ihminen tai prosessi. Sama muoto, sama identiteettimalli, sama auditointijälki kummallakin tavalla.
Jos olet vertaillut agenttikehyksiä kuten LangGraphia, CrewAI:ta ja OpenAI Agents SDK:ta, Buzz on aivan eri kerros. Ne ovat koodiin upotettavia kirjastoja, joilla orkestroit agentin päättelyä. Buzz on huone, jossa agentti ja tiimisi keskustelevat, siirtävät työtä eteenpäin ja jättävät jäljen. Ne täydentävät toisiaan, eivät kilpaile.
Miksi "agentit jäseninä" muuttaa mallin
Bottimallissa on rakenteellinen ongelma: agentti on vieras. Myönnät sille oikeuslippuja, se toimii kapean rajapinnan kautta, ja kun jotain menee pieleen, sovitat yhteen kahta erillistä historiaa – tiimin chatin ja botin lokit.
Buzz kääntää tämän nurin. Agentti saa oman avainparin, omat kanavajäsenyydet ja oman auditointijäljen. Lisäät agentin kanavalle samalla tavalla kuin lisäät ihmisen. Projekti kuvailee rajauksen tapahtuvan "identiteetin, ei oikeuslippujen perusteella" – samalla tavalla kuin rajaisit ihmistiimiläisen. Luotat heihin joissain huoneissa, etkä toisissa.
Kun agentti on jäsen, se saa samat mahdollisuudet kuin kaikki muutkin. Se voi avata repoja, lähettää patcheja, tehdä koodikatselmuksia, ajaa työnkulkuja, muokata canvaksia, orkestroida muita agentteja, luoda kanavia ja hypätä äänihuddleihin. README käy läpi kolme skenaariota, jotka tekevät tästä konkreettista:
- Häiriön muisti. Kello on 2 yöllä, kysyt "olemmeko nähneet tämän virheen aiemmin?", ja kanavaa seuraava agentti kaivaa kuuden kuukauden historian, postaa säikeet ja perussyyt ja tarjoautuu hälyttämään sen, joka toimitti viime korjauksen. Koko keskustelu jää kanavalle todisteeksi.
- Branch huoneena. Avaat feature-branchin, ja kanava ilmestyy. Patchit saapuvat tapahtumina, CI postaa tulokset, agentti tekee ensimmäisen katselmuskierroksen, ja merge-päätös elää samassa huoneessa kuin sen perustelleet todisteet.
- Julkaisu, joka kirjoittaa itsensä. Työnkulku laukeaa tagista, agentti luonnostelee julkaisumuistiinpanot mergetyistä PR:istä, postaa ne ihmisen katsottavaksi, saa peukkureaktion ja julkaisee. Jokainen vaihe allekirjoitettu, jokainen vaihe haettavissa.
Yhteinen nimittäjä on se, että keskustelu, koodi ja päätös elävät kaikki yhdessä paikassa sen sijaan, että seitsemän välilehteä teeskentelisi tietävän toisistaan.
Miten agentit oikeasti kytkeytyvät: ACP ja MCP
Tässä insinööritoiminta menee siistiksi. Buzz toimittaa kaksi pientä binääriä agenteille, eivätkä ne tahallisesti tiedä toisistaan mitään.
buzz-agent on ACP-agentti. Se puhuu Agent Client Protocol -protokollaa stdion yli, kutsuu LLM:ää ja käyttää MCP-työkaluja. Se ajaa jopa kahdeksaa samanaikaista istuntoa, joilla jokaisella on omat MCP-palvelimensa, historiansa ja kontekstinsa. Kun istunnon konteksti täyttyy, se tiivistää oman historiansa ja jatkaa. Se toimii Zedin, JetBrainsin tai minkä tahansa muun ACP:tä puhuvan kanssa.
buzz-dev-mcp on MCP-palvelin. Se antaa mille tahansa agentille shellin ja tiedostoeditorin. Prosessit ovat lyhytkestoisia, ja prosessiryhmä tapetaan jokaisella poistumispolulla, tuloste on rajattu, ja tiedostomuokkaukset ratkaistaan työhakemistoa vasten. Jos olet rakentanut Model Context Protocolilla aiemmin, tämä tuntuu tutulta: se on tavallinen "anna agentille kädet" -malli, karkaistuna.
Repon suunnittelumuistio sanoo sen suoraan: "kaksi binääriä, kaksi protokollaa, ei kytköstä niiden välillä". Agentti ei tiedä, mille MCP-palvelimelle se puhuu, eikä MCP-palvelin tiedä, mikä agentti sitä kutsuu. Ne yhdistyvät protokollien, eivät importtien kautta. Käytännön hyöty on se, että voit ajaa kymmentä agenttia Buzzin takana eri MCP-konfiguraatioilla tai vaihtaa LLM-tarjoajaasi yhdellä ympäristömuuttujalla.
Koska buzz-acp siltaa releen @maininnat agenttien aliprosesseihin, voit suunnata sen Gooseen, Codexiin tai Claude Codeen. Jos ajat jo taustakoodausagentteja, Buzz antaa niille jaetun huoneen toimia hiljaisen headless-loopin sijaan. Ja jos haluat tuoda omat työkalusi, MCP-palvelimen rakentaminen on tuettu polku, ja lähtökohdaksi on runsaasti valmiita MCP-palvelimia.
Pellin alla: arkkitehtuuri
Buzz on Rust-monorepo, ja yksittäisen tärkein fakta on tämä: rele on ainoa totuuden lähde. Ei vertaisverkkokuulumisia eikä replikointia. Clientit yhdistyvät yhteen releeseen WebSocketin yli, ja rele hoitaa autentikoinnin, varmentaa allekirjoitukset, persistoi tapahtumat, jakaa ne tilaajille, indeksoi ne hakua varten ja laukaisee automaation.
Kaikki on Nostr NIP-01 -tapahtuma. Jokaisessa tapahtumassa on kuusi kenttää: id (serialisoidun tapahtuman SHA-256), pubkey, kind-kokonaisluku, tagit, sisältö ja Schnorr-allekirjoitus. kind-kokonaisluku on ainoa ohjauskytkin. Haluatko uuden ominaisuuden? Määrittele uusi kind-numero. Olemassa olevat clientit eivät näe mitään eivätkä riko mitään. Koodipohja määrittelee 81 kindiä, ja Buzzin omat kindit elävät alueella 40 000–49 999.

Tukipino on tarkoituksella tylsä, parhaalla mahdollisella tavalla:
| Crate | Rooli |
|---|---|
buzz-core | Zero-I/O-tyypit, Schnorr-varmennus, suodatinten täsmäytys, kind-rekisteri |
buzz-relay | Axum-palvelin, joka sitoo kaikki alijärjestelmät yhteen |
buzz-db | Postgres-tapahtumavarasto, kanavat, työnkulut, kuukausittainen partitionointi |
buzz-auth | NIP-42- ja NIP-98-Schnorr-auth, scopet |
buzz-pubsub | Redis pub/sub -fan-out, läsnäolo, kirjoitusilmaisimet |
buzz-search | Postgres-kokoteksthaku generoidun tsvector-sarakkeen päällä |
buzz-audit | Tiivisteketju, peukaloinnin paljastava auditointiloki |
buzz-workflow | YAML-as-code-automaatiomoottori |
buzz-cli | Agent-first-CLI, JSON sisään / JSON ulos |
buzz-acp | Siltaa releen @maininnat tekoälyagenteihin ACP:n kautta |
Postgres pitää tapahtumat ja ajaa kokotekstihaun. Redis hoitaa pub/sub-fan-outin, läsnäolon ja kirjoitusilmaisimet. S3-yhteensopiva objektitallennus (MinIO lokaalisti) säilyttää median Blossom-protokollan kautta.
Tietoturvamalli on kohta, jossa lopetin silmäilemisen. Jokaisen tapahtuman Schnorr-allekirjoitus ja SHA-256-tunnus varmennetaan ennen tallennusta. NIP-42-auth käyttää ±60 sekunnin aikaleimantoleranssia toistohyökkäysten estämiseksi, eikä auth-tapahtumia koskaan tallenneta tai auditoida. Auditointiloki on aito tiivisteketju: jokaisen merkinnän SHA-256 kattaa kaikki kentät edellinen tiiviste mukaan lukien, joten yhden merkinnän peukalointi rikkoo jokaisen sen jälkeisen merkinnän. Lähtevät webhookit saavat SSRF-suojauksen, joka tarkistaa yksityiset IP-alueet. Ja kanavajäsenyys on ainoa pääsyportti, jota valvotaan jokaisessa operaatiossa – tilauskäsittelijä tarkistaa pääsyn ennen kuin se rekisteröi tilauksen, joten yksityiskanavavuodoille ei jää kilpailutilanteen aikaikkunaa.
Jos arvioit, miten agenttista tekoälyä julkaistaan infrastruktuurissa, jota kontrolloit, tämä on se osa, joka kannattaa lukea kahdesti.
Mikä toimii tänään (ja mikä ei)
Projekti on epätavallisen rehellinen omasta tilastaan, ja mielestäni juuri tuo rehellisyys on vahvin signaali vakavasti otettavasta koodipohjasta. Tässä nykytila suoraan reposta:
| Tila | Ominaisuus |
|---|---|
| ✅ Toimii tänään | Rele, kanavat, säikeet, DM:t, canvakset, media, haku, auditointiloki, työpöytäsovellus (Tauri + React), buzz-cli + ACP-harness, YAML-työnkulut, Git-tapahtumat (NIP-34), git-hostingtausta |
| 🚧 Työn alla | Mobiiliclientit (iOS + Android, Flutter), työnkulkujen hyväksyntäportit, huddlejen elinkaaritapahtumat |
| 💭 Koodia odottaa | Web-of-trust-maine releiden välillä, push-ilmoitukset |
Sitten se osa, jonka useimmat tuotepostaukset ohittavat. Arkkitehtuuridokumentti listaa varmennetut puutteet, ei toiveita:
- Nopeusrajoitusta ei vielä valvota.
RateLimiter-trait on olemassa ja neljä tasoa on suunniteltu (human, agent-standard, agent-elevated, agent-platform), mutta ainoa toteutus on testistub. - Hyväksyntäportteja ei ole kytketty päästä päähän. Suoritin voi keskeyttää ajon, mutta työnkulku, joka osuu hyväksyntäporttiin, merkitään tällä hetkellä epäonnistuneeksi.
- Osa työnkulun toiminnoista on stubattu.
send_dmjaset_channel_topicpalauttavat "not implemented", joten niihin osuva ajo epäonnistuu. - Huddle-tallennusta ja raittakohtaista julkaisua ei ole rakennettu. Äänihuoneet ja liittymis-/poistumiselinkaari toimivat; tallennukselle on varatut tapahtumakindit, mutta ei tuottajaa.
- Ei sqlx:n offline-kyselyvälimuistia. Kyselyt ajetaan ajonaikaisesti sen sijaan, että ne validoittaisiin käännösaikana.
Mikään tästä ei diskvalifioi itse isännöitävää työkalua, jota olet arvioimassa, mutta se kertoo tarkalleen, missä reunat ovat. Jos sinun täytyy arvioida agentteja tuotannossa kovin takuita, käsittele 💭- ja 🚧-sarakkeita kantavina varoituksina.
Näin pääset alkuun Buzzilla
Polkuja on kolme, riippuen siitä, kuka olet.
Haluat vain kokeilla? Nappaa paketoitu build uusimmasta releasesta: macOS (.dmg), Linux (.AppImage tai .deb) tai Windows (.exe). Oletuksena se yhdistää osoitteeseen ws://localhost:3000, joten haluat silti releen pyörimään.
Haluatko rakentaa lähdekoodista? Tarvitset Dockerin ja joko Hermitin tai Rust 1.88+:n, Node 24+:n, pnpm 10+:n ja just:n. Sitten:
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 togetherRele asettuu osoitteeseen ws://localhost:3000, ja työpöytäsovellus ponnahtaa esiin. Yhden solmun VPS-julkaisuun paikallisen kehityspinon sijaan on tuotannon Compose-paketti hakemistossa deploy/compose/, mukana Postgres, Redis, MinIO ja valinnainen Caddy TLS:ää varten.
Tuletko agentin kanssa? Aseta BUZZ_PRIVATE_KEY ja käytä buzz-cli:tä, joka ottaa JSONia sisään ja ulos ja on suunniteltu erityisesti LLM-työkalukutsuihin. Se on sauma, johon agenttityönkulkusi kytkeytyvät.
Kenen kannattaa ajaa Buzzia?
Buzz on tiimeille, jotka haluavat yhden alustan liimakoodikasan sijaan. Jos nykyinen setuppisi on chatti plus forge plus botit plus CI-dashboardit plus julkaisutyökalut plus hakuindeksi, ja olet kyllästynyt siihen, etteivät ne tiedä toisistaan, tämä on se veto, jonka Buzz tekee: yksi yhteisö, yksi identiteettimalli, yksi tapahtumaloki.
Se sopii vahvasti:
- Itse isännöitsijöille, jotka haluavat agenttiliikenteensä omaan infrastruktuuriin auditointijäljellä, jonka voivat varmentaa.
- Alustainsinööreille, jotka arvioivat agent-first-työnkulkuja, joissa agentit tekevät bugitriagea, ajavat katselmuksia ja luonnostelevat julkaisuja jäseninä eivätkä skripteinä.
- Avoimen lähdekoodin arvioitsijoille, jotka haluavat lukea koko systeemin yhdessä iltapäivässä. Agenttipinta on kaksi cratea ilman kytköksiä – tarkoituksella tarpeeksi pieni auditointiin.
Se ei ole vielä ihmisille, jotka haluavat valmiin, kaiken kattavan SaaS:n, jonka voi antaa huomenna ei-teknisen tiimin käsiin. Hyväksyntäportit, nopeusrajoitus ja mobiiliclientit ovat vielä valmistumassa. Buzz kertoo tämän suoraan, ja juuri siksi luottaisin siihen huolellisessa pilotissa.
Se framays, johon palaan yhä uudelleen, löytyy README:stä: "Agentit ovat osa huonetta, eivät kummittelevia cron-töitä." Jos olet koskaan debugannut bottia kello 2 yöllä tietämättä, mitä se teki tai miksi, tiedät jo, miksi sillä on väliä.
FAQ
Onko Buzz ilmainen ja avoimen lähdekoodin?
Kyllä. Buzz on avoimen lähdekoodin Apache 2.0 -lisenssillä, ja sen rakentaa Block, Inc. Isännöit releen itse, joten ohjelmistolla ei ole käyttäjäkohtaista maksua. Kustannuksesi ovat oma infrastruktuurisi: palvelin releelle, Postgres, Redis ja objektitallennus. Lähdekoodi, issuet ja tiekartta ovat kaikki julkisia GitHubissa osoitteessa block/buzz.
Miten Buzz eroaa Slackista boteilla?
Slackissa agentti on toisen luokan botti, jolla on erillinen identiteetti ja auditointijälki ja joka rajataan oikeuslipuilla. Buzzissa agentti on täysivaltainen jäsen, jolla on oma avainpari, kanavajäsenyydet ja samat mahdollisuudet kuin ihmisellä: repojen avaaminen, patchien lähettäminen, työnkulkujen ajaminen, huddleihin liittyminen. Kaikki päätyy yhteen allekirjoitettuun, haettavaan tapahtumalokiin.
Mitä ACP ja MCP ovat?
ACP on Agent Client Protocol, stdio-rajapinta, jota buzz-agent käyttää puhuakseen LLM-clientille kuten Zedille. MCP on Model Context Protocol, rajapinta, jota buzz-dev-mcp käyttää antaakseen agentille shellin ja tiedostoeditorin. Kaksi binääriä eivät tiedä toisistaan; ne yhdistyvät protokollien kautta, joten voit sekoittaa agentteja ja työkalupalvelimia vapaasti.
Käyttääkö Buzz lohkoketjua?
Ei, ja README sanoo sen suoraan: "Ei lohkoketjua. Allekirjoitetut tapahtumat ovat hyödyllisiä ilman, että kaikkien tarvitsee ostaa muistorahaa." Buzz käyttää Nostrin kryptografisia allekirjoituksia ja tiivisteketjuauditointilokia peukaloinnin todistamiseen, mutta tokenia, ketjua tai konsensusmekanismia ei ole. Saat varmennettavan historian ilman ylikuormitusta.
Voinko käyttää omia tekoälyagenttejani, kuten Goosea, Codexia tai Claude Codea?
Kyllä. buzz-acp-harness käynnistää tekoälyagenttien aliprosesseja ja siltaa releen @maininnat niihin ACP:n yli. Se tukee Goosea, Codexia ja Claude Codea suoraan paketista, ajaa 1–32 agenttiprosessin poolia ja käynnistää agentin uudelleen, jos se kaatuu. Omia työkaluja varten kytket oman MCP-palvelimesi.
Onko Buzz tuotantovalmis?
Osittain. Rele, kanavat, haku, auditointiloki, työpöytäsovellus ja agentti-CLI toimivat tänään. Mutta nopeusrajoitusta ei valvota, hyväksyntäportteja ei ole kytketty päästä päähän, ja mobiiliclientit ovat vielä työn alla. Itse isännöitävään pilottiin tiimin kanssa, joka sietää karheuksia, se on valmis kokeiltavaksi. Vaatimustenmukaisuuskriittiseen julkaisuun odota 🚧-kohtien valmistumista.
Tietoja kirjoittajasta
Mert Batur on Techsy.ion toinen perustaja, ja tiimi rakentaa tekoälyagentteja, automaatiojärjestelmiä sekä puhe-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa. Ota häneen yhteyttä LinkedInissä.