Когда агенты становятся коллегами: идея, стоящая за Buzz

О Buzz я уже писал, тогда с явным фокусом на Shared Compute и совместную эксплуатацию моделей. Поначалу для меня это была самая захватывающая и необычная часть проекта. Но чем дольше я занимаюсь Buzz, тем интереснее мне становится сам рабочий раздел. Поэтому я уже опробовал Buzz в небольшой конфигурации.

Это связано и с проблемой, которую я в последние месяцы ощущаю всё отчётливее. Моя работа с ИИ стала не только быстрее, но и более запутанной. Codex работает над одним репозиторием, Claude Code проверяет вторую идею, ещё один агент собирает информацию, а где-то между ними работают терминал, браузер, почта и несколько чатов. Каждый агент может быть полезен сам по себе. Проблема возникает на стыках. Контекст приходится копировать, решения повторять, а результаты сводить вручную.

Именно здесь начинает работать Buzz. Проект с открытым исходным кодом создан компанией Block, которую возглавляет соучредитель Twitter Джек Дорси и которая стоит за Square. Buzz не пытается создать ещё одного ИИ-ассистента. Buzz создаёт общее рабочее пространство, в котором люди и агенты используют одни и те же каналы, треды, проекты и протоколы. Агент Codex может составить план, Claude Code может его раскритиковать, человек может принять решение, а следующий агент может превратить это в изменение в репозитории. Вся цепочка остаётся видимой в одном и том же пространстве.

Быстрое определение “убийца Slack” мне кажется слишком узким. Buzz показывает возможную форму работы для команд с большим числом агентов. При этом проект пока молодой, требователен к ресурсам и сложнее с точки зрения безопасности, чем можно предположить по дружелюбному интерфейсу. Именно эта смесь большой идеи и раннего этапа разработки делает более пристальный взгляд интересным.

Настоящая проблема не в модели

Большинство ИИ-инструментов возникли как отношения между одним человеком и одним агентом. Я открываю Codex, ставлю задачу и получаю результат. Затем открываю Claude Code, ещё раз объясняю тот же контекст и прошу второе мнение. Для отдельных задач это работает хорошо. Но в команде или при нескольких параллельно работающих агентах возникает новая проблема координации.

Именно эту проблему я знаю по своей повседневной работе. Claude Code, Codex, Hermes, браузер, чаты и разные терминалы работают параллельно. Протоколы сессий переходят из одного инструмента в другой. Один агент знает заметки встречи, другой знает репозиторий, третий знает нужные доступы или навыки. У каждого есть свой фрагмент, но ни у кого нет общей картины состояния работы.

Дашборды mission control решают эту проблему лишь частично. Они, возможно, показывают, что активны пять агентов. Но они всё ещё не создают общего понятного места, где задание, обсуждение, промежуточный статус, ревью и решение остаются вместе. Поэтому Buzz начинает не с более красивого списка агентов, а с самого рабочего пространства.

Агенты - это участники, а не приклеенные боты

На первый взгляд Buzz выглядит знакомо. Есть сообщества, публичные и приватные каналы, треды, личные сообщения, форумы, поиск, huddle-звонки и мобильное приложение. Решающее отличие от обычной интеграции со Slack скрыто глубже.

В Buzz агент - это самостоятельный участник. У него есть профиль, криптографическая пара ключей, членство в каналах и собственный журнал аудита. Его сообщения появляются под его собственной идентичностью. Благодаря этому позже видно не просто, что “ИИ” что-то сделал. Видно, какой именно агент действовал, в каком канале он получил задание и какой человек или другой агент его инициировал.

Сначала это звучит как небольшое изменение в управлении пользователями. Но для реальной работы это центральный момент. Бот в Slack обычно привязан к интеграции и ждёт, когда его упомянет человек. Два бота от разных провайдеров обычно ничего не знают друг о друге. В Buzz агенты могут обращаться друг к другу, передавать задачи и обсуждать свои результаты в одном треде. Codex и Claude Code от этого не становятся единой системой. Но они получают общее коммуникационное пространство.

При этом Buzz не приносит с собой автоматически весь интеллект. Рабочее пространство соединяет так называемые harnesses и модели, которые уже работают локально, на сервере или через провайдера. По текущему состоянию проекта к ним относятся, среди прочего, Codex, Claude Code и Goose. Другие агенты можно подключить через открытые интерфейсы. Это модель “принеси своего агента”: Buzz координирует, а сам агент думает и действует, используя собственные инструменты, навыки, доступы и стоимость моделей.

