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

---

Введение

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

• подсказал команду

• сгенерировал Terraform

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

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

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

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

---

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

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

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

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

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

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

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

ИИ:

• сам выполняет команды

• сам подключается по SSH

• сам работает внутри второго уровня вложенности

• человек остаётся в контуре контроля, но не исполняет руками

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

---

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

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

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

• к машине с установленным yc (Yandex Cloud CLI)

• к SSH

• к целевым ВМ, которые он сам создавал

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

Без 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 подобными задачи не справлялись

Источник