Статья

Построение невизуальных интерактивных интерфейсов с интегрированными интеллектуальными агентами на примере платформы LUWRAIN

Пожидаев М. С., Сущенко С. П., Теплых Е. С.

Ключевые слова: Java, Accessibility, Агенты, AI, UI/UX

Введение

Появление трансформерной архитектуры в 2017 г. привело к глубокому переосмыслению многих технологий, связанных с обработкой естественного языка и взаимодействием человека с вычислительными системами. Дальнейшее развитие этой архитектуры легло в основу больших языковых моделей, которые принято относить к системам искусственного интеллекта.

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

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

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

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

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

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

Платформа LUWRAIN предлагает иной подход к организации рабочего пространства для незрячих пользователей. Она представляет собой Java-фреймворк для создания невизуальных приложений, в котором содержимое, элементы управления и результаты взаимодействия приведены к текстовой форме. Благодаря этому пользователь работает не с адаптированным представлением графического интерфейса, а с изначально невизуальной средой, организованной в соответствии с особенностями слухового и тактильного восприятия.

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

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

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

1. Обзор предшествующего опыта

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

Одним из ранних примеров специализированного интерфейса ввода является аккордовая клавиатура Engelbart chord keyset, разработанная Дугласом Энгельбартом в 1960-х годах в рамках создания системы oN-Line System (NLS) [3, 4]. Устройство состояло из пяти клавиш и позволяло вводить символы и команды посредством одновременного нажатия различных комбинаций клавиш, то есть «аккордов». Такой принцип обеспечивал доступ к значительному числу операций при минимальном количестве физических элементов управления. Аккордовая клавиатура применялась совместно с обычной клавиатурой и компьютерной мышью и была ориентирована на повышение эффективности навигации, редактирования и работы со структурированной информацией.

Использование chord keyset отражало предложенную Энгельбартом концепцию расширения интеллектуальных возможностей человека, в соответствии с которой вычислительная система должна помогать пользователю решать сложные интеллектуальные задачи, а не только выполнять отдельные операции [3]. Вместе с тем аккордовая клавиатура не устраняла микроконтроль, а делала его более эффективным. Пользователь по-прежнему должен был знать доступные команды, выбирать очередную операцию и самостоятельно определять последовательность действий. Таким образом, уменьшение числа физических элементов управления и повышение плотности ввода сами по себе ещё не означали перехода к управлению на уровне целей и намерений.

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

Похожая идея получила развитие в макросах и системах программирования по демонстрации. Макрос позволяет один раз записать последовательность действий, а затем многократно выполнять её как единую команду. В системах программирования по демонстрации предпринимается попытка автоматически построить процедуру на основании действий пользователя и выявить общий принцип их выполнения [1, 5]. Такой подход снижает требования к владению языками программирования и оказывается удобным для регулярно повторяющихся операций. Вместе с тем создаваемая процедура обычно оказывается связанной с конкретной структурой интерфейса и плохо переносится на задачи, которые отличаются от исходного примера. Кроме того, пользователь должен сначала продемонстрировать системе правильную последовательность действий, то есть самостоятельно решить задачу хотя бы один раз.

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

Попытка предоставить пользователю возможность формулировать команды в более естественной форме была предпринята при создании голосовых ассистентов. Такие системы позволяют выполнять отдельные операции без непосредственного взаимодействия с графическим интерфейсом, например создавать напоминания, искать информацию, запускать приложения и управлять воспроизведением мультимедийных данных. Однако традиционные голосовые ассистенты распознают главным образом заранее предусмотренные типы запросов. Если формулировка пользователя не соответствует поддерживаемому сценарию или задача требует продолжительного взаимодействия с несколькими приложениями, возможности ассистента оказываются ограниченными [6]. Диалоговая форма интерфейса, таким образом, ещё не обеспечивает способности самостоятельно планировать и выполнять произвольные последовательности действий.

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

В работах [9, 14] были предложены подходы, объединяющие обработку естественного языка с обращением к внешним инструментам и источникам данных. Такая организация позволяет модели не только сформировать текстовый ответ, но и выбрать подходящую функцию, передать ей необходимые аргументы и использовать полученный результат для продолжения работы.

