Google ADK 2.13.0 добавил маршрутизацию через классификаторы, прерывание речи и хранение в MongoDB

Google опубликовала ADK для Python версии 2.13.0. Обновление расширяет инструменты разработки агентов сразу в трёх направлениях: маршрутизация запросов через классификаторы, голосовые диалоги с возможностью перебить ответ и постоянное хранение состояния в MongoDB. GitHub датирует публикацию релиза 23 октября 2026 года, хотя заголовок включённого журнала изменений содержит дату 22 октября.

Одновременно 12 ранее экспериментальных возможностей получили стабильный статус. Это не означает стабилизации всех новинок: пакет классификаторов и новые сервисы MongoDB пока остаются экспериментальными. Отдельного внимания требует несовместимое изменение телеметрии.

Классификатор выбирает ветвь процесса

Новый ClassifierNode объединяет классификацию входных данных и выбор дальнейшего маршрута. Узел задаёт один вопрос типа Choice или Binary: например, определяет, относится обращение к оплате или технической поддержке. Ответ выбирает ветвь графа, а следующий узел получает исходные данные без изменений. При построении Workflow проверяется соответствие меток и маршрутов, что позволяет обнаружить опечатки и отсутствующие переходы до исполнения.

Для моделей Jev от TypeSafe добавлен TypesafeClassifier. Интеграция обращается к API TypeSafe и требует ключа, переданного явно или через TYPESAFE_API_KEY. Разработчики описывают Jev как модели, возвращающие вероятности за один проход вместо генерации текста. Их преимущество в скорости следует воспринимать как заявление разработчиков: приведённые материалы не дают основания обещать такой же выигрыш для любого агентного приложения.

Голосовой ответ можно перебить

В CascadeLive добавлены поддержка прерывания ответа пользователем и интеграции Gemini для распознавания и синтеза речи. Архитектура CascadeLive разделяет распознавание звука, работу текстовой модели и озвучивание результата. Это позволяет использовать голосовой интерфейс вместе с обычной текстовой LLM и её инструментами.

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

Сессии и память в MongoDB решают разные задачи

MongoDbSessionService сохраняет сессии, историю событий и состояние приложения и пользователя. Несколько процессов Runner могут работать с общей базой, сохраняя данные между перезапусками. Для подключения документация предлагает установить google-adk[mongodb], создать сервис с параметрами подключения и передать его в Runner.

Условия развёртывания здесь существенны. На replica set, шардированном кластере или Atlas связанные записи выполняются в общей транзакции. На отдельном сервере mongod сервис переходит к последовательным записям без атомарности между документами. При попытке записать событие в устаревшую версию сессии возникает StaleSessionError: вызывающий код должен заново загрузить сессию и повторить операцию.

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

Что проверить перед обновлением

По умолчанию релиз переходит на OpenTelemetry GenAI v2 с идентификатором otel_semconv_1_44 и удаляет span call_llm. Поэтому запросы, панели и правила наблюдаемости, зависящие от прежней структуры трассировок, требуют проверки. В примечаниях к релизу указан способ сохранить старую схему: ADK_TELEMETRY_SCHEMA_VERSION_OPT_IN=otel_semconv_1_36.

Авторы также сообщают о сокращении времени отдельного хода агента с моделью, заданной строкой, с 20 до 2,5 мс — отсюда заявленное ускорение до восьми раз. Это результат для конкретного пути исполнения в условиях разработчиков, а не подтверждённое восьмикратное ускорение полного запроса с вызовами модели, инструментов и базы данных.