Подключить ИИ к серверу: как ИИ-агент развёртывает изменения и управляет вашим сервером

Большинство людей до сих пор используют ИИ как очень эрудированного коллегу, с которым общаются по телефону: человек описывает проблему с сервером, получает предложенную команду, копирует её в консоль, копирует сообщение об ошибке обратно и повторяет этот цикл, пока всё не заработает. Как только вы подключаете ИИ к своему серверу, этот обходной путь больше не нужен. ИИ-агент вроде Claude Code, OpenAI Codex CLI или Gemini CLI сам входит на сервер по SSH, читает логи, проверяет конфигурацию, вносит изменения, тестирует результат и записывает, что он сделал. Вы ставите задачу и одобряете шаги, которые нельзя отменить.

Эта статья представляет собой отчёт из практики. В KernelHost уже несколько месяцев ИИ-агент ежедневно участвует в работе над нашей собственной инфраструктурой: клиентским порталом, мониторингом, приёмом платежей, документацией. Мы покажем, как устроено соединение между агентом и сервером, по какому регламенту агент выполняет развёртывание на производственных системах, какие правила не дают чему-либо пойти не так или утечь наружу и что должен предоставлять сервер, чтобы всё это работало. Базовые сведения об инструментах и архитектурах приведены в статье Сервер под управлением ИИ: безопасное подключение ИИ-агентов, а установка на сервер описана в руководстве по Claude Code и Codex CLI.

Подключить ИИ к серверу: что это значит

Подключить ИИ к серверу означает дать ИИ-агенту собственный контролируемый доступ к командной строке сервера, обычно через SSH-ключ. С этого момента агент может не только предлагать команды, но и сам выполнять их, читать вывод и определять по нему следующий шаг. Сама языковая модель по-прежнему работает у провайдера (Anthropic, OpenAI или Google), а на вашем компьютере или сервере работает только лёгкий инструмент командной строки, который отправляет команды.

Главное здесь слово «контролируемый». Агент с доступом к серверу не автопилот, а очень быстрый сотрудник, который спрашивает перед каждым вмешательством в систему. Сколько ему разрешено делать без согласования, вы решаете сами: от доступа только на чтение до самостоятельной установки обновлений по строгому регламенту.

Чат-бот или агент: разница в одной таблице

Так полчаса переписки туда и обратно часто превращаются в несколько минут, а источник ошибок «неправильно перепечатал» исчезает полностью.

Что ИИ-агент делает на сервере: примеры из нашей работы

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

Развёртывания с резервной копией и путём отката

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

Поиск неисправностей: от симптома к причине за минуты

«Из нашего офиса сайт недоступен, а вне офиса открывается». Раньше это означало бы долгие поиски. Агент проверяет правила файрвола, ищет адрес офиса в журналах защитного ПО, находит сработавшее правило и объясняет, какой запрос его вызвал. Решение о том, что делать, остаётся за нами, а вот детективную работу берёт на себя агент. При типичных ошибках веб-сервера вроде 502 Bad Gateway или переполненного диска он действует так же: изучает вывод journalctl и логи приложения, выдвигает гипотезу и подтверждает её, прежде чем что-либо менять.

Мониторинг, который агент строит сам

Значительная часть нашего мониторинга создана совместно с агентом: небольшие проверочные скрипты, которые каждые несколько минут по cron-заданию проводят сквозную проверку службы и при сбое отправляют сообщение на телефон, например через Telegram-бота. Агент пишет скрипт, тестирует его на специально вызванном сбое, настраивает cron-задание и документирует, как заглушить оповещение. Как выстроить нечто подобное в принципе, описано в статье Настройка мониторинга сервера.

Обзоры и наведение порядка

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

Документация, которая растёт сама собой

Каждое изменение завершается записью в журнале изменений и, если нужно, дополнением в руководстве по эксплуатации. У агента на это уходят секунды, а нам это потом экономит часы, потому что на вопрос «Почему здесь всё устроено именно так?» есть письменный ответ.

Преимущества, когда ИИ работает прямо на сервере

• Скорость: агент за секунды прочитывает то, на что человеку нужны минуты, и сразу проверяет гипотезу, вместо того чтобы сначала её описывать.
• Тщательность: он читает всю конфигурацию вместе с подключёнными файлами и строки лога вокруг ошибки, а не только фрагмент, который кто-то посчитал важным.
• Неизменный порядок действий: резервная копия, проверка синтаксиса и контроль выполняются каждый раз, и в пятницу вечером, и при двадцатом мелком изменении.
• Документация без лишних усилий: каждое изменение описано вместе с причиной, местом хранения резервной копии и путём отката.
• Автоматизация без изучения скриптовых языков: проверочные скрипты, cron-задания и отчёты создаются по описанию обычным языком и тестируются перед вводом в эксплуатацию.
• Обучение попутно: агент объясняет, что он делает и почему. Кто следит за его работой, через несколько недель заметно лучше понимает свой сервер.

