# Полный дуплекс изменил автомат состояний голосового агента

Как выпуск GPT-Live-1 в API меняет управление состояниями голосового агента и обнаруживает границы отмены и обработки устаревших результатов.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-10
Первоисточник новости: https://openai.com/index/introducing-gpt-live-1-in-the-api/
Канонический URL: https://retrivium.ai/ru/retrospectives/live-api-full-duplex-state-machine/

## От чередования реплик к одновременному звуку

[Анонс Realtime API от 1 октября 2024 года](https://openai.com/index/introducing-the-realtime-api/) описывал более ранний интерфейс речевого взаимодействия. [GPT-Live появилась 8 июля 2026 года](https://openai.com/index/introducing-gpt-live/), а [10 сентября вышла её версия для разработчиков API](https://openai.com/index/introducing-gpt-live-1-in-the-api/). Последний выпуск сделал одновременное слушание и говорение задачей прикладной архитектуры. Разговор уже нельзя достаточно точно представить единственным переключателем между вводом пользователя и ответом помощника. Входящая речь способна изменить запрос в тот момент, когда помощник объясняет прежнее понимание задачи и ещё не закончил свою фразу.

## Звуковая активность и владение задачей различаются

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

## У отмены бывает несколько целей

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

## Трасса, объясняющая наложение реплик

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

## Граница архитектурного вывода

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

## Связанные материалы

- [Трассировка принадлежности запросов](/ru/journal/provider-request-id-trace-context/)
- [Измерение временных границ](/ru/journal/provider-monotonic-latency-measurement/)