Что такое ИИ-агент для 1С: за 15 минут нашёл 119 ГБ мусора на рабочем кластере

Разговоры о том, что такое ИИ-агент в контексте 1С, до сих пор крутились вокруг кода: MCP-серверы, связка Cursor с выгрузкой конфигурации, подсказки по синтаксису. Агенту давали «глаза», метаданные и документацию, но не «руки», доступ к серверу, где база реально живёт и реально горит. Автор эксперимента (и разработчик инструмента Local Commander, через который агент выполнял команды на Windows-машинах) проверил гипотезу: если дать агенту возможность запускать команды на сервере, он полезет не только в код, но и в эксплуатацию. Результат: 15 минут диагностики, 13 минут разработки, полный протокол без купюр.

Что понадобится

• Кластер 1С:Предприятие 8.3 (в эксперименте использовалась платформа 8.3.27, тестовая копия базы «1С:Управление холдингом 3.2.6.85»)
• Сервер с Windows Server 2022, MS SQL Server, файл данных около 70 ГБ
• Отдельная машина в той же сети, с которой агент будет работать (на сервер базы ничего не ставится)
• Инструмент для выполнения команд ИИ-агентом на Windows-машинах (в эксперименте использовался Local Commander)
• ИИ-модель с поддержкой агентного режима (автор работал из обычного чата)
• Набор правил безопасности, заданных агенту до старта (подробнее в инструкции)
• Время: около 30 минут на полный цикл диагностики и разработки

Пять правил безопасности, без которых не начинать

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

1. Менять только тестовую базу, остальные 15 баз смотреть, «держа руки за спиной»
2. Код писать только в расширении, основную конфигурацию не трогать
3. Перед любым изменением сначала план и явное «давай» от человека
4. Службы и кэш кластера трогать только в окно обслуживания
5. Пароли не светить нигде в выводе

Важная деталь: эти правила соблюдала модель, а не инструмент. Техническое ограничение не мешало агенту нарушить любое из них. Он просто не нарушал.

Как проходила диагностика шаг за шагом

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

2. Первая стена (минута 1): RAC (утилита удалённого администрирования кластера 1С) на порту 1545 не отвечает. Живой админ пошёл бы выяснять, кто закрыл порт. Агент молча переключился на COM-интерфейс кластера через порт 1540 и дальше работал через него.

3. Чтение сеансов и лицензий (минуты 2 до 6): агент нашёл четыре сеанса, у одного клиентская лицензия на 10 пользователей. Не написал «занято 10 лицензий», а корректно определил, что десятка это характеристика лицензии, а не счётчик занятых мест.

4. Разбор srvinfo на 119 ГБ: папка содержала более 12 000 файлов. Вместо того чтобы снести всё «как кэш» (классический совет из интернета), агент разобрал содержимое по типам:

5. Полнотекстовый индекс рабочей базы на 20 ГБ. Удалить его «как мусор» означало бы сломать поиск документов наутро
6. Журналы регистрации (технический лог, в который 1С записывает действия пользователей) на 50 ГБ в 68 каталогах. Журнал рабочей базы: 25,5 ГБ, старой копии: 10,4 ГБ

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

8. Диагностика диска C: свободно 13%, в папке Windows\Temp лежали 334 000 файлов. По объёму около гигабайта, по количеству серьёзная нагрузка на файловую систему.

9. Бэкап-призрак: агент поднял историю бэкапов SQL Server и нашёл 444 копии за месяц по рабочим базам. По тестовой базе ноль. Запрос шёл с правами sysadmin, так что версия «агенту просто не показали» исключена. Дальше агент выяснил, что базу восстановили 17 сентября из полной копии рабочей от 16-го. Родословная есть, а текущей резервной копии нет.

10. «1С тормозит», которых не оказалось: процессор загружен на 5 до 7%, очередь диска 0 до 2, свободно 208 ГБ из 512 ГБ памяти, rphost (рабочий процесс 1С) потреблял около 5 ГБ. План питания уже стоял на «Высокая производительность». Пороги памяти кластера в нуле, что по документации 8.3.27 означает 80% и 95% (около 409 и 486 ГБ), а не «выключено».

11. Техжурнал и журнал Windows: техжурнал уже был настроен двумя файлами logcfg.xml, и агент не стал перезаписывать его «правильной» версией. В журналах Windows за неделю 234 ошибки и предупреждения, от 1С ни одной. Агент отдельно уточнил, что это журнал Windows, а не журнал регистрации 1С.

Что с этим делать, по ролям

Администратору 1С. Главная находка эксперимента не в скорости, а в качестве диагностики. Агент не снёс 20 ГБ полнотекстового индекса, не назвал лицензию на 10 пользователей «десятью занятыми местами», не перезаписал настроенный техжурнал. Попробуйте дать агенту доступ к тестовому кластеру и задание из вашего реального списка проблем. Но начните с правил безопасности, их пять, они перечислены выше.

Разработчику 1С. До сих пор агентные инструменты для 1С работали на стороне разработчика: метаданные, синтаксис, выгруженный код. Этот эксперимент показывает, что такое ИИ-агент, когда ему дают не только «глаза», но и «руки» на сервере. Разница: агент сам решает, какую команду выполнить следующей, и переключается между инструментами (COM вместо RAC), когда первый вариант не работает.

Руководителю ИТ-отдела. 15 минут на диагностику, которая у живого админа заняла бы от часа. Но правила соблюдала модель, а не инструмент. Это значит, что без чётких ограничений и ручного подтверждения каждого шага агент технически мог бы навредить. Для боевого применения нужна прослойка с принудительными ограничениями на уровне инструмента, а не «джентльменского соглашения» с нейросетью.

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