AI-система как живой музей: боевые инструменты ломаются при зрителях

За один день — 19 июня 2026 года — я запустил «живой музей» своих AI-систем и тут же сломал 3 из 4 выставленных экспонатов. Модератор в 7 чатах упал через несколько часов после запуска. Голосовой помощник завис через 46 секунд на живом созвоне с клиентом. Аватар-рендер при ошибке одного куска из шести перезапускал весь цикл с нуля — сжигая деньги и время. Это не провал запуска. Это и есть суть формата.

Клуб «Solar — внутрянка» — мой закрытый клуб для предпринимателей — я переделал из формата «видеоуроки на полке» в формат музея рабочих систем. Причина простая: 4 видеоурока не сняты, значит «продукт как бы не готов». Снял этот блок. Текст с механикой и граблями полноценен сам по себе — видео апгрейд сверху, его можно докрутить позже. Первый зал: 4 боевых экспоната из продакшена. Под каждым — механика, файлы, где ломается. Подпись одна: «моё, бери и адаптируй». Пока я вешал табличку, три экспоната дали живую демонстрацию зачем эта подпись нужна.

Почему «живой музей» — это архитектурное решение, а не маркетинговый приём

Большинство продуктов в нише AI-автоматизации продаются через глянцевые кейсы: «внедрили систему — эффективность выросла». У читателя в голове сразу появляется вопрос: «а вдруг у меня не выйдет так же?» Этот вопрос блокирует покупку сильнее любого возражения по цене.

Музейный формат работает иначе. Каждый артефакт — это живая боевая система с историей: почему я её сделал, что внутри, где ломалась и как починил. Клиент видит не маркетинговую картинку, а документацию из живого продакшена с постмортемами инцидентов.

Технически это означает: каждый экспонат клуба — это не урок «как сделать X», а реальный файл, который прямо сейчас крутится на моём сервере или Mac. AGENTS.md конкретного агента с инструкциями и ограничениями. Скрипт populate_monthly_pnl.py, который считает выплаты инвесторам. Промпт модератора чата с комментариями где он ошибается. Конфиг watchdog-скрипта с алертами. Забирай, разворачивай, ломай сам.

Для B2B-аудитории это особенно важно. Предприниматель не покупает курс — он покупает уверенность, что решение работает именно в его контексте. Показать живые грабли — дать эту уверенность через прозрачность, а не через обещание идеального результата.

Дополнительный эффект — отстройка от инфобиза через формат запуска. До переделки клуб держал публикацию в заложниках: 4 видеоурока не сняты, значит «продукт не готов». Я снял этот блок намеренно: текст с механикой, кодом и постмортемом — полноценный артефакт сам по себе. Видео — апгрейд сверху, его можно добавить позже. Это архитектурное решение меняет что именно является MVP продукта: не набор уроков, а набор живых рабочих файлов.

Для мультиагентной архитектуры, где одновременно работают 14 агентов, это принципиально. У системы такого масштаба всегда что-то находится в стадии «сломалось → чинится → починили → сломалось снова иначе». Прятать это — создавать ложное ожидание. Экспонировать это — делать грабли частью позиционирования, а не исключением из него.

Юрий Солар, основатель Solar OS: «Я давно понял: люди покупают доверие, а не идеальную картинку. Когда показываешь, где ломается и как чинишь, тебе верят сильнее. Это работает не для всего рынка — но для правильной аудитории работает стабильно.»

Дополнительный эффект — отстройка от инфобиза. Курсы «как за 3 месяца внедрить AI и увеличить выручку на 300%» живут на обещании результата. Музей живёт на демонстрации процесса. Разные аудитории, разное доверие, разная конкуренция.

Из чего состоит боевая мультиагентная система на 14 агентов

Solar OS работает на 14 активных Paperclip-агентах. Каждый — отдельный инстанс с собственным AGENTS.md, зоной ответственности и инструментами. Иерархия трёхуровневая: CEO-агент (tier 1) координирует 5 менеджеров (tier 2), которые координируют 8 исполнителей (tier 3). Плюс горизонтальный QA-агент вне иерархии — проверяет все артефакты перед выходом наружу.

Первый зал музея — 4 экспоната, каждый представляет отдельный уровень системы:

