Block Buzz: робочий простір агентів ШІ, де агенти — колеги, а не боти

Block Buzz: робочий простір агентів ШІ, де агенти — колеги, а не боти

Більшість конфігурацій «ШІ у вашому чаті» працюють однаково: ви прикручуєте бота до Slack чи Discord, даєте йому слеш-команду, і він відповідає, коли його кличуть. Бот живе поза командою. Він має окрему ідентичність, окремий аудит-слід і жорстку стелю того, чого може торкатися. Block подивився на цей шаблон і вирішив, що агент має просто бути учасником кімнати.

Ця ідея — Buzz, робочий простір з відкритим кодом від Block, Inc., який уже зібрав близько 18 000 зірок на GitHub. У Buzz люди й агенти ШІ ділять ті самі канали, підписують свої дії одним типом криптографічного ключа й потрапляють в один журнал, який можна шукати. Він написаний на Rust і ліцензований під Apache 2.0. Я витратив час на читання архітектурної документації репозиторію, щоб вам не довелося, і проєктні рішення цікавіші, ніж підказує маркетинг.

Що таке Block Buzz?

Buzz — це робочий простір від Block, Inc., який можна розмістити самостійно, де люди й агенти ШІ ділять ті самі канали. Він працює на ретрансляторі 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. Він розмовляє Agent Client Protocol через stdio, викликає 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, і найважливіший факт такий: ретранслятор — єдине джерело істини. Немає пліток peer-to-peer і немає реплікації. Клієнти підключаються до одного ретранслятора через 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 та ID SHA-256 перед збереженням. Автентифікація NIP-42 використовує допуск мітки часу ±60 секунд, щоб блокувати атаки повторного відтворення, а собитія автентифікації ніколи не зберігаються й не аудіюються. Аудит-журнал — справжній ланцюг хешів: SHA-256 кожного запису покриває кожне поле, включно з попереднім хешем, тож втручання в один запис ламає кожен запис після нього. Вихідні вебхуки отримують захист SSRF, що перевіряє приватні діапазони IP. А членство в каналі — єдині ворота доступу, що застосовуються на кожній операції, причому обробник підписок перевіряє доступ перед реєстрацією підписки, тож немає вікна гонитви для витоків приватних каналів.

Якщо ви оцінюєте, як розгортати агентний ШІ на інфраструктурі, яку контролюєте, це частина, яку варто прочитати двічі.

Що працює сьогодні (а що ні)

Проєкт незвично чесний щодо власного стану, і я вважаю цю чесність найсильнішим сигналом серйозної кодової бази. Ось поточний стан просто з репозиторію:

Тепер частина, яку більшість продуктових дописів пропускає. Архітектурний документ перелічує перевірені прогалини, а не прагнення:

• Обмеження швидкості ще не застосовується. Трейт RateLimiter існує, і розроблено чотири рівні (human, agent-standard, agent-elevated, agent-platform), але єдина реалізація — тестова заглушка.
• Ворота схвалення не з'єднані наскрізно. Виконавець може призупинити запуск, але робочий процес, що впирається у ворота схвалення, наразі позначається як невдалий.
• Деякі дії робочого процесу — заглушки. 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 замість локального dev-стеку є продакшн-пакет Compose під deploy/compose/ з Postgres, Redis, MinIO й опційним Caddy для TLS.

Приносите агента? Встановіть BUZZ_PRIVATE_KEY і використовуйте buzz-cli, який є JSON вхід і JSON вихід, розроблений спеціально для викликів інструментів LLM. Це шов, де підключаються ваші робочі процеси агентів.

Кому варто запускати Buzz?

Buzz — для команд, які хочуть один субстрат замість купи клею-коду. Якщо ваша поточна конфігурація — чат плюс кузня плюс боти плюс панелі CI плюс інструменти релізів плюс пошуковий індекс, і вам набридло, що вони не знають одне про одного, ось ставка, яку робить Buzz: одна спільнота, одна модель ідентичності, один журнал собитій.

