Как создавать надежные агентные системы с помощью Antigravity: от инструкций к циклам

Я наблюдал, как дискуссия вокруг агентных циклов (agentic loops) становилась все громче и достигла своего пика на прошлой неделе. Но для меня реальность проще: промпт-инжиниринг сместился от решения отдельных задач к проектированию систем, и теперь моим основным ограничением в разработке ПО является рабочий процесс (workflow), а не сама модель.

Я разделяю работу, которую мы поручаем нашим агентам, на несколько различных уровней:

• Простой вопрос: здесь агент не требуется; на него может ответить обычный ассистент.
• Задача / идея: это то, что можно решить с одного промпта (zero-shot). Мне нравится использовать AI Studio для быстрого превращения идей в работающие прототипы.
• Приложение / крупная фича / стори: тип работы, который до появления ИИ требовал еженедельного планирования и разбиения на подзадачи. Именно здесь циклы начинают обретать смысл для выполнения задач, а полнофункциональные агенты, такие как Antigravity, приносят реальную пользу.
• Проект / эпик: несколько фич, которые при объединении образуют целостную историю. Циклы здесь могут помочь и с планированием. На этом уровне также необходимо выходить за рамки простых пошаговых диалогов (turn-based prompting).
• Система: все проекты и задачи, видимые с высоты птичьего полета. Это самый глубокий уровень, где создаются навыки (skills), настраиваются вспомогательные сервисы (sidecars) и конфигурируется панель инструментов, чтобы держать все под контролем. Циклы на этом уровне дают наибольший эффект.

Почему именно цикл?

Базовый уровень разработки программного обеспечения меняется. Этот сдвиг отражает фундаментальный закон человеческой природы: мы стремимся к максимальному увеличению рычага (leverage), переходя от ручного труда к делегированию, а затем к оркестрации. Поскольку внимание становится новым узким горлышком, любое решение, позволяющее продолжать работу с меньшим количеством прерываний, является шагом в правильном направлении. К началу 2026 года эмпирические исследования проектов с открытым исходным кодом показали, что внедрение кодинг-агентов достигло от 15% до 22% активных репозиториев на GitHub. Те, кто осваивает агентные рабочие процессы сейчас, получают рычаг, который многократно повышает продуктивность всей команды. Однако это также увеличивает когнитивную нагрузку на каждого, кто берет на себя ответственность на системном уровне.

Чтобы понять этот сдвиг, давайте проследим техническую эволюцию циклов и определим базовые ожидания.

Академический фундамент

Академическим фундаментом стала статья Яо и др. о методе ReAct в октябре 2022 года, в которой цепочки рассуждений чередовались с вызовами инструментов. Этот подход превзошел базовые модели обучения с подкреплением на 34% в ALFWorld и на 10% в WebShop благодаря тому, что модель рассуждала перед действием, повторяя человеческую природу: мы работаем лучше, когда проговариваем свои планы. Затем в начале 2023 года появился AutoGPT, привлекший миллионы венчурных инвестиций. Хотя его первые итерации часто уходили в бесконечные циклы, он доказал, что разработчикам нужна полная автоматизация без ручного вмешательства, подчеркнув необходимость структурных ограничений (guardrails).

Бесстаточные эксперименты

Как следствие, практики начали искать более простые архитектуры. В середине 2025 года разработчики запускали бесстаточные (stateless) bash-циклы, которые передавали промпты в CLI-агентов и сбрасывали файлы контекста на каждом шаге. Сброс контекста предотвращал когнитивную перегрузку, подтверждая, что ограничения человеческой памяти применимы и к моделям. Это позволило успешно создавать самокомпилируемые компиляторы за месяцы автоматических запусков. К весне 2026 года основные среды разработки вобрали в себя этот паттерн, предоставив нативные команды вроде /goal, позволяющие агентам работать в автономных циклах.

Математика автономии

Давайте рассмотрим простой теоретический пример: Если вы поместите своего агента в плоскую последовательную цепочку для выполнения нескольких задач подряд, вероятность его успеха будет снижаться экспоненциально. Когда каждый отдельный шаг является независимым вероятностным событием, последовательность из $N$ шагов имеет совокупную вероятность успеха $p^N$. Например, если вы запускаете задачу, требующую 20 последовательных изменений файлов с моделью, точность которой составляет $p = 0.95$, вы сталкиваетесь с вероятностью успеха всего в 36%. Без вашего структурного вмешательства они почти наверняка потерпят неудачу.

Именно поэтому нам нужны циклы оценки (evaluation loops). Проверочный барьер (verification gate) не должен заставлять вашего агента пытаться выполнить задачу бесконечно (что приводит к неконтролируемым бесконечным циклам). Вместо этого он должен точно определять, где произошла ошибка, и давать модели ровно одну целевую попытку для её исправления. Если базовая точность вашего агента составляет 95%, а ваш цикл оценки имеет 95%-ную вероятность обнаружить и исправить ошибку при этой единственной повторной попытке, эффективная вероятность успешного шага возрастает до $0.95 + (0.05 \times 0.95) = 99.75%$.