AI-продажник. Агент-классификатор входящих сообщений. Слушает диалоги в Telegram через spider_daemon, квалифицирует лид по параметрам (бюджет, срочность, контекст задачи), маршрутизирует в нужный контур. Хранит контекст диалогов в PostgreSQL с историей взаимодействий. Когда потенциальный клиент пишет «хочу автоматизацию» — агент отвечает первым, собирает контекст и передаёт в Product-head для следующего шага. Важная деталь: агент не закрывает продажу сам — он квалифицирует и передаёт. Это намеренное ограничение: продажи с чеком от 180 000 рублей требуют живого разговора.

Система памяти агентов. Агенты помнят не только текущий диалог, но и историю взаимодействий через несколько сессий. Файловая память по PARA-методу: Projects, Areas, Resources, Archive. Каждый агент пишет в свой раздел, CEO-агент читает сводку из всех разделов утром. 337 845 чатов проиндексированы через pgvector — семантический поиск находит нужный диалог по смыслу запроса, а не только по точным словам.

Контур безопасности (модератор). 7 Telegram-чатов покрыты одним LLM-классификатором входящих сообщений. Классифицирует: спам, обфускация, подозрительная активность. Проблема, которая вскрылась в день запуска: один аккаунт-«мозг» кормил все 7 чатов через один API-ключ. Когда у него закончился баланс — модерация упала везде одновременно. Об этом ниже подробно.

Говорящий аватар. Пайплайн: текст → TTS → wav-файл → разбивка на 6 кусков по 10 секунд → рендер синхронизации губ для каждого куска через внешний API → склейка через FFmpeg. Использую для создания видео-презентаций и контента. Один сломанный кусок запускал полный перезапуск вместо retry только упавшего — об этом тоже ниже.

Все 4 системы связаны через общую БД solar_property (PostgreSQL 15) и Paperclip control plane. CEO-агент видит статус каждого компонента через ежедневный дайджест в 07:30 по WITA. Когда что-то падает — алерт в Telegram-канал Solar AI, оттуда через ассистента к Юрию.

Единая точка отказа: как один пустой счёт убил модерацию в семи чатах

Самый показательный инцидент дня — история про модератора. В одном из чатов появился спам казино. Не обычный — написанный через Unicode-подмену символов: ℓ вместо l, ᴀ вместо а, ᴄ вместо с. Классический обход keyword-фильтров: regex не срабатывает потому что символы формально другие, но визуально читаются как обычные буквы.

Пока разбирался с источником, выяснилось: проблема не в ботах. Боты работают нормально. Не работает их общий «мозг» — LLM-сервис, к которому они обращаются за классификацией сообщений. Один аккаунт кормил сразу 7 чатов. Баланс закончился без алерта, без fallback, без уведомления оператору.

Это называется single point of failure (SPOF): один компонент падает, падает всё что от него зависит. В мультиагентных системах это особенно коварно: агенты кажутся независимыми потому что у каждого свой код и своя логика. Но если у них общий ресурс — зависимость глубже чем в монолите, потому что скрыта за видимостью независимости.

Решение двухуровневое. Первый уровень — локальный фильтр без LLM. Список стоп-слов плюс детектор Unicode-обфускации через нормализацию unicodedata.normalize('NFKD', text) перед проверкой — это приводит ℓ к l, ᴀ к a и так далее. Работает локально без сети и без баланса. Перехватывает примерно 80% очевидного спама. Второй уровень — LLM для серых случаев: сообщения которые локальный фильтр не может однозначно классифицировать. Если LLM недоступен: fail-open (пропускаем спорные сообщения) вместо fail-closed (блокируем всё). Потерять один спам лучше чем заблокировать живого участника чата.

При отладке обнаружился побочный баг: старый keyword-фильтр банил людей за слова «доход», «проект», «срочно». Это false positive — обычные слова из рабочих диалогов предпринимателей. Два часа на одновременный фикс обоих проблем: Unicode-нормализация для спама и исключения из стоп-листа для нормальной лексики.

Для тех, кто строит AI-модерацию для своих чатов или платформ: не держите критический компонент с единой точкой отказа. Первичный rule-based фильтр должен работать без внешних API. LLM — дополнительный слой, не единственный. И разделяйте квоты по независимым контурам, а не на всю систему через один аккаунт.

Голосовой помощник, который молчал 47 минут: баг AVAudioEngine при смене устройств

Solar Copilot — программа, которая слушает разговор с клиентом в реальном времени и подсказывает реплики в плавающем окне на Mac. Стек: перехват микрофона через AVAudioEngine → транскрипция через Whisper → Claude для генерации подсказки → отображение в overlay-окне. Всё локально, latency около 3 секунд от слова до подсказки на экране.

На реальном созвоне с клиентом я переключил наушники прямо во время разговора. Программа встала через 46 секунд. Замолчала совсем. Весь созвон — 47 минут — вёл вручную, без подсказок системы.

