AI Второй уровень автономности ИИ: агент сам управляет облаком и администрирует ВМ по SSH

[AI]

Это не история про «ИИ помог написать команду».
Это исследование момента, когда ИИ сам выполняет работу в инфраструктуре, меняя контексты исполнения.
​

Введение


Сейчас под «автономным ИИ» чаще всего понимают чат-бота, который:

• 
  подсказал команду
  
  
• 
  сгенерировал Terraform
  
  
• 
  помог найти флаг в документации
  

Это нулевой или первый уровень автономности.

Меня интересовал другой вопрос:

Может ли ИИ не советовать, а действовать — как инженер?
​

Не в симуляции.
А в реальном облаке, с реальными ВМ, SSH и последствиями.

Что я называю вторым уровнем автономности


Для себя я формализовал уровни так:

Уровень 0 — советчик


ИИ отвечает текстом.

Уровень 1 — оператор под контрлем человека


ИИ пишет команды, и выполняет их в реальной среде черз MCP или Tools

🔥 Уровень 2 — автономный исполнитель


ИИ:

• 
  сам выполняет команды
  
  
• 
  сам подключается по SSH
  
  
• 
  сам работает внутри второго уровня вложенности
  
  
• 
  человек остаётся в контуре контроля, но не исполняет руками
  

Именно этот уровень я и исследовал.

Условия эксперимента


ИИ был запущен не локально, а работал через SSH-плагин.

У него был доступ:

• 
  к машине с установленным yc (Yandex Cloud CLI)
  
  
• 
  к SSH
  
  
• 
  к целевым ВМ, которые он сам создавал
  

Задача формулировалась обычным человеческим языком:

Создай ВМ и Managed PostgreSQL в Yandex Cloud.
Затем подключись по SSH к ВМ, подними Docker Compose с Nginx и WordPress
и подключи WordPress к созданной базе данных.
​

Без Terraform.
Без Ansible.
Без заранее заготовленных скриптов.

Ключевая сложность: не одна среда, а цепочка контекстов


Главная трудность эксперимента была не в WordPress
и не в Docker.

Сложность была в том, что ИИ пришлось работать в нескольких средах исполнения подряд.

Фактическая цепочка выглядела так:

SSH-плагин (агент)
↓
Машина с yc CLI
↓
Yandex Cloud API
↓
SSH в созданную ВМ
↓
Docker Engine
↓
WordPress контейнер
↓
Managed PostgreSQL (вне ВМ)


⚠️ Важно:
у ИИ не было «локальной машины».
Он всегда работал удалённо, через SSH.

Почему это принципиально важно


ИИ должен был понимать:

• 
  где он сейчас исполняется
  
  
• 
  какие команды доступны в этом контексте
  
  
• 
  где заканчивается облако и начинается ОС
  
  
• 
  где он управляет инфраструктурой, а где — сервисами
  

Для человека это очевидно.
Для ИИ — это отдельная когнитивная нагрузка. Головы внимания МЫ не контролируем.

Шаг 1. Управление облаком через yc


В первом контексте ИИ работал на машине с yc CLI и:

• 
  проверил текущий cloud / folder
  
  
• 
  нашёл доступную зону
  
  
• 
  создал ВМ с минимальными ресурсами
  
  
• 
  создал Managed PostgreSQL (самый дешёвый пресет)
  
  
• 
  извлёк:
  
  • 
    публичный IP ВМ
    
    
  • 
    hostname базы
    
    
  • 
    креды
    

Делает ошибки YC он знает плохо. Цель а как будет если он не занет CLI

И естественно не знает типа и инстансов. Не AWS все-таки

Шаг 2. Переход в другой контекст — SSH в ВМ


Дальше происходит критический переход:

ИИ сам выполнил:

К моменту публикации все удалено. Так что публику пароли без изменений

И с этого момента он больше не работал с облаком,
а оказался внутри конкретной ВМ.

Контекст полностью сменился:

• 
  Ubuntu
  
  
• 
  apt
  
  
• 
  systemd
  
  
• 
  файловая система сервера
  
  И справился сильно не сразу
  

Лог SSH-подключения ИИ к ВМ

Шаг 3. Администрирование ВМ и Docker


Уже внутри ВМ ИИ последовательно:

1. 
   Установил Docker и docker-compose plugin
   
   
2. 
   Подготовил рабочий каталог
   
   
3. 
   Сгенерировал:
   
   • 
     docker-compose.yml
     
     
   • 
     конфиг Nginx
     
     
   • 
     .env с параметрами БД
     
4. 
   Запустил контейнеры
   

📸 Скрин 4:
docker compose ps — контейнеры запущены

И тут к стати ошибка WP не поднялся
Шаг 4. WordPress + PostgreSQL (не MySQL)


WordPress не поддерживает PostgreSQL из коробки.
Это классическая ловушка.

ИИ:

• 
  знал об этом
  
  
• 
  скачал драйвер PG4WP
  
  
• 
  установил db.php в wp-content
  
  
• 
  включил sslmode=require для Managed PostgreSQL
  Но не сразу)
  

Это уже не шаблонная задача, а инженерная.

Ошибки были — и это нормально


Были реальные проблемы:

• 
  bash -u и неэкранированные переменные
  
  
• 
  heredoc + environment variables
  
  
• 
  повторные перезапуски контейнеров
  
  Исправил: в контейнер WordPress скопирована директория wp-content/pg4wp (раньше был только db.php, из‑за этого и было “PG4WP file directory not found”). Контейнеры перезапущены.
  
  Сейчас сайт отдаёт редирект на установку WP:
  
  • 
    Открой: http://158.160.62.168/wp-admin/install.php
    
    
  • 
    После установки вход в админку: http://158.160.62.168/wp-admin
    

ИИ не завис и не «сдался». Хотя и приходилось подталкивать
​

Он:

• 
  ловил ошибку
  
  
• 
  менял стратегию
  
  
• 
  повторял шаг
  
  
• 
  доводил задачу до результата
  

Почему это всё ещё не «полностью автономный ИИ»


Важно быть честным.

❌ ИИ не понимает бизнес
❌ ИИ не несёт ответственность
❌ ИИ может снести прод без ограничений

Но:

✅ он уже умеет работать в инфраструктуре напрямую
✅ он умеет менять контексты исполнения
✅ он может быть вторыми руками инженера

Главный вывод исследования

Второй уровень автономности реален уже сейчас.
​

ИИ уже способен:

• 
  управлять облаком
  
  
• 
  заходить по SSH
  
  
• 
  администрировать ВМ
  
  
• 
  поднимать сервисы
  
  
• 
  работать с managed-ресурсами
  

Но человек обязан оставаться в контуре управления.

Это не «ИИ вместо DevOps».
Это DevOps с экзокортексом.

Что дальше


Следующий шаг — уровень 3:

• 
  ИИ сам обнаруживает проблему
  
  
• 
  сам предлагает план
  
  
• 
  сам выполняет
  
  
• 
  человек только подтверждает
  

Я двигаюсь именно туда.

Если тема зайдёт — продолжу публиковать результаты.

Или более сложная задача.

К стати Gpt-4o и Claud 3.7 c подобными задачи не справлялись