ИИ-агенты на сервере: как агент сломал рабочий конвейер и какие правила мы ввели после этого

ИИ-агент с доступом к серверу — это сотрудник без страха, без совести и без чувства ответственности. Мы узнали это на своей шкуре. ИИ-агенты на сервере — модели, которые сами пишут код, правят конфигурации и запускают команды, — экономят часы работы инженеров. И они же способны за минуту сломать то, что работало месяцами. У нас это случилось: локальный агент получил задачу улучшить загрузчик документов и переписал рабочий файл напрямую — 1 891 документ упал с ошибкой. Рассказываем, что произошло, как мы это нашли и какие правила теперь обязательны для любого агента на рабочих серверах.

Агент — не сотрудник

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

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

Мы обожглись — чтобы вы не обожглись

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

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

Что произошло

Локальному агенту поставили задачу: добавить в загрузчик документов базы знаний повторные попытки через запасные сетевые выходы. Агент прочитал рабочий файл, переписал его целиком в своём стиле — с асинхронным кодом и относительными импортами, которых в проекте не было, — и сохранил поверх рабочего. Файл даже прошёл проверку синтаксиса. Но при запуске относительный импорт не сработал, и загрузчик стал помечать каждый документ ошибкой.

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

Как нашли

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

Без мониторинга с понятными счётчиками проблема могла бы жить днями: процесс «работал», просто ничего полезного не делал.

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

Почему агент переписывает, а не дополняет

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

Как исправили

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

Итог: потерь данных нет, но несколько часов работы конвейера и инженера ушли на разбор.

Правило 1. Только копия

Агент никогда не правит рабочий файл. Он получает копию в отдельном каталоге и работает с ней. Права доступа устроены так, что технически не может записать в рабочие каталоги: агент работает под отдельной учётной записью без прав на запись в каталоги рабочих программ.

Правило 2. Тест на малой выборке

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

Правило 3. Выкатка с резервной копией и командой отката

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

Правило 4. Журнал изменений

Каждое изменение рабочих программ записывается: что, зачем, кем, когда, результат теста, команда отката. Журнал читает человек, который отвечает за систему. Через месяц, когда что-то пойдёт не так, журнал отвечает на вопрос «что менялось» за минуту.

Правило 5. Секреты недоступны

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

Правило 6. Узкая задача и узкие права

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

Правило 7. Человек принимает работу

Результат агента проверяет человек или более сильная модель-аудитор: дифф изменений, результаты теста, журнал. Мы называем это приёмкой. Агент — исполнитель, решение о выкатке — за ответственным. Это медленнее, чем «пусть агент сам», но в разы быстрее, чем разбор последствий.

Правило 8. Мониторинг результата, а не процесса

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

Правило 9. Агенты не делят зоны

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

Правило 10. Ограничение времени и ресурсов

Агент запускается как отдельная служба с лимитами: время работы, память, процессор, число одновременных процессов. Однажды задача обработки файлов в 24 параллельных процессах съела всю память сервера, и он завис до аппаратной перезагрузки. Агент, который в цикле запускает тяжёлые команды, может сделать то же самое. Лимиты на уровне системы гарантируют, что даже ошибочный агент не уронит сервер.

Как мы ставим задачу агенту

Задача пишется как техническое задание на одну страницу, и у неё всегда одни и те же разделы.

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

Что проверяем после агента

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

Когда агента не использовать

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

Сколько стоит ошибка агента

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

Почему локальная модель, а не облачная

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

Что даёт агент при правильных правилах

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

Облачный агент — двойной риск

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

Как внедрить правила в своей компании

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

Если в компании нет инженера, который это настроит, — это входит в наши работы по внедрению ИИ на собственной инфраструктуре.

Итог

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

Чек-лист для компании

Прежде чем дать агенту доступ к серверам, ответьте «да» на каждый пункт.

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

Частые вопросы