Root cause: AVAudioEngine не обрабатывает смену аудиоустройства в runtime. При появлении нового девайса или при отключении AirPods движок получает уведомление AVAudioEngineConfigurationChange, не переинициализируется автоматически и зависает. Это задокументированное поведение macOS — но написано мелким шрифтом и не бросается в глаза при первоначальной реализации.

Фикс: подписаться на AVAudioEngineConfigurationChangeNotification, при получении уведомления — engine.stop(), пересоздать audio tap с новым дефолтным девайсом, engine.start(). Время рестарта: 200-300 миллисекунд. Для пользователя незаметно.

Вторая проблема вскрылась при разборе качества подсказок на том же созвоне: подсказки были куцыми вопросами. «Какой бюджет?» «Когда планируете?» На реальном звонке нет времени переформулировать короткий вопрос в живую фразу под контекст разговора. Переделал на развёрнутые готовые реплики с данными из текущего диалога: «Слышал, что планируете автоматизацию в следующем квартале — это Q3 или смотрите на Q4 с учётом готовности команды?» Разница в использовании: 4 секунды вставить готовую фразу против 20 секунд сформулировать вопрос самому.

Этот класс ошибок — устройство меняется во время работы — не воспроизводится на тестах в контролируемых условиях. Тестируешь без смены наушников — всё работает идеально часами. Первый реальный созвон с реальным переключением — падает. Единственный способ поймать такой баг — жить с системой в реальных условиях достаточно долго.

Идемпотентный рендер: почему retry одного куска дешевле retry всего пайплайна

Говорящий аватар — это не «загрузил фото и нажал кнопку». Полный пайплайн: текст → озвучиваю через TTS-API → получаю wav-файл → разбиваю на 6 кусков по 10 секунд → каждый кусок рендерю отдельно через внешний API (синхронизация движений губ с аудио) → склеиваю обратно в одно видео через FFmpeg.

Проблема: один кусок из шести периодически падал на этапе рендера губ. Причины разные: нестабильный API под нагрузкой, слишком быстрая речь в конкретном фрагменте, граница между кусками в неудачном месте где слово разрезается пополам. Старый код реагировал на любую ошибку одинаково: выбросить весь batch и запустить всё заново. 6 кусков × 45 секунд рендера каждый = 4,5 минуты ожидания плюс деньги на повторные API-вызовы. При трёх повторных падениях подряд: 13,5 минут потерянного времени на одно видео.

Решение — паттерн идемпотентного пайплайна с checkpointing. Каждый кусок получает уникальный идентификатор (SHA256 от контента исходника плюс индекс куска), статус в БД: pending / done / failed, путь к output-файлу. Оркестратор при любом старте проверяет: что уже в статусе done — не трогает, запускает только pending и failed.

Экономия в цифрах: вместо 4,5 минуты полного retry — 45 секунд на один упавший кусок. Вместо «всё или ничего» — «готовое уже готово, доделываем остальное». Бонус: система теперь показывает частично готовое видео из доделанных кусков сразу по мере готовности, а не держит пустой экран с ошибкой до финала.

Принцип идемпотентности применяется в любом многошаговом пайплайне. Если операция может упасть на шаге N — сохраняй результаты шагов 1 до N-1 и перезапускай только с шага N. В AI-системах с внешними API это критично вдвойне: каждый вызов стоит денег и времени, повторные запуски на уже готовых шагах — прямые потери.

Для предпринимателя, который строит пайплайн с несколькими шагами — транскрипция → перевод → публикация, или сбор данных → обработка → отчёт — добавляйте checkpointing с первого дня. Не «потом когда масштабируемся». Именно потому что первый сбой случится в самый неудобный момент, и лучше чтобы система умела продолжить с места падения, а не с самого начала.

Семантический поиск по 337 тысячам чатов: pgvector без выделенного сервера

Ещё один экспонат дня — поиск по архиву переписок. Задача: найти «тот разговор с клиентом про проблему с платёжкой» — не помня точную дату, не помня точные слова из диалога. Keyword-поиск типа LIKE '%платёж%' для таких запросов не подходит: нужен поиск по смыслу, а не по буквам.

Решение: pgvector — расширение PostgreSQL для векторного поиска. Каждое сообщение при сохранении получает эмбеддинг — числовой вектор-«отпечаток смысла» от embedding-модели (1536 измерений для text-embedding-3-small от OpenAI). При поиске запрос тоже превращается в вектор через ту же модель, база находит ближайших соседей по косинусному расстоянию между векторами.

