Vertex AI Extensions закроется 26 ноября: три пути миграции на Agent Platform

Google тихо объявила об отказе от Vertex AI Extensions 26 мая 2026 года и установила жёсткую дату отключения — 26 ноября 2026 года, ровно через шесть месяцев. Для инженерных команд, построивших agent-воркфлоу на Code Interpreter, Google Search или Custom Extensions, это вынужденная архитектурная миграция с реальным дедлайном. Разберём, что меняется, почему это важно и как подойти к миграции.

Что произошло

Vertex AI Extensions — это управляемый runtime-слой, позволявший моделям Gemini вызывать предустановленные или кастомные tool-серверы в рамках generation-запроса. Три основных типа extensions:

• Code Interpreter — управляемая sandbox-среда для выполнения AI-сгенерированного кода в ходе диалога
• Google Search — заземлённый поиск с внедрением результатов в контекст модели
• Custom Extensions — пользовательские инструменты, определённые через спецификацию OpenAPI и зарегистрированные в Vertex

Google перенесла эти возможности в Gemini Enterprise Agent Platform (ранее Reasoning Engine / Agent Engine) — новое поколение управляемого agent-runtime. Extensions API перестанет принимать запросы после 26 ноября 2026 года. Никакого grace period после этой даты не предусмотрено.

Почему это важно для AI-инженерных команд

Vertex AI Extensions нередко служила связующим слоем в enterprise-развёртываниях на базе Gemini. Под угрозой — команды, использующие:

1. Выполнение кода в data science или финансовых воркфлоу — замена Code Interpreter требует многошаговых изменений в SDK, а не просто переключения конфига.
2. RAG-пайплайны с Google Search grounding — Search Extension заменяется нативным grounding в Gemini и инструментом GoogleSearch в Agent Platform SDK.
3. Кастомные инструменты по OpenAPI-спецификации — Custom Extensions требуют миграции на шаблон FunctionTool или MCPTool в Agent Platform, включая повторную регистрацию схем и обновление логики вызовов.

Подход на базе Extensions помещал логику оркестрации в управляемый слой Vertex. Agent Platform смещает контроль в сторону Agent Development Kit (ADK) — это означает больше кода, зато выше портируемость.

Три пути миграции

Code Interpreter → Code Execution Sandbox в Agent Platform

Прямая замена — AgentEngineSandboxCodeExecutor в ADK или инструмент code_execution в SDK google-genai. Оба запускают изолированные, stateful sandbox-среды. Ключевое отличие с точки зрения оператора: имена sandbox-ресурсов теперь нужно предоставлять отдельно и передавать во время runtime. Команды с большим числом параллельных сессий должны оценить необходимость sandbox pooling и управления жизненным циклом сессий.

Google Search Extension → Нативный Gemini Grounding

Инструмент GoogleSearch теперь является first-class параметром в generation-запросах Gemini. Командам, маршрутизировавшим запросы через Extensions API для получения web-grounded ответов, достаточно переключиться на tools=[types.GoogleSearch()] в SDK — это убирает лишний сетевой хоп и накладные расходы на регистрацию Extension. Для команд, использующих Vertex AI Search (enterprise-корпус), эквивалент — VertexAISearch.

Custom Extensions → Function / MCP Tools в Agent Platform

Custom Extensions определялись как OpenAPI-спецификации, зарегистрированные в консоли Vertex. Эквиваленты в Agent Platform: FunctionTool (встроенные Python-функции), OpenAPITool (внешние OpenAPI-спецификации) или MCPTool (серверы Model Context Protocol). Путь через MCPTool — наиболее портируемый: если инструменты уже доступны через MCP, миграция сводится в основном к обновлению реестра. Custom Extensions со сложными схемами запросов/ответов потребуют работы по маппингу схем.

Угол маршрутизации и стоимости

Если ваша команда маршрутизирует к Google через OpenAI-совместимый gateway TheRouter, сам факт deprecation не изменяет конфигурацию роутинга — model ID и поведение endpoint не затронуты. Меняется архитектура вызовов инструментов выше по стеку, до routing-слоя.

Миграция также — хороший повод переоценить, должны ли вызовы инструментов вашего agent вообще жить внутри управляемого runtime Vertex. ADK ориентирован на нативные развёртывания в Vertex, но командам, требующим портируемости между провайдерами — один и тот же agent против Anthropic, OpenAI или DeepSeek — может больше подойти provider-agnostic слой вызова инструментов.

Ключевое решение: ADK vs. provider-agnostic оркестрация

Что сделать до 26 ноября

1. Проаудировать использование Extensions — составить список всех зарегистрированных extensions в консоли Vertex AI и классифицировать их по трём категориям. Custom Extensions со сложными auth-флоу потребуют больше всего времени.
2. Протестировать замены Code Interpreter — sandbox executor в ADK и инструмент code_execution имеют разную семантику сессий. Проверьте требования к stateful-поведению для вашей нагрузки.
3. Начать с Search Extensions — минимальный объём работы; для большинства воркфлоу переход на инструмент GoogleSearch — изменение одной строки в SDK.
4. Проверить маппинг схем Custom Extensions — трансляция OpenAPI → FunctionTool может давать silent failures на граничных случаях схем (nullable union, паттерны allOf/anyOf). Тестируйте на репрезентативных входных данных.
5. Обновить observability-хуки — Extensions генерировала собственный audit trail в Vertex logs. Формат логов Agent Platform иной; обновите запросы в системе мониторинга.

Дедлайн 26 ноября даёт командам около пяти месяцев. На первый взгляд — достаточно, но с учётом типичного замедления темпа разработки в Q3, staging и нагрузочного тестирования — начинать аудит нужно сейчас.

Ссылки

• Объявление об отказе от Vertex AI Extensions
• Руководство по миграции: Extensions → Agent Platform