Розробка оркестратора AI-агентів: де ламається процес
Ланцюжок агентів ламається не на генерації відповіді, а на стиках між кроками.
Один агент передає результат другому у вільній формі, другий перепитує і запускає той самий інструмент заново — так збій ланцюжка агентів перетворюється на дублювання викликів: двічі списаний залишок, двічі створена заявка, двічі надісланий лист. У журналі видно результат кроку, але не видно, чому він узагалі був зроблений.
Друга точка відмови — втрата стану задачі. Обрив з'єднання, перезапуск сервісу або перевищення часу очікування на середині сценарію обнуляють контекст, і агент іде з першого кроку, вже маючи за собою частково виконані дії.
Закривається це не повторами, а журналом кроків і контрольними точками: кожен перехід фіксується, повторний запуск продовжує з останньої підтвердженої точки.
Окрема проблема — межі доступу. Агент із широкими правами звертається до внутрішніх систем напряму: пише в базу, викликає адміністративні методи, забирає дані поза межами задачі.
Обмеження мають стояти на рівні інструментів і ролей, а не в текстовій інструкції — формулювання в описі можна обійти, політику доступу ні.
І поверх усього — непрозорість рішень агента. Відповідь приходить, а відповісти на питання, які дані використовувалися, які інструменти викликалися і де логіка звернула не туди, нічим. Розбираємо, як закривається кожне з цих місць.
Що змінюється після впровадження керованих агентних систем
Ефект агентної системи вимірюється двічі — до впровадження і після місяця експлуатації: час проходження сценарію, частка звернень без ручного втручання, кількість збоїв на тисячу операцій і клас відмов, який перестав траплятися.
Нижче — чек-ліст, за яким приймаємо роботу: кожен пункт перевіряється на живому потоці задач, а не на демонстраційному сценарії.
- Час виконання сценарію. Ланцюжок із 5–8 кроків виконується без пауз на передачу між людьми; очікування погодження залишається лише там, де воно потрібне за регламентом.
- Частка звернень без оператора. Рахується за кожним типом запиту окремо: рутинні переходять в автономний режим, людина підключається на винятках і нетипових випадках.
- Скорочення ручних операцій. Звірка даних, вивантаження, підготовка документів і постановка задач переводяться в кроки агента з фіксованим результатом, а не в інструкції для співробітника.
- Стійкість до відмов. Ретраї, таймаути і жорстке обмеження кількості кроків знімають клас відмов «цикл без виходу» і «втрата контексту» — вони помітні в метриках, а не спливають у клієнта.
- Спостережуваність. Кожен крок агента залишає слід: вхід, викликаний інструмент, відповідь, тривалість. Трасування будується на відкритому стандарті OpenTelemetry, тому дані не замикаються у форматі одного постачальника.
- Відновлення. Відкат на попередню конфігурацію оркестратора займає хвилини і не потребує перезбирання зв'язок між агентами.
- Витрата ресурсів. Прості запити маршрутизуються на легкі моделі, важкі — на сильні; навантаження перестає зростати лінійно разом із кількістю звернень.
Ці сім пунктів дають одну картину: скільки роботи система закриває сама, де вона ламається і як швидко повертається в стрій.
Варіанти побудови агентної системи: порівняння режимів
Режим роботи агентів — це не про «розумніше чи простіше», а про те, де ви готові платити складністю: на вході, в рантаймі чи у відлагодженні.
Один і той самий сценарій збирається п'ятьма способами, і вибір визначається ціною помилки, довжиною ланцюжка кроків і тим, наскільки передбачуваний порядок дій.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Єдиний агент | Короткі сценарії з 2–4 інструментами, діалог із користувачем, перевірка гіпотези | Порядок викликів не контролюється; на довгому ланцюжку втрачається контекст, збій важко локалізувати |
| Жорсткий граф кроків | Регламентні процеси з фіксованим порядком: приймання заявки, звірка документа, маршрутизація | Відхилення від сценарію потребує правки графа; погано переносить розгалуження і неповні дані |
| Керуючий шар із планувальником задач | Задачі зі змінним набором кроків: збір даних із кількох джерел, аналіз, зведення | Планувальник потрібно обмежувати за кількістю кроків і глибиною, інакше з'являються цикли і зростає час відповіді |
| Подієва схема з чергами і повторними спробами | Довгі та зовнішні операції, інтеграції, де відмова вузла — штатна ситуація | Складніше трасування і відлагодження; потрібен контроль дублів та ідемпотентності обробників |
| Гібрид: граф плюс планувальник на окремих вузлах | Продуктивні процеси, де критичні кроки регламентні, а варіативна частина залежить від даних | Потребує явної схеми станів і правил ескалації, дорожчий у проектуванні та супроводі |
На практиці робочі системи найчастіше сходяться до гібриду: жорсткий граф тримає критичні кроки і точки погодження з людиною, планувальник закриває варіативну частину, а черги і повторні спроби відповідають за доставку результату при збоях зовнішніх сервісів.
Така схема допускає поетапний перехід — вузли графа викликають ті самі інструменти, що й автономний агент, тому режим змінюється без переписування логіки з нуля.
Етапи впровадження: від аудиту процесів до передачі
Оркестратор — це не один агент, а контур із кількох ролей, інструментів і правил, за якими вони обмінюються результатами. Тому робота йде етапами: спочатку фіксуємо процеси, потім будуємо схему, потім перевіряємо її на відмовах.
- Аудит процесів — розбираємо, які операції повторюються, де рішення приймається за правилами, а де потрібна модель. На виході карта сценаріїв, список джерел даних і точки, де людина обов'язково підтверджує дію.
- Проектування схеми контуру — визначаємо склад агентів, їхні ролі, порядок передачі задачі, місце зберігання стану і межі повноважень. Тут же описуємо правила обміну: формат повідомлень, граничний час очікування відповіді, повтори при збої.
- Налаштування і збирання — підключаємо джерела та інструменти, налаштовуємо маршрутизацію задач, ліміти, журналювання і трасування, щоб кожен крок агента можна було відновити.
- Тестові сценарії відмов — перевіряємо поведінку при недоступному джерелі, порожній відповіді, конфлікті двох агентів. Контур не повинен іти в цикл або виконувати одну дію двічі.
- Пробний запуск на одному сценарії — виводимо процес на обмежену групу, звіряємо результат із ручним виконанням і правимо правила обміну за фактом.
- Передача і навчання команди — віддаємо схеми, регламенти, доступи і журнали, проводимо навчання і залишаємося на супроводі, поки команда не почне змінювати сценарії сама.
Після цього нові ролі та гілки логіки додаються силами замовника — без повторного заходу з нашого боку.
Регламенти, схеми і конфігурації: що залишається у вас
Розробка оркестратора AI-агентів закінчується не демонстрацією працюючого сценарію, а передачею комплекту, за яким ваша команда зможе супроводжувати рішення без нас.
Ми віддаємо не архіви і скриншоти, а робочі артефакти: те, що лежить у репозиторії, те, що застосовується на контурі, і те, що описує поведінку системи при збої.
- Конфігурації оркестратора: описи маршрутів між агентами, правила вибору виконавця, ліміти паралельних запусків, таймаути й умови повторних спроб — у версійному контролі, а не лише в БД на сервері.
- Схема контуру: що розгортається на вашому боці, де зберігаються стани і журнали, які зовнішні сервіси задіяні і що станеться при недоступності кожного з них.
- Політики доступу: ролі операторів і сервісів, до яких даних та інструментів агент має право звертатися, де зберігаються ключі і як вони ротуються.
- Описи сценаріїв: які задачі переходять агенту автоматично, де обов'язкова людина, що вважається успішним завершенням і які результати неприпустимі.
- Регламент розбору інцидентів: де дивитися журнал прогону конкретної задачі, як відкотити проблемний сценарій і хто приймає рішення про зупинку.
- Порядок змін: як правляться інструкції та маршрути, які перевірки проходять до викатки, як готується і перевіряється відкат на попередню версію.
- Документація супроводу: інструкції з локального запуску та відлагодження, опис точок розширення і журнал прийнятих рішень з обґрунтуванням.
Обсяг комплекту залежить від кількості сценаріїв та інтеграцій — обговоримо задачу, і ми повернемося з оцінкою та планом передачі.
Кейс: як керований контур прибрав ручні кроки
До впровадження потік клієнтських звернень тримався на операторі: він вручну розбирав заявку, визначав тип, підтягував дані з облікової системи і вирішував, якому фахівцю передати.
Типовий сценарій займав 18–20 хвилин, на піку зміни черга зростала швидше, ніж її розбирали, а частина звернень ішла з помилкою в категорії — їх повертали на повторний прохід.
Ми почали не з моделі, а з карти процесу: виписали кроки, де рішення приймає людина, і відокремили ті, де вибору немає — лише звірка за правилом. Таких виявилося більшість.
Контур зібрали з трьох ролей: агент-класифікатор, агент-виконавець і шар перевірки, який пропускає результат далі лише після валідації за схемою. Оркестрація побудована на LangGraph: стан задачі зберігається явно, тому зірваний крок переграється з точки збою, а не з початку.
Що саме змінили
Головне — не автономність агентів, а межі. У кожного обмежений список дозволених дій, ліміт кроків і обов'язкова точка ескалації на оператора при низькій впевненості моделі.
Звернення, де контур сумнівається, переходять до людини з уже зібраним контекстом: оператор не шукає дані заново, а підтверджує рішення.
Після запуску час обробки скоротився з 18–20 до 4–6 хвилин. Частка звернень, закритих без ручного втручання, вийшла на 78%; решта 22% — не відмови, а усвідомлена ескалація там, де ціна помилки вища за швидкість.
Збої, які раніше призводили до повторного розбору — втрата контексту між кроками, неправильна категорія, дубль запису в обліковій системі, — на тисячу операцій упали з 34 до 3.
Цей клас відмов закрито архітектурно: правила перевірки живуть у самому контурі, а не в інструкції для оператора.
Чим оркестратор відрізняється від набору скриптів і черг?
Окремий скрипт вирішує одну задачу: запустився за подією або розкладом, відпрацював, записав результат. Поки кроків три і збій видно очима, цього достатньо.
Але щойно задача потребує розгалуження, зовнішніх сервісів і підтвердження від людини, скрипт розвалюється: ніхто не зберігає, на якому кроці все стало і що вже встигло змінитися.
| Варіант | Що вміє | Де ламається |
|---|---|---|
| Набір окремих скриптів | Лінійний запуск за подією або розкладом | Немає спільного стану задачі: після збою незрозуміло, що зроблено, а що ні |
| Черга задач з обробниками | Розподіляє навантаження, повторює завдання, що впали | Обробник не бачить контексту всієї задачі; порядок кроків тримається на домовленостях між командами |
| Керуючий шар | Планує кроки, зберігає стан задачі, переграє збійні ділянки | Потребує дисципліни: опис кроків, ідемпотентність, спостережуваність |
Керуючий шар відрізняється тим, що тримає стан задачі цілком: який крок виконано, які дані отримано, чого чекаємо від зовнішньої системи. Планування кроків стає даними, а не порядком викликів у коді, — маршрут можна змінити, не переписуючи логіку обробки.
Повторні спроби також перестають бути загальним налаштуванням черги. Оркестратор знає, що списання повторювати не можна, а запит до зовнішнього сервісу — можна, з наростаючою паузою і лімітом спроб.
Збійна ділянка переграється разом із уже накопиченим контекстом, а не з нуля: довгий ланцюжок із десяти кроків не починається заново через одну мережеву відмову.
Ціна такого контуру — власна спостережуваність. Потрібен журнал переходів, ручний розбір застряглих задач і обмеження на паралельні запуски, інакше керуючий шар сам стає джерелом тихих зависань.
Технічні питання: надійність, доступи, контроль
Сумніви щодо оркестратора стосуються не моделі, а поведінки на межах: відмова зовнішньої системи, межі прав агента, збій раз на сотню запусків. Розбираємо те, що найчастіше запитують до старту.
Що станеться, якщо зовнішня система не відповідає?
Зовнішній виклик — окремий крок зі своїм таймаутом і політикою повторних спроб. Якщо система не відповідає, сценарій іде у гілку компенсації або стає на паузу, а не віддає користувачу частковий результат. Кожна спроба з кодом відповіді потрапляє в журнал — видно, на якому кроці обірвався ланцюжок.
Як обмежуються доступи агентів до даних?
Агент отримує не доступ до бази, а набір дозволених дій з обмеженим набором полів. Права видаються під конкретну роль і живуть на час виконання задачі, а запис і видалення виносяться в окремі підтверджувані кроки.
Як відлагоджувати сценарій, який падає не завжди?
Запуски трасуються: слід на OpenTelemetry зв'язує кроки, входи і відповіді інструментів. Нестабільний сценарій відтворюється на збереженому наборі вхідних даних, а спірні випадки стають регресійними перевірками перед викладкою змін.
Чи вбудується це в наші наявні кроки і які є ліміти?
Готові кроки підключаються як окремі інструменти: переписувати їх не потрібно, достатньо описати входи, виходи й умови помилки.
Ліміти звернень задаються на рівні сценарію і зовнішньої системи — черга й обмеження паралельних задач не дають одному сценарію вичерпати загальну квоту.
Ці питання розбираємо на етапі проектування — інакше перша серйозна відмова зовнішньої системи стає першим тестом на стійкість.Обговоримо задачу і повернемося з оцінкою та планом
Щоб оцінка спиралася на факти, а не на припущення, для старту вистачить того, що вже є у вашій інфраструктурі: перелік сценаріїв, які має закривати оркестратор, список систем, до яких звертаються агенти, й обмеження щодо доступів і даних.
Якщо збереглися приклади запитів, де логіка розвалилася, вони заощадять години уточнювальних розмов.
За підсумком обговорення повертаємося не з описом «на словах», а з інженерним планом впровадження:
- склад робіт за етапами — від схеми маршрутизації запитів між агентами до обв'язки навколо викликів зовнішніх систем;
- схему контуру: де запускаються агенти, як зберігається стан діалогу і чим обмежений доступ до чутливих даних;
- контрольні точки і терміни етапів із критеріями приймання на кожному: який набір сценаріїв має проходити без ручного втручання;
- перелік ризиків з оцінкою: деградація якості при зростанні навантаження, конфлікти паралельних викликів, неповні відповіді зовнішніх сервісів;
- вимоги до вашого боку — доступи до систем, тестові дані, відповідальний за приймання і той, хто підтверджує бізнес-правила.
Пропонуємо обговорити задачу предметно: розберемо її на частини, відзначимо неясні місця і надішлемо план впровадження зі складом робіт, термінами і зонами відповідальності. Опишіть задачу у зручній формі — повернемося з оцінкою та планом.