Даже если исправление не удастся, простое обнаружение ошибки с точностью 95% позволяет вам вмешаться и вручную скорректировать систему, сохраняя ту же точность субагента в 99.75% и оплачивая лишь стоимость вмешательства человека в контур (human-in-the-loop).

Что делать с раздуванием контекста?

Если каждый шаг в цепочке добавляет примерно 1% контекста в токенах, мы получим цепочку длиной не более 50 шагов, прежде чем потребуется сжатие. Базовая точность в 95%, которую можно оценить (и скорректировать курс с точностью 95% по каждому важному для нас направлению), должна обеспечивать хорошие показатели успешности для таких индивидуальных агентов. Если мы создадим масштабируемый способ разделения и властвования над проблемами, мы сможем применять аналогичные принципы для управления нашими субагентами. Как мы видим, на 20 шагах точность 95% в сочетании с корректирующим циклом с одной повторной попыткой дает 95% сквозного успеха (при условии, что сама коррекция укладывается в наш мягкий лимит в 20 шагов), сохраняя при этом разумный размер контекста. Обратите внимание, что нет жесткого требования, чтобы коррекция выполнялась именно ИИ или человеком, важнее, чтобы она давала точные и проверяемые результаты.

Именно на это я и делаю ставку: разделение проблем на задачи, каждая из которых требует небольшого количества шагов. Если проблема сложнее, она остается решаемой, но ее необходимо разделить на более мелкие подпроблемы и так далее. Для нашего примера это означает выделение до 20 шагов для каждого агента / задачи / траектории уровня и еще 20 шагов для контролирующего агента следующего уровня для консолидации результатов. Чтобы предотвратить отклонение от цели, это также означает создание отдельных оценок на всех уровнях субагентов и супервизоров, наряду с финальными критериями приемки.

Наконец, мы должны сами оценить эти метрики хотя бы один раз для каждого уровня, чтобы убедиться, что они измеряют именно то, что нужно, прежде чем запускать автоматизацию на более высоком уровне. Это приблизительные оценки, но я держу их в уме, чтобы быстро решить, стоит ли мне разделить проблему, повторить шаг или зафиксировать результаты и двигаться дальше.

На практике ваши цифры будут отличаться, но законы масштабирования будут схожими.

Как построить надежную систему

То, что начиналось как источник трудностей, теперь стало одним из моих главных профессиональных интересов: как нам строить автоматизацию, когда нам самим еще многое предстоит узнать о самом ремесле? У меня есть несколько идей.

Чтобы построить цикл, который не улетит в пропасть, мы должны установить базовые ограничения (guardrails), которые поддержат высокую точность и позволят нам отлаживать систему и вмешиваться в нее в любой момент. В частности, я выделил следующие столпы:

• Устойчивое состояние (Durable state): контрольные точки на базе Git гарантируют, что ваш агент сможет возобновить работу после сбоя.
• Проверочные барьеры (Verification gates): автоматизированные тестовые наборы и компиляторы детерминированно проверяют правильность изменений. При правильном подходе их точность будет >95%. Однако вам следует обращать внимание на пограничные случаи, о которых вы могли забыть. Особенно если показатели успешности верификации, оценки или ручной проверки расходятся для какой-либо из ваших фич.
• Эвалы (Evals): все, что нельзя проверить детерминированно, но что при этом важно, должно иметь оценку или бенчмарк, которые вы сможете позже изучить на предмет точности. Постарайтесь писать их так, чтобы ответы сводились к простому «да» или «нет», а точность оставалась высокой, в идеале выше 95%. Если вы получаете результаты, указывающие на путаницу или неожиданные сбои, вам, вероятно, нужно разбить критерии на более простые.
• Условия остановки (Halt conditions): лимиты на количество шагов (как мы видели выше, 20 шагов — это «золотая середина»), а также лимиты на токены или бюджет останавливают работу до того, как расходы на API выйдут из-под контроля.
• Стандартизированные навыки (Standardized skills): переиспользуемые утилиты, документированные в формате SKILL.md, предпочтительно поставляемые вместе с кодом и авторитетными источниками информации (sources of truth).

Нативные возможности платформ

Платформы вроде Antigravity кодифицировали эти паттерны (/grill-me и /goal) в нативные примитивы, перенеся работу из кастомных скриптов в возможности платформы для большинства стандартных сценариев использования. Я рекомендую вам попробовать их. Однако не забывайте следить за длиной траекторий и обращать внимание на возможную путаницу в действиях модели.

Я сам часто полагаюсь на нативные примитивы /goal в Antigravity 2.0 при координации многошаговых задач, требующих тщательной валидации и измерений перед завершением. Чтобы закрепить выполнение, я использую команду /grill-me для интерактивного интервью, чтобы зафиксировать проектные ограничения перед запуском циклов /goal.

Сбор метрик для этой технической статьи и её последующее редактирование — лишь один из примеров того, как я использую эти циклы выполнения.

