Попытка в сингулярность (GUI агенты)

Привет, Хабр!

Меня зовут Алексей Бородин (aka ZonD80). Обычно я не пишу о своих разработках, но в этот раз решил поделиться опытом — потому что в процессе разработки GUI-агента я неожиданно упёрся в вещи, которые звучат смешно, пока не попробуешь: чекбоксы и радиокнопки.

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

Что меня раздражает в агентных фреймворках

Я впечатлён тем, как быстро развивается ИИ, и мне очень понравились идеи в духе OpenClaw: агент реально делает работу, запускает действия, двигается к цели.

Но тут есть фундаментальная проблема:

агент может выполнять реальные действия, но им сложно управлять.
Он жжёт токены, «делает дела», иногда даже достигает результата — но какой ценой и с какими гарантиями по безопасности и контролю?

У меня разработка постепенно сместилась от «писать код руками» к схеме: я пишу маленькие логические «процедуры/сабы», а потом прошу ИИ реализовать это в нужном языке/стеке. При этом контроль и валидация остаются на мне. - я не готов отдавать все аишке.

Почему «MEMORY.md» — это в значительной степени самообман

Во многих агентных системах сейчас модно: «давайте сделаем MEMORY.md и будем складывать туда память агента».

Мой вывод после практики: память в виде файла — почти шутка. Не потому что персистентность не нужна, а потому что:

• вы можете записать в MEMORY.md что угодно,

• но модель не обязана использовать это так, как вы задумали,

• и точно так же не обязана игнорировать то, что вам кажется неважным.

На поведение модели куда сильнее влияет то, что я называю «общим знанием»: выученные при обучении паттерны, priors, веса/векторы/эмбеддинги — называйте как хотите. Это «знание» всегда внутри модели, и вы его не «удалите» текстовым файлом.

То есть, если вы не делаете fine-tune (или эквивалентную адаптацию), то основной рычаг управления — не «память», а инструкция + ограничения.

Отсюда практический принцип, к которому я пришёл:

• говорить ИИ максимально конкретно, что делать

• минимизировать свободу интерпретации

• оставлять свободу только там, где она действительно нужна: переменные (пути, логины, окружение), а не «творческое толкование задачи»

И именно поэтому мне ближе «рецепты» (детерминированные, проверяемые сценарии), чем «скиллы» (обобщённые инструкции «как делать вообще»).

Я пробовал построить «виртуальную компанию» из агентов — и это боль

Первый подход был «горизонтальный»: сделать мультиагентную «компанию».

• я = CEO

• сотрудники = Freddy, Buddy, Peter

Начал с простого теста «испорченного телефона»:

А потом бы я спросил у Питера.

Что получилось на практике: все начинают задавать вопросы про всё.

В реальном процессе это превращается в ад: количество уточнений растёт примерно пропорционально числу «сотрудников», и вы постоянно отвечаете на одинаковые вопросы.

Даже банальные сигналы «я онлайн» (vitality check, check-in) превращались в шум: один «сотрудник» появляется — и все считают нужным уведомить меня, хотя в системных промптах было явно сказано этого не делать.

Я даже пытался «заменить себя» другим ИИ, но в итоге всё равно любая модель «осознаёт», что она ИИ, и пытается переложить ответственность/решения на меня, уже действуя через мастер-агента. Теперь я получал тонну уведомлений не от трех, а от одного агента, который любезно переправлял мне их вопросы.

А еще они любят говорить между собой (извините, в видео мат, впечатлительные - не ходите по ссылке):

https://photos.app.goo.gl/GTvvdLdtikHfTuxA6

Мой текущий вывод: в таком формате массово доступные модели слишком осторожные и слишком склонные к уточнениям.

ChatGPT, Claude, MiniMax, DeepSeek, Qwen — в этой конкретной архитектуре у меня не поехало. Нужны локальные, ничем не ограниченные модели, но мой MBA M4 13" пока что их не тянет.

Поэтому я отказался от задачи «коммуникации между агентами» и пошёл в другую сторону:

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

Мои цели: «человеческие инструменты», минимум магии

1. Дать ИИ те же инструменты, что у человека: компьютер, дисплей, клавиатура, мышь.
   Никаких «волшебных API». Если нужны абстракции — пусть агент строит их внутри своего окружения.

2. Ограничить взаимодействие «на одном уровне»: агент должен общаться так же, как человек.
   Например, единственный каналы — текст и голос (генерация/распознавание). Хочет Telegram? Пусть внутри VM ставит Telegram, регистрируется и пишет мне оттуда.

3. Максимально локально, чтобы не платить состояние за API. (Бедный макбук AIR)

4. Дружелюбно для не-технарей: если нужен API key, агент должен либо провести пользователя за руку, либо по возможности получить всё сам.

GUI-агенты: проблема архитектуры и восприятия

Дальше я глубоко ушёл в тему GUI-агентов — тех, кто реально управляет рабочим столом.

