Большинство современных инструментов агентной разработки полностью завязаны на постоянное обращение к внешним облачным API. Google обновил Antigravity SDK и добавил нативную поддержку локальных моделей: задачи аудита, поиска уязвимостей, генерации тестов и исправления кода теперь можно выполнять на рабочей станции разработчика без отправки исходников в облако через LiteRT, Ollama или vLLM.
Автономные AI-агенты требуют колоссального объёма токенов. Когда агент анализирует проект, запускает линтер, ловит ошибки в тестах, пробует исправить функцию и повторяет этот цикл пять раз подряд, счётчик токенов наматывает сотни тысяч за одну задачу. В коммерческой разработке это мгновенно упирается в два жёстких барьера: бюджет на API и требования информационной безопасности. Корпоративные правила часто прямо запрещают передавать проприетарный код сторонним провайдерам.
В большом разборе Google Antigravity мы подробно разбирали механику этой среды: агент не просто подсказывает строки в редакторе, а самостоятельно планирует задачу, правит файлы, использует терминал, проверяет интерфейс и готовит изменения. До сих пор вся эта логика требовала обращения к облачным Gemini или Claude.
Обновление Antigravity SDK от 23 сентября 2026 года меняет правила игры. Google открыл доступ к локальным средам исполнения моделей. Самая ресурсоёмкая и конфиденциальная часть работы теперь может оставаться внутри периметра разработчика.
Локальный стек: LiteRT, Gemma 4 и серверы с интерфейсом OpenAI
На аппаратном уровне Google сделал ставку на собственную экосистему Google AI Edge и среду исполнения LiteRT с библиотекой litert-lm. В качестве базовой локальной модели представлена Gemma 4 26B A4B. Связка оптимизирована для эффективной утилизации видеопамяти и оперативной памяти рабочей станции.
Но для практического применения куда важнее другое архитектурное решение. В SDK появился класс LocalOpenAIAgentConfig. Это означает сквозную поддержку любых серверов инференса, совместимых со стандартом OpenAI API: Ollama, vLLM или LM Studio.
Командам не навязывают единую модель или закрытый рантайм. Вся агентная инфраструктура Antigravity — изоляция рабочих пространств (workspaces), политики безопасности (policies), перехватчики действий (hooks) и цепочки инструментов — остаётся прежней. Разработчик просто подменяет бэкенд вызова модели и может крутить локально Qwen, Llama или специализированные открытые модели для работы с кодом.
import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy
MODELPATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")
WORKSPACE = os.path.expanduser("~/projects/core-api")
async def main():
config = LiteRTAgentConfig(
modelpath=MODELPATH,
workspaces=[WORKSPACE],
policies=[policy.allowall()],
).lightweight()
async with Agent(config) as agent:
response = await agent.chat("Проведи аудит безопасности и найди уязвимости в модулях авторизации")
async for token in response:
print(token, end="", flush=True)
if _name == "main_":
asyncio.run(main())При переходе на Ollama или vLLM код меняется минимально: вместо прямого пути к файлу весов указывается локальный адрес сервера и имя развёрнутой модели.
Архитектура «Архитектор — Исполнитель»: 95 токенов в облаке и 97% работы локально
Попытка полностью изолировать агента на слабой машине обычно приводит к разочарованию: небольшие локальные модели быстро теряют общую нить задачи при сложном планировании. Google предлагает не впадать в крайности, а использовать гибридный шаблон: «Архитектор — Исполнитель» (Architect-Builder).
В этой схеме роли строго разделены:
- Мощная облачная модель выступает архитектором и диспетчером. В демонстрации Google эту роль выполняет Gemini 3.8 Flash. Она получает только общую постановку задачи, дерево каталогов и имена файлов. Исходный код файлов в облако не отправляется. Архитектор декомпозирует задачу на последовательные шаги и спускает инструкции вниз. В контрольном примере на всё стратегическое планирование ушло всего 95 облачных токенов.
- Локальный пул моделей берёт на себя всю черновую работу. На машине разработчика запускается состязательный цикл аудита. Локальная Gemma 4 воспроизводит сценарий уязвимости, пишет вариант исправления, проверяет собственный патч на регрессию и запускает модульные тесты.
- Исходный код остаётся на диске. В опубликованном замере аудита трёх критических модулей (
auth.py,billing.py,database.py) 97,2% всех токенов (3 322 токена) были сгенерированы локально и без доступа к сети.
Второй наглядный сценарий — генерация локальных утилит с нуля без расхода квот. Агент по короткому текстовому запросу самостоятельно написал терминальный монитор ресурсов системы на базе библиотек psutil и rich, сгенерировал файл зависимостей requirements.txt, запустил утилиту и проверил корректность вывода на локальном экране.
Что меняется в реальной работе команд
Для инженерных команд этот шаг снимает главное противоречие внедрения ИИ-агентов. До сих пор приходилось выбирать: либо удобный автономный агент в облаке с риском утечки кода, либо урезанные локальные автокомплиты, которые не умеют работать с проектом как единым целым.
Гибридный контур решает четыре конкретные задачи:
- Соответствие требованиям безопасности (Compliance). Финтех, медицинские сервисы, государственные подрядчики и закрытые корпоративные хранилища могут применять агентные инструменты. Проприетарные алгоритмы не покидают периметр рабочей станции или защищённого локального сервера компании.
- Обнуление стоимости токеноёмких итераций. Рутинные операции — прогон через статические анализаторы, генерация вариантов типизации, написание сотен однотипных модульных тестов и взаимное ревью патчей — больше не требуют расходов на оплату облачных API.
- Устойчивость к перебоям связи. Разработчик может продолжать глубокий рефакторинг или аудит локального репозитория в изоляции, без привязки к стабильности интернет-соединения или доступности зарубежных сервисов.
- Защита от ограничений частоты запросов (Rate limits). Локальный агент не упирается в лимиты запросов в минуту при массовой обработке сотен файлов проекта.
Железо, задержки и потолок рассуждений
У локального исполнения есть объективные барьеры, о которых важно знать до начала настройки рабочего места.
Первое ограничение — требования к оперативной и видеопамяти. Для комфортной работы Gemma 4 26B A4B через LiteRT Google рекомендует рабочую станцию с объёмом не менее 24 ГБ VRAM или объединённой памяти (Unified Memory). На стандартных офисных компьютерах с 16 ГБ RAM развернуть 26-миллиардную модель без тяжёлой потери производительности не выйдет. В таких случаях придётся переключаться на Ollama с более компактными моделями калибра 7B–9B.
Второе — задержки генерации. Локальный инференс на потребительских видеокартах работает медленнее серверных облачных кластеров. В официальном примере от Google прямо указано, что локальный ответ может занимать несколько минут. Для фонового ночного рефакторинга или проверки перед коммитом это приемлемо, но в интерактивном диалоге паузы будут ощутимы.
Третье — потолок логических рассуждений. Ни одна компактная локальная модель пока не способна сравниться с флагманскими Gemini 3 Pro или Claude Sonnet 4.5 на сложной архитектурной декомпозиции. Если попытаться полностью отключить облако и поручить локальной модели всё проектирование большой системы, качество решений неизбежно просядет. Гибридная связка здесь — вынужденная и грамотная инженерная необходимость.
Четвёртое — статус SDK. Поддержка LiteRT-LM и локальных серверов находится на этапе раннего превью. Инструменты активно дорабатываются, а поведение на разном оборудовании под Linux, macOS и Windows может различаться.
С чего начать тестирование
Я рекомендую не переносить в локальный контур все процессы сразу, а протестировать его на одной контролируемой задаче:
- Установите Antigravity SDK и поднимите локальный инференс-сервер — например, привычную Ollama с качественной моделью для кодинга (Qwen 2.5 Coder 14B или 32B при наличии подходящей видеокарты).
- Выберите одну изолированную задачу: генерацию модульных тестов для вспомогательного модуля или поиск забытых проверок входных данных.
- Замерьте три параметра: время выполнения итерации, нагрузку на память рабочей станции и процент корректных исправлений, которые принимаются без ручной доработки.
- Если результаты стабильны, соберите гибридный пайплайн: пусть облачная модель готовит план и разбивает изменения на атомарные шаги по именам файлов, а локальный агент выполняет правку кода и валидацию тестов.
Агенты возвращаются на рабочие станции
Последние два года индустрия развивалась под знаком тотальной централизации: считалось, что любой полезный агент обязан жить в облачном дата-центре. Обновление Antigravity SDK показывает начало обратного тренда.
Агентная инфраструктура разделяется на уровни. Стратегическое планирование и глобальный контекст остаются за облачными флагманами, но само исполнение, работа с кодовой базой и проверка гипотез возвращаются туда, где этот код физически находится — на компьютеры разработчиков. Это делает автономных агентов не только дешевле, но и применимыми в тех отраслях, куда облачный ИИ до сих пор не пускали соображения безопасности.
Ссылки