Три архитектуры и какую из них используем мы

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

Наш выбор: агент на рабочем компьютере, серверы по SSH

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

Руководство: подключение ИИ-агента к серверу по SSH

Следующие семь шагов одинаково работают с Claude Code, Codex CLI и Gemini CLI. В примерах используются адрес из диапазона для документации 203.0.113.10 и имя пользователя deploy, замените их своими значениями. Предварительное условие: сервер со входом по SSH-ключу, как описано в статье Защита SSH и настройка входа по ключу.

Шаг 1: создать отдельный SSH-ключ только для агента

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

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ключ Ed25519 короткий, быстрый и считается надёжным. Комментарий ki-agent позже появится в authorized_keys на сервере и позволит узнать ключ с первого взгляда.

Шаг 2: разместить открытый ключ на сервере

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Чтобы ещё сильнее ограничить доступ, добавьте опции перед ключом в файле ~/.ssh/authorized_keys на сервере. from= разрешает вход только с определённого адреса, а no-agent-forwarding и no-port-forwarding не дают использовать соединение в качестве трамплина:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Если после этого сервер отвечает Permission denied (publickey), поможет статья Исправление ошибки SSH Permission denied (publickey).

Шаг 3: создать алиас хоста в конфигурации SSH

Благодаря алиасу агенту достаточно знать короткое имя, и он всегда использует правильный ключ:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

После этого достаточно команды ssh web-prod "systemctl status nginx". IdentitiesOnly yes не даёт SSH перебирать другие ключи из вашей связки ключей. Для каждого следующего сервера создайте отдельный блок, для тестовых и производственных систем лучше с разными именами, например web-test и web-prod, чтобы путаница была заметна уже по имени.

Шаг 4: установить агента и войти

Claude Code, Codex CLI и Gemini CLI работают на Linux, macOS и Windows, а вход в них выполняется с учётной записью провайдера или с API-ключом. Установка и вход без браузера описаны в пошаговом руководстве. Для варианта с рабочим компьютером установите инструмент на свой компьютер, а не на сервер.

Шаг 5: задать правила, которым следует агент

Все три инструмента при запуске читают файл правил в рабочем каталоге: у Claude Code это CLAUDE.md, у Codex CLI AGENTS.md, у Gemini CLI GEMINI.md. В нём описано, как ведётся работа на ваших серверах. Проверенная отправная точка:

# Правила работы на серверах

- Перед каждым изменением создавать датированную резервную копию за пределами веб-каталога.
- Перед развёртыванием проверять синтаксис (nginx -t, php -l, apachectl configtest).
- После развёртывания проверять службу, лог и функцию и сообщать результат.
- Никогда не выводить пароли, API-ключи и токены, никогда не копировать их в файлы.
- Удаление, изменения в базах данных и всё необратимое только после явного одобрения.
- Не изменять напрямую файлы, которыми управляет панель управления.
- После теста удалять тестовые файлы.

Правила растут вместе с работой. Каждый раз, когда агент делает что-то не так, как вы хотите, исправление нужно внести в этот файл в виде правила. Через несколько недель он работает так, как работали бы вы сами.

Шаг 6: настроить одобрения и белый список

По умолчанию инструменты спрашивают перед каждой командой, которая что-то меняет. На первых порах это правильно. Команды на чтение, которые вы постоянно подтверждаете, можно разрешить. В Claude Code это делается в файле .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

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

Шаг 7: первая задача только на чтение

Начните с задач, которые ничего не могут изменить, и понаблюдайте, как действует агент:

Проверь на web-prod ошибки nginx за последние 24 часа и назови три
самые частые причины, для каждой с подтверждением из лога. Ничего не меняй.

Только когда результаты анализа верны, наступает очередь небольших изменений, например новой ротации логов или systemd-службы, и лишь после этого развёртываний на производственной системе.

Как агент выполняет развёртывание: наш регламент для каждого изменения на производственной системе

ИИ-агент вправе выполнять развёртывание на производственной системе только по строгому регламенту, который включает резервную копию, заранее подготовленный откат и проверку до и после развёртывания. У нас этот регламент выглядит так:

