SeedRealtime, Seeduplex и полнодуплексный телефонный агент Android

Что SeedRealtime и Seeduplex меняют для телефонных агентов

SeedRealtime и полнодуплексный телефонный агент стали важной темой для всех, кто строит voice-first phone experience. 9 апреля 2026 года ByteDance Seed представила Seed Full-Duplex Speech LLM и Seeduplex: native listen-while-speaking framework, где модель может слушать пользователя во время собственного ответа. Это меняет темп разговора. Пользователь может перебить, уточнить, сказать «нет, не так», продолжить мысль или добавить условие, пока ассистент еще говорит.

На странице семейства моделей ByteDance также отдельно показывает SeedRealtime, и для рынка это сигнал: real-time voice interaction становится не демо-эффектом, а отдельным направлением моделей. Seed сообщает об улучшениях в interference suppression, endpointing и interruption handling, а также о rollout в Doubao. Эти заявления важны как вендорская оценка возможностей, а не как независимый benchmark всех телефонных агентов.

Для нас в FoneClaw главный вывод практический. Полнодуплексный голосовой ИИ делает разговор естественнее, но телефонная задача заканчивается не словами, а действием: изменить режим, подготовить SMS, открыть маршрут, начать звонок, переключить настройку, восстановить разрешение. Поэтому real-time voice model должна соединяться с execution layer, где действие остается видимым и управляемым. Более широкий тезис о телефоне, где голос становится первым входом, мы развиваем в статье AI-смартфон с голосом как главным интерфейсом: почему экран больше не должен быть первым.

Как full-duplex voice AI работает с паузами, шумом и перебиваниями

Обычный half-duplex голосовой помощник похож на разговор по рации: пользователь говорит, система ждет конец фразы, затем отвечает. Если пользователь перебивает, помощник часто теряет часть контекста или продолжает говорить поверх него. Full-duplex voice AI устроен иначе: слушание и генерация идут параллельно. Для телефонного агента это особенно важно, потому что пользователь часто меняет задачу на ходу: «поставь режим встречи… подожди, только на час… и включи звук для жены».

Технически здесь сразу появляются сложные задачи. Endpointing должен понимать, где пользователь закончил мысль, а где просто сделал паузу. Barge-in должен распознавать осмысленное перебивание, а не фоновый шум. Interference suppression помогает отделить речь пользователя от голоса модели, музыки, улицы, клавиатуры и других людей. Seed в релизе Seeduplex связывает свою full-duplex архитектуру именно с более внимательным слушанием, подавлением помех и обработкой перебиваний.

Исследовательский контекст показывает, почему это трудно. Работа How Should LLMs Listen While Speaking? описывает routing problem: что делать с пользовательским аудио, которое приходит во время генерации ответа. Channel fusion и cross-attention routing дают разные компромиссы между grounding и robustness к предыдущему контексту. Для продукта это означает, что «слушать во время речи» — не одна кнопка, а выбор архитектуры, задержки, памяти и поведения при шуме.

Скорость модели тоже влияет на ощущение живого разговора. Низкая задержка помогает ассистенту отвечать естественно, обрабатывать поправки и не заставлять пользователя ждать. Эту сторону мы отдельно разбираем в материале LLM на 1000 TPS и эпоха телефонных AI-агентов. Но быстрая речь модели не заменяет проверку Android-действия: даже мгновенный ответ должен пройти через permission, approval и verification, если он меняет состояние телефона.

Почему разговор и Android-выполнение живут в разных плоскостях

Мы в FoneClaw разделяем две плоскости: interaction plane и execution plane. Interaction plane отвечает за разговор: услышать, понять, уточнить, принять перебивание, обработать шум, продолжить диалог. SeedRealtime и Seeduplex двигают вперед именно эту часть. Execution plane отвечает за Android-действие: какой экран открыт, какой инструмент доступен, какое разрешение нужно, какой шаг меняет состояние, где требуется подтверждение и как проверить результат.

