Оркестрація ШІ-агентів: збої, схвалення та повторні спроби

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

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

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

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

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

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

Розгляньмо приклад із воркшопу Perplexity про Computer: створення аналітичної панелі щодо клієнтів на основі інформації із Salesforce, Snowflake, електронної пошти, календаря та свіжих новин.

Зрозуміти мету й спланувати роботу. Оркестратор починає з бажаного результату й розкладає його на завдання з явними залежностями. У нашому прикладі з панеллю це передбачає збирання інформації з різних джерел і перетворення її на готовий результат. Планувальник визначає, які кроки залежать від інших, а які можуть виконуватися незалежно.
Спрямувати завдання відповідним агентам. Оркестратор визначає завдання, залежності яких задоволено, і делегує роботу спеціалізованим агентам або моделям. Залежні завдання чекають на виконання своїх передумов. Perplexity Computer використовує кілька передових моделей, спрямовуючи різні частини робочого процесу до систем, які найкраще підходять для цих завдань. Це також дає змогу виконувати незалежну роботу паралельно.
Виконувати виклики інструментів у контрольованих середовищах. Агенти взаємодіють зі своїм середовищем через інструменти, як-от вебпошук, API, підключені застосунки, операції з файлами або виконання коду. Рівень виконання запускає ці дії та повертає результати агентам.
Передавати результати й контекст між агентами. Щойно агент завершує своє завдання, наступному агенту в ланцюжку потрібні відповідні вихідні дані, щоб продовжити роботу. Запис про передачу може містити ідентифікатор завдання, посилання на вихідні дані, версію схеми та метадані джерела. Оркестратор координує ці передачі, зберігаючи контекст, потрібний для подальших кроків. Важливо, що агентам не потрібно тримати у своїх контекстних вікнах усю історію роботи кожного іншого агента.
Зберігати стан виконання окремо від контексту агента. Коли агенти починають чи завершують завдання або не можуть їх виконати, механізм виконання оновлює постійний запис робочого процесу зі статусами завдань, спробами виконання, посиланнями на вихідні дані та рештою роботи. Цей запис дає оркестратору змогу відстежувати прогрес і відновлювати роботу після переривань, не покладаючись на LLM для відтворення робочого процесу з історії розмови.
Перевіряти результати й вирішувати, що робити далі. Коли завдання повертає результат, рівень оркестрації перевіряє, чи відповідають його вихідні дані очікуваному контракту і чи виконано залежності наступного завдання. Якщо виявлено проблему, робочий процес може повернутися до попереднього кроку для виправлення або призупинитися. Інакше він продовжується до завершення.

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

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

Отже, оркестрація корисна у трьох сценаріях:

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

В інших випадках оркестрація — це лише дорогий тренд. Більше агентів також означає більше координації та потенційно вищі витрати на токени.

«Зазвичай я починаю з найпростішого варіанту й розвиваю його далі. Якщо ми знаємо кроки й вони повторювані, це, найімовірніше, робочий процес. Я бачу причину залучати кількох агентів лише тоді, коли в них різні обов’язки, дозволи або користувачі», — каже Josh Spilker, керівник напряму пошукового маркетингу в AirOps.

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

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

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

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

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

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

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

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

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

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

Така структура може допомогти, коли робочі процеси надто широкі, щоб один оркестратор міг ефективно ними керувати.

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

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

Порівняння цих архітектур:

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

Варто розуміти ще одну відмінність. Архітектура визначає, хто координує агентів. Шаблон виконання визначає, як просуваються їхні завдання.

Ось три шаблони виконання:

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

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

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

Передавання між агентами із втратою інформації. Оркестратор передає спеціалізованому агенту стислий план, але в цьому підсумку губляться обмеження, залежності чи деталі реалізації.
Передчасне об’єднання результатів (fan-in). Наступний у ланцюжку агент починає агрегувати результати ще до завершення всіх попередніх завдань.
Недетерміновані оновлення спільного стану. Паралельні агенти записують у ті самі ключі стану без чітко визначеної семантики злиття. Залежно від того, як фреймворк обробляє оновлення, це може призвести до втрати записів, дублювання даних, результатів, що залежать від порядку виконання, або конфліктних змін.
Розбіжність між контрольними точками й побічними ефектами. Завдання виконує зовнішню операцію, але її успішне виконання не встигає надійно зафіксуватися до збою обробника. Під час відновлення оркестратор бачить незавершене завдання й запускає його повторно.
Стани гонитви під час відновлення після схвалення людиною. Призупинення й відновлення виконання створюють власні проблеми синхронізації.
Цикли делегування й лавиноподібне зростання повторних спроб. Агенти раз у раз передають роботу одне одному, бо їхні обов’язки перекриваються, залежності циклічні або умови завершення неоднозначні.
Засоби контролю на рівні інструкцій, які помилково сприймають як безпеку виконання. Оркестратор може наказати агентам не звертатися до певних ресурсів або не виконувати чутливі дії, але інструкції для моделі не забезпечують дотримання дозволів операційної системи, мережевих обмежень чи меж авторизації. Дослідження з інженерії безпеки Perplexity пояснює, чому агенти можуть перетинати межі безпеки, переслідуючи легітимні цілі, навіть без зловмисних інструкцій

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

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

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