1. Проверить текущее состояние. Файл на сервере сравнивается с последней известной версией. Если его тем временем изменил кто-то другой, агент останавливается и уточняет, вместо того чтобы перезаписать чужое изменение.
2. Создать резервную копию. Затрагиваемые файлы сохраняются в датированный каталог резервных копий за пределами веб-каталога. Резервная копия внутри веб-каталога при определённых условиях могла бы оказаться общедоступной.
3. Подготовить откат. Небольшой скрипт, который одной командой возвращает прежнее состояние, создаётся до изменения, а не в разгар аварии.
4. Проверить синтаксис. Новый файл проверяется до развёртывания: для PHP командой php -l, для nginx командой nginx -t. Так синтаксическая ошибка вообще не попадает на производственную систему.
5. Развернуть с правильными правами. Владелец, группа и права доступа к файлу переносятся с прежней версии. После синтаксических ошибок неправильные права являются самой частой причиной сбоев после обновления.
6. Тестировать без побочных эффектов. Тестирование идёт в режиме чтения, на вымышленных тестовых данных или в изолированной среде и никогда на реальных заказах или реальных данных клиентов.
7. Проверить вживую. После развёртывания контролируются HTTP-статус, лог ошибок и изменённая функция.
8. Задокументировать. Журнал изменений и руководство по эксплуатации дополняются, включая место хранения резервной копии и команду отката.

В виде последовательности команд, с условными путями вместо настоящих, это выглядит примерно так:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Почему откат готовят до изменения

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

Тесты, которые ничего не могут сломать

Многие функции невозможно протестировать так, чтобы ничего не произошло: заказ, платёж, электронное письмо. Здесь помогают три приёма. Во-первых, пробные запуски, которые предлагает сам инструмент. Во-вторых, вымышленные идентификаторы, которых гарантированно нигде нет. В-третьих, изолированная среда: процесс, работающий в собственном сетевом пространстве имён без сети (unshare -n), не может ни обратиться к внешнему API, ни случайно что-нибудь купить, но по-прежнему видит локальную базу данных через Unix-сокет. После теста все тестовые файлы удаляются.

Действиям, которые стоят денег, нужна блокировка

Если процесс что-то заказывает, выставляет счёт или удаляет, он не должен выполняться дважды одновременно, даже если кто-то нажал дважды или агент повторил команду. В Linux проще всего использовать flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "уже выполняется"

В приложениях с базой данных ту же задачу решает именованная блокировка (GET_LOCK в MySQL и MariaDB), в API эту роль играет Idempotency-Key, подробнее о нём в разделе о KernelHost API ниже.

Безопасность: доступ для агента без утечек

Опасение, которое мы слышим чаще всего, звучит так: «А что с моими данными?» Честный ответ: всё, что агент читает, он отправляет на обработку языковой модели провайдера. Поэтому с помощью следующих правил вы решаете, что он вообще увидит.

Секретам не место в чате

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

Собственные ключи, собственные права, отзыв в любой момент

Каждый агент получает собственный SSH-ключ, и каждый ключ в authorized_keys можно узнать по его комментарию. Чтобы отозвать доступ, удаляют эту одну строку. Там, где этого хватает, агент работает под собственным пользователем с правилом sudo, которое разрешает только нужные команды. Для API выпускаются отдельные ключи с минимально возможными правами, для чистой аналитики только на чтение.

Одобрения: что никогда не происходит без человека

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

Прослеживаемость: лог, список изменений, резервные копии

Каждая сессия оставляет следы, которые может прочитать человек: датированные резервные копии, скрипт отката, запись в журнале изменений и входы в системном логе. Кто дополнительно ведёт /etc в Git с помощью etckeeper, видит каждое изменение конфигурации в виде diff. Что нельзя проследить, нельзя и откатить. Основой остаётся работающая стратегия резервного копирования, ведь агент не заменяет резервную копию.

Какой сервер подходит для ИИ-агента?

Серверу для управления с помощью ИИ нужны полный root-доступ, вход по SSH-ключу, беспрепятственные исходящие соединения, постоянная защита от DDoS и в идеале API, через который можно автоматически заказывать серверы и управлять ими. GPU ему не нужен, потому что языковая модель работает у провайдера.

Почему KernelHost для серверов под управлением ИИ

В принципе ИИ-агент может работать с любым сервером, на котором он получает shell. Но на практике от окружения зависит, сколько работы вы действительно можете ему передать. На KVM root-сервере или выделенном сервере KernelHost нет урезанных учётных записей, нет препятствий для HTTPS-соединений с ИИ-провайдерами и нет привязки к договору, из-за которой эксперименты обходятся дорого. Постоянная защита от DDoS активна на каждом сервере без доплаты, а для ресурсоёмких задач есть профессиональные root-серверы с выделенными ядрами. Расчёт идёт по модели PrePaid: без договора, без минимального срока, без платы за подключение. Если хотите сначала попробовать, начните с бесплатного тестового сервера.

