Чому більшість ШІ-агентів гинуть після однієї сесії та як ті, що працюють довго, виживають.

Чому багато агентів здаються тимчасовими

Кожен, хто використовував ChatGPT, Claude чи іншого агента для виклику інструментів, бачив звичайну схему:

1. Ви передаєте завдання.
2. Агент починає працювати.
3. Він викликає кілька інструментів.
4. Розмова стає довгою.
5. Відповіді погіршуються, або сесія просто закінчується.

Це звичайний досвід роботи з чат-агентом. Він підходить для коротких завдань та припиняє працювати, коли робота триває години чи дні.

Агент, який працює довго, продовжує досягати прогресу протягом значно довшого періоду — чи то годин, днів чи тижнів — і не втрачає своїх досягнень, коли контекст заповнюється чи процес перезапускається. Ось ідея з самого початку, а потім — закономірності, які забезпечують її функціонування.

Почніть просто: що таке агент, який працює довго

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

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

У технічних термінах такий агент може існувати протягом кількох контекстних вікон, виживати після перезапусків та збоїв (стійкість до несправностей), залишати структуровані дані у вигляді артефактів та журналів сеансів, а також відновлювати роботу без початку з нуля.

Зберігання стану поза моделлю та його чисте відновлення є ключовою частиною того, що називають інженерією керування.

Три стіни

Майже кожен агент, який працює протягом тривалого часу, стикається з тими самими трьома проблемами.

1. Обмежений контекст. Кожна модель має обмежене вікно контексту, і навіть великі вікна заповнюються. Коли воно заповнюється, старіша інформація видаляється або стискається, що погіршує рішення агента. Це часто називають розкладанням контексту.
2. Відсутній постійний стан. Нова сесія зазвичай починається з порожньої пам’яті. Оскільки немає способу зберігати прогрес поза системою, кожне перезапускання схоже на те, як новий співробітник приєднується до проекту, не знаючи нічого про його історію.
3. Слабка самоперевірка. Моделі схильні до оптимізму. Коли їх запитують, чи завершена робота, вони часто відповідають «так», хоча робота виконана лише частково. Без зовнішньої перевірки незавершена робота вважається завершеною.

Ці три причини пояснюють, чому прості агенти не можуть надійно працювати протягом тривалого часу.

Від основ до корисних шаблонів

Як тільки стіни усунені, виникає питання про те, як люди їх подолають. Чотири основні патерни постійно з’являються знову.

• Перевірка та відновлення. Агент періодично зберігає прогрес у структурованому вигляді. Якщо щось зазнає невдачі, він починає роботу з останньої коректної точки перевірки, а не з початку.
• Зовнішня пам’ять. Важливі дані зберігаються поза контекстом моделі — у файлах, базі даних чи системі зберігання сеансів, і агент читає їх на початку кожного нового сеансу.
• Участь людини. Для важливих рішень агент зупиняється, чекає, поки людина схвалить чи відхилить пропозицію, а потім продовжує роботу. Цей механізм потрібно ретельно спроєктувати, щоб стан не ставав застарілим під час очікування.

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

Ці патерни самі по собі прості, але разом вони є дуже потужними.

Ментальна модель

Корисне уявлення: модель — це мозок, інструменти — це руки, а журнал сеансу разом із зовнішнім станом — це пам’ять, яка зберігається.

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

Що стає можливим

Коли агенти можуть існувати довше, відкриваються нові види роботи:

• дослідження, які тривають кілька днів;
• масштабні міграції коду;
• постійний моніторинг та робота на фоні;
• робочі процеси, які потребують людського схвалення на певному етапі;
• команди агентів, які координують свої дії протягом часу.

Агенти для коротких чатів добре справляються з відповідями на запитання. Агенти, які працюють тривалий час, починають бути корисними для досягнення реальних результатів.

Від демо-версії до продакшну

Більшість демо-версій закінчуються на цьому етапі, і починається справжня робота над проектом. П’ять патернів відіграють ключову роль у цьому процесі.

1. Точка контролю та відновлення

Це найважливіший патерн, оскільки найпоширенішою проблемою під час тривалої роботи є втрата прогресу. Уявіть агента, який обробив 200 документів та зіткнувся з помилкою на 201-му. Без точки контролю, тобто копії стану пам’яті чи процесу, вся робота йде на марно. Багато агентів реагують на це перезапуском усього процесу, що споживає велику кількість токенів.

Хороша система регулярно записує стан прогресу, фіксуючи:

• що вже було завершено;
• що ще залишається незавершеним;
• будь-які важливі проміжні результати.

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

2. Пам’ять поза моделлю

Зазвичай існує два типи:

• Робоча пам’ять — це те, що потрібно агенту прямо зараз, у поточному контексті.
• Стійка пам’ять — це те, що має зберігатися після завершення сеансу, і вона зберігається зовні.

Стійка пам’ять може зберігатися у структурованих файлах, таких як progress.txt, plan.json або notes.md, у базі даних, у сховищі сеансів чи у спеціалізованій службі пам’яті. Принцип простий: модель може забувати, але система навколо неї — ні.

3. Розділяйте процес генерації та оцінки

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

