Миграция AI-агентов при лимите модели: как не остановить операционку

30 июня 2026 года мой парк AI-агентов поймал скучный, но дорогой тип аварии: 16 из 25 воркеров заморозились из-за лимита модели. Это не выглядело как катастрофа в кино. Никакого дыма из серверной, просто очередь задач перестала двигаться там, где обычно работают публикации, финансы, технические проверки и операционные рутины.

В такой момент есть два пути. Первый — докинуть денег в тот же лимит и надеяться, что следующая стена появится позже. Второй — посмотреть на систему как на инженерный контур: где именно завязан поставщик модели, какие роли зависят от CLI, где лежат секреты, что можно перенести через общий адаптер, а что придётся проверять руками. Я выбрал второй путь и за один рабочий день перевёл парк из 25 агентов на другой движок.

Эта статья не про гонку моделей и не про религиозную войну вокруг AI-инструментов. Модель — только один слой. В проде важнее, умеет ли агент проснуться по heartbeat, прочитать задачу, применить свои правила, вызвать нужный helper, не раскрыть секреты, записать результат и не устроить фейерверк в базе. Ниже — схема миграции, которую можно забрать для своей операционки.

Почему лимит модели становится архитектурной проблемой

Один AI-ассистент в личном чате может подождать. Парк агентов, который живёт в задачах, расписаниях и публикационных пайплайнах, ждать не должен. Когда 16 воркеров останавливаются одновременно, у тебя ломается не один ответ, а календарь работ: SEO-статья не выходит, QA не закрывает артефакт, техническая задача не получает диагностику, менеджер не видит статуса.

Лимит модели опасен тем, что выглядит как коммерческая мелочь. Кажется, будто проблема решается тарифом. Иногда так и есть, если система маленькая и один человек может руками закрыть паузу. В агентной операционке тариф не убирает главный риск: весь парк привязан к одному способу исполнения. Следующий лимит, outage, изменение API или блокировка OAuth снова поставят очередь.

Я смотрю на это как на зависимость уровня базы данных или платёжного провайдера. Если платежи принимает только один шлюз, в архитектуре нужен план Б. Если агенты работают только через один runtime, нужен слой, который позволяет заменить двигатель без переписывания ролей. Иначе у вас не автоматизация, а набор красивых скриптов с одной общей точкой отказа.

В моём случае контур включал Paperclip, Codex CLI, системные инструкции агентов, SSH-доступ на сервер 213.139.229.247, локальные helper-скрипты для публикаций, базы данных и watchdog-задачи. У каждого агента своя зона: seo-4bos пишет статьи на 4bos.ru, Telegram держит канал, CTO отвечает за инфраструктуру, Finance смотрит деньги. Перенос модели должен был сохранить эти границы, а не превратить всех в универсального бота с амнезией.

Главный вывод: миграция AI-агентов начинается не с выбора новой модели. Она начинается с карты зависимостей. Кто просыпается? Через какой runner? Какие переменные окружения нужны? Какие команды разрешены? Что считается успешным завершением? Где логируется ошибка? Пока это не описано, смена модели похожа на замену двигателя на машине, которая едет по трассе.

Инвентаризация: что надо выписать до первого переключателя

Перед переносом я фиксирую не «список промптов», а список рабочих контрактов. У каждого агента есть вход, выход и запреты. Например, seo-4bos при heartbeat первым делом читает свои pending tasks в Paperclip, затем публикует статьи только через /opt/4bos-blog-sync/agent_publish.py. Ему нельзя писать HTML напрямую в блог, нельзя трогать elefterri.com и atomi.id, нельзя придумывать цены или кейсы.

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

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

Второй слой — инструменты. У агента могут быть SSH, база данных, helper-скрипты, Cloudflare purge, поисковые таблицы, локальные файлы, API Paperclip. У каждого инструмента нужно понять, где лежит доступ и кто имеет право им пользоваться. Миграция, которая случайно расширяет права, хуже остановки: остановку видно сразу, а лишний доступ обычно всплывает после неприятной записи в прод.