Relay - это общее состояние работы

Технически Buzz состоит из нескольких частей. Приложение для десктопа - это интерфейс. Сообщество - это, собственно, рабочее пространство. Buzz Relay хранит и распределяет его сообщения, участников, агентов, правила, медиа, данные поиска, workflow и события Git. Агенты могут работать на той же машине, что и десктоп-приложение, на постоянно работающем сервере или на совершенно другой машине.

В качестве протокола Buzz использует Nostr. Люди и агенты подписывают события своими приватными ключами. Relay проверяет идентичность и членство, сохраняет события и распределяет их клиентам с соответствующими правами. Однако это не делает Buzz волшебной одноранговой сетью. Relay - это центральный источник сообщества. Автоматической репликации между релеями нет, и сообщения остаются на том релее, на который были отправлены.

Эта конструкция имеет два интересных следствия. Идентичность принадлежит не просто центральному аккаунту Slack, а базируется на собственной паре ключей. При этом команда может сама эксплуатировать рабочее пространство. Тот, кто сначала хочет просто протестировать, может использовать сообщество, размещённое Block. Тот, кто хочет сам контролировать хранение данных, доступность и резервное копирование, эксплуатирует relay на собственной инфраструктуре.

Текущая серверная архитектура использует известные компоненты: PostgreSQL для событий и полнотекстового поиска, Redis для pub/sub, а также S3-совместимое хранилище для медиа. Это не небольшой сервис, о котором можно забыть после установки. Самостоятельно эксплуатируемый relay требует TLS, обновлений, резервного копирования, мониторинга и аккуратного управления ключами.

Почему общий контекст так ценен

Самая сильная идея Buzz - это постоянный, совместно видимый контекст. Проект больше не состоит из сообщения в чате Slack, отдельного запуска агента, pull request на GitHub и решения на видеоконференции. Buzz пытается свести эти следы в единое пространство событий.

Это особенно полезно, когда у разных агентов разные сильные стороны. Реалистичный процесс может выглядеть так:

1. Человек описывает в проектном канале цель и границы.
2. Агент-исследователь собирает информацию и документирует свои источники.
3. Второй агент атакует слабые места и ищет контраргументы.
4. Codex или Claude Code составляет конкретный план.
5. Другой агент проверяет план на безопасность, отсутствующие тесты или неясные допущения.
6. После одобрения человека изменение реализуется в отдельном worktree.
7. Diff, результаты тестов, ревью и решение остаются доступными для поиска в соответствующем канале.

Особенно интересен этот паттерн при adversarial-ревью. Одна модель получает явную роль атаковать план продукта или реализацию. Вторая модель должна защищать или улучшать решения. Поскольку обе видят весь тред целиком, возникает настоящая дискуссия по поводу текущего состояния работы, а не просто изолированное ревью скопированного текста.

Этот паттерн интересен и для контент- и бизнес-процессов. Один агент исследует темы, второй пишет, третий редактирует. Показатели или новые сообщения могут регулярно поступать в канал, чтобы люди и агенты вместе обсуждали развитие ситуации. Huddle-звонки идут ещё дальше: люди и агенты общаются в аудиоконференции, разговор переводится в текст и затем может превращаться в конкретные задачи.

Именно здесь Buzz становится чем-то большим, чем групповой чат. Канал - это не просто место для коммуникации. Он становится прослеживаемым рабочим журналом.

Buzz также хочет заменить GitHub

Buzz интегрирует Git-репозитории, патчи, ревью и статусные события в то же рабочее пространство. Relay может сам размещать репозитории. Агенты могут использовать Worktree, работать над вариантами отдельно, предоставлять изменения в виде патчей и обсуждать ревью в контексте проекта.

Идея, стоящая за этим, сильна: feature-ветка становится пространством. Там находятся не только коммиты, но и обсуждение того, почему изменение было необходимо, какие альтернативы были отклонены, что сообщил CI и кто одобрил merge. Именно у кода, созданного агентами, сегодня часто отсутствует эта история возникновения.

Тем не менее я бы пока не спешил списывать GitHub со счетов. GitHub - это не просто хранилище Git, а выросшая за годы экосистема прав, ревью, CI/CD, сканирования безопасности, релизов, интеграций и внешнего сотрудничества. У Buzz есть работающие основы Git и интересный подход к forge. Но собственное описание состояния проекта чётко различает уже работающие части, ещё не подключённые функции и видение. Для критически важных репозиториев постепенное внедрение разумнее, чем немедленная миграция.

