Как я настроил 17 AI-агентов за один день: watchdog, голос и Telegram-мост

Я проснулся и первое, что сделал — открыл дашборд. Один из ботов завис ещё вчера в обед. В очереди накопилось 9 необработанных задач. Восемь часов работы — в мусор. Никаких уведомлений, никаких алертов, тишина. Именно с этого момента начался один из самых продуктивных дней в моей жизни: я не просто разгрёб зависшую очередь, я перестроил архитектуру всей системы так, чтобы подобное не повторялось. Watchdog, который следит за 17 агентами каждые пять минут. Лимиты бюджета и ходов для каждого бота. Починенный SEO-агент, который наконец начал видеть источники. Голосовой ввод через iCloud без лишних приложений. Переговоры по автопарку, которые закрылись цифрой вдвое лучше ожидаемой. И, как вишенка на торте, — синхронизация локального Claude с Telegram-ботом в единую память. Всё это за один день. Ни одного нанятого сотрудника, ни одного ручного действия, кроме нажатия Enter.

Восемь часов потерянного времени: почему зависший бот — это не баг, а системная проблема

Когда бот зависает, интуитивная реакция — «перезапустить и забыть». Перезапустил, работает, закрыл ноутбук. Через неделю зависает снова. Перезапустил. Через три дня — опять. Именно так выглядел мой первый год с AI-агентами: я был живым watchdog-ом, которого не хватало на ночные смены.

Конкретно тот бот, который завис в этот раз, отвечал за обработку входящих задач из Telegram-очереди. Его работа простая: получить задачу, разобрать её на шаги, делегировать исполнителям, записать результат в базу. Он отлично справлялся днём, но ночью что-то пошло не так: скорее всего, потерял соединение с базой данных на секунду, не обработал исключение правильно, и ушёл в бесконечное ожидание ответа, который никогда не пришёл. Восемь часов в этом состоянии — и в очереди 9 задач, которые должны были быть выполнены ещё вчера.

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

Это и есть фундаментальная проблема с автономными AI-агентами: стандартные инструменты мониторинга проверяют факт существования процесса, но не его осмысленную активность. Нужен другой уровень контроля — тот, который понимает разницу между «процесс запущен» и «процесс работает и приносит пользу».

Почему девять задач в очереди — это только видимая часть ущерба

Девять задач звучит не страшно. Но каждая из них запускала цепочку: бот принимал задачу → передавал SEO-агенту или финансовому агенту → они генерировали результаты → результаты записывались в базу и уходили в отчёты. Цепочка зависла целиком. Утренний отчёт по финансам вышел неполным. SEO-статья не была опубликована в срок. Три напоминания о встречах не ушли менеджерам.

Реальная цена одного зависшего бота на восемь часов — это не девять задач, это десятки вторичных эффектов, которые расходятся кругами по всей системе. Понимание этого и заставило меня в то утро не просто перезапустить контейнер, а сесть и построить нормальный watchdog.

Watchdog для AI-агентов: как сторожевой процесс следит за 17 ботами каждые пять минут

Watchdog — это отдельный процесс, единственная задача которого — следить за здоровьем остальных агентов. Не просто проверять, что они запущены, а убеждаться в том, что они активно работают: обрабатывают задачи, обновляют heartbeat-метки, отвечают на ping-запросы в разумное время.

Логика моего watchdog-а проста. Каждые пять минут он обходит список из 17 агентов. Для каждого проверяет:

Время последнего heartbeat — каждый агент раз в минуту обновляет метку «я жив» в Redis. Если метка не обновлялась больше 10 минут — агент считается подозрительным.
Длина очереди — если очередь задач агента растёт, но heartbeat обновляется — значит, бот завис в обработке одной задачи. Это отдельный паттерн зависания.
CPU и память — если агент потребляет 100% CPU дольше трёх минут без видимого прогресса, скорее всего, он в бесконечном цикле.
Последнее успешное завершение задачи — самый надёжный индикатор. Если агент не завершил ни одной задачи за последние X минут (где X зависит от ожидаемой частоты работы), что-то идёт не так.

При обнаружении проблемы watchdog не паникует и не шлёт мне немедленный алерт. Сначала он пробует мягкое восстановление: отправляет агенту команду «сбрось текущую задачу и перейди в ожидание». Если это не помогает в течение двух минут — делает жёсткий перезапуск контейнера. Только если и это не решает проблему после трёх попыток — пишет мне в Telegram.