Параметры в продакшене: 337 845 проиндексированных сообщений, индекс IVFFlat с параметром lists=200, latency поиска 120-200 миллисекунд. Запрос «разговор про застрявший платёж в мае» находит 3 релевантных диалога из 337 тысяч за 150 мс. Запрос «клиент жаловался на медленную работу агента» без единого совпадающего слова — находит нужный чат по семантической близости.

Важно для B2B: pgvector работает там, где у вас уже есть PostgreSQL. Не нужно разворачивать отдельный Pinecone, Weaviate или Qdrant для MVP и даже для умеренного продакшена. Для объёмов до 1 млн документов pgvector с правильными индексами справляется без проблем на обычном VPS. Мигрировать на dedicated vector DB стоит при 5-10 млн+ документов и требованиях к latency ниже 50 мс.

Технический стек: PostgreSQL 15 + pgvector extension, embedding через API, FastAPI-обёртка для поисковых запросов. Запущено как сайдкар-контейнер к основному боту — не отдельный сервис, экономит на infrastructure overhead и на поддержке. Это не исследовательский проект — это прод, который используется ежедневно для навигации по архиву.

Ещё один момент из практики: индекс IVFFlat требует периодического пересоздания при значительном росте коллекции — примерно при каждом удвоении числа документов. При 337 тысячах сообщений с lists=200 точность поиска держится на уровне 95%+ по сравнению с точным перебором (которого на таком объёме не делаешь). HNSW-индекс даёт более высокую точность и не требует пересоздания, но занимает больше памяти — выбор зависит от соотношения RAM к объёму коллекции.

Для предпринимателя с похожей задачей — «умный поиск» по CRM-переписке, базе знаний, архиву документов — pgvector с OpenAI или Anthropic embeddings это 2-3 дня работы на существующем PostgreSQL. Не «сложный AI-проект», а стандартный паттерн с документированным инструментарием.

Итог: чем живая система отличается от глянцевого кейса

День запуска музея показал ровно то, зачем музей нужен. Я выставил 4 экспоната с подписью «боевое, моё, бери». До конца дня 3 из них напомнили что «боевое» означает «иногда падает». Модератор упал на пустом балансе одного аккаунта на 7 чатов. Голосовой помощник завис при смене наушников через 46 секунд. Аватар-рендер перезапускал полный цикл из 6 кусков при ошибке одного.

Каждый из этих инцидентов получил разбор и фикс в тот же день. Не потому что нужно успеть быстро — а потому что так работает нормальный режим обслуживания боевой AI-системы. Что-то ломается, смотришь root cause, чинишь, меняешь архитектуру чтобы следующий раз упало иначе.

Глянцевый кейс звучит так: «Внедрили AI-систему — стало лучше». Живая система звучит так: «Вот контур из 14 агентов. Вот как упал модератор: один счёт на 7 чатов, баланс закончился без алерта. Вот фикс: локальный keyword-слой как независимый резерв плюс раздельные квоты по контурам. Вот почему в следующий раз упадёт иначе.»

Второй вариант строит доверие, потому что честный. Предприниматель не покупает «AI-систему которая никогда не падает» — таких нет в природе. Он покупает систему с понятной архитектурой, понятными точками отказа и человеком, который умеет их диагностировать и чинить быстро.

Если хотите посмотреть, как устроена мультиагентная система изнутри — AGENTS.md каждого агента, промпты с комментариями о граблях, скрипты из продакшена, постмортемы всех инцидентов — это и есть клуб «Solar — внутрянка». Все системы из этой статьи там: берите, адаптируйте, ломайте и чините.

Три паттерна из одного дня, которые стоит забрать:

1. SPOF — если компонент критичный и единственный, он упадёт в самый неудобный момент. Добавьте локальный резерв без внешних зависимостей, разделите квоты по независимым контурам.

2. Устройства меняются вживую — тестируйте на реальных условиях эксплуатации, не в лаборатории. Смена наушников, плохой интернет, неожиданный вопрос — это штатные ситуации, не edge cases.

3. Idempotent pipelines — любой многошаговый пайплайн с API-вызовами должен уметь продолжить с места падения. Checkpointing добавляется один раз, окупается при первом же инциденте.

Читайте также: Multi-agent vs single-agent: когда нужна команда ботов, а не один умный агент.

Полный набор артефактов — AGENTS.md, промпты, скрипты, постмортемы по каждому инциденту из этой статьи — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

— Solar OS.