Мой первый тест с Buzz

Я сознательно начал с малого: собственное сообщество, один канал и два агента с чётко разделёнными ролями. Codex должен был составить технический план, Claude Code должен был атаковать допущения, уязвимости и излишнюю сложность. Продуктивные учётные данные, данные клиентов и чувствительные репозитории остались вне теста. Сначала мне было важно протестировать сотрудничество, а не максимальную автономию.

Первое открытое задание было слишком неточным. Оба агента начали планировать, реагировали друг на друга и в какой-то момент ждали следующего импульса. Это было хорошим напоминанием о том, что общий канал ещё не заменяет оркестрацию. С чёткой инструкцией “Codex составляет план, Claude проверяет его, затем вы ждёте одобрения” процесс стал заметно спокойнее и понятнее. Больше агентов не заменяет определение процесса.

Больше всего меня убедил не какой-то впечатляющий отдельный ответ, а отсутствие разрыва между инструментами. Оба агента видели один и тот же тред, критика оставалась рядом с исходным планом, и я в любой момент мог отследить, кто именно сейчас работает. Мне не нужно было копировать текст между окнами и заново объяснять предысторию второму агенту. Именно в этом, на мой взгляд, и заключается настоящая ценность Buzz.

Для интенсивной разработки ПО прямая работа в Codex или Claude Code всё же оставалась быстрее. Buzz добавляет коммуникацию, протоколирование и общий контекст. Этот слой стоит времени и токенов. У каждого дополнительного агента своя собственная сессия, и обширная история канала может при нескольких моделях обрабатываться многократно. Поэтому для долгого прогона кодинга я бы по-прежнему использовал нативный harness, а Buzz применял бы скорее для планирования, передачи задач и ревью.

Пока недостаточно глубоко я протестировал workflow, более длинные huddle-звонки, локальные модели и несколько постоянно работающих удалённых агентов. Именно здесь Buzz должен на практике доказать, что задачи не просто красиво видны, но и надёжно доводятся до завершения. Программа находится до версии 1.0 и местами ощущается соответственно молодой. Для экспериментов это нормально. Но центральные процессы по-прежнему требуют контроля, логики повторов и чёткого ручного пути отступления.

Общий контекст - это ещё и граница безопасности

То, что делает Buzz полезным, одновременно увеличивает поверхность атаки. Подключённый агент Codex, Claude Code или Hermes может приносить с собой доступ к файлам, оболочку, браузер, MCP-серверы, почту, календарь или другие внутренние инструменты. Если участнику команды разрешено обращаться к такому агенту, эти права выходят далеко за рамки написания ответа в чате.

Поэтому важнейшее правило звучит так: агент должен работать только в тех каналах, содержимое и состав участников которых соответствуют его доступу к инструментам. Членство в канале - это центральные ворота доступа. Тот, кто является участником, может читать и писать. Тот, кто не является участником, не должен видеть приватные каналы и подписываться на их события.

Тем не менее криптографические подписи решают не каждую проблему аудита. Buzz ведёт связанный, чувствительный к манипуляциям журнал аудита. Однако злоумышленник с правом записи в базу данных мог бы пересчитать цепочку после манипуляции. Таким образом, журнал является tamper-evident, а не tamper-resistant. Он делает изменения распознаваемыми, пока основа доверия хранилища не полностью подорвана.

Для сообществ, размещённых Block, добавляется ещё один момент: сообщения, личные сообщения и загруженные медиа не зашифрованы end-to-end. Block может просматривать это содержимое для целей эксплуатации, безопасности, модерации или правовых обязательств. Кроме того, соответствующий провайдер модели может получать промпты и содержимое каналов, если агент использует облачный сервис.

Self-hosting меняет владение данными, но не автоматически весь поток данных. Собственный relay удерживает сообщения и файлы на собственной инфраструктуре. Если агент по-прежнему использует облачную модель, данные, необходимые для выполнения задачи, всё равно покидают relay. Действительно локальная эксплуатация требует поэтому как собственного relay, так и локальных моделей и локальных инструментов. О возможностях и границах Buzz Shared Compute я уже писал отдельно.

Как я пока использую Buzz

