👾 bb — лучший супер-харнесс Я использую параллельно агентов разных провайдеров, личные и рабочие учётки, несколько физических машин и виртуалок. Инфострат внутри на всех уровнях активно поддерживает ИИзацию всего, что этому поддается, тем более, если речь про разработку, да и самому хочется держать руку на пульсе и не отставать, поэтому пока есть возможность — пользуемся на полную катушку, токенмаксим и вот это все. Но чтобы этим зоопарком было удобно управлять, не переключаясь между разными интерфейсами кодинговых агентов, всегда хотелось иметь какой-то универсальный инструмент. И bb (getbb.app), о котором хочу рассказать, — первый из опробованных в этой категории, которым действительно удобно и приятно пользоваться и у которого безграничные возможности, но при этом он максимально прост и понятен. Главное окно bb Пишу бескомпромиссно и категорично, потому что до него использовал достаточно долго по нынешним меркам (месяцы) «флагманские» Orca и Paseo, а потому есть с чем сравнивать. Orca я использовал почти полгода (про эту тулу писал Никита Арипов), потом параллельно часть задач стал делать в Paseo. Но и то и то, то в каких-то моих сценариях были не удобными, то просто ломались на чем-то базовом. bb — это супер-харнесс: среда, которая объединяет кодинговых агентов разных провайдеров и позволяет организовать их совместную работу, не насильно встраивая их в свой интерфейс через консоль (как упомянутый Orca), а работая «поверх», через официально поддерживаемые протоколы и SDK,  давая инструмент управления ими и организуя бесшовную интеграцию кодинговых агентов разных провайдеров, не подменяя их харнесс. Активно про bb начали говорить относительно недавно, и инструмент этот совсем зеленый (да как и все сейчас с этим вайбкодингом) — текущая версия 0.46 и часть компонент (например, Desktop-клиент) еще в альфе. Но я уже скоро как полтора месяца с ним (с веб-версией в основном, но последние две недели на десктопе), и ни единого разрыва с серьезными проблемами не сталкивался. Вот что в нем крутого: 1. Разные агенты на разных машинах — в одном интерфейсе. Можно работать с Codex, Claude Code и другими поддерживаемыми агентами, выбирать, где выполнять задачу, и следить за результатом в общей среде, с одинаковым UX, в одном GUI. Выпадашка в выбором агента и модели По ощущениям — как будто все агенты принадлежат одной экосистеме. При этом код и процессы остаются на выбранных машинах. Это работает не так, как сделано, например, в Orca, который эксплуатирует cli-агентов, загоняя в эмулятор терминала, которым управляет сам. Никакого глючного написанного навайбкоженого хипстерами TUI, который вроде красивый и местами отзывчивый, но для старперов тех, кто часто пользовался консолью еще до эры ИИ-агентов, ломает стандартное поведение и привычки. 2. Агенты могут взаимодействовать друг с другом. Главная мега-фича. В bb работа организована в тредах. Агент может создавать другие треды, делегировать задачи и управлять их выполнением. Самое крутое, что граница между провайдерами тут максимально размывается. Например, можно поручить реализацию Codex’у, а проверку — Cursor’у, поручив пообщаться друг с другом: Переписка между агентами Для меня это одна из главных причин пользоваться bb: меньше ручной передачи заданий и результатов между чатами. Я подключаюсь только там, где требуется моё решение. Не нужно пилить никаких самодельных обвязок раньше времени, чтобы управлять разнородными агентами и это позволяет моделировать и проверять разные мультиагентные схемы работы просто описав правила и принципы в виде промпта: Вот простой пример: Создай на все найденные во время аудита проблемы новые задачи в git.homelab.lan Затем последовательно решай задачи, делегируя исполнение в дочернем треде агенту cursor моделью grok 4.7 на машие IS@ai-ubt, а ревью решения поручи агенту codex с моделью gpt 6.1-sol на машине ME@bots, переписку они должны вести в MR, созданном по задаче, но пусть пингуют/уведомляют друг друга, отправляя сообщения в треды по типу "я сделал ревью, проверь замечания в MR" и "я исправил замечания, иди проверь повторно. И вот фрагмент их переписки в процессе работы: Пример переписки между агентами разных провайдеров В сравнении с субагентами: тут не просто разные модели, а еще и агенты разных провайдеров. Или вот более навороченный пример и не про программирование (осторожно, промпт на много букв): Нужно проработать макеты всех экранов, описанных в файле docs/design/mvp-screens.md, опираясь на дизайн-систему docs/design/design-system.md и дополняя/развивая ее в процессе реализации макетов. Пути заданы относительные, файлы закоммичены в основную ветку проекта. Тебя, как автора первой версии, я назначаю арт-директором и главным технологом проекта. Не выполняй работу самостоятельно, делегируй ее агентам в субтредах и координируй их взаимодействие. У тебя в распоряжении три дизайнера/технолога: два агента с моделью Astra Medium провайдера codex ты можешь запустить на ME@ai-sandbox и еще одного с моделью Astra Medium провайдера codex на машине IS@ai-sandbox. Распредели между агентами экраны, сам определи, как эффективнее это сделать, поделить сразу поровну и отдать на отрисовку сразу все, или выдавать каждому агенту по одному экрану за раз или что-то еще. Решение зафиксируй в отчете. Каждому агенту ставь задачу не только нарисовать делегированный ему набор экранов, но и на основе нарисованных экранов улучшить/доработать дизайн-систему в диалоге с коллегами. Каждый агент в первую очередь должен опираться на текущую версию дизайн-системы. Если в ней не хватает описания какого-то элемента, или встретилась задача, не решаемая в рамках существующей дизайн-системы, то нужно выработать такое решение и внести предложение на изменение дизайн-системы. Предложение нужно обсудить всем агентам между собой, чтобы все экраны были единообразны, чтобы решения одного агента, принятые в дизайн-систему, были согласованы с решениями других агентов. Организуй для такого обсуждения отдельный чат любым доступным, но простым способом (без создания своего приложения для чата и т.п.), чтобы ты и другие агенты могли обсуждать дизайн-систему. Каждый макет, созданный агентом, должен пройти ревью другим агентом, а затем финальное ревью тобой. В процессе ревью агент должен не просто сравнивать решение автора макета с правилами дизайн-системы и описанием экрана, но также смотреть, какие похожие вещи он реализовывал у себя и одинаково ли они выглядят? Если нет, то агентам нужно договориться между собой об едином виде, а если консенсуса достигнуть не могут, принятие решения они должны эскалировать тебе. В качестве результата ожидаю: — новую версию дизайн-системы docs/design/design-system.md — дизайн всех экранов, перечисленных в файле docs/design/mvp-screens.md, выполненных по правилам, установленным дизайн-системой В этом примере агенты одинаковые, это, возможно, не очень интересно, но интересно то, что они из разных подписок: рабочей и личной. После отладки при необходимости такую схему взаимодействия можно оформить в виде жесткого workflow, стейт-машины и любым другим удобным способом, чтобы минимизировать недетерминированность пайплайна целиком. 3. Интерфейс можно достраивать прямо во время работы. Через плагины в bb можно добавлять собственные панели и инструменты. Причём попросить агента создать такой плагин можно и нужно внутри самого bb и он сделает и без перезагрузки запустит его. Вот канбан-доска задач из нашей внутренней системы учета задач, полученных по API, которая была сделана за один короткий промпт (буквально "вот тебе api, вот скриншот, как это у нас на портале, сделай такую же канбан-доску по своим гайдлайнам"): Пример интерфейса, созданного внутри bb bb — представитель нового типа приложений: начинаешь пользоваться готовым инструментом, а затем вместе с агентами собираешь внутри него рабочее место под свои задачи. Любые нужные действия и данные можно вынести в собственный интерфейс.