Эта страница переведена с английской документации. Команды, идентификаторы и примеры не изменены. Среда выполнения 7.24.4 · SDK 2.6.7. Английский оригинал

Режим облачных операций

Статус: активно Область: текущее состояние Последняя проверка: 2026-09-04 Владелец: среда выполнения ax-code

Режим облачных операций — готовая позиция для администрирования инфраструктуры: облачных провайдеров (AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod) и сетевых устройств (VyOS, Juniper Junos), где ошибка затрагивает живые системы, а откат git не восстанавливает состояние. Он поставляется как встроенный агент cloudops: системный запрос плюс позиция разрешений, которую вы включаете одним выбором, а не пишете правила вручную.

Что даёт режим

Агент, который сначала только читает. Агент cloudops начинает каждую задачу с инвентаризации и пробных запусков, а его запрос запрещает изменение, пока нет плана, diff и рецептов отката.
Оболочка с вопросом перед запуском. bash установлен в ask, поэтому каждая команда оболочки подтверждается. Изменяющие глаголы облака и сети (семейство удаления aws/gcloud/az/doctl, kubectl delete/apply --prune, terraform apply без файла плана, удалённый commit по ssh без commit-confirm, мутации curl к API плоскости управления) классифицируются как bash_destructive и несут отдельный интерактивный шлюз, который нельзя обойти.
Полноценные инструменты операций. ops_plan, ops_diff, ops_verify и ops_journal заранее разрешены; ops_approve и ops_apply остаются на своих интерактивных путях (ниже).

Процесс: план → diff → одобрение → применение → проверка → журнал

ops_plan — открыть OperationPlan: цель (провайдер, аккаунт, регион или устройство), намерение, точная команда применения и контекст команды, а также шаги с эффектом, обратимостью (reversible | hard | irreversible) и радиусом поражения (low | med | high). Даёт канонический хеш плана.
ops_diff — получить и просмотреть артефакт, который может проверить машина (terraform plan -out, show | compare, вывод пробного запуска CLI), и приложить его. Нет diff — нет одобрения.
ops_approve — человек одобряет план, закреплённый хешем. Этот шлюз только интерактивный: ни правило с подстановкой, ни автономный режим не могут одобрить его заранее, и долговременное разрешение «всегда разрешать» не предлагается.
ops_apply — выполнить изменение одобренного плана с токеном одобрения. Это единственный санкционированный путь изменения; токен погашается до того, как что-либо запустится.
ops_verify — выполнить декларативные утверждения плана только для чтения и записать свидетельства успеха или неудачи.
ops_journal — запросить журнал операций только для добавления в пределах проекта по проекту, плану или статусу.

Включение режима

В TUI выберите Cloud Ops в выборе агента (или упомяните через @ cloudops для задачи с ограниченной областью). Чтобы сделать его значением по умолчанию для проекта, добавьте в ax-code.json:

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write ограничивает изменения файлов рабочей областью; network: true оставляет доступными webfetch, websearch и CLI провайдеров (сеть иначе выключена в режимах песочницы — см. Режим песочницы). Оба параметра — изоляция сессии, независимая от агента, поэтому они задаются здесь, а не внутри пресета агента.

Позицию можно ужесточить или расширить для проекта в agent.cloudops.permission, например запретить конкретные инструменты. Конфигурация, зафиксированная в репозитории, может только добавлять правила запрета; ослабление ask до allow должно прийти из доверенной пользовательской или управляемой конфигурации, но никогда из репозитория. Чтобы убрать агента целиком, задайте "agent": { "cloudops": { "disable": true } }.

Разобранный пример

Применение изменения межсетевого экрана на маршрутизаторе VyOS:

Вы просите: «разрешить tcp/8443 из 10.0.0.0/8 на пограничном межсетевом экране».
Агент загружает навык vyos-firewall, снимает текущую конфигурацию по SSH (show configuration commands сохраняется в файл с датой) и открывает план через ops_plan: один шаг, эффект add firewall rule, обратимость reversible (удаление правила восстанавливает состояние), радиус поражения med.
Он ставит изменение в режиме конфигурации и прилагает diff устройства через ops_diff.
ops_approve показывает хеш плана и точное подготовленное изменение; вы одобряете, и выдаётся токен на 10 минут.
ops_apply погашает токен и запускает последовательность commit-confirm; таймер автоматического отката остаётся взведённым до проверки.
ops_verify проверяет достижимость и то, что правило соответствует задуманному трафику; и одобрение, и результат пишутся в журнал, поэтому поздний запрос ops_journal восстанавливает всё изменение.

