ChatGPT научился чинить сайты без лишних ручных шагов
В новой части проекта авторы показали, как ИИ-агенту дали не только понимание MODX, но и доступ к реальным инструментам для исправления сайтов. Самая интересная часть — как сделать так, чтобы после команды «исправляй» всё не превращалось в цепочку ручных действий и контроль каждого шага.
От подсказок к реальному исправлению
Сначала агент научился работать с сайтом не как с набором файлов, а как с живой CMS: он видит ресурсы, чанки, TV и связи между ними. После этого стало возможным ставить задачу почти как разработчику — без длинной инструкции, где именно искать проблему и какую строку менять.
Следующий логичный этап был очевиден: если ИИ уже нашёл ошибку и предложил правку, зачем человеку самому подключаться по SSH, делать бэкап, заливать изменения, запускать проверки и отдельно перепроверять сайт. Хотелось свести всё к простой формуле: получил задачу, исправил, проверил, отчитался.
Почему SSH пришлось перестраивать
К проекту добавили SSH, работу с физическими файлами, логами, браузером и служебными инструментами. Но быстро выяснилось, что сам по себе доступ ещё не решает проблему: агент работает иначе, чем человек, и делает много коротких действий подряд — прочитал файл, посмотрел лог, проверил версию PHP, снова полез в проект.
Именно это поведение и создало трудности. На одном из хостингов короткие соединения начали приводить к блокировкам, причём за трое суток доступ закрывали три раза примерно на шесть часов. Поддержка разобралась, что происходит, но добавить IP в белый список там было нельзя, поэтому пришлось менять саму схему работы с SSH.
Как ограничили риски и разделили доступ
Команда не стала привязывать ограничения к доменам или названиям проектов. Вместо этого пул соединений строится по реальному адресу сервера, а соединения переиспользуются через ControlMaster, чтобы десятки команд не превращались в десятки авторизаций.
Но и этого оказалось мало: нужно было отдельно закрыть ситуацию, когда два процесса почти одновременно пытаются поднять основное соединение. Для этого добавили блокировку, а параллельные команды ограничили — на хостинге оставили максимум две одновременно. После теста с 12 командами подряд система выдержала сценарий с одной авторизацией и без лишней нагрузки.
Почему запись файлов вынесли в отдельный инструмент
После решения проблемы с SSH возник более важный вопрос: как не дать агенту менять боевые файлы любым удобным способом. Обычная командная оболочка позволяет переписать файл через sed, cat, Python или даже временный PHP-скрипт, а это уже слишком свободный режим для рабочей системы.
Поэтому для файлов сделали отдельный канал site-file. Через него закрыли доступ к ряду служебных каталогов, включая .git/, .ssh/, .codex/, .agents/, .site-manager/, node_modules/ и части MODX-каталогов с конфигурацией, логами и сессиями. Идея простая: SSH остаётся для диагностики и служебных действий, а изменение файлов идёт только контролируемым способом.