Мета: Виявити й усунути причину нестабільного інтеграційного тесту API оформлення замовлення.
Вхідні дані: Вихідний код тесту, журнали збоїв CI, нещодавні коміти й відповідний код застосунку.
Обмеження: Не вимикати тести, не послаблювати твердження (assertions) і не змінювати непов’язану поведінку застосунку.
Очікуваний результат: Патч коду, пояснення першопричини й результати виконання тестів.
Критерії прийняття: Тест, який раніше не проходив, успішно проходить 10 запусків поспіль, а відповідний набір регресійних тестів також проходить.
Умови невдачі: Не вдається встановити першопричину, виправлення спричиняє регресії або потрібне тестове середовище недоступне.

Але є ще одна важлива частина: коли агент має зупинитися?

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

Повернімося до нашого прикладу з CI. Можна визначити такі умови зупинки:

Успіх: Виправлення проходить 10 тестових запусків поспіль і відповідний набір регресійних тестів.
Ліміт ітерацій: Агент може спробувати не більше ніж два варіанти виправлення.
Бюджет виконання: Агент має зупинитися через 60 хвилин, навіть якщо проблему не вирішено.
Ліміт делегування: Агент може делегувати роботу одному спеціалізованому агенту без подальшого делегування субагентам.
Часткове виконання: Якщо обидві спроби невдалі або ліміт часу вичерпано, агент повертає свої висновки, зміни, які він намагався внести, і результати тестів.
Заблоковане виконання: Якщо тестове середовище недоступне, агент зупиняється й повідомляє про перешкоду, а не заявляє про успіх.

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

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

Розгляньмо приклад: status: completed стосується призначеної агенту роботи, а не всього робочого процесу. Оскільки тести досі в стані pending, оркестратор не повинен схвалювати остаточний результат.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

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

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

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

Припустімо, ваш CI-агент запускає тестовий прогін, але час очікування відповіді на запит до API спливає. Тестовий прогін не запустився чи сервіс CI поставив його в чергу й утратив відповідь?

Тайм-аут не обов’язково означає, що операція завершилася невдало. Тому, перш ніж вирішувати, що робити далі, потрібно розрізняти помилки:

Тимчасові помилки (429, 503): Повторюйте спроби з обмеженою експоненційною затримкою та випадковим розкидом (jitter), дотримуючись Retry-After, якщо його передано.
Помилки валідації чи дозволів (400, 403): Зупиніться або усуньте першопричину, замість того щоб повторювати той самий запит.
Неоднозначні результати (тайм-аут після можливого запису): Перевірте, чи операція виконалася успішно, перш ніж пробувати знову.

Примітка: Навіть для помилок, які можна повторити, потрібні ліміти. Установіть тайм-аут для кожного виклику інструмента, обмежте кількість повторних спроб і загальний час на них, а також запровадьте загальний дедлайн робочого процесу, щоб вкладені агенти не могли безкінечно перезапускати ту саму операцію. Якщо залежність постійно дає збій, використовуйте запобіжник (circuit breaker), щоб тимчасово припинити запити.

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

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

Приклад логіки повторних спроб для нашого CI-агента у вигляді псевдокоду:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Примітка до коду: У прикладі передбачається, що API CI підтримує пошук прогонів за ідентифікатором запиту. Параметр request_id запобігає дублікатам лише тоді, коли постачальник явно гарантує ідемпотентність. bounded_retry() — це ілюстративний псевдокод. У продакшені повторні спроби мають обмежуватися як бюджетом повторних спроб для кожної операції (максимальною кількістю спроб або витраченим часом), так і загальним дедлайном робочого процесу.

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

Тут потрібно збалансувати дві речі: скільки можливостей моделі потребує кожне завдання і скільки завдань ви можете виконувати одночасно. Помилитеся в будь-чому з цього — і ризикуєте тим, що агенти конкуруватимуть за спільні квоти API або покладатимуться лише на дорогі моделі з міркуванням.

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

Наприклад, режим зусиль у Perplexity Computer дає змогу вибрати, скільки зусиль заслуговує завдання, без ручного вибору моделі. Виберіть Light, Standard, High або Ultra, і Perplexity автоматично вибере оркеструвальну модель та її рівень міркування. Потім цей оркестратор делегує підзавдання допоміжним агентам, які можуть використовувати моделі різних постачальників.

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

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

Щоб споживання ресурсів залишалося передбачуваним, запровадьте ліміти ресурсів і засоби контролю планування:

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

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

«Я скептично ставлюся до надмірно складних мультиагентних систем, особливо коли агенти рецензують і схвалюють роботу одне одного. Може статися так, що кілька агентів упевнено передаватимуть ту саму помилку далі, і ніхто насправді її не помітить», — застерігає Спілкер.

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

Для дій, що потребують схвалення людиною, призупиніть виконання й збережіть точну запропоновану операцію:

її параметри
її цільовий ресурс
її коміт або версію стану
рішення рецензента

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

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