Отдельное направление составляют интеллектуальные агенты, предназначенные для работы с веб-интерфейсами и графическими приложениями. Подобные системы получают сведения о состоянии интерфейса, сопоставляют его элементы с инструкцией пользователя и пытаются выполнить необходимую последовательность действий [2, 13]. Для оценки таких агентов создаются наборы задач, включающие поиск информации, заполнение форм, редактирование документов, работу с файлами и взаимодействие с несколькими приложениями. Результаты этих исследований показывают принципиальную возможность управления рабочим пространством на уровне обобщённых инструкций.

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

С этой точки зрения особый интерес представляют технологии доступности, изначально предназначенные для предоставления незрячим пользователям невизуального доступа к графическим интерфейсам. Программы экранного доступа получают сведения об элементах приложений посредством системных интерфейсов доступности и представляют их пользователю в речевой или тактильной форме. Стандарты и программные интерфейсы доступности описывают тип элемента, его название, состояние, значение и допустимые действия [12]. В результате формируется структурированное представление интерфейса, которое может быть использовано не только программой экранного доступа, но и интеллектуальным агентом.

Тем не менее технологии доступности обычно накладываются на уже существующий графический интерфейс. Незрячий пользователь должен последовательно перемещаться между элементами, восстанавливать структуру приложения по их описаниям и самостоятельно выбирать очередное действие. Если приложение предоставляет неполные или некорректные сведения о своём интерфейсе, доступ к его функциям оказывается затруднённым. Таким образом, графическая организация рабочего пространства продолжает определять способ взаимодействия даже в том случае, когда визуальные элементы преобразуются в речевую или тактильную форму.

Появление интеллектуальных агентов привело также к созданию специализированных физических устройств управления. Одним из таких примеров является компактная клавиатура Codex Micro, представленная в 2026 г. как командный центр для взаимодействия с агентами и разработанная при участии OpenAI совместно с компанией Work Louder [11]. Устройство содержит механические клавиши, сенсорный датчик, поворотный регулятор и плоский джойстик, предназначенные для запуска типовых сценариев работы с программным кодом, выбора режима работы модели и контроля выполняемых задач. Состояние агентов отображается при помощи визуальной световой индикации. Codex Micro представляет интерес как попытка вынести управление интеллектуальными агентами за пределы отдельного окна приложения и создать для него специализированный физический интерфейс. Однако устройство преимущественно предоставляет быстрый доступ к заранее предусмотренным функциям. Пользователь по-прежнему должен выбирать необходимый орган управления и интерпретировать состояние агента, а использование визуальной индикации требует дополнительного решения для обеспечения доступности незрячим людям.

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

Рассмотренные подходы позволяют выделить несколько последовательных способов сокращения микроконтроля.

Специализированные устройства ввода повышают плотность и скорость передачи команд.

Командные языки позволяют объединять множество операций в одну формальную инструкцию.

Макросы, программирование по демонстрации и RPA сохраняют и повторяют ранее определённую последовательность действий.

Голосовые ассистенты принимают команды на естественном языке, но обычно ограничиваются заранее предусмотренными сценариями.

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

Для реализации последнего подхода недостаточно предоставить модели диалоговый интерфейс.

Интеллектуальный агент должен располагать целостным представлением рабочего пространства, получать сведения о состоянии приложений и иметь доступ к допустимым действиям.

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

2. Принципы и архитектура LUWRAIN

22.1. Особенности пользовательского интерфейса

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

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

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

Вместе с тем некоторые объекты невозможно представить невизуально без частичной потери информации. Например, содержание веб-страницы может быть передано в виде текста и семантической структуры, однако особенности её пространственной композиции, графические связи и некоторые способы интерактивного взаимодействия при таком представлении могут быть утрачены. В подобных случаях задача LUWRAIN состоит не в буквальном воспроизведении внешнего вида объекта, а в предоставлении пользователю его содержания, структуры и доступных действий в форме, пригодной для последовательного невизуального изучения.

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

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

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

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

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