Часто використовується така структура: спочатку керівник або планувальник, потім експерти з завдань як виконавці, а далі — оцінювач, який займається розподілом та координацією. Наступний варіант описує це більш детально.

4. Правильна схвалення з боку людини

Багато систем стверджують, що підтримують процес схвалення, але реалізують його погано. У примітивній версії зберігається трохи JSON-даних, надсилається сповіщення, очікується відповідь від людини, а потім намагається продовжити роботу, часто з застарілим станом даних.

Краща версія розглядає паузу як частину самого процесу роботи. Агент доходить до чітко визначеної точки прийняття рішення, чітко зберігає свій стан та чекає. Коли людина відповідає, агент продовжує роботу, точно знаючи, чому зробив паузу. Це особливо важливо для дій із наслідками, таких як витрачання грошей, зміна виробничих систем чи надсилання повідомлень за межі організації.

5. Координація багатьох агентів

У міру збільшення кількості завдань один агент, який робить усе сам, починає створювати хаос. Більш стабільний підхід розділяє обов’язки:

• планувальники досліджують проблему та розбивають її на завдання;
• виконавці виконують конкретні завдання;
• судді вирішують, чи є певна ітерація достатньо гарною.

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

Як виглядає стек для обробки даних

Реалістичний стек зазвичай складається з трьох шарів:

1. Логіка агента, тобто запити, інструменти та цикл прийняття рішень.
2. Механізм керування, тобто управління сеансами, контроль робочого процесу, повторні спроби та відновлення.
3. Керовані примітиви, тобто надійне зберігання даних, планування, інструменти для тривалої роботи, тригери подій та можливості моніторингу.

Наприклад, ADK від Google постачає елементи для створення сеансів, які зберігаються, для забезпечення продовження виконання після перезапуску, а також тригери, які активуються подіями. Завдяки цьому агент може довго залишатися неактивним, а потім все одно правильно продовжити роботу. У статтях Anthropic про механізми керування наголошується на необхідності розділення „мозку“ — моделі та її циклу прийняття рішень — від „рук“ — середовищ виконання, а також від сеансу — надійного журналу подій.

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

Правила проектування, які допомагають

Ці звички надійно роблять системи міцнішими:

• Щоразу зберігайте важливу інформацію про прогрес у надійному сховищі.
• Віддавайте перевагу структурованим форматам, таким як JSON, журнали у форматі markdown та списки завдань, замість інформації у вигляді звичайного тексту в пам’яті.
• Ставіться до збоїв як до чогось нормального та плануйте їх усунення.
• Забезпечуйте можливість продовження роботи за стандартним маршрутом, а не як у особливому випадку.
• Коли важлива якість, тримайте виробника та оцінювача окремо.
• Використовуйте компактифікацію чи узагальнення, коли обсяг контексту починає зростати занадто сильно.
• Навмисно передбачайте точки схвалення проекту, а не додавайте їх пізніше.

Невеликі рішення накопичуються. Одна хороша стратегія створення контрольних точок може врятувати багатоденну роботу та заощадити як час, так і ресурси.

Обмеження, які залишаються

Навіть за наявності хорошої архітектури існують незмінні обмеження:

• Витрати. Довгі процеси споживають багато токенів.
• Безпека. Система, яка працює довше, має більшу поверхню для атак.
• Відхилення від початкової мети. З часом агент може поступово відхилятися від первісної мети.
• Перевірка. Деякі аспекти якості все ще потребують людського оцінювання.

Роль людини не зникає — вона змінюється. Замість виконання кожного кроку люди визначають цілі, встановлюють обмеження, переглядають критичні рішення та вирішують винятки, з якими система не може ефективно впоратися.

Що це означає для вас

Короткі чат-агенти підходять для запитань та дрібних завдань. Агенти, які працюють довго, підходять для роботи, яка вимагає часу, охоплює кілька сеансів або має пережити перерви у реальному світі.

Ця зміна менше пов’язана з роботою над тим, щоб зробити модель розумнішою, а більше — зі створенням навколишньої системи, яка буде стійкою, здатною до відновлення та чесною щодо власного прогресу. Оскільки ці системи мають прослужити довше, ніж час, збої та обмеження контексту, їх проектування стає значно простішим. Агенти, здатні виконувати значущу роботу, зазвичай походять з команд, які ставлять наполегливість та відновлення в центр проектування.

Пов’язана література

• Практичні нотатки: Проектування кешу для AI-агентів: Його використання в промислових умовах — Детальний посібник з практичних нотаток щодо проектування кешу для AI-агентів та його роботи в промислових умовах: контракти, перевірки та шаблони коду для команд, які впроваджують цю модель.

Чому агенти, які вражають у демо-версіях, зазнають невдач у реальних умовах, та що слід створювати замість них — причини невдач, компроміс між одиночним та багатоагентним підходом, практики проектування, такі як повторні спроби та запасні рішення, а також повна картина витрат на експлуатацію AI-агента окрім плати за токени.

Керування AI-агентами за допомогою FRAMEWORK CARE: ясність, автономія та інше — ідеї керування також застосовні до AI-агентів. Дізнайтеся, як ясність, автономія, взаємовідносини та рівність впливають на делегування обов’язків, умови контрактів з агентами, вибір моделей та контекст, необхідний агентам.