Спілкер також не підтримує уявлення про повністю автономних наскрізних агентів як про мету. «Як на мене, кращий підхід — створити кілька вузькоспеціалізованих агентів із чіткими обов’язками, визначеними дозволами й перевіркою людиною в потрібних місцях. Ви все одно отримуєте ефективність, не відмовляючись від повного контролю», — підсумовує він.

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

Щоб розібратися, відстежте, що відбувалося під час виконання, і незалежно перевірте результати. Тож приділімо трохи часу тому, щоб локалізувати й усунути проблему.

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

Семантичні конвенції GenAI від OpenTelemetry надають стандартизований спосіб опису цих операцій. Наприклад, invoke_workflow позначає виконання робочого процесу, invoke_agent — виклик агента, а execute_tool — виклик інструмента. Кожну операцію можна записати як span із її часовими показниками, статусом і відповідними метаданими.

Цей крок дає вам трасування шляху виконання, тож ви зможете визначити, де в агента стався збій.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Ілюстративне трасування виконання.

Використовуйте програмні перевірки скрізь, де це можливо. Валідуйте результати за JSON-схемами, запускайте модульні й інтеграційні тести, перевіряйте наявність потрібних артефактів і надсилайте запити до зовнішніх систем, щоб підтвердити, що дії справді виконано успішно.

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

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

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

Щоб перевірити це, навмисно вносьте збої в тестовому середовищі:

Імітуйте тайм-аути API
Аварійно завершуйте воркери між записами в зовнішні системи та контрольними точками
Повертайте некоректні результати інструментів
Допускайте закінчення терміну дії схвалень

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

Припустімо, ваш агент CI надсилає запит на запуск тестового прогону, але час очікування відповіді API спливає. Агент повторює спробу, отримує успішну відповідь і повідомляє Success. Усе виглядає гаразд, доки ви не перевірите сервіс CI і не виявите, що замість одного тестового прогону було створено два.

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

Додавайте виявлені збої до регресійних тестів, щоб майбутні зміни не повернули їх знову.

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

Ізольовані агенти можуть правильно виконувати свої окремі завдання, але разом давати неузгоджені результати. Уявіть, що агент із продажів отримує умови клієнта о 10:00, агент із ціноутворення розраховує комерційну пропозицію за оновленими цінами о 10:05, а юридичний агент перевіряє договір, який змінився о 10:07. Кожен агент працює з іншим знімком стану бізнесу, тож їхні результати можуть суперечити одне одному.

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

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

Не повторюйте незмінені запити після помилок валідації або дозволів. Якщо залежний сервіс постійно дає збій, автоматичний вимикач (circuit breaker) може не дати агентам створювати додаткове навантаження.

Механізм відновлення залежить від вашого середовища виконання. У LangGraph постійне сховище контрольних точок (checkpointer), як-от PostgresSaver, зберігає стан графа за ключем thread_id, що дає змогу продовжити виконання зі збереженого стану. У Temporal інший воркер може відтворити робочий процес, програвши його історію подій. Під час відтворення він повторно використовує раніше записані результати активностей.

Якщо застосунок повторно розгортають, поки робочі процеси ще виконуються, збережений стан та історії виконання можуть стати несумісними. Temporal розв’язує цю проблему за допомогою Worker Versioning і патчів робочих процесів (workflow patching). Для систем на основі контрольних точок плануйте міграції схем і тестуйте відновлення на наявних збережених станах, перш ніж розгортати несумісні зміни.

Запускайте ті самі репрезентативні завдання кілька разів і розрізняйте pass@k (чи успішна хоча б одна з k спроб) і pass^k (чи успішні всі k спроб)

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

Що таке оркестрація ШІ-агентів?

Як працює оркестрація ШІ-агентів: усередині механізму виконання

Коли варто використовувати оркестрацію ШІ-агентів?

Архітектури оркестрації ШІ-агентів та їхні компроміси

Централізована оркестрація

Децентралізована оркестрація

Ієрархічна оркестрація

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

Типові збої оркестрації ШІ-агентів

7 найкращих практик оркестрації ШІ-агентів для надійної роботи в продакшені

1. Визначте чіткі контракти завдань, критерії прийняття й умови зупинки

2. Не перевантажуйте оркестратори й запровадьте структуровані передавання

3. Зберігайте стан робочого процесу й контролюйте зростання контексту

4. Проєктуйте повторні спроби з урахуванням типів збоїв і відновлюване виконання інструментів

5. Маршрутизуйте й розпаралелюйте роботу з чіткими бюджетами ресурсів

6. Запровадьте обов’язкові схвалення й ізолюйте виконання агентів

7. Перевіряйте результати незалежно й тестуйте поведінку під час відновлення

Відстежте робочий процес, щоб з’ясувати, що пішло не так

Незалежно перевірте результати

Штучно вносьте збої, щоб перевірити відновлення

Поширені запитання про оркестрацію ШІ-агентів

Чому ізольовані ШІ-агенти дають збій у масштабах підприємства?

Як запобігти нескінченним циклам повторних спроб у ШІ-агентах?

Як відновити робочий процес ШІ-агента після збою?

Як перевірити надійність оркестрації ШІ-агентів?