Текущая позиция пользователя определяется фокусом ввода или «горячей точкой» (hot point). При переходе между объектами LUWRAIN сообщает сведения, достаточные для понимания нового контекста, но не перегружает пользователя повторением уже известной информации. Объём речевых сообщений может настраиваться: начинающему пользователю могут сообщаться тип элемента, его состояние и доступные действия, тогда как опытному пользователю достаточно краткого названия или текущего значения.

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

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

Для повышения предсказуемости интерфейса одинаковые действия должны по возможности выполняться одинаковыми командами во всех приложениях LUWRAIN. Команды перемещения, редактирования, поиска, копирования, вызова справки и перехода между объектами должны сохранять единообразное поведение. Если конкретный элемент требует особого способа взаимодействия, пользователь должен иметь возможность получить сведения о доступных командах непосредственно в текущем контексте.

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

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

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

2.2. Архитектура компонентов

Подпроект core — центральный компонент платформы LUWRAIN. Он содержит основной исполняемый код, который собирается в главный JAR-файл luwrain.jar, и предоставляет базовую функциональность для разработки приложений и расширений. Ниже рассмотрена архитектура этого подпроекта с особым вниманием к встроенной поддержке сценариев.

Основные абстракции. Архитектура ядра LUWRAIN основана на нескольких ключевых абстракциях, которые образуют каркас всей платформы.

Интерфейс org.luwrain.core.Luwrain служит основной точкой доступа приложений и расширений к службам ядра. Через него можно управлять синтезом речи, выводом на брайлевский дисплей, воспроизведением звуков, рабочими областями, запуском приложений, буфером обмена, конфигурацией и другими возможностями платформы. Каждое приложение и расширение получает собственный экземпляр Luwrain. Благодаря этому ядро может определять источник запросов и разграничивать уровни доступа к системным функциям.

Приложения. Любое интерактивное приложение LUWRAIN реализует интерфейс org.luwrain.core.Application. К его основным методам относятся:

• onLaunchApp(Luwrain) — выполняет первоначальную инициализацию приложения;
• getAreaLayout() — возвращает компоновку рабочих областей;
• onAppClose() — вызывается при завершении работы приложения.

Интерфейс MonoApp расширяет Application и предназначен для приложений, которые могут быть запущены только в одном экземпляре.

Рабочие области. Фундаментальной единицей пользовательского интерфейса LUWRAIN является область — area. Область представляет собой интерактивный рабочий объект, например поле текстового ввода, структурированный документ, дерево или форму. Она формирует текстовое представление содержимого, обрабатывает события ввода и управляет «горячей точкой» (hot point). Горячая точка определяет текущую позицию взаимодействия пользователя с содержимым области и фактически выполняет роль фокуса.

Расширения. Интерфейс org.luwrain.core.Extensions определяет основной контракт для подключения внешних расширений. Расширения загружаются с помощью механизма ServiceLoader. Они могут предоставлять приложения и команды для их запуска, фабрики компонентов панели управления, средства интернационализации и другие объекты, дополняющие возможности платформы.

События и речевой вывод. События ввода, представленные классом org.luwrain.core.events.InputEvent, и системные события, представленные классом org.luwrain.core.events.SystemEvent, передаются активным областям. В ответ области формируют объекты EventResponse, которые, помимо прочего, управляют речевой обратной связью. Непосредственное взаимодействие с подсистемой синтеза речи осуществляется через класс org.luwrain.core.Speech и интерфейс org.luwrain.speech.Engine.

Одной из важных архитектурных особенностей LUWRAIN является встроенная поддержка сценариев, реализованная в пакете org.luwrain.script и его подпакетах. Сценарии позволяют расширять функциональность платформы без предварительной компиляции Java-кода. Для их выполнения используется JavaScript-среда GraalVM. Загрузкой сценариев управляет ExtensionsManager. При запуске ядро сканирует каталоги js/, расположенные как в общей структуре платформы, так и внутри установленных пакетов, и ищет файлы с расширением .js.

Имена файлов должны соответствовать шаблону <компонент>-<имя>.js. Примерами допустимых имён являются core-startup.js и core-commander.js.

Класс org.luwrain.script.core.ScriptCore управляет жизненным циклом сценариев. Он реализует интерфейс org.luwrain.core.HookContainer, благодаря чему сценарии могут регистрировать обработчики системных событий в виде хуков. При загрузке сценария ScriptCore создаёт новый экземпляр класса Module. Этот объект инкапсулирует контекст GraalVM и отвечает за выполнение сценария.