Когда эти плоскости смешивают, возникает опасная иллюзия. Ассистент может звучать очень уверенно и естественно, но естественный голос не является разрешением на отправку SMS, изменение DND, удаление файла или запуск звонка. Фраза «да, сделай» должна быть привязана к конкретному действию, объекту и текущему состоянию телефона. Иначе модель хорошо разговаривает, но пользователь не понимает, что именно будет выполнено.

Android добавляет реальные системные условия: permission flows, app state, accessibility, default handlers, foreground screens, protected dialogs, разные OEM-настройки. Практичный телефонный агент должен видеть эти условия как часть задачи. Он должен уметь сказать: контакт неоднозначен, кнопка отправки нестабильна, разрешение отсутствует, экран изменился, действие требует выбора пользователя.

Поэтому для FoneClaw real-time voice model — это вход в задачу, а governed execution layer — путь к результату. Общий принцип Android phone-agent execution мы подробно раскрываем в статье Управление телефоном AI-агентом: как Android переходит от команд к действиям. Full-duplex делает разговор гибким; execution contract делает действие надежным.

Семь этапов от голосового намерения до проверенного результата

Архитектура Android-агента начинается с контракта. Мы используем семь этапов, которые помогают соединить голосовой агент реального времени с реальным телефоном. Первый этап — capture: пользователь запускает голосовой ввод и дает намерение. В текущем FoneClaw voice input является user-triggered, поэтому команда появляется в контексте явного действия пользователя.

Второй этап — clarify. Full-duplex model может уточнять без жесткой очередности: пользователь перебивает, добавляет условие, меняет время, исправляет имя. Агент удерживает смысл, а не только последнюю фразу. Третий этап — plan: модель превращает запрос в поддерживаемый Android-маршрут, выбирает инструмент, проверяет контекст, ожидаемый результат и риски.

Четвертый этап — approve. Действие с последствиями должно быть связано с конкретным объектом: какой режим будет включен, кому уйдет сообщение, какой маршрут откроется, какая настройка изменится. Подробную механику такого UX мы раскрываем в статье Интерфейс подтверждения действий ИИ-агента на телефоне: уверенность, причины и восстановление. Пятый этап — execute: governed tool выполняет поддерживаемое действие через Android permission flows.

Шестой этап — verify. Агент проверяет, что результат действительно появился на телефоне: DND включен, SMS-черновик создан, навигация передана выбранной карте, звонок подготовлен. Седьмой этап — recover. Если разрешение отсутствует, экран устарел, приложение изменилось или пользователь остановил задачу, агент сохраняет состояние и предлагает следующий путь. В full-duplex мире этот контракт особенно важен: быстрый разговор не должен перепрыгивать через проверяемые этапы выполнения.

Как мы строим текущий execution layer FoneClaw

По актуальной информации о продукте на момент обновления статьи, FoneClaw является текущей базой нашего execution plane. В доступные возможности входят floating assistant, same-phone task continuity, permission recovery и quick actions. Это не интеграция с SeedRealtime; это наш shipped Android layer, который показывает, как разговорное намерение должно переходить в видимое и recoverable телефонное действие. Актуальную сборку можно получить на странице загрузки FoneClaw.

Мы делаем voice и screen context user-triggered. Пользователь сам вызывает ассистента, сам прикрепляет текущий экран, сам видит, какая задача выполняется и где требуется подтверждение. Текущий экран прикрепляется по действию пользователя, а не как непрерывное наблюдение. Эта модель важна для доверия: агент получает контекст, когда он нужен для задачи, и возвращает понятный результат.

Плавающий ассистент помогает держать FoneClaw рядом с рабочим экраном. Home и floating assistant поддерживают непрерывность выполнения, approvals, stopping и permission recovery на одном телефоне. Если пользователь начинает задачу из приложения, а затем возвращается в Home для подтверждения или восстановления доступа, задача сохраняет направление. Подробно этот current-screen путь описан в статье Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль.

