Ваше демо агента працює. Ваш агент — ні.
Більшість архітектур агентів не справляються з реальною роботою.
Демонстрація виглядає чудово, коли є одне завдання та швидка відповідь. Реальна робота включає страхові претензії, послідовності продажів або звірку даних. Ці завдання потребують часу та багатьох кроків.
Проблема полягає у відсутності збереження стану (statelessness). Більшість агентів щоразу заново відновлюють контекст із нуля під час взаємодії. Вони втрачають ланцюжок міркувань та досягнутий прогрес. У підсумку ви отримуєте ввічливий ШІ, який лише вдає, що розуміє ситуацію.
Експерти Google Cloud Адді Османі та Шубхам Сабу поділилися п'ятьма патернами для вирішення цієї проблеми. Ось детальний розбір:
Checkpoint-and-Resume (Контрольна точка та відновлення) Ставтеся до свого агента як до сервера. Зберігайте прогрес через кожні кілька одиниць роботи. Якщо агент зазнає невдачі на завданні 201 із 1000, він має продовжити з 201-го. Не починайте з нуля.
Delegated Approval (Делеговане схвалення) Припиніть використовувати Slack або електронну пошту для схвалення людиною. Ці інструменти розривають контекст. Поставте агента на паузу в поточному місці. Зберігайте повний стан незмінним, щоб він миттєво відновив роботу, коли людина відповість. Використовуйте структуровану поштову скриньку для запитів та помилок.
Memory-Layered Context (Контекст із багаторівневою пам'яттю) Відокремте довготривалу пам'ять від робочої пам'яті. Довготривала пам'ять зберігає знання між сесіями. Робоча пам'ять обробляє поточне завдання. Ви повинні запобігати «дрейфу пам'яті» (memory drift), коли агенти переймають погані звички через граничні випадки. Використовуйте управління ідентифікацією та рівень управління (governance layer), щоб блокувати некоректні дані.
Ambient Processing (Фонова обробка) Створюйте агентів, які стежать за потоками даних, такими як запити в службу підтримки або зміни в базах даних. Не зашивайте правила безпосередньо в агента. Розміщуйте правила у зовнішньому рівні управління (governance layer). Таким чином, ви зможете оновлювати правила в одному місці, і весь «флот» агентів їх дотримуватиметься.
Fleet Orchestration (Оркестрація флоту) Використовуйте агента-координатора для керування агентами-спеціалістами. Кожен спеціаліст має власні інструменти та ідентифікацію. Це відповідає патерну «воркер» (worker pattern), що використовується в розподілених системах. Ви можете оновити одного спеціаліста, не порушуючи роботу всієї системи.
Найбільший ризик — це дрейф пам'яті (memory drift).
Люди зосереджуються на промптах, але ігнорують те, як поведінка агента змінюється з часом. Якщо агент навчається на основі поганих або дивних взаємодій, він перестає діяти відповідно до написаного вами коду.
Ви повинні ставитися до агентів як до мікросервісів. Їм потрібні ідентифікація, реєстр та суворе дотримання політик.
Запитайте себе: Яке найтриваліше завдання має виконувати мій агент без зупинок? Якщо відповідь — години або дні, вам потрібні ці патерни.
Демонстрація вашого агента працює, а сам агент — ні
Ви побудували ШІ-агента. Він неймовірний. Він виконує інструкції, викликає інструменти та вирішує складні завдання. Ви показуєте його своєму керівнику, і той у захваті. Потім ви запускаєте його в продакшн, і він починає розвалюватися. Чому?
Пастка демонстрації
Коли ми створюємо демо-версію, ми зазвичай створюємо так званий «щасливий шлях» (happy path). Ми точно знаємо, які запити будемо надсилати, які інструменти будуть викликані та які відповіді ми отримаємо. Ми не будуємо агента; ми створюємо добре відрепетировану виставу.
У реальному світі користувачі не діють за сценарієм. Вони вводять заплутані, неоднозначні або навіть шкідливі дані. Вони змінюють тему розмови на півдорозі. Вони просять про речі, на які ваш агент не був розрахований.
Чому агенти дають збої в продакшні
1. Непередбачуваність вводу користувачів
У демо-версії ви контролюєте середовище. У продакшні — ні. Користувачі надаватимуть дані, що виходять за межі вашої моделі, мають неправильний формат або є логічно суперечливими. Якщо ваш агент не є достатньо надійним, щоб обробляти такі випадки, він вийде з ладу.
2. Збої інструментів та API
Агенти покладаються на мережу інструментів та API. У демо-версії ці інструменти завжди працюють ідеально. У продакшні API можуть не працювати, затримки можуть зростати, а інструменти можуть повертати неочікувані помилки. Якщо ваш агент не має механізмів обробки помилок і логіки повторних спроб, він просто зламається.