Головна / Статті

Агентний інжиніринг та зовнішня петля: місце Antigravity та Agents CLI у цій концепції.

Технічні характеристики, оцінки та правила визначають концепцію агентного інжинірингу. Огляд інструменту Google’s Agents CLI, його рівня використання у GCP та відмінностей Antigravity від інших інструментів програмування.

Видавець: REACTAPP.TOP8 хв читання1803 слів

Джерела: Agentic Engineering and Antigravity 2.0: The New Operating Model for Software Development

Наступний етап розвитку ШІ залежить менше від потужніших моделей, а більше — від розвиненіших інженерних систем. На конференції Sequoia Ascent 2026 Андрей Карпаті описав перехід індустрії від кодування на основі інтуїції до агентного інжинірингу. У цій сфері люди створюють специфікації, цикли оцінки та правила безпеки, а агенти виконують певні частини реалізації.

Ця зміна має велике значення, оскільки ШІ не замінює дисципліну програмної інженерії. Він посилює будь-яку вже існуючу дисципліну. Дослідження DORA від Google та відповідні рекомендації щодо платформ вказують на те саме: організації з міцною інженерною основою отримують більше користі від робочих процесів із допомогою ШІ, ніж ті, у яких процеси є нестабільними та перевірка — слабкою. Використання інструментів для розробки за допомогою ШІ є поширеним, але довіра — ні. Обмежуючим фактором більше не є сама модель, а система навколо неї: специфікації, оцінки, процес розгортання та механізми управління. Інженерія з агентами — це практика створення саме такої системи.

Що означає інженерія з агентами

Коротко кажучи, це структурований підхід до розробки за допомогою ШІ, у якому люди контролюють архітектуру, якість та коректність, тоді як агенти виконують обмежені завдання з реалізації в межах визначених правил. Карпаті визначив три основні принципи.

Спочатку специфікації. Перш ніж агент напише будь-який код, інженер формулює мету, обмеження та критерії успіху у машинночитабельній специфікації. Структурований договір між людиною та агентом замінює нечіткі вказівки.

Оцінка перед довірою. Одна успішна робота нічого не говорить про надійність. Агентів потрібно тестувати на структурованих наборах даних для оцінки, оцінюючи їх за допомогою певних метрик та методів з використанням ШІ як судді, щоб результати були відтворюваними перед тим, як щось буде впроваджено.

Захисні механізми та сандбоксинг. Агент має знаходитися у захищеному сандбоксі з чіткими дозволами, інструментами для взаємодії та контрольними точками політики, щоб його виконання не відбувалося без перевірки. Сьогодні лише 12% пілотних проектів корпоративних AI-агентів потрапляють у продакшн, і причиною цього здебільшого не є моделі. Проблеми інфраструктури полягають у відсутності сандбоксингу, сканування на наявність секретної інформації та контрольних точок політики.

Якими є сучасні інструменти програмування

Будь-яка об’єктивна оцінка починається з визнання того, що сучасні інструменти програмування на основі AI роблять добре, і це справді вражаюче.

Вони демонструють високу ефективність у виконанні завдань з багаторазовими кроками: розбивці завдання на частини, редагуванні кількох файлів, виконанні команд у локальному терміналі та самостійній корекції помилок компілятора. Вони вже давно вийшли за межі простого генерування коду та автодоповнення.

Проте внутрішня петля — це лише половина проблеми. Команди великих компаній більше не запитують, чи може агент писати та редагувати код, адже у 2026 році майже кожен основний інструмент це дозволяє. Складнішою є зовнішня петля: як організація оцінює, розгортає, контролює та керує агентами після того, як вони залишають локальний термінал розробника. Саме тут змінюється характер дискусій. Структурна різниця виглядає так:

Це жодним чином не підриває цінності інших інструментів. Як двигуни для виконання завдань у межах внутрішньої петлі, вони залишаються серед найкращих на ринку. Але генерація коду — це лише початок, а інструменти, налаштовані для роботи у локальному терміналі розробника, не створені спеціально для керування всім життєвим циклом у межах зовнішньої петлі. Щоб досягти успіху у 2026 році, потрібно більше, ніж просто створити здатних агентів — необхідна інфраструктура для їх оцінки, розгортання та керування у продакшені.

Agents CLI як вхідний портал

