Пока индустрия пытается изобрести AGI, бизнес кормят 80 строк на Python

В ноябре прошлого года ко мне пришел основатель логистической компании. Злой, невыспавшийся и на 7 400 долларов беднее, чем месяцем ранее. Эту сумму съела модная студия, которая строила ему «мультиагентную ИИ-систему обработки заявок» на базе тяжелых фреймворков и облачных очередей. В пятницу вечером стороннее API ответило нестандартным JSON-ом с пустым полем. Вся эта хрупкая конструкция из десяти абстракций подавилась ошибкой, тихо легла и похоронила под собой 310 входящих заказов за выходные.

Мы выкинули весь этот картонный замок за два часа. Вместо него написали сухой скрипт на 80 строк, завернули его в юнит systemd и повесили на виртуалку за пять евро в месяц. Он работает до сих пор. Ни разу не упал, не потерял ни одной строчки лога и жрет ровно 38 мегабайт оперативной памяти.

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

Анатомия хайпа против суровой практики

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

Большинству компаний не нужен искусственный сверхразум, рассуждающий о смысле жизни за счет их кредитки. Им нужно другое: чтобы в 03:15 ночи выписка из банка скачалась, распаковалась, проверила статус платежа и отправила чек клиенту. Без драмы. Без галлюцинаций. Каждую ночь, триста шестьдесят пять дней в году.

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

Почему Linux-примитивы бьют любой оверинжиниринг

Мы в GuardLabs годами собираем инфраструктуру вокруг двух фундаментальных инструментов: systemd и cron. Звучит старомодно? Возможно. Зато это железобетонно надежно.

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

Связка systemd cron автоматизация решает 99% эксплуатационных проблем из коробки:

Процесс упал из-за тайм-аута стороннего шлюза? Параметр Restart=always с экспоненциальной задержкой поднимет его через три секунды. Сторонняя библиотека течет по памяти? Директива MemoryMax=512M мягко прибьет зарвавшийся скрипт и запустит свежий инстанс, не уронив соседние сервисы. Ротация логов? journald забирает стандартный вывод потоков, не требуя развертывания монструозных стеков сбора метрик.

Такие 24/7 фоновые сервисы python живут годами. Они не требуют внимания системных администраторов, не отваливаются от чиха облачного провайдера и делают именно то, что в них заложено кодом, а не случайным распределением вероятностей в нейросети.

Правило изоляции и гигиена скриптов

Чтобы держать десятки независимых процессов на скромном сервере и спать по ночам, достаточно соблюдать четыре простых правила, за которые мы в свое время заплатили сотнями седых волос:

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

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

Третье — жесткие таймауты на абсолютно каждый сетевой запрос. Любая библиотека вроде requests по умолчанию способна висеть вечно, если удаленный сервер просто замолчал посреди TCP-сессии. Забытый таймаут — гарантированная смерть воркера в самый неподходящий момент.

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

Мы любим сложные технологии, но еще больше мы любим системы, которые не звонят нам в субботу утром с сообщением о сбое. Если вам тоже надоело бороться с переусложненным софтом и нужен предсказуемый, неубиваемый результат, мы берем эту рутину на себя: настраиваем и поддерживаем флот автономных Python-агентов на VPS (systemd + cron), 24/7, освобождая ваше время под развитие продукта, а не починку отвалившихся очередей.