Сочетая /goal с /grill-me, вы можете выстроить эффективную динамику парного программирования: согласование намерений на старте с последующей автономностью при выполнении.

Кастомные циклы своими руками

Чтобы понять эволюцию циклов, мы можем сравнить две разные архитектуры для самостоятельного создания агентных циклов:

Бесстаточный пятистрочник

Цикл «Ralph» Джеффри Хантли — отличный пример бесстаточной архитектуры. Вот простейшая рабочая версия CLI-цикла для Antigravity:

bashКопировать
limit=20
for ((i=1; i<=limit; i++)); do
agy -p - < prompt.md || break
./commit-and-test && break
done

Несмотря на простоту, бесстаточный цикл хрупок при координации работы с несколькими файлами, поскольку сброс контекста стирает логи размышлений модели.

Хороший агентный навык (skill) мог бы исправить большую часть этого ограничения, если проинструктировать модель выводить отчеты о прогрессе в файлы markdown (подобно wiki) и отслеживать изменения по логам git.

Тем не менее, эта сложность приводила к трудностям у разработчиков в более крупных мультиагентных средах, для которых кастомные циклы, судя по всему, являются многообещающим решением.

Что делать, если вы хотите погрузиться на глубину?

Если вы хотите попробовать написать кастомный цикл с нуля, вот практическая реализация на Python с использованием Google Antigravity SDK. В частности, этот цикл инициализирует сессию агента, выполняет задачу, проверяет результат и жестко контролирует лимиты итераций. Это экспериментальная отправная точка, которую вы можете адаптировать под свои нужды, а не готовое к продакшену решение:

pythonКопировать
import asyncio
from google.antigravity import Agent, LocalAgentConfig

async def verify_output(workspace_path: str) -> bool:
    """Проверочный барьер с тестами и эвалами."""
    # TODO: Запустите здесь тесты, линтеры и эвалы.
    return True

# 1. Определяем конфигурации субагентов с лимитом в 20 итераций и бюджетом токенов
research_config = LocalAgentConfig(
    system_instructions="You are a research subagent. Analyze the codebase and find implementation paths.",
    max_iterations=20,
    token_budget=50_000
)

feature_config = LocalAgentConfig(
    system_instructions="You are a feature implementation subagent. Write robust code and fix compiler errors.",
    max_iterations=20,
    token_budget=100_000
)

# 2. Передаем конфигурации исследователя и исполнителя как субагентов для супервизора
supervisor_config = LocalAgentConfig(
    system_instructions="You are a supervisor agent. Delegate to your research and feature subagents to complete tasks.",
    subagents={
        "researcher": research_config,
        "feature_implementer": feature_config
    },
    token_budget=200_000
)

async def run_agentic_loop(prompt: str, max_iterations: int = 20) -> bool:
    """Цикл супервизора. Мы явно создаем и запускаем только супервизора."""
    async with Agent(supervisor_config) as supervisor:
        iteration = 0
        success = False
        while not success and iteration < max_iterations:
            iteration += 1
            print(f"[Supervisor Loop] Running iteration {iteration}/{max_iterations}...")
            
            # Отправляем промпт супервизору; он сам запускает субагентов по мере необходимости
            response = await supervisor.chat(prompt)
            await response.text()
            
            # Контролируем лимиты расхода токенов в рамках сессии супервизора
            usage = supervisor.conversation.total_usage
            if usage.total_token_count and usage.total_token_count > supervisor_config.token_budget:
                print(f"❌ Loop halted: Token budget of {supervisor_config.token_budget} exceeded.")
                break
            
            # Проверяем результат в рабочей области
            success = await verify_output("./workspace")
            if success:
                print("🎉 Goal completed successfully.")
                break
                
            prompt = f"The previous attempt failed tests with the following error:\n{error_msg}\nFix the compiler errors and retry."
            
        return success

if __name__ == "__main__":
    asyncio.run(run_agentic_loop("Refactor types.go to use explicit interfaces.", max_iterations=20))

Для разработчиков, которые предпочитают не создавать и не хостить свои собственные кастомные циклы на базе SDK с нуля, Google предоставляет Antigravity Agent — автономного асинхронного кодинг-агента. Он работает в безопасной изолированной виртуальной машине Google Cloud. Таким образом, можно создавать аналогичные агентные циклы, используя управляемых агентов для оркестрации планов выполнения на инфраструктуре под управлением Google.

Универсальных решений не существует

Вы должны установить четкую границу для каждой из ваших систем валидации, которая позволит вам сохранять контроль. Насколько бы идеальным ни был ваш цикл, если вы, как ответственный человек, не можете аппрувнуть результат работы вашего агента, ценность создаваемых им артефактов стремится к нулю. Хорошая новость заключается в том, что создание качественной оценочной карты (scorecard) или алгоритма цикла использует те же процессы, что и создание любого другого программного артефакта. Так что большая часть выполнения будет автоматизирована.

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