Підхід Google ґрунтується на одному ключовому дизайнерському рішенні. Agents CLI призначений для використання разом з будь-яким асистентом для програмування, і це є перевагою архітектури, а не її недоліком. Під час встановлення він додає сім основних функцій, створених на основі Agent Development Kit (ADK), які охоплюють створення основи для роботи агентів, оцінку їхньої продуктивності за допомогою LLM як судді, налаштування під час виконання, розгортання у Cloud Run та забезпечення можливостей моніторингу через Cloud Trace. Користувачі Claude Code чи Cursor можуть виконувати команди agents-cli scaffold, agents-cli eval та agents-cli deploy приблизно з такою ж легкістю, як і користувачі Antigravity.

Це робиться навмисно. Google не конкурує на рівні генерації коду. Компанія сподівається, що цінність інженерії агентів переміститься з фронтенду, де пишеться код, у бекенд, де агенти запускаються, контролюються та керуються. І незалежно від того, який фронтенд обере розробник, команди CLI ведуть до одного й того самого результату:

  • agents-cli розгортається на Cloud Run, GKE або Agent Engine, які всі належать до GCP.
  • agents-cli для відстеження надсилає телеметрію до Cloud Trace та BigQuery, що також є сервісами GCP.
  • agents-cli для публікації реєструє агенти в Agent Registry, який також знаходиться у GCP.
  • Шар керування, що включає Model Armor, Agent Identity та політики безпеки, також працює на GCP.

CLI є вхідним портом, а GCP — кінцевою точкою. Кожен асистент для програмування, який його використовує, стає клієнтом GCP для циклу життя продукту. Саме тому фраза „він також працює з Cursor“ підтримує цю стратегію, а не підриває її: Google не потребує, щоб хтось змінював редактори, лише щоб продукція працювала на GCP, а CLI робить цей процес найпростішим для кожного інструменту.

Три концентричні шари

Екосистема Google складається з трьох вкладених шарів. Кожен з них додає нові можливості, причому жоден не вимагає відмови від наявних інструментів.

Найвнутрішніший шар — це Agents CLI, сумісний з Cursor, Claude Code, Codex, Copilot, Antigravity чи будь-яким іншим інструментом, який підтримує вбудовування функцій. Він пропонує стандартний спосіб створення основи проекту (agents-cli scaffold), структуровану оцінку, яку здійснює суддя у вигляді ШІ (agents-cli eval), розгортання на Cloud Run чи GKE за допомогою однієї команди (agents-cli deploy) та автоматичне налаштування системи моніторингу Cloud Trace (agents-cli observe). У ньому відсутні функції оркестрації кількох агентів, створення постійного контексту та вбудовані цикли перевірки. Аргумент для користувачів: залишити улюблений редактор, отримати повторюваний процес переходу від прототипу до продакшну та погодитися з тим, що продакшн працює на GCP.

Шар хмари є необхідним для будь-якого інструменту, який використовує Agents CLI, оскільки саме там фактично працюють агенти. Він складається з:

  • Cloud Run, GKE та платформи агентів для масштабованого керованого хостингу
  • Cloud Trace – для повного відстеження шляху виконання з телеметрією, сумісною з OTel
  • BigQuery Agent Analytics – для панелей керування для всієї групи розгорнутих агентів
  • Agent Registry – центральний каталог для керування, версіонування та обміну агентами
  • Model Armor – засіб, який запобігає витоку даних та фільтрує небезпечний контент
  • Agent Identity – з криптографічними ідентифікаторами, прив’язаними до перевірених людських ідентичностей або принципалів сервісу
  • Протокол Agent2Agent (A2A) – для комунікації між агентами під час координації групи

Причина полягає у тому, що самостійні асистенти з кодування зазвичай залежать від зовнішньої хмарної інфраструктури для розгортання в продакшені, моніторингу та керування, і не пропонують інтегрованого середовища виконання для корпоративних проектів. Це структурна особливість, а не конкурентна перевага. Claude Code не конкурує з Cloud Run, оскільки вони функціонують на різних рівнях.

Що додає Antigravity

Якщо у всіх є підагенти та файли контексту, що відрізняє Antigravity? Відповідь — це не одна конкретна функція, а вертикальна інтеграція з рівнем продакшену.

Підагенти в Claude Code працюють усередині терміналу: вони пишуть код, запускають тести та генерують результати. Розгортання цього коду, його безперервний моніторинг, керування низкою агентів та координація їх роботи між різними сервісами — усе це лежить на користувачеві, адже Claude Code нічого не знає про інстанції Cloud Run, конвеєр спостережуваності чи політики керування. Це інструмент для розробки. Підагенти Antigravity можуть робити більше:

  • Розгортати код безпосередньо в Cloud Run, GKE чи на платформі агентів через Agents CLI, оскільки CLI є частиною самого продукту, а не стороннім плагіном.
  • Запитувати дані Cloud Trace під час дебагування, адже Antigravity може читати дані спостережуваності GCP.
  • Реєструвати завершені агенти в Agent Registry, оскільки публікація є частиною вбудованого процесу роботи.
  • Координувати дії з розгорнутими агентами через протокол A2A, оскільки шар комунікації належить до тієї самої екосистеми.

