AI Extensions, 6 листопада: agent-desktop і ціна повторного кліку

Команда кліку завершилася тайм-аутом, а форма вже змінилася. Повторення може надіслати її вдруге. Нове спостереження відповідає на питання, яке залишив тайм-аут: що саме відбулося?

Сьогодні AI Extensions докладно розглядає один проєкт: agent-desktop від Vercel Labs. Першоджерела перевірено 6 листопада 2026 року. Я не встановлював програму, не надавав доступу до ОС і не керував реальним застосунком. Останній оглянутий коміт датований 5 листопада; прочитаний LICENSE містить Apache-2.0. Популярність не дорівнює якості, кількість зірок не є оцінкою.

Структура замість самих координат

CLI та бібліотека C звертаються до API доступності ОС: AX у macOS, UI Automation у Windows, AT-SPI у Linux. Викликач отримує структуру інтерфейсу й посилання на елементи. Усередині agent-desktop немає моделі: рішення про наступну дію ухвалює зовнішній агент.

Назви кнопок і зв'язки вікон допомагають перевіряти ціль. Але якість спостереження залежить від того, що надає застосунок через доступність. Мій висновок: семантичне дерево зменшує частину невизначеності, не усуваючи неповні або неоднозначні ділянки інтерфейсу.

Посилання прив'язане до знімка

У README наведено @s8f3k2p9:e8. Частина з ідентифікатором знімка потрібна; коротке @e8 відхиляється. Зміни інтерфейсу можуть спричинити STALE_REF або AMBIGUOUS_TARGET. Документований шлях передбачає нове спостереження й свіжі посилання. Для кількох вікон може знадобитися явний ідентифікатор.

Початкову перевірку я б проводив на порожньому документі в одноразовій сесії: оглянути вікно, вибрати відоме поле, ввести нешкідливу мітку та прочитати результат. Зміна документа потребує повторної перевірки цілі. Це план випробування, а не опис проведеного досліду.

Спостереження → посилання знімка → дозволена дія
                                         |
                                нове спостереження
                                         |
                       очікуваний результат / невідомо
                                         |
                          перевірка перед новим записом

Дозвіл на повтор

Документація помилок радить розгалужувати логіку за кодом і disposition, не за текстом повідомлення. Повторювати можна лише коли error.disposition.retry дорівнює safe. Невдала відповідь не доводить, що ввід не дійшов до застосунку: доставка може бути непідтвердженою.

def next_step(envelope):
    if envelope.get("ok") is True:
        return "observe_expected_result"
    retry = envelope.get("error", {}).get("disposition", {}).get("retry")
    if retry == "safe":
        return "review_declared_recovery_and_target"
    return "inspect_state_without_repeating_action"

Це оригінальний пояснювальний псевдокод, не реалізація API й не виконаний приклад. Він навмисно не надсилає наступної команди. Навіть гілка safe потребує перевірки дозволу та цілі. Завершений клік і потрібний текст у документі є різними спостереженнями.

Headless не ізолює дані

За README дії через посилання типово використовують API доступності без руху вказівника чи захоплення фокуса. Прапорець --headed дозволяє фізичний ввід. Це механіка доставки, а не дозвіл на повідомлення, покупки чи читання приватного вмісту.

Сторінки macOS та Linux описують особливості платформ. README указує macOS 13+, Windows 10 1809+ і Ubuntu 24.04+ для Linux. Варто перевірити власну ОС і потрібні поверхні. Автоматичний перехід до фізичного вводу після відмови змінює умови виконання.

Перевірити артефакти

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

Документовані пакет npm із нативними файлами та окремі архіви випусків. MCP-сервер через stdio відкриває команди викликачеві й розширює набір можливих дій. Інструкція встановлення пояснює механіку, але не згоду власника на кожний наслідок.

Критерії приймання

Я б вимагав спостережувану зміну чернетки, відмову при неоднозначному вікні, оновлення після застарілого посилання та відсутність сліпого повтору при невідомій доставці. Невдачі потрібно зберігати разом з успіхами. Перед передаванням трасування слід перевірити його вміст. Проєкт цікавий конкретними назвами цих меж, проте їх дотримання у вибраному застосунку ще потребує перевірки.