Как я перестал решать задачи и начал чинить систему, которая их решает: один день, пять систем, ноль ручных действий

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

Где-то к полуночи поймал себя на мысли: я уже несколько месяцев делаю именно это. Мои рабочие дни — это не задачи бизнеса, это задачи по улучшению автоматизации. Продать виллу? Бот. Опубликовать пост? Бот. Посчитать расходы за месяц? Бот. Я занимаюсь тем, что слежу, чтобы боты работали правильно, и делаю их лучше. Это другой жанр работы — и мне он нравится значительно больше.

Вот что конкретно я построил за тот день — и почему каждая из этих вещей меняет качество работы системы в целом.

Утро: бот завис, 9 задач в очереди — строю сторожа

Зависший бот — это классический тихий баг. Технически он "работает": процесс запущен, нет никаких ошибок в логах. Но он не делает ничего. Очередь задач накапливается, дедлайны горят, никто об этом не знает — потому что система не знает разницы между "ждёт, пока что-то придёт" и "завис в ожидании, которое никогда не завершится".

После того как я вручную почистил 9 задач, которые залежались за ночь, стало понятно: нужен сторож. Не человек, не ручная проверка раз в день — автоматический процесс, который следит за каждым агентом и знает, когда тот завис.

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

При обнаружении аномалии watchdog делает одно из трёх: перезапускает агента (если это безопасно), отправляет алерт мне (если перезапуск небезопасен), или просто записывает в лог (если аномалия несущественная). Какой из вариантов — определяется конфигурацией каждого агента отдельно.

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

Лимиты для всех агентов: чтобы энтузиасты не сжирали бюджет

Пока разбирался с watchdog, заодно прошёлся по конфигурации всех 17 агентов и поставил двум параметрам жёсткие лимиты.

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

Второй — количество шагов. Агент не может сделать больше N последовательных действий без паузы и проверки. Это защита от инфинити-лупов: ситуаций, когда агент уходит в цикл, каждый шаг которого выглядит логично, но вся цепочка уводит всё дальше от исходной задачи. Лимит шагов — это принудительная точка остановки: "сделал N — остановись, проверь, продолжи только если всё ещё нужно".

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

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

Отдельная история дня — SEO-агент для блога. Он работал, исправно выдавал статьи, но с одной проблемой: статьи были по 200-300 слов вместо нормальных 1500-2500. Поверхностно, без деталей, без реальных примеров — просто пустые слова вокруг темы.

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

Починил путь, проверил доступ. Но дальше решил заодно обновить и правила для агента: что такое хорошая SEO-статья для этого блога, а что нет. Написал список запретов (AI-клише, обобщения без примеров, CTA "записывайтесь к нам") и список обязательств (минимум 2500 слов, первое лицо от Юрия, конкретные числа и кейсы, внутренние ссылки). Это заняло час, но теперь каждая следующая статья агента будет строиться на этой базе.

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

Голос в текст через iCloud: как обойти Apple Диктофон

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

Первая попытка — стандартный Диктофон на iPhone. Записал — хочу, чтобы файл улетел на сервер. Проблема: Apple прячет записи Диктофона в CloudKit — собственное системное хранилище, куда не попасть обычными инструментами. Никакой файловой системы, никакого доступа извне, никакого пути для автоматизации. 2 часа на эксперименты, потом признал: тут не обойти.

Решение пришло через отказ от Диктофона. Вместо него — любое приложение для записи звука, которое сохраняет в папку iCloud Drive. Папка iCloud Drive синхронизируется с Mac. На Mac запущен демон (простой Python-скрипт), который наблюдает за папкой и при появлении нового аудиофайла запускает транскрипцию через Whisper.

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

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

Сделка с Никитой: когда лучший ход — промолчать и согласиться

Ближе к вечеру созвон с Никитой по Пхукету. Мы уже месяц переписываем условия на автоматизацию его автопарка. Переговоры шли долго: сначала я хотел 25% от прироста прибыли, потом он предлагал 17.5%, потом обсуждали ступенчатые условия с порогами. Каждый новый вариант добавлял сложность в расчёты.

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

Я посчитал минут 15. Вышло, что это примерно вдвое больше того, на чём мы почти сошлись неделю назад — потому что при расчёте "от прироста" есть много способов определить базу, и спор об этой базе мог идти бесконечно. Формула "от валовой" убирает весь этот спор.

Я не стал ничего переспрашивать и торговаться. Попросил только одну цифру — отдельно данные по субаренде, чтобы понять структуру. Согласился.

Это тоже часть работы системного мышления: когда переговоры сложные, простая формула с понятным расчётом часто стоит больше "выгодной" сложной формулы с постоянными спорами об интерпретации. Простота устойчива. Сложность — нет.

Мост Mac→сервер: один мозг на две платформы

Ночью обнаружил кое-что неожиданное. Мой Telegram-бот, который "в курсе всего, что происходит" — не видел ни слова из разговоров с локальным ассистентом на ноутбуке.

Я два часа считал цифры по сделке с Никитой с локальным ассистентом — и Telegram-бот при этом не знал, что этот разговор вообще был. Если я потом спрошу Telegram-бота что-то по условиям сделки — он начнёт отвечать с нуля, без контекста. Как будто разговора не существовало.

Это фрагментация контекста между платформами. У каждого инструмента своя память, и они не видят друг друга. Я один, а "мозгов" несколько — и они не синхронизированы.

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

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

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

Что объединяет все пять вещей

К полуночи, глядя на список сделанного за день, я понял, что объединяет все пять систем. Ни одна из них не решает задачи бизнеса напрямую. Ни одна не приносит деньги сама по себе. Все они делают одно: они улучшают инфраструктуру, которая приносит деньги.

Watchdog не продаёт виллы. Он следит за тем, чтобы боты, которые продают виллы, не зависали. Лимиты бюджетов не генерируют контент. Они следят за тем, чтобы агенты, которые генерируют контент, не уходили в неконтролируемое потребление ресурсов. Мост контекста не считает прибыль. Он следит за тем, чтобы я не терял контекст при переключении между инструментами.

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

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

Как понять, что вы стали наладчиком

Есть несколько признаков, по которым я понимаю, что двигаюсь в правильном направлении.

Ни один из этих признаков не означает, что вы больше не работаете. Наладчик работает много — просто по-другому. Он строит, а не делает. Он думает на уровень выше. Он видит систему целиком, а не отдельные задачи внутри неё.

С чего начать: один первый шаг

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

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

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

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

А у вас бывает, что вы проверяете не то, как выполнилась задача, а то, насколько хорошо отработала ваша автоматизация?