Результат: большинство зависаний разрешается без моего участия. Агент завис, watchdog его тихо перезапустил, задача вернулась в очередь и была выполнена заново. Я узнаю об этом только из утренних сводок — не из ночных разбудинок.

Техническая реализация: три строки, которые изменили всё

Сам watchdog реализован как Python-скрипт, запускаемый через cron каждые пять минут. Он не сложнее 200 строк кода. Главная идея — минимальные зависимости: Redis для heartbeat-меток, Docker API для управления контейнерами, простой HTTP для ping-проверок.

Каждый агент при старте регистрируется в реестре watchdog-а: передаёт своё имя, тип ожидаемой активности и пороги для алертов. Это позволяет watchdog-у быть умным: он понимает, что SEO-агент может не выполнять задачи часами (потому что пишет длинную статью), а агент обработки входящих сообщений должен активничать каждые несколько минут.

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

Лимиты бюджета и ходов: как я поставил забор на 17 агентов и перестал бояться неожиданных счётов

Пока я разбирался с watchdog-ом, мне пришла в голову смежная мысль: а что если один из агентов не зависает, а наоборот — слишком активно «увлекается» задачей? Иногда AI начинает копать тему всё глубже и глубже, генерирует подзапросы, вызывает инструменты снова и снова, и в итоге тратит в 50 раз больше ресурсов, чем планировалось. В деньгах это может вылиться в неожиданный счёт на десятки долларов за одну задачу.

Прошёлся по всем 17 агентам и задал каждому два параметра:

Лимит бюджета на задачу — максимальная стоимость в долларах, которую агент может потратить на решение одной задачи. Для простых агентов-маршрутизаторов это $0.05, для глубоких аналитических агентов — до $2.
Лимит ходов (max_iterations) — максимальное количество шагов, которые агент может сделать в рамках одного запуска. Это защита от бесконечных циклов рассуждений. Для большинства задач 20–30 ходов более чем достаточно.

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

До введения лимитов мой самый «прожорливый» агент — аналитический, который изучал переписки и делал сводные отчёты — иногда тратил $3–5 за один запуск. После ограничения в $1.50 его поведение не ухудшилось: оказалось, что дополнительные ходы в основном шли на «переосмысление» уже найденного ответа, а не на поиск новой ценной информации.

Суммарная экономия за первый месяц после введения лимитов — около 35% от предыдущих трат на API. Не потому что агенты стали хуже работать, а потому что я перестал платить за их задумчивость.

Как правильно подобрать лимиты для своих агентов

Первая неделя после введения лимитов была немного хаотичной: некоторые лимиты оказались слишком жёсткими, и агенты начали «не доделывать» задачи. Пришлось откалибровать. Вот мой подход к подбору правильных значений:

Запустите агента на 10–20 реальных задачах без лимитов, но с логированием стоимости и количества ходов. Найдите медиану и 95-й перцентиль. Установите лимит примерно на уровне «медиана × 2», но не выше 95-го перцентиля. Это даёт агенту пространство для сложных задач, но отсекает аномальные запуски.

Для нетривиальных агентов, где сложность задачи сильно варьируется, я использую динамические лимиты: клиент при создании задачи может указать «priority: high», и агент получает двойной бюджет. Это редкий случай, но иногда нужен.

SEO-агент без глаз: как починить бота, который смотрит в пустоту вместо источников

Один из самых важных агентов в моей системе — SEO-агент, который пишет статьи для блога. Он получает из библиотеки контента исходный материал, превращает его в полноценный текст и публикует на сайте. Теоретически. На практике последние несколько недель он стабильно выдавал тексты по 200 слов — бессодержательную воду про «важность автоматизации в современном мире».

Я долго грешил на качество промпта. Переписывал инструкции, добавлял примеры, ужесточал требования. Ничего не менялось. 200 слов, сухо, без конкретики.

Когда я наконец сел разбираться системно, оказалось, что проблема банальная до неловкости: агент не видел исходники. Путь к папке с подготовленными материалами прописался неправильно три недели назад — я переструктурировал директории на сервере, и монтирование тома Docker-контейнера устарело. Агент честно читал файл по неверному пути, получал пустой ответ или ошибку, интерпретировал это как «источника нет» и писал статью из общих соображений. Без единого реального факта, кейса или числа.