Сейчас FoneClaw работает с выбранными governed Android workflows: DND, видимые messaging-сценарии, dialer, navigation и selected settings. Обзор текущих возможностей находится на странице функций FoneClaw. Для нас это практическая база будущего phone-agent stack: модель может стать быстрее и естественнее, но Android-действие по-прежнему должно проходить через permission, approval, verification и recovery.

Сценарии full-duplex phone agent, где нужны safeguards

Первый сценарий — meeting DND. Пользователь говорит: «Включи режим встречи на час», затем перебивает: «стой, оставь звонки от семьи». Full-duplex model должна принять поправку во время ответа. Execution layer должен показать итог: DND на час, исключение для выбранных контактов, подтверждение перед изменением и проверку результата после применения. Без этого естественный разговор не дает уверенности, что телефон изменен правильно.

Второй сценарий — messaging. Пользователь диктует: «Напиши Антону, что я опоздаю на двадцать минут», ассистент начинает повторять, пользователь перебивает: «не Антону клиенту, а Антону из доставки». Interaction plane должен обработать поправку. Execution plane должен проверить контакт, текст, приложение по умолчанию и стабильный Send control. Если появляется dual-SIM prompt или вложение, действие остается видимым для выбора пользователя.

Третий сценарий — call или navigation. Пользователь просит: «Позвони врачу… подожди, сначала открой маршрут до клиники». Полнодуплексный голосовой ИИ помогает естественно изменить приоритет. Телефонный агент должен подготовить звонок или передать маршрут в выбранное map app, показывая объект действия. Для навигации особенно важно, чтобы пользователь видел адрес, приложение и начало маршрута.

Четвертый сценарий — прерванная многошаговая задача. Пользователь попросил собрать уведомления, подготовить ответ и включить тихий режим. Потом приходит звонок, приложение закрывается или разрешение отсутствует. FoneClaw должен сохранить состояние: что уже понято, что ждет, какой доступ нужен, что можно восстановить. Именно здесь full-duplex conversation и governed Android execution начинают работать вместе: разговор живой, а действие проверяемое.

Приватность, батарея, аудио-визуальные ограничения и следующий шаг

Полнодуплексный голосовой ИИ усиливает требования к приватности и ресурсу устройства. Если система слушает во время собственного ответа, пользователь должен понимать, когда микрофон активен, какой ввод идет в модель, как остановить сессию и какие действия требуют отдельного подтверждения. В FoneClaw текущий голосовой ввод запускается пользователем, а current-screen context прикрепляется по явному действию, что помогает держать границу контекста понятной.

Батарея и задержка тоже становятся архитектурными вопросами. Real-time audio, noise suppression, routing и model inference требуют ресурсов. На телефоне это влияет на нагрев, автономность, стабильность фоновых процессов и UX. Практичный агент должен уметь выбирать: когда держать короткую live-сессию, когда перейти к обычному запросу, когда остановить listening и когда вернуть управление на экран.

Визуальная часть остается отдельным рубежом. В релизе Seeduplex visual input и proactive interaction указаны как future work. Исследование VideoFDB full-duplex audio-visual benchmark показывает, что streaming audio-visual grounding является отдельной сложной задачей: системы часто недоиспользуют visual streams вне прямых визуальных вопросов. Для phone agent это означает, что listen-see-speak нельзя считать решенным одной маркетинговой меткой.

Наш builder checklist для следующего поколения phone agents такой: user-triggered listening, явный screen context, устойчивое состояние задачи, понятный approval перед external effect, Android permission recovery, verified result, остановка в любой момент, экономный режим батареи и отдельная визуальная политика. SeedRealtime и Seeduplex показывают, куда движется разговор. FoneClaw строит практический governed layer, который превращает разговорное намерение в действие на Android с контролем пользователя.