Чому лінійні ланцюжки викликів ламаються, а LangGraph — ні
Лінійний ланцюжок викликів виглядає надійно, поки сценарій короткий: крок, ще крок, відповідь.
Як тільки з'являється розгалуження — «якщо даних не вистачає, уточни в користувача» — код перетворюється на дерево умов, а стан агента розмазується по локальних змінних і проміжних словниках.
Додайте цикл на кшталт «перепитати й дочекатися підтвердження», і відстеження того, на якому кроці ми перебуваємо, стає окремим завданням.
Найгірше поводиться збій посеред сценарію. Процес упав на п'ятому кроці з десяти — і повторний запуск кроку заново виконує те, що вже пройшло: лист іде вдруге, картка в CRM створюється дублем, зовнішній лічильник збільшується повторно. Точки повернення немає, тому відновлення зводиться до повного прогону з нуля.
LangGraph змінює модель виконання: сценарій описується як граф вузлів і переходів, а стан агента стає явною структурою, яку кожен вузол читає й дописує.
Стан фіксується після кожного переходу — після збою сценарій продовжується з останнього успішного вузла, а розгалуження й цикли виражаються звичайними ребрами графа, а не вкладеними умовами.
Далі розбираємо, як це закривається на практиці: де живе стан, як влаштовані точки збереження і як виглядає повторний запуск кроку після падіння.
Що дає LangGraph: вимірюваний ефект графової оркестрації
Графова оркестрація відрізняється від лінійного ланцюжка тим, що кожен крок — окремий вузол з явними входами та виходами, а стан живе поза моделлю.
Збій кроку тому не руйнує весь прогін: агент повертається до останньої збереженої контрольної точки й повторює лише вузол, що впав — відновлення займає секунди замість перезапуску сценарію з нуля.
Звідси перший вимірюваний ефект — частка сценаріїв, доведених до кінця. Там, де одиночний виклик моделі обривався на недоступному сервісі або неповній відповіді, граф доходить до фінального кроку в 90+% випадків: невдалий вузол повторюється, а вже зібрані дані не втрачаються. Резервна гілка описується тим самим способом, що й основна.
Другий ефект — повторне використання гілки.
Нова логіка (перевірка вхідних даних, передача оператору, інше джерело відомостей) додається як вузол і зв'язок, а не як правка всього сценарію: типове розширення закривається за один-два дні інженерної роботи замість переписування половини логіки й повторного налагодження.
Третій — спостережуваність агента, яка знімає головний біль підтримки: «відповідь невірна, незрозуміло де». Кожен перехід між вузлами протоколюється, видно, на якому кроці загубився контекст, скільки зайняв виклик і де спрацював резервний шлях. Інцидент розбирається за журналом прогону, а не відтворенням наосліп.
Технічно це дає LangGraph — контрольні точки стану, повтор кроку й розгалуження вбудовані, не потрібно добудовувати їх навколо викликів моделі.
Режими виконання графа: порівняння підходів
Режим виконання визначає, де ухвалюється рішення про наступний крок — усередині одного виклику моделі, у жорсткому сценарії або у вузлі графа. Від цього залежить відтворюваність відповіді та те, наскільки швидко локалізується збій. Нижче — чотири варіанти, між якими обирають на старті.
| Варіант оркестрації | Коли підходить | Що обмежує |
|---|---|---|
| Один великий виклик моделі | Короткий сценарій без розгалужень: розібрати запит і повернути структуровану відповідь | Немає проміжного контролю — помилку в середині міркування видно лише у фіналі |
| Жорсткий ланцюжок кроків | Регламент відомий заздалегідь і змінюється рідко | Відхилення від сценарію ламає весь ланцюжок, розгалуження доводиться писати умовами в коді |
| Граф із спільним станом | Багатотурові завдання: збір даних, перевірка, повернення на крок назад | Потрібна дисципліна в описі стану, інакше граф читається гірше за лінійний сценарій |
| Зовнішній диспетчер завдань | Довгі процеси та паралельні гілки, що переживають перезапуск | Додається шар інфраструктури, який треба супроводжувати й синхронізувати з логікою |
Ключова відмінність графа — стан живе між кроками: вузол отримує накопичений контекст, а не лише останнє повідомлення. Це дозволяє повернути завдання на попередній крок, якщо перевірка не пройшла, і не переказувати моделі всю історію заново. Так влаштований LangGraph: маршрутизація між вузлами описана явно, а не виводиться моделлю на ходу.
Чисті варіанти трапляються рідше за гібрид: диспетчер тримає чергу й повторні запуски, а рішення про наступний крок ухвалює граф. Схему фіксуємо до розробки — відразу видно, де закінчується логіка агента й починається інфраструктура.
Етапи впровадження LangGraph у працюючий сервіс
Впровадження графа не означає переписування сервісу: ми розширюємо наявну логіку, залишаючи робочі маршрути як резервні. Кожен етап закінчується артефактом, який можна перевірити до переходу до наступного.
- Розбір поточних сценаріїв. Фіксуємо, де сервіс уже ухвалює рішення: розгалуження, звернення до зовнішніх систем, місця, де обов'язкова людина. На виході — карта процесів з явними входами, виходами та точками відмови.
- Схема графа. Визначаємо вузли, переходи, умови зупинки та стан, який переноситься між кроками. Схему узгоджуємо до коду — на ній відразу видно цикли, глухі кути та сценарії, де агент може зациклитися.
- Перенесення логіки. Наявні перевірки, ліміти та виклики сервісів стають вузлами графа; правила валідації зберігаються. Старий маршрут залишається робочим, щоб перемикання було оборотним.
- Перевірка агента на реальних даних. Проганяємо історичні звернення з відомим результатом і рахуємо частку вірних рішень. Розбіжності розбираємо по кроках: видно, який саме вузол або перехід дав помилку.
- Прогін під навантаженням. Дивимося поведінку на потоці, близькому до бойового: час відповіді, повтори, витрати на дорогі виклики. Тут же налаштовуємо обмежувачі та правила відкату до попередньої логіки.
- Передача в експлуатацію. Віддаємо схему графа, конфігурацію, журнали прогонів та інструкцію з правки вузлів. Окремо описуємо, що видно в моніторингу і за якими ознаками команда розуміє, що агент відхилився від очікуваної поведінки.
Такий порядок дає передбачуваний перехід: спочатку логіка, потім перевірка на реальних даних, і лише згодом навантаження та експлуатація.
Що передаємо на руки: графи, політики, документація
Проєкт вважається зданим не тоді, коли агент відповідає на підготовленому прикладі, а коли ваша команда може сама змінити поведінку окремого кроку, не розбираючи код заново. Тому в передачу входить комплект артефактів: від карти графа до регламенту випуску. Нижче — що саме залишається у замовника після інтеграції LangGraph.
- Опис графа та карта станів — схема вузлів, переходів і умов розгалуження, з позначками, які дані накопичуються по ходу виконання і на якому кроці агент зупиняється.
- Контракти вузлів — формати входу та виходу кожного кроку, обов'язкові поля, поведінка при порожній або некоректній відповіді моделі, таймаути й число повторів.
- Правила доступу до зовнішніх систем — які облікові записи потрібні, де зберігаються ключі та як вони оновлюються, що агент лише читає, а куди йому дозволено писати.
- Регламент випуску змін — як правка логіки вузла або інструкції для моделі проходить перевірку на наборі сценаріїв і потрапляє в робочу версію.
- Моніторинг і розбір інцидентів — які події фіксуються, як відрізнити збій зовнішнього сервісу від помилки маршрутизації та як повернути граф до попередньої версії.
- Документація агента для підтримки — інструкції простою мовою: що робити при типовому збої, куди дивитися в першу чергу, де межі відповідальності команди.
- Набір перевірочних сценаріїв — завдання з очікуваним результатом, за якими проганяють збірку після кожної правки.
Кейс: агент обробки заявок перестав падати
У замовника — сервісна компанія з кількома тисячами звернень на тиждень — агент на LangGraph розбирав вхідні заявки: витягував реквізити з листа, звіряв їх з базою клієнтів, готував відповідь і передавав дані в облікову систему. Ламалася не якість відповідей, а стійкість сценарію.
Відмова кроку агента — недоступний зовнішній сервіс, обрив з'єднання, несподіваний формат поля — валила весь прогін. Заявка зависала в невизначеному стані, оператор розбирав її руками, а відновлення сценарію після відмови займало години. Частка заявок, доведених до кінця без втручання, трималася близько 60%.
Ми перевели обробку в явний граф станів: у кожного кроку з'явилася точка збереження, обмежене число повторів і ознака невідновної відмови.
Помилка вузла більше не відкочує весь прогін — агент повертається до останнього збереженого стану й продовжує з того ж місця або передає заявку оператору разом із уже зібраним контекстом.
Метрики до та після
| Метрика | До | Після |
|---|---|---|
| Заявки, доведені до кінця без оператора | ~60% | 94% |
| Повернення сценарію після відмови кроку | вручну, години | автоматично, секунди |
| Ручні доопрацювання логіки обробки | щотижня | раз на квартал |
Побічний ефект виявився не менш важливим: коли частина відмов закривається повтором, а частина — коректною передачею оператору з контекстом, інженери правлять причину, а не наслідок.
Обсяг ручних доопрацювань логіки падає з тієї ж причини — нові гілки додаються в граф, не ламаючи вже працюючі.
LangGraph чи власний оркестратор на функціях?
Коротка відповідь: поки сценарій лінійний, власний оркестратор зі звичайних функцій дешевший і в розробці, і в підтримці. Графова бібліотека на кшталт LangGraph окупається там, де з'являються розгалуження, цикли та відновлення виконання з середини.
Саморобний диспетчер — це ланцюжок викликів, де стан лежить в одному словнику й передається від кроку до кроку. Два-чотири кроки, один зовнішній сервіс, проста обробка помилок: такий код читається цілком і не вимагає, щоб команда знала чужу модель виконання. Вартість підтримки тут близька до нуля — правка порядку кроків не ламає нічого навколо.
Програвати саморобне починає, коли з'являються розвилки за результатом кроку, паралельні гілки, цикл уточнення та пауза до відповіді користувача.
Тоді доводиться самим реалізовувати обхід, зберігати контрольні точки стану, повторювати кроки, що впали, без дублів і обмежувати число ітерацій. Це вже невеликий рушій — з його тестами, налагодженням і документацією для нових розробників.
Критерій вибору простий: якщо схема вміщається на один аркуш, станів небагато й повернень назад немає — беріть функції. Якщо є цикли, розвилки, довгі завдання з очікуванням зовнішньої події або участю оператора — граф дає стійкість, яку інакше пишуть руками.
Вартість підтримки розходиться на горизонті: саморобне дешевше на старті й дорожче з кожною новою вимогою, графова схема — навпаки. Перехід при цьому не переписує логіку: вузли залишаються звичайними функціями, змінюється лише шар маршрутизації між ними.
Технічні сумніви перед стартом інтеграції
Інженерів, які поведуть інтеграцію, рідко цікавить загальна вигода — вони запитують, що станеться з уже працюючим агентом. Нижче п'ять питань, які звучать до старту перенесення на LangGraph, і наші відповіді на них — щоб обсяг робіт був зрозумілим заздалегідь.
Чи доведеться переписувати логіку поточного агента?
Ні. Виклики моделі, звернення до бази та зовнішніх сервісів залишаються попередніми — змінюється зв'язок між кроками: замість жорсткого ланцюжка з'являються вузли та явні переходи.
Що відбувається зі станом при переході між кроками?
Стан — спільний об'єкт, який кожен крок отримує та доповнює. У будь-який момент видно, що агент знав і на що спирався в момент рішення.
Чи можна продовжити перерваний запуск, а не починати заново?
Так. Контрольні точки зберігаються після кожного вузла, тому повторні запуски не проходять знову виконані кроки й не дублюють звернення до зовнішніх сервісів.
Як додати нову гілку, не ламаючи живу систему?
Новий вузол ставиться поруч зі старими, попередній маршрут залишається робочим. Гілка вмикається флагом на частині запитів, відкат — перемиканням назад.
Як розібрати, чому агент ухвалив саме це рішення?
Покроковий журнал: який вузол викликано, що увійшло в стан і що вийшло. Розбіжність видно на конкретному кроці, а не в загальному лозі — розбір перестає бути вгадуванням.
Якщо сумнів залишився за конкретним пунктом — розберемо його на схемі вашого агента.Обговоримо завдання: як почати інтеграцію графа
Щоб повернутися з оцінкою та планом, а не із загальними міркуваннями, потрібні вихідні дані за вашим сценарієм. Надсилати можна у вільній формі — нотатки з трекера й схема на серветці підійдуть краще, ніж вилизана документація.
- Поточний сценарій: хто і що робить зараз, де розгалуження, у який момент підключається людина.
- Обсяг: скільки запусків на добу, довжина типового діалогу або пакета документів, чи є піки навантаження.
- Обмеження: що не можна виносити за периметр, що знеособлювати, яка затримка відповіді допустима.
- Точки інтеграції: звідки граф отримує запуск і куди повертає результат — інтерфейс, база, тікетниця, CRM.
- Що вже пробували: вузли, виклики моделей, результати — що не влаштувало за якістю чи стабільністю.
- Критерій приймання: що вважаємо успіхом у числах — частка звернень, закритих без людини, ручні доопрацювання, час відповіді.
Цього достатньо, щоб розкласти сценарій на граф: визначити стан, розгалуження, контрольні точки та відкати, показати, де вузли LangGraph замінюють розрізнені виклики моделі, і як вимірювати ефект на першому етапі.
Опишіть завдання в тому вигляді, в якому воно є, — повернемося з оцінкою та планом: склад робіт, послідовність етапів, що робимо на першому кроці і в якій точці ви приймаєте результат.