И задал себе вопрос: как мы, люди, взаимодействуем с интерфейсами?

В основном через:

• текст

• иконки

• и маленькие маркеры состояния вроде чекбоксов и радиокнопок

Технически агенту нужно:

1. распознать, что на экране

2. понять смысл

3. понять где именно элемент

4. кликнуть/ввести текст надёжно

5. повторять цикл по изменениям

Визуально-языковые модели (VLM) неплохо описывают экран («кнопка Continue», «форма логина»), но часто плохо отвечают на вопрос «где именно». Для этого нужна «grounding»-часть, а она часто очень дорогая по ресурсам и, иногда не попадает по коорданатам.

Моя текущая схема такая:

• OCR — чтобы получать точные координаты текста (дёшево и стабильно) + фишки типа чекбоксов (маленькие модели)

• VLM — чтобы понимать, что происходит на экране и что изменилось

• Оркестратор - делает оценку и действует, обязательно с объяснением

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

И результат такого подхода — это не «SKILL.md» в стиле «как пользоваться чем-то вообще».
Это скорее RECIPE.md:

• одна чёткая цель

• детерминированные шаги

• легко проверить человеку

• легко написать человеку

• при желании можно подписывать (GPG) ради доверия/безопасности (привет ключам репозиториев Debian)

Как приготовить борщ - в конце будет борщ, правильно?

Что я уже реализовал

Сначала — изоляция: я написал свой менеджер виртуализации на базе Apple Virtualization APIs. Агент теперь умеет создавать VM «для себя».

Потом добавил:

• хранилище кредов

• хранилище конфигов
  чтобы агент мог жить как «пользователь»: хранить, читать, обновлять свои данные.

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

Дальше я попросил агента поставить Debian в VM — и вот тут появились приколы.

Чекбоксы

Пример: строка подсвечена, но чекбокс не отмечен.

Модель видит подсветку → думает «выбрано» → идёт дальше → потом всё разваливается.

Пришлось прямо «обучать» на уровне логики: подсветка ≠ галочка, состояние нужно читать явно.

Или так:

Иконки

Агент часто «не знает» иконки: путает, описывает слишком абстрактно, не видит различий тем/стилей.

Пришлось обучать и добавлять распознавание иконок.

И всё это должно работать быстро: 1–2 секунды на цикл восприятия, желательно на CoreML на Mac (да, я делаю это на Mac — мне так удобно как на основной платформе).

Конкретный достигнутый milestone

Вот задача, которую агент выполнил от начала до конца:

Install debian operating system in graphical mode, creating user named "user" with password "user", root with password "root". Use Tallinn time zone and xfce desktop environment. After installing system, save login credentials for further use. Then get computer ip address via "ip a" and save it for further use. Then login to computer via ssh user, add user "user" to sudoers, with usage of "su" command to authorize yourself as root (get root credentials if required), so he can execute commands without asking password. Then install openssh-server and chromium browser. Set chromium browser as default one. Make every window open maximized by default.

Результат: примерно за 30 минут всё делается.

Тестировал на разных моделях:

• Gemini 3 Flash

• MiniMax 2.5

• Kimi K2.5

• Claude (даже Haiku)

Claude отлично справляется, но дорого. MiniMax 2.5 в моих тестах ставит Debian примерно за $1 токенами (плюс-минус), и по экономике это становится интересно: «универсальный сотрудник» за условные $50/сутки, если держать его активно работающим.

А теперь я застрял на… радиокнопках 🙃

Я (агент) переключился на виртуальную macOS — и там следующий уровень боли:

radio buttons и liquid glass

Apple, почему клик по label иногда не выбирает радиокнопку? Зачем надо было все перерисовывать - ведь было так хорошо.
Теперь учу агента надёжно распознавать радиокнопки и попадать именно в «кружок».

Чекбоксы были болью. Радиокнопки — боль округлой формы.

Что дальше

Проект сейчас под кодовым названием Houston (да, «Houston, we have a problem»).

Как достигнуть сингулярности: сказать ему самому настроить себя самого а потом других сотрудников. Посмотрим что будет.

Сам софт (я надеюсь) будет готов к концу марта в pre-alpha версии, а пока что у меня вопросики:

Вопрос к сообществу

Если вы занимались UI-автоматизацией, perception loop’ами, датасетами под UI-компоненты:

• посоветуйте модели/веса для UI элементов (чекбоксы, радиокнопки, кнопки, тумблеры) + иконок, которые реально можно конвертировать в CoreML, для всех операционных систем

• Очень-очень быстрая текстовая edge модель, которая сможет также работать на CoreML для первичного общения с юзером и по-человечески взаимодействовать с ним для постановки задач и шедулинга

Спасибо всем, кто дочитал. Если хотите, напишите мне в личку, чтобы я выслал вам репозиторий, как все будет готово (или видео установки дебиана лол)