Система хуков. Сценарии регистрируют обработчики событий с помощью метода Luwrain.addHook(name, func). Ядро запускает зарегистрированные обработчики посредством метода HookContainer.runHooks(). Пакет org.luwrain.script.hooks предоставляет несколько стратегий выполнения хуков:

• ChainOfResponsibilityHook реализует цепочку обязанностей: хуки вызываются последовательно, а первый обработчик, вернувший true, останавливает дальнейшее выполнение цепочки;
• ProviderHook реализует стратегию поставщика и возвращает первый результат, отличный от null;
• CollectorHook вызывает все хуки и собирает полученные результаты;
• PermissionHook используется для проверки разрешений, при которой каждый хук должен вернуть true;
• NotificationHook вызывает все зарегистрированные хуки, игнорируя возвращаемые ими значения;
• TransformerHook последовательно передаёт значение через цепочку хуков, позволяя каждому из них преобразовать результат предыдущего обработчика.

Такая архитектура делает механизм сценариев гибким и позволяет использовать его для обработки событий, предоставления данных, проверки разрешений, рассылки уведомлений и последовательного преобразования значений.

3. Интеграция ИИ-агентов в архитектуру LUWRAIN

Архитектура LUWRAIN, несмотря на то, что первоначально не рассматривалась в качестве платформы для интеграции интеллектуальных технологий (проект был запущен в 2012 г.), удачно подходит для интеграции ИИ-агентов, поскольку взаимодействие пользователя с платформой уже основано на текстовых представлениях, событиях, приложениях, расширениях и хуках. ИИ-агент в такой системе может выступать не только в роли диалогового помощника, но и как полноценный участник рабочего процесса, способный анализировать состояние интерфейса, вызывать разрешённые операции и координировать действия нескольких приложений. При этом интеграция учитывает особенности невизуального интерфейса: линейный характер восприятия информации, высокую значимость речевой обратной связи и необходимость сохранять полный контроль пользователя над выполняемыми действиями.

3.1. Общая архитектура агентной подсистемы

На уровне ядра предусматривается отдельная служба управления агентами, условно обозначаемая как AgentService. Доступ к ней приложения и расширения получают через упомянутый в предыдущей главе фасад org.luwrain.core.Luwrain. Такая служба отвечает за взаимодействие с языковыми моделями, управление контекстом, регистрацию доступных инструментов, выполнение агентных циклов и передачу результатов приложениям.

Непосредственное обращение к конкретным моделям выносится в отдельный интерфейс AgentEngine. Его реализация предуссматривает поддержку OpenAI API, хотя в будущем можно рассмотреть и другие протоколы. Это позволяет не связывать приложения с определённым поставщиком ИИ и выбирать модель с учётом конфиденциальности данных, стоимости запросов, времени ответа и доступных вычислительных ресурсов.

Типичный цикл работы агента выглядит стандартно и включает следующие этапы:

1. Получение запроса пользователя и доступного контекста.
2. Формирование унифицированного текстового представления текущего состояния.
3. Передача запроса языковой модели.
4. Получение текстового ответа или команды на вызов инструмента.
5. Проверка прав и параметров операции.
6. Выполнение инструмента приложением, расширением или системной службой.
7. Возврат результата модели для продолжения рассуждения.
8. Формирование итогового ответа и его передача через речевой или брайлевский интерфейс.

Подобный цикл не блокирует основной поток обработки событий. Запросы к модели и продолжительные операции выполняются асинхронно, предоставляя пользователю возможность отменить действие, проверить его состояние или переключиться на другую задачу.

3.2. Работа с унифицированным текстовым представлением

Первый способ интеграции основан на обработке агентами текстового представления объектов интерфейса. Он особенно естественен для LUWRAIN, поскольку рабочие области уже представляют содержимое в текстовой форме и управляют «горячей точкой». Однако передавать модели весь отображаемый текст без дополнительной структуры недостаточно.

Для надёжной работы агенту требуется семантическое представление, включающее тип области, её назначение, доступные действия, положение горячей точки и состояние интерактивных элементов. К примеру, описание области может содержать:

• идентификатор и тип области;
• заголовок и краткое назначение;
• текстовое содержимое;
• текущую позицию горячей точки;
• выделенный фрагмент;
• список доступных команд; *- сведения о полях формы и их состоянии;
• признаки доступности элементов только для чтения;
• связи с другими областями приложения.

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

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

3.3. Интеграция агентов в приложения

Другая возможность предусматривает непосредственную интеграцию агентных функций в приложения. В этом случае приложение предоставляет языковой модели набор инструментов, соответствующих операциям предметной области. Почтовый клиент, например, мог бы определить инструменты для поиска писем, подготовки ответа, перемещения сообщения и добавления вложения. Текстовый редактор мог бы предоставлять операции чтения выделенного фрагмента, замены текста, перехода к разделу и сохранения документа. Инструмент (тул, функция) должен иметь стабильное имя, понятное описание, формальную схему аргументов и описание результата. Для этого в архитектуре предусматриваются интерфейсы AgentTool и AgentToolProvider.

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

• операции чтения: получают данные, но не изменяют состояние;
• операции изменения: редактируют документы или настройки;
• внешние операции: отправляют сообщения, выполняют сетевые запросы или публикуют данные;
• системные операции: запускают приложения, работают с файлами или меняют конфигурацию платформы.

Перед выполнением потенциально опасного инструмента агентная подсистема может запросить подтверждение пользователя. Подтверждение должно содержать не внутреннее имя операции, а понятное описание предполагаемого действия, его объекта и возможных последствий. Например, вместо сообщения «вызвать sendMessage» пользователь должен услышать: «Отправить подготовленное письмо адресату Иван Петров с темой "Отчёт"?».

3.4. Добавление инструментов с использованием JavaScript-хуки

Встроенная система сценариев позволяет добавлять агентные возможности без изменения и повторной компиляции Java-кода. JavaScript-сценарий может зарегистрировать инструмент через специализированный хук, например agent.tools. Обработчик такого хука возвращает описание инструмента, схему его аргументов и функцию выполнения. Регистрацией и сбором инструментов может управлять стратегия, аналогичная CollectorHook, поскольку агенту требуется получить полный список доступных операций от всех подключённых поставщиков. Условная регистрация может выполняться с учётом текущего приложения, активной области, прав пользователя и доступности внешних служб. Например, сценарий мог бы предоставлять инструмент перевода текста только при наличии выделенного фрагмента, а инструмент управления сообщениями — только при активном почтовом приложении.

Сценарии также могут использоваться для преобразования контекста перед его передачей модели. Для этого подходит стратегия, аналогичная TransformerHook, при которой структурированное представление последовательно проходит через несколько обработчиков. Один хук может удалить конфиденциальные поля, другой — добавить описание предметной области, а третий — сократить слишком длинный текст. Хуки типа PermissionHook могут участвовать в проверке разрешений. В таком случае инструмент будет выполнен только при положительном результате всех зарегистрированных проверок. NotificationHook можно использовать для уведомления расширений о начале и завершении агентной операции, а ProviderHook — для выбора подходящей модели или поставщика контекста.

Загрузка сценарных инструментов может выполняться существующим механизмом ExtensionsManager при сканировании каталогов js/. Для таких файлов, возможно ,предстоит предусмотреть отдельное соглашение об именовании, например agent-<имя>.js или <компонент>-agent.js. При этом JavaScript-код не должен автоматически получать неограниченный доступ ко всем службам ядра. Каждому сценарию необходимо предоставлять только явно разрешённый набор объектов и операций.

3.5. Агент как обработчик событий

Агенты интегрируются также в событийную модель LUWRAIN. Некоторые объекты InputEvent или SystemEvent могут направляться агенту после предварительной обработки обычными средствами приложения. Не следует, однако, передавать модели каждое событие клавиатуры. Такое решение увеличит задержки, создаст лишние расходы и может раскрыть чувствительные данные. Агент должен подключаться только к событиям высокого уровня: явным пользовательским запросам, изменениям активного документа, завершению длительной операции или появлению новых значимых объектов. Ответ агента можно преобразовывать в EventResponse, если он предназначен для немедленной речевой обратной связи. Для более сложных результатов лучше использовать отдельный объект ответа, содержащий текст, рекомендуемые действия, уровень важности и указание на область, к которой относится сообщение.