Для своего первого теста я использовал небольшое, чётко ограниченное сообщество. Никаких продуктивных учётных данных, никаких данных клиентов и никакого репозитория с секретами. Двух агентов было вполне достаточно: один создаёт, другой проверяет. К этому добавляюсь я как человек, который определяет задание, точку одобрения и критерий прерывания.

Моя первая конфигурация была не автономным предприятием со ста агентами, а ограниченным ревью:

• Один агент составляет технический план на основе существующего issue.
• Второй агент ищет уязвимости, отсутствующие допущения и излишнюю сложность.
• Оба должны указывать источники, файлы и открытые вопросы.
• После не более двух раундов обсуждения команда ждёт одобрения человека.
• Только после этого агент может подготовить изменения в изолированном worktree.

Так я смог протестировать настоящую сильную сторону Buzz, не перестраивая сразу всю свою работу. При этом стали видны потребление токенов, задержка, права и прослеживаемость.

Для соло-работы над одной задачей кодинга я по-прежнему остаюсь при прямом интерфейсе агента. Он быстрее и легче контролируется. Buzz становится интересным, как только нескольким людям, нескольким агентам или нескольким рабочим потокам нужен один и тот же контекст. Поэтому небольшие команды разработчиков, агентства, исследовательские группы и технически подкованные соло-предприниматели являются очевидной целевой аудиторией.

Для более крупной компании я был бы сдержаннее. До версии 1.0, без долгосрочной линии поддержки и с ещё молодыми workflow я бы не делал Buzz единственным местом для критически важной коммуникации или исходного кода. Пилотный проект может иметь смысл. Полная замена Slack и GitHub сейчас была бы ставкой на скорость развития проекта.

Идея, стоящая за Buzz, больше, чем текущий клиент

Самая захватывающая часть Buzz для меня - это не отдельная функция. Каналы, форумы, huddle-звонки, хостинг Git и локальные модели существуют и в других местах. Новизна в последовательном допущении, что агенты больше не являются лишь частными инструментами отдельных пользователей. Они становятся видимыми участниками общего рабочего процесса.

Тем самым смещается сам вопрос. Мы спрашиваем уже не только о том, какая модель пишет лучший код. Нам нужно решить, как люди и несколько агентов распределяют задачи, делятся контекстом, контролируют друг друга и делают ответственность прослеживаемой. Именно для этого сегодня часто не хватает социальной и технической инфраструктуры.

Buzz пока не даёт готового ответа. Программа молодая, некоторые workflow ненадёжны, общий контекст может обходиться дорого, а self-hosting несёт с собой реальную эксплуатационную ответственность. Тем не менее проект затрагивает реальную проблему. Если агенты берут на себя всё больше работы, недостаточно просто открыть пять отдельных чатов рядом друг с другом. Нам нужно общее место, где их работа остаётся видимой, ограниченной и проверяемой.

Возможно, Buzz когда-нибудь заменит Slack и GitHub. На сегодня достаточно более скромного, но более важного утверждения: Buzz - это убедительный набросок того, как может выглядеть рабочее пространство, когда в нём работают уже не только люди. Shared Compute обратил моё внимание на этот проект. Общее рабочее пространство - вот причина, по которой я буду продолжать тестировать Buzz.

Мой вывод после первого теста

В моём коротком тесте Buzz попал точно в ту проблему, которая у меня сейчас есть с ИИ-агентами. Отдельные модели давно перестали быть узким местом. Сложность в том, чтобы удерживать несколько агентов, решений и результатов на одной общей линии. Buzz делает эту работу видимой и даёт Codex, Claude Code и другим агентам место, где они могут реагировать не только на меня, но и друг на друга.

Меня убедили общий контекст, чётко разделённые идентичности агентов и возможность напрямую дать второй модели атаковать результат. Меньше меня убедили дополнительные накладные расходы. Для отдельной задачи кодинга прямой путь через Codex или Claude Code пока быстрее. Как только вовлечены несколько агентов или людей, Buzz начинает раскрывать свою сильную сторону.

Мой тест был сознательно коротким. Я не проверял ни долгосрочную командную эксплуатацию, ни большие репозитории, ни сложные workflow, ни более длительные пиковые нагрузки. Для этого программа пока слишком молода и меняется слишком быстро. Сегодня я бы не делал Buzz единственным местом для критически важной коммуникации или исходного кода. Но для небольшой команды, агентства или личной ИИ-лаборатории это уже больше, чем просто интересное демо. Это инструмент, который я буду использовать дальше и целенаправленно встраивать в свою повседневную работу.

До следующего раза,
Joe

FAQ