LangGraph пояснено: графи, стан, маршрутизація та шаблони для практичного застосування.
Як моделі LangGraph представляють агентів у вигляді циклічних графів із типовим станом, редукторами, контрольними точками, механізмами маршрутизації, інструментами та циклами ReAct, а також шаблонами для практичного використання.
Джерела: Mastering LangGraph: The Complete Technical Guide to Building Production-Grade Agentic AI Systems
Перша хвиля додатків на основі LLM була простою заміною: надсилається запит, отримується відповідь. Агенти — це інший тип програм. Вони міркують у кількох кроках, вирішують, що робити, ґрунтуючись на тому, що вони дізналися досі, та вживають дій у зовнішньому світі. Це вимагає інфраструктури, побудованої навколо циклів, гілок та пам’яті, а не прямої лінії від вхідних даних до результату.
LangGraph — це одна з таких платформ. Він розроблений для додатків із станом, у яких один або кілька агентів, керованих LLM, працюють разом. Замість лінійної ланцюгової структури він дозволяє описати спрямовану графіку, яка може містити цикли, умовно направляти потоки даних, зберігати постійний стан та координувати виклики інструментів. Це не просто зручності. Агенту, якому потрібно боротися з невизначеністю, відновлюватися після помилок та вдосконалювати свою роботу протягом кількох спроб, потрібні всі ці функції.
У наступному розділі розглядається те, як фреймворк працює всередині, чому важливі його архітектурні рішення та коли застосовується кожен з патернів. До кінця ви зможете впевнено приймати архітектурні рішення, виправляти дивну поведінку агентів та розширювати фреймворк відповідно до ваших потреб.
Графи як основні елементи будови
Старіші інструменти оркестрації моделюють робочий процес як пряму ланцюгову структуру або, у кращому випадку, як орієнтований ациклічний граф. Це підходить для передбачуваних завдань, але не ефективно, коли агенту потрібно повторювати дії, робити резервні копії чи миттєво обирати інший шлях. LangGraph виходить з протилежної припущення та використовує орієнтований граф із циклами як свою основну примітивну структуру.
Чому ланцюг недостатній
Різниця між ланцюгами та графами є практичною, а не формальною. Ланцюг передбачає, що ви знаєте точний порядок виконання операцій під час написання коду. Граф допускає, що шлях у системі залежить від стану під час виконання, проміжних результатів та умов, які ніхто не може передбачити.
Уявіть агента, який досліджує компанію. Він починає з фінансових даних. Чи буде він потім збирати новини, отримувати звіти аналітиків чи читати документи конкурентів, залежить від того, що розкрили фінансові дані. Така умовна, повторювана поведінка потребує як циклів, так і гілок, а ланцюг не може виразити жодного з цих елементів.
Звичайний патерн агента — це цикл: розглядається, що потрібно зробити, виконується дія, спостерігається результат, і цей процес повторюється до досягнення мети. З інструментом, заснованим на ланцюгах, у вас є два погані варіанти: ви можете розгорнути цикл у фіксовану кількість кроків, що позбавляє систему гнучкості, або ж написати логіку керування самостійно поза фреймворком, що жертвує можливістю комбінування елементів. У LangGraph сам цикл є ідеєю першого класу, яка виражається у вигляді циклічної графіки з умовними ребрами.
Вузли
Вузол — це окремий крок обчислень. Він отримує поточний стан, виконує певну дію та повертає оновлення. Ця дія може бути викликом LLM для прийняття рішення, викликом інструменту для взаємодії з зовнішньою системою, перетворенням даних чи певною логікою маршрутизації.
Вузли — це звичайні функції Python із певною структурою: увійде поточний стан, а вийде словник оновлень. Такий функціональний інтерфейс робить їх комбінованими та легкими для тестування. Вузол ніколи не змінює стан на місці. Він повідомляє про бажані зміни, а LangGraph об’єднує їх згідно з правилами, які ви визначили.
Вузли можуть бути настільки простими, як один виклик LLM, або настільки складними, як багатоетапна логіка. Деякі викликають цілі інші графи, що дозволяє створювати ієрархічні агенти. Інші працюють асинхронно або використовують логіку повторних спроб із експоненційним затримуванням. Фреймворк не цікавиться тим, наскільки складним є вузол всередині.
Краї
Краї визначають, куди буде передано керування далі, і існує два їхні типи з дуже різною семантикою.
- Статичні краї є детерміністичними. Коли вузол A завершує свою роботу, керування завжди переходить до вузла B. Вони поводяться як звичайні виклики функцій та підходять для послідовностей, відомих заздалегідь. Після ініціалізації дослідницького завдання, наприклад, завжди слідує збір даних.
- Умовні краї маршрутизуються динамічно на основі стану. Як тільки збір даних завершується, може знадобитися вирішити, чи є достатньо інформації для початку аналізу, чи варто спробувати знову виконати невдалі виклики API. Цей вибір не можна зробити на етапі проектування, тому функція маршрутизації робить це під час виконання програми.
Функція маршрутизації перевіряє поточний стан та повертає рядок із назвою шляху, який потрібно обрати. Фреймворк зберігає зв’язок між цими рядками та відповідними вузлами-призначеннями. Це дозволяє створювати дерева рішень, логіку повторних спроб, обробку помилок та адаптивні потоки, зберігаючи при цьому чіткість маршрутизації та можливість її тестування.
Стан як спільна пам’ять
Управління станом — це та частина дизайну LangGraph, яка робить його особливо цікавим. Об’єкт стану є спільною структурою, яка переміщується по графу. Кожен вузол читає поточний стан, а всі оновлення, які він повертає, об’єднуються перед тим, як запуститься наступний вузол. Таким чином кожен крок ґрунтується на тому, що було дізнано на попередніх кроках.
Стан ви визначаєте за допомогою словарів із типами чи моделей Pydantic, що забезпечує безпеку типів та чіткі умови взаємодії між вузлами. Схема вказує, які поля існують, які у них типи та як об’єднуються оновлення. Цей останній аспект легко проігнорувати, але він має велике значення.
Коли вузол повертає оновлення, LangGraph мусить вирішити, як поєднати його з тим, що вже є. Для рядка чи числа заміна старого значення є очевидною. Але зі списком чи словником це не так. Чи слід додати повернутий список у кінець, замінити старий чи об’єднати елемент за елементом? На це відповідають редюсери.
Редюсери
Редюсер — це функція, яка визначає, як оновлення об’єднується з існуючим станом. Редюсери перетворюють стан LangGraph зі звичайного контейнера на щось, здатне обробляти патерни накопичення даних.
За замовчуванням нове значення просто замінює старе. Це підходить для більшості полів, але не підходить для даних, які накопичуються. Уявіть список помилок, який збирає проблеми під час виконання. Ви не хочете, щоб кожен елемент стирав попередні записи — ви хочете, щоб нові помилки додавалися поруч із старими. Редюсер add_messages ґрунтується на цій ідеї, і ця схема може застосовуватися не лише до повідомлень.
Ви можете написати власний редюсер для будь-якого поля. Його вхідними даними є значення, вже наявне у стані, та нове значення, а вихідним — те, що поле має містити після цього. Для списків помилок він може об’єднувати списки; для словників — глибоко об’єднувати вкладені структури; для лічильників — додавати числа.
Редюсери підключаються за допомогою типових підказок Python Annotated, тому схема залишається декларативною:
from typing import TypedDict, Annotated
def append_lists(existing: list, new: list) -> list:
return existing + new
class AgentState(TypedDict):
query: str # Simple replacement
results: Annotated[list, append_lists] # Custom accumulation
iteration: int # Simple replacement
Це робить поведінку об’єднання чіткою та централізованою, замість того щоб вона була розкидана по окремих вузлах.
Створення контрольних точок
Агенти у продакшні часто працюють протягом тривалого часу, здійснюють дорогі виклики API або обробляють операції, які не повинні бути втрачені через тимчасові збої. Створення контрольних точок — це механізм, який це забезпечує. Коли він увімкнений, LangGraph зберігає повний стан після завершення кожного вузла. Якщо процес зупиняється або у нього закінчується пам’ять, виконання може бути продовжене з останньої контрольної точки, замість того щоб починатися знову. Крихкий послідовний скрипт стає робочим процесом, який можна продовжувати.
Контрольні точки також уможливлюють роботу з участю людини. Виконання може бути призупинено у вибраній точці, щоб людина могла її переглянути або надати інформацію, а потім продовжитися після її відповіді. Оскільки контрольна точка фіксує точний стан на момент призупинення, не має значення, скільки днів мине між цими моментами.
Сховище, яке знаходиться за ним, є підключуваним. Використання контрольних точок у пам’яті підходить для розробки, SQLite забезпечує локальну стабільність даних, а Redis підходить для розподілених систем. Граф залишається незмінним, а змінюється лише реалізація контрольних точок.
Типові запитання, пов’язані з маршрутизацією, включають наявність достатньо даних для продовження роботи, успішність операції чи необхідність її повторної спроби, досягнення межі кількості спроб та наскільки висока достовірність аналізу для прийняття рішення. Функція може бачити весь стан, тому вона може порівнювати кілька полів, виконувати обчислення, звертатися до зовнішніх умов чи кодувати бізнес-правила. Єдиною вимогою є те, щоб вона була детермінованою та чистою, тобто завжди надавала однакову відповідь для однакового стану.
Уникнення нескінченних циклів
Цикли дозволяють ефективну ітерацію, але водночас створюють ризик нескінченних ланцюгів. Агент, який постійно намагається виконати операцію знову та знову, може безкінечно споживати ресурси, і LangGraph пропонує кілька способів цього запобігти.
Найпростішим варіантом є лічильник у стані. Функція маршрутизації порівнює його з максимальним значенням та надсилає керування до кінцевого вузла, як тільки цей ліміт перевищується. Майже кожен продакшн-агент використовує цю схему. Більш вдосконалені варіанти включають виявлення збіжності, яке зупиняється, коли зміна між ітераціями опускається нижче певного порогу, та завершення роботи за таймером, де маршрутизація враховує пройдений час.
Головний висновок полягає у тому, що запобігання циклам — це завдання маршрутизації, а не обмеження фреймворку. LangGraph надає інструменти для створення захисних механізмів, пристосованих до вашого випадку, замість того, щоб нав’язувати універсальні правила.
Інструменти: від мови до дії
Агенти стають справді корисними, коли ШІ може взаємодіяти з зовнішніми системами. Інструменти — це те, що перетворює розуміння мови на реальні дії у світі.
Шаблон виконання
У LangGraph інструмент — це вузол, який виконує певну дію поза процесом. Він може викликати API, запитувати базу даних, виконувати код чи шукати інформацію в Інтернеті. Він отримує параметри зі стану, виконує операцію та повертає результати у вигляді оновлень стану.
Ця схема стає потужною, коли поєднується з оцінкою LLM. Вузол LLM читає стан та вирішує, який інструмент викликати. Функція маршрутизації надсилає керування відповідному вузлу інструменту. Інструмент виконується та записує свій результат у стан. Керування повертається до LLM, який інтерпретує результат та обирає наступний крок. Цей процес триває до досягнення мети.
Сучасні моделі підтримують виклик функцій, тобто вони генерують структурований запит із назвою інструменту та його параметрами. Вузол LLM аналізує такий запит у відповіді моделі та записує обраний інструмент у стан. Функція маршрутизації читає цей вибір та спрямовує потік до відповідного вузла інструменту.
Керування помилками інструментів
Зовнішні системи можуть зламатися, досягти таймауту, повертати некоректні дані та порушувати припущення. Вузли інструментів мають бути готові до цього.
- Виявлення та повідомлення. Виявляйте винятки, фіксуйте їх та повертайте деталі помилки у стані, замість того щоб дозволити їм зламати агента. Тоді ШІ зможе зрозуміти, що пішло не так, та спробувати знову з іншими параметрами або обрати інший підхід.
- Таймаути. Огортайте операції так, щоб вони завершувалися після максимального часу виконання. Одна повільна API не повинна затримувати весь агент.
- Перевірка. Аналізуйте відповіді та перевіряйте їх за схемами. Некоректні дані мають спричиняти виконання шляху обробки помилок, а не зберігатися там, де вони можуть пошкодити наступні вузли.
Цикл ReAct
ReAct, скорочення від reasoning and acting, — це базова архітектура агента, яку LangGraph легко реалізує, і розгляд її демонструє, як інші концепції взаємопов’язані.
Як працює цикл
Він починається з вузла міркувань. Штучний інтелект аналізує стан справ та вирішує, що робити далі: викликати інструмент, запитати додаткову інформацію, надати остаточну відповідь чи попросити введення від людини. Саме тут важливі можливості моделі, адже вона може оцінити складний контекст та зробити витончений вибір.
Якщо система вирішує діяти, керування переходить до вузла дії, який виконує обраний операційний процес – чи то виклик API, обчислення чи запит до бази даних. Вузол дії залишається детермінованим та спрямованим, виконує запит та повертає результати.
Далі йде вузол спостереження, який додає результати до стану системи та підготовлює їх для LLM. Він може сформатувати дані, видалити небажані елементи чи обчислити додаткові показники, які полегшують інтерпретацію результатів. Потім цикл знову повертається до процесу міркувань із більш детальним станом системи. LLM бачить, що сталося, та обирає наступний крок, продовжуючи цей процес доти, доки не накопичить достатньо інформації для завершення.
Як знати, коли зупинитися
Вирішення питання про те, коли закінчити, є важливою частиною циклу, і на практиці спостерігається кілька типових підходів.
- Ціль досягнута. Найпростіший варіант: ШІ стверджує, що завдання виконано, та надає кінцеву відповідь. Функція маршрутизації це помічає та переходить до вузла завершення.
- Ліміт ітерацій. Після досягнення максимальної кількості циклів «аналізу та дії» цикл закінчується, незалежно від того, чи була досягнута мета, тож агент завжди зрештою зупиняється.
- Поріг впевненості. Якщо модель досягає достатнього рівня впевненості, наприклад 95%, вона може зупинитися раніше, замість того щоб збирати інформацію зі все меншою користю.
- Фатальні помилки. Коли критичні операції постійно зазнають невдач або агент стикається з ситуацією, з якою не може впоратися, він повинен завершити роботу зі звітом про помилку, замість того щоб безцільно продовжувати.
Кілька агентів, які працюють разом
Деякі завдання краще виконувати командою спеціалізованих агентів, ніж одним монолітичним агентом. Граф упрощує розуміння кількох моделей співпраці.
Ієрархія
У ієрархічній структурі планувальник вищого рівня розділяє роботу та делегує її спеціалізованим агентам. Він контролює загальну мету та координує дії, але не виконує детальну роботу. З точки зору реалізації деякі вузли викликають інші скомпільовані графи. Вузол планування може проаналізувати складне завдання, розкласти його на частини та запустити відповідний граф для кожної частини. Результати надходять назад до планувальника, який об’єднує їх у кінцевий результат.
Основною перевагою є розділення обов’язків. Кожного спеціаліста можна створювати, тестувати та налаштовувати окремо, а планувальнику потрібно знати лише, як їх координувати, а не як вони працюють.
Рівні
Агенти також можуть співпрацювати як рівні, кожен з них вносячи свою експертизу. Команда програмних агентів може включати окремі агенти для архітектури, реалізації, тестування та документування, які всі спілкуються через спільну шину повідомлень. Це досягається за допомогою спільного стану, який кожен агент може читати та змінювати. Функція маршрутизації вирішує, хто буде діяти далі, враховуючи поточний стан та необхідні навички. Кожен агент записує свій внесок, позначає його метаданими про те, що було вирішено, та передає керування назад, після чого маршрутизатор обирає наступного відповідного агента.
Співпраця між рівними учасниками забезпечує різноманітність поглядів та дозволяє агентам виявляти помилки один у одного, коли хтось помічає недолік у міркуваннях іншого.
Дискусії та консенсус
Для важливих рішень кілька агентів можуть незалежно вирішувати проблему, а потім домовлятися щодо рішення. Цей підхід запозичує ідеї конституційного ШІ та розглядає розбіжності як сигнал якості. Три агенти аналізують ситуацію, і кожен пропонує рішення. Модератор по черзі керує дебатами, під час яких кожен агент представляє свої аргументи та критикує інших, а також мусить відповісти на конкретну критику. Після кількох раундів етап консенсусу об’єднує обговорення в рішення, можливо, надаючи більший вагомість найбільш переконливим аргументам.
Цей підхід виявляє галюцинації та помилки міркувань, які могли б залишитися непоміченими у одного агента, але стають очевидними, коли кілька агентів розглядають проблему з різних точок зору.
Отримання інформації всередині агентів
Метод генерації з підтримкою отримання інформації надає агентам доступ до великих баз знань та матеріалів у певній галузі, а графи роблять його природним рішенням для цього.
Отримання інформації за запитом
У класичному RAG інформація завантажується один раз на початку виконання завдання. У агентному RAG процес отримання інформації стає інструментом, який агент використовує щоразу, коли помічає прогалину. Агент починає міркувати, спираючись на свої базові знання. Коли він стикається з питанням, на яке не може відповісти, або йому потрібен додатковий контекст, він формує запит на отримання інформації, використовує цей інструмент та продовжує роботу з новими даними.
Цей підхід кращий за попереднє завантаження інформації з двох причин. Він дешевший, оскільки агент завантажує лише те, що йому потрібно. Крім того, він точніший, адже запити формуються на основі того, що агент наразі розуміє.
Запити, що керуються станом
Справжня користь проявляється тоді, коли запити відображають усю зібрану до цього інформацію, а не лише початкове запитання. Візьмемо розслідування щодо компанії. Воно може розпочатися з загального огляду. У результаті згадується нещодавнє придбання, що спонукає до цілеспрямованого запиту щодо цієї угоди. Це виявляє проблеми, пов’язані з регулюванням, що, у свою чергу, призводить до запиту щодо відповідних правил. Кожен пошук ґрунтується на попередньому, тож отримується цілеспрямоване розслідування замість хаотичного накопичення інформації.
Кілька джерел
Агенти часто користуються джерелами з різною затримкою, вартістю та надійністю: внутрішніми документами, зовнішніми API, пошуком в Інтернеті, спеціалізованими базами даних. LangGraph підтримує стратегії багатоджерельного пошуку. Агент може спочатку перевірити швидку локальну кеш-базу, потім звернутися до API та використати дорогий пошук в Інтернеті лише як останній засіб. Або ж він може одночасно запитувати кілька джерел та просити ШІ узгодити відповіді, які можуть суперечити одна одній.
Логіка маршрутизації може вибирати джерело інформації залежно від типу запиту. Для фактичних запитів використовується структурована база даних, для концептуальних запитів — векторний пошук у документах, для останніх подій — пошук у Інтернеті, а для історичних запитів — ретельно підібрана база знань.
Підготовка до експлуатації
Агента для демонстрації концепції легко створити за допомогою LangGraph. У режимі експлуатації виникають додаткові вимоги щодо надійності, спостережуваності та управління.
Обробка помилок на кожному рівні
Агенти виробництва керують несправностями на кількох рівнях. Вузли інструментів фіксують очікувані помилки та повертають їх у вигляді оновлень стану, а не винятків. Функції маршрутизації перевіряють умови помилок та налаштовують шляхи повторної спроби з експоненційним затримуванням. У графі є спеціалізовані вузли обробки помилок, які аналізують накопичені помилки та вирішують, чи слід повторити спробу, перейти на альтернативний варіант чи граційно завершити роботу. Для критичних операцій пристрій типу „циркуїт-брейкер“ може призупинити спроби після повторних несправностей, запобігаючи каскадним ефектам та зменшуючи додаткове навантаження на несправний сервіс.
Перегляд того, що сталося
Коли щось йде не так, вам потрібно знати, що зробив агент та чому. LangGraph інтегрується з такими платформами, як LangSmith, щоб надавати детальну інформацію про виконання кожного вузла, зміну стану та виклики LLM. Вузли повинні генерувати структуровані журнали з достатньою кількістю контексту для пояснення своїх рішень. Час виконання дозволяє виявити вузькі місця, підрахунок токенів допомагає оцінити витрати, а відстеження взаємодії з користувачем сприяє оцінці ефективності. Особливо зручно відтворювати процес з точок контролю — ви завантажуєте саме той стан, у якому виникла помилка, та поступово виявляєте первинну причину.
Зниження витрат
У більшості агентів основною статтею витрат є виклики LLM, проте кілька прийомів дозволяють їх зменшити без погіршення якості.
- Вибір моделі. Використовуйте потужну модель, таку як GPT-4, лише для складних завдань на міркування. Прості завдання на класифікацію чи вилучення інформації краще передавати швидшим та дешевшим моделям, використовуючи логіку маршрутизації, яка аналізує завдання.
- Кешування відповідей. Зберігайте результати для ідентичних або семантично схожих вхідних даних. Якщо аналіз повторюється, кешування усуває зайві виклики, і ембеддинги можуть відповідати запитам, сформульованим по-різному, але означають одне й те саме.
- Оптимізація запитів. Короткі запити, які містять лише необхідну інформацію, економлять токени. Шаблони з підстановкою змінних забезпечують їхню послідовність.
- Раннє завершення. Зупиніться, коли агент отримає достатньо інформації, замість того щоб використати весь встановлений ліміт ітерацій.
Керівні принципи проектування
Впровадження агентів LangGraph демонструє, які закономірності відрізняють надійні системи від крихких прототипів.
Схема стану
Схема є основою. Використовуйте моделі Pydantic замість вільних словників, щоб перевірка дозволяла виявляти помилки на ранніх етапах, а також документуйте значення та призначення кожного поля. Додаткові поля дозволяють різним вузлам поступово додавати свої дані, тоді як обов’язкові поля гарантують наявність критично важливих даних. Спеціалізовані союзи дозволяють керувати станом, який може мати різну форму залежно від обраного шляху. Уникайте глибокого вкладення елементів, що ускладнює доступ до полів. Уможливо спрощуйте структуру, використовуйте назви, які відображають взаємозв’язки, та тримайте метадані окремо від даних домену, щоб інформація про керування залишалася окремою.
Межі вузлів
Хороші вузли добре виконують одну функцію. Це робить їх придатними для повторного використання в різних графах, а також полегшує їх тестування та підтримку. Вузли-інструменти повинні взаємодіяти лише з зовнішніми системами, а не містити бізнес-логіку. Вузли-трансформації здійснюють перетворення без прийняття рішень. Вузли-рішення направляють потік даних без виконання операцій. Уникайте прихованих побічних ефектів: вузли мають бути максимально „чистими“, прямо повертаючи кожну зміну стану, замість того щоб змінювати глобальні змінні.
Форма графа
Структура має відображати спосіб міркувань агента. Почніть з етапу налаштування, який перевіряє вхідні дані та підготовлює контекст. Потім збирайте дані, можливо, паралельно. Додайте вузли аналізу, потім вузли синтезу, які генерують результат, та вузли завершення, які очищують інформацію. Розмістіть умовні ребра у справжніх точках прийняття рішень, де наступний крок залежить від отриманих даних, а також використовуйте статичні ребра, коли процес є детермінованим. Зберігайте кожну графіку на одному рівні абстракції. Якщо частина графіки реалізує складну підпроцедуру, перенесіть її у власну графіку та використайте її як вузол.
Тестування
Графи можна тестувати на кількох рівнях. Тестируйте вузли шляхом передачі штучного стану та перевірки оновлень. Тестируйте функції маршрутизації, подаючи різні стани та перевіряючи повернутий шлях. Проводьте інтеграційні тести для всіх графів із відомими вхідними даними та перевіряйте кінцевий стан. Використовуйте штучні відповіді ШІ, щоб тести були швидкими та детермінованими, а також записані реальні відповіді для більш реалістичних умов тестування. Тестування на основі властивостей дозволяє перевіряти поведінку в широкому діапазоні вхідних даних. Ретельно тестуйте критичні шляхи, особливо шляхи з помилками, адже їх важко викликати в реальних умовах, проте вони є надзвичайно важливими, коли все ж таки трапляються.
Вирішення питання про необхідність
LangGraph є потужним інструментом, але не кожен проект з використанням ШІ потребує його.
Це підходить тоді, коли агент мусить міркувати ітеративно, збираючи та аналізуючи інформацію та вирішуючи, чи продовжувати пошук. Це також підходить, коли потік керування залежить від стану під час виконання, як у випадку повторних спроб, відновлення від помилок чи адаптивних робочих процесів, коли кілька інструментів чи систем мають складні залежності, коли стан має зберігатися між кроками чи сеансами, коли виконання мусить призупинятися та продовжуватися заради людей, або коли кілька агентів співпрацюють чи утворюють ієрархію.
Достатньо чогось простішого, коли завдання полягає у звичайному запиті та відповіді без циклів чи гілок, потік є лінійним та відомим заздалегідь, робота може бути ланцюгом детермінованих кроків, ніщо не потребує зберігання після однієї роботи, або додаток використовує щонайбільше один чи два прості API. У таких випадках ланцюги LangChain чи прямі виклики API дають більш зрозумілий та легший у обслуговуванні код, ніж спроба представити проблему у вигляді графа.
Розвиток ідеї
Багато додатків починаються просто та стають складнішими. Це є нормальним для проектів зі звуковим дизайном. Почніть з ланцюга, але зберігайте запити, інструменти та бізнес-логіку у вигляді модулів із слабкою взаємозв’язаністю, щоб згодом було легко перетворити їх на граф. Як тільки ланцюг досягне п’яти–семи кроків або ви додасте другу умовну гілку, розгляньте можливість міграції, перш ніж складність вийде з-під контролю.
Продвинуті техніки
Окрім основ, кілька технік відкривають додаткові можливості.
Паралельна обробка. Вузли, які не залежать від результатів роботи один одного, можуть працювати одночасно. Наприклад, вузли збору даних, які використовують різні API, скорочують загальний час виконання, якщо працюють паралельно, а фреймворк збирає та об’єднує результати. Для цього потрібні явні паралельні зв’язки, і необхідно переконатися, що вузли справді незалежні, без прихованого зв’язку через спільні ресурси чи глобальний стан.
Стрімінг. Для довготривалих агентів відображення проміжних результатів покращує користувацький досвід. Вузли можуть надсилати часткові оновлення стану, які спостерігачі бачать миттєво. Це підходить для створення звітів, де абзаци можуть з’являтися у міру їх написання, а також для пошуку, де результати відображаються у міру їх знаходження.
Підграфи. Складні агенти отримують перевагу від ієрархічного розкладання. Підграфи створюються окремо та використовуються як вузли в батьківському графі, отримуючи підмножину стану батьківського графа та повертаючи оновлення, які знову об’єднуються. Різні інженери можуть керувати різними підграфами, розгортати та тестувати їх незалежно, а також повторно використовувати спільні підграфи в кількох батьківських графах.
Динамічні зміни графа. Більшість графів залишаються незмінними на етапі проектування, але в деяких складних випадках граф може змінюватися під час виконання. Агент планування може створити індивідуальний граф після аналізу завдання, динамічно створюючи вузли та ребра. Це ускладнює аналіз поведінки, тому такий підхід слід використовувати обережно. Він дозволяє мета-агентам проектувати та запускати індивідуальні робочі процеси для нових типів завдань.
Заключні міркування
LangGraph відображає зрілий набір інструментів для агентних систем. Його сила полягає не у складності, а у тому, наскільки примітиви точно відповідають способу поведінки агентів: вони міркують, діють та спостерігають у циклах, приймають рішення на основі накопичених знань, координують інструменти та адаптуються, коли щось йде не так. Ви можете безпосередньо використовувати ці шаблони, замість того щоб створювати їх з нуля.
Для досягнення хороших результатів необхідно опанувати управління станом, умовне маршрутизування та інтеграцію інструментів як архітектурні шаблони, а не просто як функції. Найкращі додатки характеризуються ретельним проектуванням схеми стану, чітким розподілом обов’язків між вузлами, розсудливим обробленням помилок та повною можливістю спостереження. Фреймворк надає інструменти, а не готові рішення. Ваші знання в галузі та судження визначають, наскільки добре вони будуть застосовані, тому почніть з простого, рано перевіряйте припущення та дозвольте справжнім вимогам, а не уявним, формувати архітектуру.
Пов’язана література
- Агент чи робочий процес? Розділення міркувань та виконання в корпоративному ШІ — Використовуйте агентів для визначення намірів та пошуку інформації, а детерміністичні робочі процеси — для обробки транзакцій: як RAG, LangGraph, MCP, процедури схвалення та SQS створюють безпечнішу архітектуру.
- Рекомендувальна система K-drama з кількома агентами, що враховує смаки: BERTopic, RAG та метод фузії взаємних рангів — Як рекомендувальна система K-drama, що враховує смаки, поєднує теги BERTopic, пошук у ChromaDB, агента для аналізу інтерв’ю, розширення запитів та метод фузії взаємних рангів перед тим, як ШІ знову ранжує результати.