3.6. Навигация и управление «горячей точкой»

Отдельным направлением интеграции является интеллектуальная навигация. Поскольку каждая область управляет горячей точкой, агент может помогать находить нужный фрагмент и предлагать переход к нему. Для этого приложению следует предоставить безопасный инструмент навигации, принимающий идентификатор области и логическую позицию объекта. Агент не должен самостоятельно изменять внутренние координаты горячей точки без участия приложения. Иначе изменение структуры документа между анализом и выполнением команды может привести к переходу в неверное место.

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

3.7. Диалоговые и фоновые агенты

В платформе LUWRAIN можно поддерживать несколько режимов работы агентов:

1. Диалоговый агент запускается пользователем и отвечает на вопросы в контексте текущего приложения или области.
2. Командный агент получает задачу, выбирает инструменты и выполняет ограниченную последовательность действий.
3. Фоновый агент реагирует на системные события, например на завершение загрузки, появление нового сообщения или изменение документа.
4. Специализированный агент обслуживает конкретное приложение и использует его предметную модель.
5. Координирующий агент взаимодействует с несколькими приложениями и выполняет составные задачи, такие как поиск документа, извлечение сведений и подготовка письма.

Для фоновых агентов особенно важны ограничения частоты запуска и правила доставки уведомлений. Некритичные результаты не должны прерывать текущую работу пользователя. Их можно помещать в очередь уведомлений, а срочные события — воспроизводить через org.luwrain.core.Speech с учётом заданного приоритета.

3.8. Работа с речью и брайлевским выводом

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

• краткое речевое резюме;
• полный текст для отдельной области;
• структурированный список действий;
• сообщение для брайлевского дисплея;
• уведомление о ходе длительной операции.

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

3.9. Контекст, память и безопасность

Для качественной работы агенту требуется контекст, однако бесконтрольное накопление истории нежелательно. В архитектуре следует разделить несколько видов памяти:

• контекст текущего запроса;
• состояние активного приложения;
• история диалога в рамках сеанса;
• долговременные пользовательские предпочтения;
• внешние знания, получаемые через поиск.

Каждый тип памяти должен иметь отдельные правила хранения и очистки. Содержимое документов, буфера обмена и полей ввода не следует сохранять в долговременной памяти без явного согласия пользователя. Пользователь должен иметь возможность узнать, какие сведения доступны агенту, удалить историю и временно отключить передачу контекста.

Для сокращения объёма запросов можно передавать не полный «снимок» интерфейса, а изменения относительно предыдущего состояния. Приложение при этом должно сохранять возможность сформировать полный актуальный снимок, если контекст модели оказался устаревшим.

Главной проблемой агентной интеграции является не генерация текста, а безопасное выполнение операций. Ответ модели следует рассматривать как недоверенный ввод. Модель не должна получать прямой доступ к объекту Luwrain, файловой системе, сетевым функциям или экземплярам приложений.

Все действия необходимо выполнять через зарегистрированные инструменты с проверяемыми аргументами. Для каждого инструмента желательно определить:

• требуемый уровень доступа;
• возможность работы без подтверждения;
• допустимые типы и размеры аргументов;
• ограничения времени выполнения;
• правила журналирования;
• возможность отмены или отката;
• перечень данных, которые разрешено передавать внешней модели.

Необходимо учитывать и атаки через содержимое документов. Текст открытой страницы, письма или файла может содержать инструкции, пытающиеся заставить агента раскрыть данные или выполнить опасное действие. Поэтому данные интерфейса должны явно отделяться от системных инструкций, а содержащиеся в них команды не должны автоматически становиться командами для агента. Журнал агентных операций должен хранить запрос пользователя, выбранный инструмент, фактически переданные аргументы, результат проверки прав и итог выполнения. Для конфиденциальных данных следует применять маскирование, чтобы журнал сам не стал источником утечки.

3.10. Возможная схема расширения ядра LUWRAIN