Это классическая ошибка «silent fail»: агент не падает с ошибкой, не сообщает о проблеме — он просто делает задачу «по-своему» с тем, что имеет. Понять, что что-то идёт не так, можно только по качеству результата. А качество результата AI-текста — субъективная вещь, и первые несколько раз я просто думал «ну, не самая лучшая статья вышла».

Три правки, которые превратили SEO-агента из водолея в специалиста

После исправления пути к источникам я сделал ещё три важных изменения.

Первое — обязательная проверка источника в начале работы. Теперь агент читает исходник и первым делом проверяет: есть ли в нём хотя бы 300 слов конкретного контента? Если нет — задача возвращается с пометкой «источник пустой или слишком короткий» и не идёт дальше. Это предотвращает ситуацию, когда агент тихо пишет воду.

Второе — новые критерии качества. Я дописал агенту правила: что такое «хорошая SEO-статья» и что такое «плохая». С конкретными примерами, с измеримыми показателями (минимум 2500 слов, минимум 5 подзаголовков H2, обязательные цифры и примеры). Раньше я описывал желаемый результат абстрактно: «напиши хорошую статью». Теперь у агента чёткий чеклист из 12 пунктов.

Третье — финальная самопроверка. После написания статьи агент сам подсчитывает количество слов через wc и проверяет структуру. Если статья не соответствует критериям — он переписывает её, не публикуя. Публикация происходит только после прохождения автоматического контроля качества.

Результат первой статьи, написанной после этих правок: 3200 слов, 6 H2-разделов, конкретные цифры и примеры из реального кейса. Это та самая разница, ради которой стоит потратить вечер на отладку системы.

Голосовой ввод через iCloud: iPhone → сервер без лишних приложений

Давняя мечта: я наговариваю идею в телефон — она прилетает на сервер уже в виде расшифрованного текста, готового к обработке AI-агентами. Никаких промежуточных шагов, никаких копипастов. Просто говорю — и через 30 секунд мысль уже в системе.

Два часа я воевал с приложением «Диктофон» на iPhone. Казалось бы, идеальный инструмент: встроено, стабильно работает, транскрибирует голос нажатием кнопки. Проблема одна, но критическая: Apple хранит файлы Диктофона в системном контейнере приложения, который синхронизируется с iCloud, но недоступен как обычная папка. Ни один файловый мониторинг на Mac туда не добирается. Файл есть — но достать его автоматически нельзя.

Перепробовал несколько подходов: Shortcuts на iPhone, AppleScript на Mac, iCloud Drive API. Каждый упирался в какое-нибудь ограничение Apple — то требовался ручной шаг, то не работал в фоне, то API был закрыт. В итоге принял прагматичное решение: не воевать с Apple, а обойти проблему.

Схема, которая работает как часы: iCloud Drive + watchdog на Mac

Решение оказалось элегантным в своей простоте. Вместо стандартного Диктофона я записываю голос в любое приложение, которое сохраняет файлы в обычную папку iCloud Drive — например, Voice Memos альтернативы или просто «Файлы» с голосовой записью. Папку назвал «VoiceIn» — она синхронизируется между iPhone и Mac автоматически.

На Mac запущен простой демон-наблюдатель (FSEvents + Python), который следит за папкой VoiceIn в iCloud Drive. Как только появляется новый аудиофайл — демон подхватывает его, отправляет на Whisper API для транскрибации и пишет получившийся текст в очередь сервера. Файл помечается как обработанный (перемещается в архивную папку).

На сервере AI-агент мониторит эту очередь и обрабатывает поступающие мысли: классифицирует их (это задача? идея? вопрос для анализа?), маршрутизирует нужному агенту и создаёт соответствующие тикеты или заметки.

Скорость работы меня приятно удивила. Запись в 30 секунд обрабатывается Whisper за 3–5 секунд, ещё 5 секунд на маршрутизацию — и через 15 секунд после того, как я закончил говорить, мысль уже висит в системе как задача с нужным приоритетом. Теперь я думаю вслух значительно чаще, чем раньше — потому что знаю: ни одна мысль не потеряется.

