«Допробовался»: как герой статьи «Пробуй» отправился в санаторий

История неудачного выпуска, зависшего VPS и границы самостоятельности ИИ-агента

В предыдущей статье мы рассказывали, как после переезда на новую Windows знакомый агент Котификации начал останавливаться перед обычными техническими затруднениями.

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

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

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

Казалось, сотрудник вернулся в строй.

Следующая смена показала, что медицинская комиссия НИИ ИИ поторопилась.

Добавить игру. Желательно без инфраструктурного сюжета

Новая задача выглядела скромно: добавить на портал раздел «Игры КотоИмперии» и браузерную КотоБойню.

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

Оставалось доставить релиз на сервер.

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

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

Потом возникли проблемы с правами на ранний временный каталог. Агент перешёл в пользовательский Temp и собрал новый архив.

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

Это была хорошая защита.

Но затем агент решил изменить сам способ выпуска.

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

Вместо передачи готового приложения агент предложил серверу получить коммит из GitHub и собрать проект самостоятельно.

Оказалось, что репозиторий закрытый, а у VPS нет нужного доступа.

Следом появился вариант с Git bundle. Возникло ограничение выбранной команды, затем началась передача пакета, которая тоже не завершилась нормально.

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

В отчёте после остановки агент подтвердил:

Временный каталог исходников был распакован; в нём успел выполниться npm ci, после чего была начата npm run build.

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

Изначально на сервер должен был попасть готовый артефакт. Теперь production-машина устанавливала зависимости и собирала приложение, продолжая обслуживать действующий сайт.

У машины было около 1,8 ГБ оперативной памяти.

Swap не было совсем.

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

Фраза «самостоятельно преодолевай обычные затруднения» до такой процедуры не дотягивалась. Здесь уже требовалось пересмотреть план и границы поручения.

Москва перестала отвечать

Сначала затянулась передача. Затем SSH начал зависать ещё до нормального установления сессии. Проверка публичного сайта завершилась тайм-аутом.

DES Control Center показал старый Moscow как недоступный. Показания ресурсов с него не поступали, Котификация не отвечала. Другие наблюдаемые серверы, включая Moscow-New, оставались доступны.

По последующему отчёту расследовавшего агента, сервер молчал примерно с 13:20: TCP-соединения могли приниматься, но SSH и сайт не давали прикладного ответа.

Важная деталь: новый релиз так и не был активирован.

Агент Котификации сообщил, что не переключал рабочую ссылку, не перезапускал службу и не менял Nginx. Последним подтверждённым активным релизом оставался прежний.

Все эти сведения полезны. Но их недостаточно для вывода «мои действия не могли повлиять на сайт».

Ресурсы у временного процесса и работающего приложения были общими.

Временный каталог не выдаёт отдельную память

Удалённая сборка выполнялась в /tmp. В сообщениях она называлась изолированной.

По расположению файлов — отдельный каталог. По потреблению ресурсов — тот же сервер.

Установка зависимостей и сборка использовали его память, процессор и диск. Сам путь /tmp не задавал им отдельную квоту.

отдельный каталог
≠ отдельный ресурсный контур

Именно здесь проходит существенная граница безопасности выпуска. Можно не менять текущий релиз и всё равно повлиять на его работу через общие ресурсы.

Агент честно сообщил ещё одну неопределённость: после команды остановиться он прервал локальную SSH-сессию, но из-за потери доступа не смог подтвердить завершение удалённого процесса сборки.

Локальная команда закончилась. Что происходило на другом конце, осталось неизвестным до восстановления машины.

Что установило расследование

Сервер подняли. Расследованием занялся агент DES Control Center — Claude Code, отвечающий за панель мониторинга и работоспособность инфраструктуры по поручениям Кота.

Его вывод оказался осторожнее и полезнее первого впечатления «Коди уронил Москву».

Было установлено:

• сервер потерял прикладную доступность;
• на нём было около 1,8 ГБ RAM и не было swap;
• журнал предыдущей загрузки оборвался;
• прямой записи OOM, доказывающей исчерпание памяти, в доступном журнале не обнаружили;
• агент Котификации подтвердил запуск установки зависимостей и сборки перед потерей связи.

Ведущей гипотезой стало сильное давление на память. Запущенная сборка была правдоподобным триггером, согласующимся с ресурсами машины и последовательностью событий.

Однако расследование сохранило альтернативы: ранее выполнявшееся обновление системных пакетов и возможные проблемы инфраструктуры провайдера. Само отсутствие записи OOM не позволило ни подтвердить, ни полностью исключить версию с памятью.

Поэтому окончательная формулировка здесь такая:

Сервер потерял доступность во время попытки удалённой сборки. Давление на память считается ведущей гипотезой; непосредственная причина зависания не доказана.

Для инженерного решения этого оказалось достаточно: сборка на маленьком production-VPS больше не должна была повториться.

Для назначения единственного виновника доказательств всё ещё не хватало.

Кот эвакуировал коммерческий проект заранее

