Які завдання, пов’язані з доходом, AI Agents уже можуть виконувати надійно, що поки не варто автоматизувати та де необхідно зберігати перевірку людиною.
Головна відмінність AI Agent від розмовного ШІ в тому, що Agent уміє діяти: відкривати браузер, заповнювати форми, читати й змінювати таблиці та проходити робочий процес крок за кроком без постійного копіювання і вставляння з боку користувача.
Ця різниця справді дає помітне зростання можливостей, але водночас дуже швидко показує межу між тим, що працює, і тим, що поки не працює. Після кількох запусків зазвичай стає зрозуміло, що головні перешкоди рідко бувають суто технічними; частіше вони лежать в іншій площині.
Завдання, які справді працюють уже зараз
Стабільні сьогодні сценарії мають спільну рису: людина може швидко перевірити результат, а помилка не призводить до незворотних наслідків.
Найпростіший варіант — упорядкування й моніторинг даних. Agent може регулярно збирати відомості з кількох джерел, узгоджувати поля, видаляти дублікати та готувати щоденний або щотижневий звіт про зміни швидко і без втоми. Коливання цін, стан запасів, зміни позицій у рейтингах та оновлення відкритих даних добре підходять для такого підходу. Якщо процес лише читає дані й нічого не записує, ціна помилки практично нульова.
Масове створення перших чернеток і переробка контенту теж уже придатні для практичного використання. Отримавши тему, Agent може зібрати публічну інформацію, перетворити її на структуровані нотатки й підготувати каркас першої чернетки, істотно скоротивши час на пошук матеріалів. З переробкою тексту діє той самий принцип: довгий матеріал можна розділити й адаптувати під довжину та тон різних каналів із досить високим ступенем готовності. Але результат усе одно слід вважати чернеткою. Частини, де потрібні досвід, судження або власна позиція, має доповнити людина; інакше зміст буде порожнім.
Перша лінія підтримки клієнтів і відповіді на електронні листи також можуть зняти значну частину навантаження. Поширені запитання, перевірка статусу доставки, пояснення правил повернення й обміну, підтвердження запису зазвичай мають стандартні відповіді. Agent може спочатку обробляти такі звернення, а розмови поза заданим сценарієм позначати й передавати людині. Швидкість відповіді помітно зростає.
Порівняння цін і зведення інформації працюють так само стабільно. Зібрати в одній таблиці ціни на той самий товар у різних каналах, відмінності характеристик і часті скарги з відгуків часто надійніше, ніж вручну переглядати все окремо. Якщо чітко задати параметри порівняння, результат зазвичай можна використовувати відразу.
У цих чотирьох сценаріїв є ще одна прихована умова: межі завдання мають бути зрозумілими. Що точніше визначено «що надходить на вхід, що має бути на виході та за якої умови треба зупинитися», то стабільніше працює процес.
Завдання, які поки не працюють надійно
Інший бік межі теж зрозумілий. Проблема не обов’язково в можливостях моделі, а в обмеженнях реального світу.
Найочевидніший приклад — операції, що потребують ідентичності облікового запису. Стан входу, підтверджені дані особи та накопичена репутація відображають права, які платформа надає конкретному суб’єкту. Agent не може отримати їх лише технічним способом. Доручити Agent «керувати акаунтом» принципово не те саме, що доручити йому «обробити набір даних».
Дії, пов’язані з платежами, також не варто віддавати повній автоматизації. Оформлення замовлення, списання коштів, переказ грошей або погашення активів — це операції з реальною цінністю. Для кожної з них розумно залишити людині останній крок підтвердження. Річ не лише в ризику помилки: фінансові дії часто незворотні.
Є й дії, результат яких обов’язково має бути визнаний платформою. Проходження оцінювання, підтвердження кваліфікації, реєстрація на подію чи схвалення контенту залежать від рішення платформи. Технічного обходу такого рішення не існує. Твердження, що інструмент може гарантовано отримати таке схвалення замість вас, зазвичай не підтверджуються на практиці.
Масова реєстрація акаунтів і автоматичне виконання завдань заради винагород також не повинні бути частиною розумного робочого процесу. Такі практики зачіпають одні з найчіткіше прописаних правил платформ. Крім того, виявлення може враховувати не лише окрему дію: значення мають ритм операцій, поведінкові послідовності та узгодженість середовища. Навіть якщо схема працює технічно, строк життя акаунтів залежить від того, що платформа готова терпіти, а ця умова може змінитися будь-коли.
Контрольні точки, які варто залишити людям
Agent найкраще використовувати як виконавчий рівень. Кілька етапів варто постійно тримати під контролем людини.
Визначення цілей і пріоритетів. Рішення про те, що робити, за яким критерієм оцінювати результат і коли зупинятися, набагато важливіше за чисту швидкість виконання. Agent не візьме на себе наслідки неправильно обраного напряму.
Перевірка зовнішніх матеріалів. Усе, що буде прочитано від вашого імені — листи, відповіді, дописи чи звіти, — слід перевіряти перед відправленням. Причина практична: якщо там буде помилка, відповідати доведеться вам.
Підтвердження дій із грошима та правами доступу. Права на читання можна зробити широкими, щоб Agent у будь-який момент переглядав дані й готував звіти. Звичайні коригування, наприклад зміну параметра або зупинку неефективного завдання, теж можна делегувати. Але великі зміни й масові операції мають проходити повторне підтвердження людиною. Так зберігаються і ефективність, і контрольованість.
Збереження журналу виконання. Потрібно фіксувати, що зробив Agent і за яким правилом. У разі проблем цей журнал стає основою для розслідування, а в повсякденній роботі — джерелом даних для покращення процесу.
Коли потрібно паралельно запускати більше акаунтів
Після того як один робочий процес починає працювати стабільно, природно виникає питання: чи можна застосувати ту саму схему до більшої кількості акаунтів?
На цьому етапі вузьким місцем зазвичай стає не Agent, а середовище облікових записів. Якщо кілька акаунтів працюють в одному браузерному середовищі та через один мережевий вихід, платформа може легко об’єднати їх в одну групу й обробляти разом. Практичний підхід — пов’язати кожен акаунт з окремим середовищем: виділити йому незалежне браузерне середовище та фіксований мережевий вихід, а під час запуску завдань завантажувати відповідне середовище. Інструменти на кшталт PurpleMark надають саме таке керування кількома середовищами й можуть працювати зі скриптами, що перемикають середовище залежно від акаунта.
Але порядок не можна міняти місцями. Ізоляція середовища вирішує лише питання про те, «чи виглядають акаунти як незалежні користувачі». Вона не відповідає на питання, чи варто взагалі виконувати певну дію. Спочатку сама активність акаунта має відповідати правилам, і лише після цього ізоляція має сенс.
Порядок упровадження з меншим ризиком помилок
Почніть з одного невеликого й конкретного сценарію замість спроби одразу автоматизувати весь процес. Перевірте, чи можна використовувати результат напряму; якщо так, додайте наступний етап. На цьому ж кроці визначте межі повноважень, особливо права на запис і дії з грошима. Дайте одному процесу стабільно попрацювати певний час, перш ніж розширювати його на більшу кількість акаунтів, і налаштуйте ізоляцію середовищ до масштабування.
Такий порядок трохи повільніший, але на кожному етапі ціна помилки залишається низькою, а висновки з кожного кроку можна використовувати повторно.