Если применение на шаге 5 не удалось, токен уже израсходован — шаг 4 нужно выполнить снова перед любой повторной попыткой.

Семантика токена одобрения

Одноразовый — погашается атомарно в начале ops_apply; израсходованный, неизвестный или просроченный токен завершается ошибкой, и ничего не выполняется.
Ограничен TTL — по умолчанию 10 минут, максимум 60. Срок проверяется лениво в момент погашения; фонового сборщика нет.
Привязан к плану — токен выдаётся против канонического хеша sha256 плана, который включает точную команду применения, необязательную команду снимка и рабочий каталог. Дрейф аргументов и токены, предъявленные для другого плана, отвергаются до погашения, что не даёт повтора, путаницы между планами и подмены команды.
Показывается один раз — сырой токен появляется ровно один раз в результате ops_approve и никогда не сохраняется (хранится только его sha256).
Без возврата — неудачное или просроченное применение не возвращает токен. Повтор требует нового одобрения через ops_approve.

Модель безопасности

bash_destructive остаётся шлюзом для разовых изменений. Процесс операций покрывает запланированное изменение; разовые разрушительные команды всё равно попадают в классификатор разрушительности и его интерактивный шлюз, и никакое правило разрешения не может одобрить их автоматически.
ops_approve только интерактивный, как isolation_escalation и bash_destructive: он всегда спрашивает, даже при наборах правил с разрешением по подстановке и в безголовом автономном режиме.
Журнал только для добавления с точки зрения агента и ограничен проектом; он переживает сессии и не каскадируется при удалении сессии.
Пакеты навыков несут регламенты провайдеров. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall и junos-firewall держат контрольные списки «сначала только чтение», шаги «план до изменения» и шаблоны отката; агент загружает подходящий пакет перед работой с поверхностью. OVHcloud и другие провайдеры покрываются настроенными серверами MCP и их документацией, а не импровизированными цепочками CLI.
Учётные данные не попадают в запись. Встроенные присваивания учётных данных в сохранённых вводах bash редактируются до того, как попадут в журнал событий.

Строгий режим

По умолчанию команда bash, классифицированная как разрушительная (семейство bash_destructive: изменяющие глаголы облака и сети, rm -rf, git push --force и остальной список классификатора), получает интерактивный вопрос, который нельзя обойти: пользователь может одобрить разовую команду, и она выполнится. Строгий режим убирает этот вариант.

При включённом строгом режиме команда bash, классифицированная как разрушительная, отклоняется сразу, до любого вопроса. Сообщение отказа перечисляет классифицированные команды с причинами и направляет модель к санкционированному процессу: ops_plan → ops_diff → ops_approve (выдаёт одноразовый токен одобрения) → ops_apply. Разовые разрушительные мутации оболочки больше невозможны вовсе; каждое изменение должно быть спланировано, сверено diff, одобрено и применено по пути с опорой на журнал.

Включите его в доверенной конфигурации (ax-code.json в каталоге пользовательской конфигурации, управляемой конфигурации или конфигурации проекта, которой пользователь явно доверяет):

{
  "ops": {
    "strict": true
  }
}

Замечания:

Взаимодействие с вопросом: строгий режим заменяет вопрос bash_destructive жёстким отказом. При выключенном флаге (значение по умолчанию) поведение точно такое, как описано выше: интерактивный шлюз остаётся.
Область: флаг — глобальная конфигурация, не настройка агента. Он применяется к каждому вызову bash в сессии, включая субагентов. Агент cloudops не может включить его сам; агенты несут разрешения и запросы, а не конфигурацию.
Граница доверия: недоверенная конфигурация проекта, зафиксированная в репозитории, не может включить строгий режим; соглашайтесь на каждой машине (AX_CODE_TRUST_PROJECT_CONFIG=1) или задайте его в доверенной пользовательской или управляемой конфигурации.
ops_apply не затрагивается: санкционированный путь изменения имеет собственный шлюз токена, привязанного к плану, внутри инструмента и никогда не смотрит на этот флаг.

Источник истины

packages/ax-code/src/agent/agent.ts — определение агента cloudops и слияние разрешений
packages/ax-code/src/agent/prompt/cloudops.txt — системный запрос агента
packages/ax-code/src/tool/ops_*.ts — шесть инструментов операций и их описания
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY (ops_approve, bash_destructive, isolation_escalation)
Режим песочницы — режимы изоляции, управление сетью и приоритет