Computer use у GitHub Copilot – це public preview на macOS і Windows для Copilot CLI та Copilot app: агент може читати вміст desktop-застосунків через accessibility tree або скриншоти, клікати, вводити текст і переносити дані між програмами. Перед керуванням кожним застосунком потрібен approval користувача. Це закриває «останню милю» автоматизації там, де немає API, – але GUI був і лишається найменш надійним інтерфейсом, тож місце computer use – в кінці ієрархії, а не на її початку.

Що саме з'явилось

Агент уже давно вміє писати код, запускати тести й створювати PR. Тепер GitHub дав йому руки: computer use дозволяє Copilot взаємодіяти з desktop-застосунками – «натискати елементи керування, вводити й редагувати текст, тиснути клавіші, скролити й перетягувати, вести workflow через кілька застосунків» (формулювання з документації).

Технічно агент «бачить» застосунок двома способами: через accessibility tree операційної системи або через скриншоти. Перший – структурований і надійніший, другий – універсальний fallback для нестандартних UI.

Статус чесно позначений: public preview, subject to change. Linux поки не підтримується.

Тому що API є не всюди.

У компаніях досі живуть internal admin panels, desktop tools, legacy CRM, vendor software і тестові середовища без нормального API. Саме там agent workflow раніше закінчувався фразою «тепер вручну відкрий застосунок і натисни...».

Computer use закриває цю останню милю. Але важливо тримати в голові правильну ієрархію інтерфейсів:

API/CLI > structured tool > browser automation > raw computer use.

Computer use потрібен не тому, що він найкращий, а тому, що іноді іншого інтерфейсу просто немає. Якщо в задачі є API – використовуй API. Побудований на скриншотах workflow – це технічний борг із дня створення.

Як працюють approvals

Модель дозволів тут продуманіша, ніж можна очікувати від preview:

  • Per-app approval. Перед першою взаємодією з застосунком агент питає дозвіл. Варіанти: дозволити лише на цю сесію, «Always allow» (зберігається локально і діє одразу для CLI та app на цій машині) або відмовити.
  • Deny переважає. Правила, що забороняють інструмент, мають пріоритет над автоматичними чи збереженими дозволами – тобто заборону не можна випадково «перезаписати» зручністю.
  • Enterprise-контроль. Адміністратори можуть вимкнути computer use повністю на рівні організації.

Це та сама логіка, що й у локальному sandboxing для Copilot: prompt – це побажання, permission – це enforcement.

Але GUI – найменш надійний інтерфейс

Документація GitHub сама чесно перелічує проблеми: агент «може обрати не той елемент керування, ввести текст не туди або мати труднощі з нестандартними чи динамічними контролами». Додай сюди чутливість до таймінгу – діалог відкрився пізніше, ніж агент очікував, – і отримаєш клас збоїв, якого не буває в API-інтеграцій:

  • кнопка змінила позицію після оновлення застосунку – workflow зламався;
  • A/B-тест показав інший layout – агент бачить іншу картинку;
  • модальне вікно з'явилось із затримкою – агент клікнув у порожнечу.

І найважливіше попередження з доків: неоднозначні інструкції або неочікуваний вміст екрана можуть призвести до ненавмисних дій, що зачіпають пристрій, дані або підключені акаунти. Плюс окремий нюанс приватності: вікна застосунків можуть показувати чутливу інформацію – зокрема про інших людей.

Security: це вже privileged automation

AI, який бачить desktop і може клікати, – це не autocomplete. Правила для такого агента ті самі, що для будь-якої привілейованої автоматизації:

  1. Narrow permissions – дозволяй лише конкретні застосунки, а не «все підряд через Always allow».
  2. Confirmation для destructive actions – будь-яка дія з «Delete», відправленням чи оплатою має вимагати людину.
  3. Isolated environment де можливо – досвід Vercel Sandbox Challenge добре показує, що ізоляція – це implementation, а не слово.
  4. Audit trail – що агент натискав і коли.
  5. Timeout і safe fallback – завислий GUI-workflow не має висіти вічно.

І загальне правило з чекліста перевірки AI-коду працює й тут: не делегуй агенту дію, наслідки якої не зможеш швидко відкотити.

Як не перетворити агента на хаос із мишкою

  1. Computer use як перший вибір. Є API – використовуй API. GUI-автоматизація як default – це добровільний flaky-шар у процесі.
  2. «Always allow» на все. Зручно сьогодні, боляче в день, коли агент отримає неоднозначну інструкцію поруч із відкритим банківським застосунком.
  3. Відсутність людини на незворотних кроках. Прев'ю-технологія + незворотна дія – погане поєднання.
  4. Ігнорування приватності екрана. Якщо на desktop відкриті чужі дані, агент їх теж «бачить».
  5. Жодного плану на збій. GUI-workflow ламаються тихо; без audit trail ти дізнаєшся про це від користувачів.

Знайди свою «останню милю»

Знайди у своїй команді один процес, який досі закінчується словами «а далі вручну відкрий X і натисни Y». Випиши: (1) чи є в X хоч якийсь API або CLI; (2) що станеться, якщо агент клікне не туди; (3) яка дія в цьому процесі незворотна. Якщо API немає, а незворотних дій нема або вони захищені confirmation – це кандидат на computer use. Якщо API є – ти щойно знайшов собі нормальну інтеграцію замість скриншотного workflow.

Computer use – корисний інструмент для чесно обмеженого класу задач. Головне не переплутати «нарешті можна» з «тепер треба всюди».