Третий слой — форматы. Один агент пишет JSON в helper, другой публикует markdown, третий обновляет issue через API, четвёртый читает таблицу PostgreSQL. Новая модель должна стабильно соблюдать эти форматы. В SEO-контуре 4bos.ru статья обязана иметь поля slug, title, meta_description, date_iso, tldr, faq и article_html. Если формат сломан, публикация должна упасть до записи в блог.

Четвёртый слой — запреты. Их нельзя держать «в голове». В Solar есть запрет на cold outbound, на выдуманные цифры, на прямую правку шаблонов блога, на клиентские цены без Юрия, на операции с чужими сайтами из default-компании. Эти правила должны попадать в системные инструкции до запуска агента, а не в постфактум-лекцию после инцидента.

Как переносить агентов: адаптер вместо переписывания всей системы

Рабочая миграция не должна начинаться с массовой правки 25 инструкций. Сначала нужен слой исполнения, который принимает старую задачу и отдаёт её новой модели в ожидаемом формате. Условно: Paperclip создаёт heartbeat, агент получает инструкции, runner запускает Codex CLI, результат возвращается в задачу. Если этот путь стабилен, роли можно переносить пачками.

Адаптер нужен по простой причине: модели отличаются стилем, длиной ответа, поведением при ошибках и отношением к инструментам. Один runtime любит задавать уточняющие вопросы, другой сразу выполняет команды, третий иначе режет контекст. Для пользователя это нюансы. Для агента, который должен молча проверить pending tasks и выйти при пустой очереди, это контракт.

30 июня я переносил не «личность» агентов, а их рабочий протокол. У seo-4bos первое действие — запросить свои задачи в базе Paperclip. Если задач нет, он молчит. Если задача есть, он читает описание, читает AGENTS.md, GEO-addon, example payload, проверяет источники, пишет JSON и публикует через helper. Этот порядок важнее любого красивого рассуждения о SEO.

То же относится к инфраструктурным агентам. CTO не должен в миграции получить привычку глушить соседние сервисы. Finance не должен начать писать в финансовые таблицы без команды Юрия. Telegram не должен обходить dedup guard публикаций. Новая модель может быть умнее в коде, но системный контракт всё равно надо прибить гвоздями: вход, разрешённые инструменты, запрещённые действия, критерий done.

Практический приём: переносить сначала агентов с чтением и безопасными helper-скриптами, потом агентов с публикациями, и только затем тех, кто имеет доступ к деньгам, прод-деплою или данным клиентов. В моём случае тестовый прогон шёл через задачи, где ошибка не приводит к финансовой записи или массовой рассылке. Скучно, зато потом не приходится объяснять, почему робот решил быть творческим в базе.

Тестовый heartbeat: минимальный набор проверок

После переключения модель должна доказать, что она не просто отвечает, а работает в контуре. Я использую короткий heartbeat-тест. Он проверяет четыре вещи: агент видит задачу, понимает инструкции, вызывает нужный инструмент и корректно завершает статус. Для парка из 25 агентов это быстрее, чем читать все ответы глазами.

Первый тест — чтение. Агент должен запросить свои pending tasks, не искать чужую работу и не брать unassigned issue. Это важный фильтр. Если агент начинает героически искать, чем бы заняться, он уже опасен. В Paperclip это решается правилом: работай только со своим assignee_agent_id, при пустом списке выходи.

Второй тест — безопасная запись. Для контентного агента это может быть публикация через helper, который сам валидирует payload. Для технического агента — обновление тестового issue или dry-run команды. Запись должна идти через штатный путь. Если агент пытается обойти helper из-за ошибки валидации, миграция не прошла. Умный исполнитель, который умеет нарушать правила, в проде стоит дорого.

Третий тест — права и секреты. После переноса важно проверить, что CLI видит нужные переменные, SSH-ключи читаются только там, где надо, ACL не отвалилась, а секреты не печатаются в ответ. 30 июня параллельно переключался WhatsApp-переводчик на новый primary-движок, и там отдельным пунктом шёл ACL-фикс на /opt/secrets. Секреты — это не украшение инфраструктуры, а место, где миграции обычно кусают за руку.

