AI Vibe Craft
← Назад к AI Vibe News

Редакция 1 июля 2026 г.

Разборы

Агент в CLI, который тащит Python с AWS на GKE: skill, субагенты и двойной HITL

Агент в CLI, который тащит Python с AWS на GKE: skill, субагенты и двойной HITL.

Соло-разработчику, который собирает агентные цепочки в терминале, важнее не «один умный промпт», а упакованный skill с жёсткими guardrails. Carlos Gomes на Antigravity CLI (agy) показывает миграцию AWS-завязанного Python на GKE через параллельных субагентов и двухслойный human-in-the-loop — в разборе видно, что из этого переносится в ваш соло-workflow со skills, hooks и keyless-auth без иллюзии полной автономии.

Skill для CLI-агента: slash-команды вместо разового чата

Типичная боль знакома: наследованный код с import boto3 в десятках файлов, захардкоженные AWS credentials и хранение в /tmp, которое ломается в ephemeral-подах Kubernetes. Автор не продаёт «магический скрипт» — он собирает Agnostic Cluster Refactor Skill под LLM-агента agy с инструментами read_file, write_to_file, run_command и invoke_subagent; в примере оркестрации указан движок Gemini.

После установки plugin в ~/.gemini/config/plugins/agnostic-cluster-refactor/ в чате появляются две команды:

  • /agnostic-cluster-refactor:scan-deps
  • /agnostic-cluster-refactor:spawn-refactor

«Agnostic» здесь — про снятие vendor lock-in при переносе на Kubernetes. В материале разобран маршрут AWS-coupled Python → GKE/GCP (замена boto3/S3/SQS на google.cloud.storage/Pub/Sub), а не каталог произвольных облаков. Skill-файлы лежат в .agents/skills/; namespace plugin не даёт slash-командам столкнуться с чужими именами — для соло-дева, который копирует паттерн под свой CLI-агент, это практичнее, чем держать промпт в заметках.

Сканер scripts/scan_deps.py обходит проект regex-паттернами и строит DAG зависимостей. На выходе — dependency-map.json с architectural_dag и recommended_action; в примере фигурирует Execute '/spawn-refactor' targeting GCP GKE. Это уже не «поговорить с моделью», а воспроизводимый skill с артефактом на диске — ближе к тому, как в IDE заводят rules и skills, только в терминальном агенте.

Параллельные субагенты: backend и infra в изолированных worktree

Второй слой — оркестрация. Параллелизм идёт через invoke_subagent: как минимум два субагента — backend-engine (рефакторинг Python по dependency-map.json) и infra-engine (генерация serviceaccount.yaml, deployment.yaml, ingress.yaml).

Каждый работает в изолированном Git Worktree — shadow-worktree-backend и shadow-worktree-infra на отдельных ветках; main не трогается до ревью человеком. У infra-субагента в примере урезанный toolset — только write_to_file, принцип least privilege для агента, который пишет манифесты.

Backend-ветка в примере меняет boto3 на google.cloud.storage и pubsub_v1, обновляет requirements.txt: уходит boto3==1.28.0, появляются google-cloud-storage==2.10.0 и google-cloud-pubsub==2.18.0. Infra-ветка отдаёт ConfigMap/Secret env и ingress с ingressClassName: gce. Если вы уже гоняете агентов параллельно, схема «два специализированных субагента + изоляция git» снимает страх, что один run перепишет и код, и кластер в одной куче без контроля.

Двойной HITL: hooks ловят запись, SKILL.md требует YES

Без human gate автономный агент на миграции — «хаотичный скрипт»; с gate — «trustworthy teammate». Здесь два независимых слоя.

Слой 1 — hooks. Файл .agents/hooks.json, hook hitl-production-gate, событие PreToolUse перед write_to_file, replace_file_content, multi_replace_file_content. Скрипт scan_deps.py --check-only читает JSON со stdin и возвращает allow, force_ask или deny. Запись без паузы разрешена только в префиксах examples/, terraform/, .agents/; иначе — force_ask с причиной [HITL Gate].

Слой 2 — явное подтверждение в SKILL.md. Перед /spawn-refactor агент обязан показать список файлов к изменению и получить YES; без YES — остановка.

Для того, кто строит agentic pipeline в одиночку, урок не в абстрактной «этике ИИ», а в инженерии: автоматический hook на опасные tool calls плюс явный чек-лист в skill — тот же класс решений, что rules и pre-commit для Cursor-агента, только привязан к CLI и файловой записи.

Keyless на GKE и LOCAL_MOCK: агент не тащит JSON-ключи в под

Финальный блок — безопасность и локальный цикл. На GKE приложение вызывает storage.Client() без JSON-ключа и без GOOGLE_APPLICATION_CREDENTIALS: ADC опирается на Workload Identity. Kubernetes Service Account аннотируется email GSA:

iam.gke.io/gcp-service-account: "gke-app-sa@MY_PROJECT.iam.gserviceaccount.com"

Метаданные GKE выдают краткоживущий OAuth2-токен; Terraform связывает KSA и GSA через roles/iam.workloadIdentityUser. MY_PROJECT в примерах — плейсхолдер, project id подставляет читатель.

Локально без GCP-учёток — флаг LOCAL_MOCK=true (in-memory store вместо GCS) и условный импорт google.cloud.storage только когда mock выключен. Для K8s на Docker Desktop автор отмечает quirk: образы docker build не видны containerd кластера; обход — локальный registry registry:2 на порту 5001 (порт 5000 занят AirPlay на macOS). Цикл: make build, make local-up, health на http://localhost:8080/health, teardown — make local-down.

Публичный репозиторий с воспроизводимыми артефактами — https://github.com/carlosrgomes/agnostic-cluster-refactor; примеры манифестов в examples/k8s/local/, production SA — examples/k8s/serviceaccount.yaml, IaC — terraform/iam.tf. Если переносите идею в свой соло-workflow, забирайте связку «skill + субагенты + двойной HITL + keyless», а не только список замен boto3 — именно агентная обвязка отличает материал от голого DevOps-гайда.

Источники

  • Carlos Gomes (@carlosrgomes), «Agnostic Cluster Refactor Skill for Antigrafity CLI: Building an AI Agent that Migrates Apps from AWS to GKE (Subagents, HITL Gate & Workload Identity)» — Dev.to (доступ: 2026-07-01)
  • Репозиторий проекта — https://github.com/carlosrgomes/agnostic-cluster-refactor (доступ: 2026-07-01)