Голос стал той функцией, которую спешит внедрить каждая платформа ИИ-агентов. Очевидный шаг — реализовать его как отдельный канал, нечто, существующее параллельно с вашим веб-приложением, CLI-инструментом или Telegram-ботом. Это кажется интуитивно понятным. Видите голос — создаете голосовой интерфейс. Но этот инстинкт ведет к хрупкой архитектуре. Он дублирует работу, портит логи и постепенно искажает контекст вашего проекта.
В APC и APX мы выбрали другой путь. Голос — это не канал. Это режим. Он накладывается на поверхность, а не заменяет её. Именно правильное понимание этого различия позволяет системе не распадаться.
Неправильная абстракция
Когда вы относитесь к голосу как к отдельному каналу, вы неявно предполагаете, что разговор с агентом голосом фундаментально отличается от переписки с ним. Команды разработчиков реагируют на это разделением кодовой базы. Внезапно появляется CLI-канал и отдельный голосовой CLI-канал. Появляется веб-канал и параллельный голосовой веб-канал. Каждый требует своих вариаций промптов, правил форматирования и логики обработки контекста.
Именно здесь начинается хаос. Теперь любое изменение в поведении агента должно быть скопировано во множество деревьев промптов. Если команда забудет про одну из поверхностей, пользовательский опыт фрагментируется. Пользователи получают один тон в тексте и слегка иную личность в речи. Со временем эти небольшие несоответствия накапливаются, приводя к дрейфу системы. Переносимый слой контекста перестает быть переносимым, потому что ему приходится учитывать голосовую подачу в одной ветке и безмолвный текст в другой. Происходит утечка абстракции, и ваше некогда единое определение проекта рассыпается на набор специфических хаков для каждого канала.
Разделение контекста и среды выполнения
Чтобы предотвратить это, мы разделили обязанности между двумя слоями, которые строго изолированы друг от друга.
APC хранит контекст проекта. Он определяет агентов, правила и навыки, из которых состоит проект. Думайте об этом как о стабильном смысле системы. Он отвечает на структурные вопросы: Что знает этот агент? Что ему разрешено делать? Какие инструменты он может вызывать? APC должен оставаться полностью агностичным к тому, будет ли ответ отрисован на экране, отправлен через API чата или выведен через динамик.
APX управляет слоем среды выполнения (runtime). Он управляет поверхностями, с которыми вы фактически взаимодействуете: CLI, веб-приложением, десктопным интерфейсом, Telegram-ботом. Когда пользователь отправляет запрос, APX выбирает, где и как представить ответ. Решение о том, форматировать ли ответ для чтения или оптимизировать его для речи, — это задача среды выполнения. Это относится к APX, а не к APC.
Такое разделение означает, что проект, определенный в APC, остается целостным, независимо от того, сколько поверхностей предоставляет APX. Контракт не меняется. Меняется только уровень представления.
Как на самом деле работают режимы
В нашей реализации такие поверхности, как Telegram, CLI и веб-приложение, являются каналами. Канал сообщает вам, где произошло взаимодействие. Голос накладывается через метаданные канала как режим. Режим сообщает вам, как должен вести себя ответ.
Конструктор промптов соблюдает эту границу. Он извлекает данные из контекста проекта в APC, а затем проверяет метаданные канала. Если десктопная поверхность работает в голосовом режиме, конструктор добавляет целевые инструкции только в этот момент. Возможно, он дает модели указание использовать более короткие предложения, более четкую пунктуацию для синтеза речи или правила произношения чисел. Если та же десктопная поверхность работает в текстовом режиме, эти голосовые инструкции в промпт не попадают.
Результатом является единое дерево промптов на каждую поверхность. Здесь нет отдельной ветки voice-desktop. Нет варианта whisper-web. Модификатор применяется только тогда, когда его запрашивает среда выполнения, и только в самый последний ответственный момент. Основной промпт остается неизменным.
Что вы получаете
Эта архитектура окупается тремя конкретными способами.
Снижение затрат на обслуживание. Если бы голос был отдельным каналом, каждой поверхности потребовался бы двойник. Вам пришлось бы поддерживать CLI-канал и голосовой CLI-канал, Telegram-канал и голосовой Telegram-канал и так далее. Каждый раз, когда вы корректируете системный промпт, исправляете баг форматирования или уточняете описание навыка, вам пришлось бы распространять это изменение по обоим деревьям. Пропустите одно — и пользователи заметят разрыв. Используя режим, вы сохраняете одно дерево промптов на поверхность. Голос становится условным наложением, а не развилкой на пути, поэтому ваша рабочая нагрузка растет линейно по мере добавления новых способов взаимодействия.
Точное логирование. Каналы фиксируют, где произошло взаимодействие. Режимы фиксируют, как был доставлен ответ. Взаимодействие на десктопе остается взаимодействием на десктопе, независимо от того, прочитал его пользователь или услышал. Когда ваша команда отслеживает баг или изучает аналитику, им не приходится сопоставлять «desktop-voice» с «desktop-text», как если бы это были разные поверхности продукта. Идентификатор канала остается чистым, а флаг режима аккуратно располагается рядом в метаданных. Ваши логи остаются достоверными, а отладка — простой, потому что местоположение и поведение не перепутаны между собой.
Чистый контекст проекта. APC определяет контракт. Ему должно быть все равно, произносится ли ответ шепотом, проговаривается ли он вслух или отображается моноширинным шрифтом. Это вопросы времени выполнения (runtime). Сохраняя форматирование голоса внутри APX, мы обеспечиваем переносимость APC. Вы можете взять определение проекта APC и перенести его в совершенно новую среду выполнения, не таща за собой допущения по форматированию голоса или лишний код для оптимизации речи. Граница сохраняется, а смысл проекта остается неизменным.
Доказательство на десктопе
Наш собственный путь десктопного приложения демонстрирует это в повседневном использовании. Десктоп — это поверхность. Когда пользователь включает голосовое управление, система запускает ту же самую десктопную поверхность в голосовом режиме. Поскольку голос находится на уровне режима, десктопный канал сохраняет свой полный контекст и поведение. Он не превращается в другой продукт с другими правилами. Конструктор промптов просто замечает флаг и добавляет голосовые инструкции только тогда, когда это необходимо. Когда пользователь возвращается к тексту, эти инструкции полностью исчезают. Базовый контекст проекта никогда не менялся. Десктоп всегда оставался десктопом.
Главный вывод
Основная идея проста. APC описывает стабильный смысл проекта. APX описывает выполнение в рантайме. Голос — это модификатор поверхности, а не её замена. Относитесь к нему именно так, и ваши промпты останутся компактными. Ваши логи останутся чистыми. Ваши