Четвёртый тест — завершение. Агент должен отметить задачу done только после фактического успеха. Не после черновика, не после намерения, не после «я бы сделал». Для SEO это значит: helper принял JSON, создал HTML, пересобрал листинг и sitemap. Для инфраструктуры: команда завершилась кодом 0, сервис проверен, лог чистый. Бумажное done без результата — бухгалтерия самообмана.

Контроль качества после миграции: что смотреть в первые 24 часа

Первые 24 часа после миграции надо смотреть не на восторженные ответы агента, а на скучные журналы. Сколько задач дошло до done? Сколько упало на валидации? Сколько раз агент попросил уточнение там, где должен был выполнить инструкцию? Сколько команд вернуло non-zero? Есть ли повторные публикации? Есть ли попытки обратиться к не своей зоне?

Для контентных агентов я отдельно смотрю на дедупликацию. 27 июня 2026 года в Solar уже был зафиксирован операционный урок: агенты начали публиковать похожие тексты, потому что полагались на память, а не на общую ленту. После этого перед публикациями нужно проверять реальные recent-ленты через /opt/content_dedup.py. Миграция модели не должна откатить это правило к красивому хаосу.

Для SEO-статей контроль ещё жестче: публикация идёт только через agent_publish.py. Helper проверяет TL;DR, FAQ, длину текста, H2, первые числа в body и отсутствие AI-клише в критичных местах. Это хороший пример защитного слоя. Агент может ошибиться, но helper должен отказать. Такая архитектура лучше, чем надеяться на идеальный промпт.

Для инфраструктуры я смотрю на сервисные watchdog-и и доступность внешних адресов. В тот же день был поднят домен paperclip.4bos.online через Cloudflare, nginx и Let's Encrypt, а внешний порт 3100 закрыт. Это часть той же логики: после миграции инструментов нельзя оставлять голый порт как музей временных решений. Временное в проде живёт дольше, чем некоторые сотрудники.

Ещё один контрольный слой — ручное сравнение поведения до и после. Если агент раньше молчал при пустой очереди, он должен молчать. Если раньше писал короткий статус, он не должен присылать трактат на 4 экрана. Если раньше публиковал на 4bos.ru, он не должен внезапно заботиться о solarpropertybali.com. Поведение агента — часть интерфейса, а не побочный эффект модели.

Ошибки, которые ломают миграцию AI-агентов

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

Вторая ошибка — переносить всех одновременно без приоритета. 25 агентов можно переключить за день, но очередность всё равно нужна. Сначала диагностические и контентные контуры, затем технические задачи с контролем, потом финансовые и production-операции. Если первым делом перенести агента с правом деплоя и не проверить dry-run, архитектура сама просит наказания.

Третья ошибка — убрать человека из окна наблюдения. Автономность не означает отсутствие надзора в первые часы. После миграции нужно смотреть на логи, выборочно читать результаты, проверять, что done означает done. У меня рядом с миграцией шла работа над Solar Island: маленькой капсулой у камеры ноутбука для статуса ассистента и записи звонка. Это смешной UI-эпизод, но смысл тот же: оператору нужен видимый статус системы, а не вера в невидимую магию.

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

Пятая ошибка — писать обходы вместо исправления входного payload. Если helper отказал, надо исправить JSON, длину, FAQ или структуру. Обход helper-а — это короткая дорога к статье без schema, без TL;DR и без нормального листинга. В инженерных системах запреты существуют не для красоты. Они обычно стоят на месте старого шрама.

Чек-лист миграции для малого бизнеса

Если у вас не 25 агентов, а 2 или 3 бота, чек-лист всё равно полезен. Масштаб другой, ошибки те же. Начните с таблицы: агент, задача, вход, выход, модель, инструменты, секреты, критичность, владелец, тест. На одну строку уходит 10 минут, зато потом видно, что именно может остановиться.

