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

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

Почему «ОС» — не метафора

У зрелой агентной платформы есть все признаки операционной системы, только процессы выполняют агенты:

  • Файловая система → память. Не история чата, а знание, которое копится месяцами и переживает любую сессию.
  • Планировщик → задачи по расписанию. Сбор сигналов в 7 утра, черновики к 9, публикации по слотам.
  • Права доступа → права агентов. Агент падает там, где сработала защита, — см. историю выше.
  • Драйверы → цепочка моделей. Облачная → локальная → две запасных. Провайдер лёг — система не заметила. Локальная модель — не компромисс, а граница для данных, которые не должны покидать машину.
  • Фоновые службы → мониторинг. Проверка здоровья, бюджет токенов, разбор логов, уведомления.

Память: четыре слоя

Самая недооценённая часть:

  1. Векторный индекс — ~70 000 фрагментов истории. Поиск по смыслу: «что мы решали про биллинг в апреле».
  2. Граф сущностей — 45 000 сущностей, 85 000 связей. Поиск по структуре: кто с чем связан.
  3. Комбинированный поиск поверх обоих — когда нужен и смысл, и связи.
  4. Автоподмешивание в контекст — выжимка, которую агент получает под задачу.

Память принадлежит вам и растёт годами — главное отличие от облачного ассистента.

Инцидент 1: система решила, что упал провайдер. Упала она сама

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

Урок: мониторинг обязан отличать «снаружи сломалось» от «я сам перезапустился».

Проверьте у себя: при алерте о провайдере сначала загляните в системный журнал — не перезапускался ли ваш собственный процесс в ту же минуту (на Linux: journalctl, ищите «out of memory» и «restart»). Несколько задач упали одновременно — причина почти всегда одна и локальная. Полечить: научите мониторинг сначала спрашивать «а жив ли я сам», и только потом обвинять внешний мир.

Инцидент 2: задача докладывала «всё хорошо» и не делала ничего

Ежедневный пайплайн несколько дней отчитывался «ok» — данных при этом не было. Причина: запуск был устроен как «агент, которому написали „запусти скрипт“». Агент вежливо отвечал, что запускать ему нечем, — и этот ответ засчитывался как успех.

Урок: если задачу можно нарисовать блок-схемой — это работа для обычного скрипта, а не для модели. Расписание и запуск — планировщику, модель — только там, где нужно думать и писать. Заодно это сняло примерно половину дневного расхода токенов.

Проверьте у себя: возьмите любую свою автоматизацию и спросите не «отчиталась ли она об успехе», а «появился ли результат и обновилась ли его дата». Если проверяете только статус — у вас театр. Полечить: успех задачи = существующий свежий артефакт, всё остальное — слова.

Инцидент 3: пайплайн тихо деградировал неделями

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

Урок: упавший пайплайн чинят в тот же день, тихо деградировавший живёт неделями.

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

Инцидент 4: автономность без обратной связи — это театр

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

Урок: у любого автономного цикла должен быть хотя бы один внешний сигнал, а не только выходной артефакт.

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

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

  • Улучшение не ломает. Зафиксировать, что работает, до изменения — проверить после. После одного мажорного апгрейда панель управления ушла в бесконечный перезапуск: 5655 рестартов, пока я спал. С тех пор — бэкап перед каждым изменением и откат одной командой.
  • Память врёт, команда не врёт. Любое утверждение о состоянии системы — сначала проверка командой, потом ответ.
  • Файлы переживают всё, «запомню» — ничего. Планы, бэклоги, уроки — на диск. Контекст сессии умирает, файл остаётся.
  • Запустилось ≠ работает. Минимум два цикла реальной обработки в логах и повторная проверка через пять минут.

Зачем это вам

Держать 30 агентов нужно немногим. Но сдвиг стоит увидеть раньше других: люди перестают «пользоваться ИИ» через чужой сайт и заводят свой агентный слой — со своей памятью, правами и процессами. Цену ночных инцидентов платит один человек, остальные получают кнопку и память.

Про контур на уровне компании — «ИИ-инфраструктура — в каждый дом и в каждую компанию». Смотреть сдвиг в цифрах — Trend Radar.

Система из статьи — рабочая, а не демо: она собрала половину фактуры для этого текста.