KernelHost API: ваш агент сам заказывает серверы и управляет ими

Самый большой рычаг находится на уровень выше отдельного сервера. Через KernelHost API агент может запрашивать продукты и цены, заказывать серверы, читать статус своих услуг, запускать, останавливать и перезапускать серверы, а также оформлять расторжение и отменять его. Так фраза «Настрой мне тестовый сервер» превращается в одну-единственную задачу: агент заказывает машину, ждёт активации, подключается по SSH, устанавливает приложение и сообщает в ответ адрес.

Для использования агентами интерфейс намеренно построен с осторожностью. API-ключи получают только те права, которые им нужны, а ключ для аналитики вообще ничего не может заказать. Idempotency-Key гарантирует, что заказ, который агент повторяет после ошибки по таймауту, не будет выполнен дважды. Запросы ограничены на каждый ключ, на каждую учётную запись и на каждый адрес, поэтому даже агент в бесконечном цикле не вызовет лавину. А каждое получение учётных данных вызывает уведомление по электронной почте, чтобы вы видели, когда агент прочитал учётные данные.

Сколько стоит сервер под управлением ИИ?

Расходы складываются из двух статей. Во-первых, сам сервер: для агента, работающего по SSH, серверу не нужно особое оснащение, подойдёт любой root-сервер, на котором и так размещено ваше приложение. Если агент работает прямо на сервере, самому инструменту нужно всего несколько сотен мегабайт оперативной памяти, и root-сервера с 2 vCPU и 4 ГБ ОЗУ хватит, если на нём больше почти ничего не запущено. Во-вторых, языковая модель: либо подписка у провайдера, включающая использование инструмента командной строки, либо API-ключ с оплатой по фактическому расходу. При ежедневном интенсивном использовании подписка обычно дешевле, а для автоматизированных задач без человека за клавиатурой API-ключ является чистым решением, потому что его можно ограничить месячным бюджетом. Актуальные цены на серверы вы найдёте на странице Аренда root-сервера.

Частые ошибки и как их избежать

• Агент работает с личным ключом администратора. Тогда его доступ нельзя отозвать отдельно, а в логах его действия не отличить. Решение: собственный ключ с собственным комментарием.
• Все запросы подтверждения отключены. В первый день это экономит клики, а однажды стоит целого сервера. Решение: белый список для команд на чтение, одобрение для всего, что вмешивается в систему.
• Нет резервной копии перед изменением. Решение: резервная копия и скрипт отката как обязательное правило в CLAUDE.md или AGENTS.md.
• Резервные копии в веб-каталоге. Файл вроде config.php.bak в корне сайта может оказаться общедоступным вместе с паролем от базы данных. Решение: каталог резервных копий за пределами веб-каталога с правами 700.
• Секреты в промпте. Решение: учётные данные только в файлах с правами 600, которые читают скрипты, а при случайной утечке немедленно создавать их заново.
• Двойное выполнение. Двойной клик или повторный запрос оформляет заказ дважды. Решение: блокировка через flock или Idempotency-Key.
• Файлы, которыми управляет панель управления, изменены напрямую. Панель перезапишет их при следующем обновлении или из-за них выйдет из строя. Решение: исключить такие файлы в правилах и вносить изменения через панель или её API.
• Вывод принят без проверки. Агент, который не понимает вывод, гадает. Решение: требовать доказательства («покажи мне строку лога») и просить проверять результаты вживую.

Коротко о главном

• Подключить ИИ к серверу означает дать агенту вроде Claude Code, Codex CLI или Gemini CLI собственный SSH-ключ и чёткие правила.
• Агент читает логи, вносит изменения, проверяет результат и документирует его, а шаги, вмешивающиеся в систему, выполняются только после одобрения.
• Каждое развёртывание идёт по строгому регламенту: проверить текущее состояние, сделать резервную копию, подготовить откат, проверить синтаксис, развернуть, протестировать, проверить вживую, задокументировать.
• Секретам никогда не место в чате, а действиям, которые стоят денег, нужна блокировка от двойного выполнения.
• Серверу нужны root-доступ, SSH-ключи, свободные исходящие соединения и защита от DDoS, но не GPU.
• Серверы KernelHost выполняют все требования из коробки, по модели PrePaid без привязки к договору, а через KernelHost API агент может даже сам заказывать серверы и управлять ими.