Практические советы для тех, кто хочет повторить

Несколько нюансов, которые упрощают жизнь при подобной схеме:

Форматы файлов — Whisper хорошо работает с m4a (стандарт iPhone), mp3 и wav. Принимайте все три, если хотите гибкости в выборе приложения для записи.
Язык записи — явно указывайте язык в запросе к Whisper. Если вы говорите по-русски, но в тексте иногда встречаются английские термины, используйте параметр language: "ru" для стабильности.
Пост-обработка текста — голосовой текст требует лёгкой нормализации: убрать «эм», «ну», расставить знаки препинания. Добавьте в цепочку небольшой промпт «причеши транскрипт, сохрани смысл».
Мониторинг задержки iCloud — синхронизация iCloud Drive не мгновенная. В редких случаях файл появляется на Mac с задержкой до 2–3 минут. Держите это в виду при оценке скорости системы.

Переговоры по Orange Car: как 10% от валовой оказались лучше любой сложной схемы

Параллельно с технической работой в тот день произошло кое-что важное в деловом плане. Уже больше месяца мы с Никитой переписывали условия по автоматизации его автопарка на Пхукете. Несколько машин, который он сдаёт в аренду, — и мы договаривались о модели оплаты за внедрение AI-системы управления.

История переговоров была запутанной. Сначала я предлагал 25% от прироста прибыли — performance-based модель, при которой я получаю деньги только если автоматизация реально улучшает показатели. Логично и справедливо с точки зрения ценности. Но тяжело считать: нужно фиксировать «базовую линию», потом сравнивать, спорить об атрибуции.

Никита предложил 17,5% — тоже от прироста, но с дополнительными ступенями. Мы долго согласовывали методологию подсчёта «базовой прибыли», пытались учесть сезонность, субаренду, разные классы машин. Каждый раунд переговоров рождал новые уточнения и новые разногласия. Продуктивность — ноль.

Простота побеждает сложность: почему процент от валовой выигрывает

В тот день Никита прислал новое предложение: 10% от валовой выручки по всему автопарку. Без прироста, без базовых линий, без ступеней — просто фиксированная доля от реальных поступлений.

Я потратил минут 15 на подсчёты. Взял его текущие данные по выручке, умножил на 10%, сравнил с тем, на что я рассчитывал по предыдущим схемам. Результат удивил: 10% от валовой оказались примерно вдвое больше того, что выходило по схеме «25% от прироста» в пессимистичном сценарии.

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

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

Это показательный пример того, как AI помог в переговорах косвенно: именно потому что я использую агентов для аналитики, у меня под рукой всегда есть точные данные для быстрого подсчёта. Те 15 минут расчётов — это не час с Excel, а мгновенный запрос к агенту, который вытащил все нужные цифры из базы и посчитал сценарии.

Мост между локальным Claude и Telegram-ботом: единый мозг на две головы

Вечером того же дня я столкнулся с проблемой, которая существовала с первого дня — просто я никогда не думал о ней как о проблеме. Мой Telegram-бот, который отвечает на вопросы о бизнесе, не знал ничего о том, что я обсуждал с локальным Claude Code на своём ноутбуке.

Конкретная ситуация: я два часа работал локально с Claude, считал профицит по сделке с Никитой, перебирал варианты моделей субаренды, формулировал аргументы для переговоров. Потом открыл Telegram и спросил бота: «Напомни, на каком варианте мы остановились по Orange Car?». Бот честно ответил: «Не могу найти информацию по этой теме». Потому что он понятия не имел, что этот разговор вообще был.

По сути у меня было два мозга, которые не разговаривали друг с другом. Локальный Claude — для глубокой работы, анализа, сложных рассуждений. Telegram-бот — для быстрого доступа к информации, напоминаний, делегирования задач. Оба умные, оба полезные. Но изолированные.

Синхронизация через промежуточное хранилище: архитектура за один час

Решение оказалось неожиданно простым. Я добавил в локальный Claude Code хук: после каждого моего сообщения (не ответа Claude, а именно моего) локальный агент в фоне слил весь текущий контекст переписки на сервер — в специальную таблицу «локальные сессии».

Telegram-бот получил новую инструкцию: прежде чем ответить на любой вопрос о бизнесе, сначала смотреть в таблицу «локальных сессий» за последние 24 часа. Если там есть что-то релевантное — использовать как контекст.