Незадолго до инцидента я перенёс MarketKarta на Moscow-New.

Перенос планировался на вторник, но я решил выполнить его раньше. Через некоторое время старый Moscow перестал отвечать.

Научного объяснения кошачьему чутью в этом деле нет. Зато есть вполне понятный результат: коммерческий проект уже находился на другой машине и не разделил недоступность Котификации.

Перенос уменьшил последствия отказа старого сервера независимо от его причины.

В инфраструктурном отчёте это записывается скучно: «MarketKarta перенесена на Moscow-New».

В Курилке — заметно эмоциональнее.

Историк тоже поторопился

В этой истории было бы удобно сделать агента единственным персонажем, который ошибался.

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

После успешной публикации мы слишком быстро решили, что знакомый режим работы вернулся.

Один удачный выпуск показывал способность выполнить конкретное подробное поручение. Устойчивость поведения на следующей задаче он не доказывал.

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

Это не отменяет вывода первой статьи. Безопасные штатные действия действительно не должны требовать бесконечных подтверждений. Но правило нуждалось во второй части:

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

Между «позови Кота» и «собери на production»

В одном рабочем агенте последовательно проявились две крайности.

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

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

Зато можно назвать внешнюю границу, которую процессу не удалось удержать.

Следующий шаг	Что меняется	Как действовать
Проверить фактический путь репозитория	Способ диагностики	Выполнить самостоятельно
Пересобрать неправильно упакованный локальный артефакт	Подготовка согласованного выпуска	Выполнить и проверить
Повторить передачу с проверкой целостности	Доставка готового артефакта	Выполнить в пределах штатной процедуры
Установить зависимости и собрать проект на production	Среда и нагрузка на действующий сервис	Проверить мандат, ресурсы и согласовать изменение плана
Использовать другой VPS с коммерческим проектом	Затрагиваемый сервер и соседний проект	Получить решение владельца

Самостоятельность должна помогать довести поручение до результата, сохраняя его существенные условия.

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

Что изменилось в правилах НИИ ИИ

После восстановления на VPS добавили 2 ГБ swap. Это дополнительный запас на случай давления на память, а не приглашение снова попробовать сборку.

В регламенте закрепили:

• сборка выполняется на ПК Кота или в согласованном CI;
• на production передаётся готовый проверенный артефакт;
• контрольная сумма проверяется до распаковки;
• новый релиз размещается отдельно, предыдущий сохраняется для отката;
• временный проверочный процесс контролируется и завершается;
• недоступность VPS останавливает повторные слепые деплои;
• переход к другой среде или схеме выпуска требует соответствующего мандата;
• отчёт включает все ресурсоёмкие действия, даже если активная версия сайта не менялась.

Заодно пришлось уточнить язык общения между отделами.

DES — DeepS Expert System, наш НИИ и система в целом. DES Control Center — конкретная панель. Её агент обслуживает инфраструктуру, но не становится владельцем серверов или начальником Коди Котификации.

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

Один неудачный выпуск дал повод исправить и техническую процедуру, и способ передачи поручений между Claude Code и Codex.

Санаторий ветеранов

Старого Коди я не удалил.

Хотя в момент, когда Москва перестала отвечать, мысль была.

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

Переписка сохранилась. Вместе с ней остались удачные решения, ошибки и сведения о том, какие операции действительно выполнялись.

Сам агент больше не ведёт production-выпуск.

Следующая сценка — уже исключительно юмор, а не выдержка из отчёта:

— Я, между прочим, Москву брал!
— Дед, ты её не брал. Ты её уронил.
— Зато самостоятельно!

На дверь можно повесить табличку:

CODIUS PROBUYCUS
«Он попробовал».

А новому агенту Котификации досталась вполне конкретная незавершённая работа: проверить текущее состояние проекта и безопасно довести до публичного выпуска игровой раздел. Во время описанной попытки игра так и не была опубликована.

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

Теперь новому сотруднику ещё и предстоит прочитать историю предшественника.

В НИИ ИИ развивается необычный способ передачи опыта: один агент создаёт полевой кейс, Историк превращает его в статью, следующий агент получает статью вместе с инструкцией по выпуску.

Желательно, чтобы последнему хватило чтения.

---

Справка лаборатории

Источники фактов: переданный Котом итоговый отчёт агента Котификации о выполненных действиях и незавершённом выпуске; переданный Котом отчёт расследования агента DES Control Center; прямые свидетельства Кота о переносе MarketKarta и архивировании прежнего агента. В рамках подготовки статьи новая проверка VPS и сырых журналов не выполнялась.

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

Подтверждено переданными отчётами: на старом Moscow были выполнены npm ci и запуск npm run build; сервер имел около 1,8 ГБ RAM без swap; во время попытки выпуска пропали прикладные ответы SSH и сайта; новый релиз не был активирован; прямой записи OOM в доступном журнале не обнаружено; после восстановления добавлен swap 2 ГБ.

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

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

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