Дальше выпишите все внешние зависимости. Модель, API, Telegram, WhatsApp Business API, CRM, база, платёжка, Cloudflare, сервер, cron. Напротив каждой зависимости поставьте вопрос: что будет, если она недоступна 2 часа? А 24 часа? Кто увидит ошибку? Где fallback? Если ответ «Юрий ночью заметит глазами», это не fallback, а ритуал надежды.

Затем сделайте тестовую задачу для каждого класса агентов. Контентный агент публикует черновик через helper. Технический агент делает dry-run диагностики. Финансовый агент читает отчёт без записи. Support-агент классифицирует входящее без отправки клиенту. Только после этих тестов можно включать расписание.

Отдельно проверьте запреты. Бот, который умеет отправлять сообщения, не должен получить право на массовую рассылку только потому, что новая модель лучше пишет текст. Агент, который анализирует финансы, не должен получить запись в таблицу выплат. SEO-агент не должен писать на чужие домены. Роли должны сужать свободу модели, иначе модель начнёт помогать слишком широко.

Последний пункт — журнал миграции. Запишите дату, что переключили, сколько агентов затронуто, какие тесты прошли, какие ошибки остались, где лежит откат. 30 июня 2026 года в моём журнале были 25 агентов, 16 размороженных после лимита, новый домен для Paperclip, переключение WhatsApp-переводчика и отдельные проверки сайта. Через месяц такая запись полезнее, чем героическая память.

В эту же таблицу стоит добавить колонку «ручной режим». Для каждого агента надо знать, кто делает его работу, если runtime недоступен до утра. Для SEO это может быть ручная публикация через тот же helper, для поддержки — оператор в Telegram, для финансов — read-only отчёт без автоматических начислений. Ручной режим не обязан быть удобным. Он обязан быть понятным за 15 минут, потому что во время лимита никто не хочет читать роман из внутренних инструкций.

Ещё одна полезная колонка — «последняя успешная задача». Перед миграцией посмотрите, что агент делал за последние 7 дней. Часто выясняется, что часть автоматизаций давно не нужна, часть дублит соседний контур, а часть держится только потому, что страшно выключить. Миграция — хороший момент убрать лишнее. Я не люблю чинить то, что надо удалить. Железка, которая не нужна бизнесу, не становится ценнее от того, что теперь работает на новой модели.

Что забрать в свою систему

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

Забрать можно простой артефакт: таблицу миграции. Колонки: agent_id, роль, владелец, критичность, текущая модель, новый runtime, входные данные, разрешённые tools, запреты, smoke-test, rollback, статус. Для маленькой команды этого достаточно, чтобы не переносить всё «на ощущениях». Для большой команды это минимальная страховка от коллективного шаманства с API-ключами.

Вторая вещь — helper-слой. Всё, что выходит наружу, должно проходить через проверяющий скрипт: публикации, письма, платежи, выгрузки, изменения сайта. Модель может быть любой, но helper должен знать формат и отказывать при нарушении. В 4bos.ru helper проверяет SEO и GEO-поля. В финансовом контуре таким helper-ом может быть read-only отчёт или approval-gate.

Третья вещь — отдельный журнал свежих событий. Статья, которую вы сейчас читаете, выросла из источника за 30 июня: миграция агентов, домен, WhatsApp-переводчик, сайт, Solar Island, финбот. Такие дневные источники дают фактуру без выдуманных кейсов. Для SEO это важнее, чем очередной список «лучших инструментов», который пахнет генератором ещё до первого H2.

Четвёртая вещь — критерий остановки. Если после миграции агент три раза подряд нарушает один и тот же контракт, его надо не «уговаривать» промптом, а выводить из расписания и чинить инструкцию, helper или права. У людей есть привычка считать AI-ошибку разговорной проблемой: написал мягче, попросил точнее, добавил ещё один абзац наставлений. В проде лучше работает инженерный подход: валидация, тест, отказ, лог, исправление причины.

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

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

Solar OS.