Первая проверка прошла отлично: я спросил Telegram-бота «какая ставка по Orange Car?» — он правильно ответил «10% от валовой, включая субаренду, договорились сегодня днём». Все цифры, которые мы обсуждали локально, были у него под рукой.

Теперь это работает так: где бы я ни думал — за ноутбуком или в телефоне — вся информация оседает в общей памяти. Это и есть «один мозг на две головы». Не важно, через какой интерфейс я взаимодействую с AI, — система знает всё, что я обсуждал за последние сутки.

Privacy-вопрос: что синхронизировать, а что оставить локальным

Один нюанс, который я проработал сразу: не всё нужно синхронизировать. Личные разговоры, черновики, спекулятивные идеи — не для общего хранилища. Поэтому у меня есть простое правило: по умолчанию синхронизируются только разговоры, где я упоминаю ключевые бизнес-сущности (имена партнёров, названия проектов, числовые показатели). Остальное остаётся локальным.

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

Итог дня: я больше не решаю задачи — я улучшаю систему, которая решает их за меня

К ночи, когда я наконец закрыл ноутбук, у меня было странное ощущение. Я сделал очень много — watchdog, лимиты для 17 агентов, починенный SEO-агент, голосовой ввод, закрытые переговоры, синхронизация Claude и Telegram — но я не решил ни одной бизнес-задачи напрямую. Я улучшил инфраструктуру, которая будет решать бизнес-задачи за меня.

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

Разница огромная. Если я решаю задачи сам — моя производительность ограничена 8–10 рабочими часами в день. Если я улучшаю систему — она работает 24 часа в сутки, параллельно по многим направлениям, без выгорания и без больничных. И каждый день, потраченный на улучшение системы, даёт мультипликативный эффект: хорошо отлаженный watchdog будет спасать агентов от зависаний следующие годы.

Сколько я потратил денег на API за этот день? Примерно $4. Сколько бы я потратил, если бы делал всё руками? Три дня плотной работы как минимум, не считая потерь от зависшего бота. Это и есть реальная математика автоматизации.

Что стоит сделать прямо сейчас, если вы строите AI-систему

Если вы работаете с AI-агентами или только начинаете, вот практический порядок приоритетов:

Сначала watchdog, потом всё остальное. Даже один агент требует надзора. Не ждите, когда очередь накопит 50 задач — стройте мониторинг с первого дня.
Лимиты — это не ограничение, а защита. Агент с лимитами работает предсказуемо. Агент без лимитов — это финансовая бомба замедленного действия.
Silent fail опаснее явных ошибок. Если ваш агент «что-то делает» но плохо — разберитесь, видит ли он реальные данные. Часто проблема именно в этом.
Интерфейс ввода важен. Если вводить данные в систему неудобно — вы будете делать это реже. Голосовой ввод, кнопки в Telegram, интеграции с инструментами, которые вы уже используете — всё это влияет на реальное использование системы.
Единая память для всех интерфейсов. Если у вас несколько точек входа в AI — убедитесь, что они делятся контекстом. Иначе вы платите за интеллект, который не помнит половины информации.

Заключение: один день, который изменил архитектуру всей системы

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

Watchdog теперь каждые пять минут обходит всех 17 агентов и тихо чинит тех, кто завис. Лимиты бюджета и ходов убрали риск неожиданных счётов и бесконечных циклов. SEO-агент наконец видит источники и пишет полноценные статьи вместо воды. Голосовой ввод через iCloud работает стабильно и без лишних приложений. Переговоры по Orange Car закрыты на условиях, которые лучше моих ожиданий. Локальный Claude и Telegram-бот теперь знают всё, что знает каждый из них.

Ни одного нанятого сотрудника. Ни одного ручного действия, кроме нажатия Enter. Именно так выглядит бизнес, который автоматизирован по-настоящему, а не «у нас есть несколько ботов».

Если вы хотите построить подобную систему для своего бизнеса на Бали или в любой другой точке мира — напишите мне. Мы разберём вашу ситуацию, найдём точки максимального рычага и построим AI-систему, которая работает даже когда вы спите.

Как я настроил 17 AI-агентов за один день: watchdog, голосовой ввод и Telegram-мост