Минимальная агентная подсистема предполагается содержащей следующие компоненты:

• AgentService: управляет запросами, контекстом и жизненным циклом агентных задач;
• AgentEngine: абстрагирует конкретную языковую модель;
• AgentContextProvider: формирует семантическое описание приложения или области;
• AgentTool: представляет отдельную операцию, доступную модели;
• AgentToolProvider: публикует набор инструментов приложения или расширения;
• AgentPermissionManager: проверяет права и организует подтверждение опасных действий;
• AgentSession: хранит состояние отдельного диалога или задачи; *AgentResponse: содержит текст, уведомления, предлагаемые действия и данные для навигации.

Эти компоненты могут быть реализованы как отдельный подпроект, зависящий от core, но не являющийся обязательной частью минимальной конфигурации платформы. Такое разделение позволит использовать LUWRAIN без ИИ-компонентов, а также устанавливать разные реализации агентной подсистемы в зависимости от требований конкретной среды.

Заключение

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

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

Список литературы

 

1. Cypher A. Watch what I do: Programming by demonstration / ed. by A. Cypher. Cambridge, MA : MIT Press, 1993. ISBN 9780262032131. https://mitpress.mit.edu/9780262032131/watch-what-i-do//
2. Deng X., Gu Y., Zheng B. et al. Mind2Web: Towards a generalist agent for the web // Advances in Neural Information Processing Systems. arXiv: 2306.06070, 2023. P. 1-24. https://doi.org/10.48550/arXiv.2306.06070
3. Engelbart D.C. Augmenting human intellect: A conceptual framework. Menlo Park, CA : Stanford Research Institute, 1962. https://www.dougengelbart.org/pubs/augment-3906.html
4. Engelbart D.C., English W.K. A research center for augmenting human intellect // Proceedings of the AFIPS Fall Joint Computer Conference. 1968. https://doi.org/10.1145/1476589.1476645
5. Lieberman H. Your wish is my command: Programming by example / ed. by H. Lieberman. San Francisco : Morgan Kaufmann, 2001. 377 p. ISBN 978-1-55860-688-3. https://dl.acm.org/doi/book/10.5555/369505
6. Luger E., Sellen A. Like having a really bad PA: The gulf between user expectation and experience of conversational agents // Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems. 2016. https://doi.org/10.1145/2858036.2858288.
7. Pozhidaev M. Introducing LUWRAIN: Can GNU/Linux help us rethink accessibility solutions for the blind? // Linux Journal. Texas, 2015. Vol. 2015, Iss. 255. P. 82–91.
8. Pozhidaev M. The framework for accessible applications: text-based case for blind people // CEE-SECR '14: Proceedings of the 10th Central and Eastern European Software Engineering Conference in Russia. 2014. Article No. 22. P. 1–7. https://doi.org/10.1145/2687233.2687234
9. Schick T., Dwivedi-Yu J., Dessì R. et al. Toolformer: Language models can teach themselves to use tools // Advances in Neural Information Processing Systems. arXiv: 2302.04761,  2023. P. 1-17.  https://doi.org/10.48550/arXiv.2302.04761
10. Van der Aalst W., Bichler M., Heinzl A. Robotic process automation // Business & Information Systems Engineering. 2018. Vol. 60. P. 269–272. https://doi.org/10.1007/s12599-018-0542-4
11. WorkLouder. CodexMicro, OpenAI, 2026. URL: https://www.rbc.ru/technology_and_media/16/07/2026/6a584a939a7947907e5bcf56 (дата обращения: 15.10.2026).
12. World Wide Web Consortium. Accessibility Object Model. URL: https://wicg.github.io/aom/ (дата обращения: 15.10.2026).
13. Xie T., Zhang D., Chen J. et al. OSWorld: Benchmarking multimodal agents for open-ended tasks in real computer environments // Advances in Neural Information Processing Systems. arXiv: 2404.07972, 2024. P. 1-51. https://doi.org/10.48550/arXiv.2404.07972
14. Yao S., Zhao J., Yu D. et al. ReAct: Synergizing reasoning and acting in language models // arXiv: 2210.03629. arXiv, 2022. P. 1-33. https://doi.org/10.48550/arXiv.2210.03629