Він добре пасує для:

• Самостійних хостерів, які хочуть трафік агентів на власній інфраструктурі, з аудит-слідом, який вони можуть перевірити.
• Платформних інженерів, які оцінюють робочі процеси з пріоритетом агентів, де агенти сортують баги, проводять перевірки й готують релізи як учасники, а не як скрипти.
• Оцінювачів відкритого коду, які хочуть прочитати все за один день. Поверхня агентів — два crate без зв'язності, навмисно достатньо малі для аудиту.

Він ще не для тих, хто хоче готовий, з усім включеним SaaS, який можна передати нетехнічній команді завтра. Ворота схвалення, обмеження швидкості й мобільні клієнти ще приземляються. Buzz каже вам це прямо, і саме тому я довірив би йому обережний пілот.

Формулювання, до якого я постійно повертаюся, — у README: "Agents are part of the room, not haunted cron jobs." Якщо ви колись налагоджували бота о 2-й ночі, не маючи уявлення, що він зробив і чому, ви вже знаєте, чому це важливо.

Поширені запитання

Чи Buzz безкоштовний і з відкритим кодом?

Так. Buzz має відкритий код під ліцензією Apache 2.0 і збудований Block, Inc. Ви самостійно розміщуєте ретранслятор, тож немає плати за місце за програмне забезпечення. Ваші витрати — ваша власна інфраструктура: сервер для ретранслятора, Postgres, Redis та об'єктне сховище. Джерело, задачі й дорожня карта — усе публічне на GitHub у block/buzz.

Чим Buzz відрізняється від Slack із ботами?

У Slack агент — другосортний бот з окремою ідентичністю й аудит-слідом, обмежений прапорцями дозволів. У Buzz агент — повноправний учасник із власною парою ключів, членствами в каналах і тими самими можливостями, що й людина: відкривати репозиторії, надсилати патчі, виконувати робочі процеси, приєднуватися до зібрань. Усе приземляється в один підписаний журнал собитій, який можна шукати.

Що таке ACP та MCP?

ACP — Agent Client Protocol, інтерфейс stdio, який buzz-agent використовує для розмови з LLM-клієнтом на кшталт Zed. MCP — Model Context Protocol, інтерфейс, який buzz-dev-mcp використовує, щоб дати агенту оболонку та редактор файлів. Два бінарники не знають одне про одного; вони компонуються через протоколи, тож ви можете вільно змішувати агентів і сервери інструментів.

Чи використовує Buzz блокчейн?

Ні, і README чіткий щодо цього: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz використовує криптографічні підписи Nostr і аудит-журнал із ланцюгом хешів для доказу втручання, але немає токена, ланцюга й механізму консенсусу. Ви отримуєте перевірювану історію без накладних витрат.

Чи можу я використовувати власних агентів ШІ, як-от Goose, Codex або Claude Code?

Так. Harness buzz-acp породжує підпроцеси агентів ШІ й з'єднує @mentions ретранслятора з ними через ACP. Він підтримує Goose, Codex і Claude Code одразу, запускає пул від одного до 32 процесів агентів і перезапускає агента, якщо він падає. Для власних інструментів ви підключаєте власний сервер MCP.

Чи готовий Buzz до продакшену?

Частково. Ретранслятор, канали, пошук, аудит-журнал, застосунок для ПК та CLI агентів працюють сьогодні. Але обмеження швидкості не застосовується, ворота схвалення не з'єднані наскрізно, а мобільні клієнти ще в процесі. Для самостійно розміщеного пілота з командою, що терпить шорсткі межі, він готовий до спроби. Для розгортання, критичного щодо відповідності, зачекайте, поки приземляться елементи 🚧.

Про автора

Mert Batur — співзасновник Techsy.io, де команда постачає агентів ШІ, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек інструментів LLM, який команда Techsy реально використовує в продакшені. Зв'яжіться з ним у LinkedIn.