Підагенти Claude Code є потужними інструментами для розробки, тоді як підагенти Antigravity — це інструменти для розробки, обізнані щодо середовища виробництва, оскільки вони використовують спільний набір компонентів від постачальника. Стверджується, що у них є чотири функції, яких наразі немає в інших інструментах:

  1. Багатоповерхнева континуїтетність: один контекст агента охоплює IDE на робочому столі, CLI, SDK для програмної роботи та керований API. Робочий процес може початися в IDE, продовжитися в терміналі та бути запущений з систем CI/CD. Claude Code переважно працює в терміналі, тоді як Cursor орієнтований на IDE.
  2. Інтеграція з CLI агентів від першого виробника: функції scaffold, eval, deploy та observe були спроектовані разом із Antigravity, тому агент природним чином знає CLI та може поєднувати команди життєвого циклу без необхідності розробки спеціальних запитів.
  • Контекст, зважений на GCP. Агенти можуть отримувати дані Cloud Trace, записи з Agent Registry та метадані розгортання у свій робочий контекст, тож агент, який вирішує проблеми у продакшені, може читати телеметрию, переглядати конфігурацію розгорнутого агента та пропонувати способи виправлення проблем у одній сесії.
  • Можливість виявлення в корпоративному середовищі. Багато користувацьких агентів залишаються ізольованими за приватними URL-адресами кінцевих точок, до яких можуть отримати доступ лише їхні розробники, і для цього потрібні обмінювані вручну облікові дані. Вбудований механізм публікації вирішує цю проблему: наказ CLI для реєстрації агента в Gemini Enterprise запускає команду agents-cli publish, і агент з’являється як безпечний та доступний інструмент у додатку Gemini Enterprise для всієї організації. Вбудована система IAM керує доступом, і команди можуть її використовувати без необхідності створення власної інфраструктури.
  • Порівняння екосистем

    Щоб зробити порівняння конкретнішим, у наступній таблиці показано, де інструменти є еквівалентними, а де вони відрізняються.

    У верхній частині порівняння три екосистеми мають схожу архітектуру: вони забезпечують якісну генерацію коду, паралельну оркестрацію підагентів та керовані хмарні сандбокси для довготривалих завдань. У нижній частині Google стверджує про наявність додаткової корпоративної цінності. Конкуруючі платформи переміщують код, дані та облікові дані у пропрієтарні середовища третіх сторін, тоді як Google дозволяє організації виконувати, ідентифікувати, автентифікувати, керувати та моніторити агенти в межах власного середовища Google Cloud за допомогою Agent Runtime, Agent Identity, Model Armor та Agent Registry. Це розмежування проявляється в практичній роботі: вбудована телеметрія GCP, єдиний механізм розгортання та керування моделями без додаткових налаштувань.

    Якщо говорити просто, можливості локального внутрішнього циклу поступово наближаються одна до одної, тоді як у рівні інфраструктури саме вертикальна інтеграція створює прогалини.

    Як приймати рішення

    Критерії прийняття рішень для керівників та інженерів є простими. Команда, яка зосереджена переважно на прискоренні виконання завдань у внутрішньому циклі, повинна залишатися зі своїми поточними інструментами. Claude Code, Cursor та Copilot є відмінними та постійно вдосконалюються щомісяця. Для роботи з циклом життя проектів можна додати Agents CLI, а при готовності команди — розгорнути його на GCP.

    Організації, які переходять від кодування з допомогою ШІ до робочих процесів, керованих агентами, мають інші вимоги. Керування флотом агентів, контроль якості на основі оцінок, регулювання у сферах з жорсткими вимогами та координація кількох агентів вимагають іншої архітектури, і Google є одним із небагатьох постачальників, які пропонують вертикально інтегрований комплекс засобів — від агентів для кодування через оцінку, розгортання, моніторинг та управління.

    Цей аспект не залежить від переваги моделей, оскільки вони поступово наближаються одна до одної. Він залежить від інтеграції інфраструктури: відстані від написання коду агента до керування флотом таких агентів у продакшені. Google скоротив цю відстань більше, ніж будь-хто інший, незалежно від того, з яким інструментом редагування починає роботу команда.