Що насправді автоматизує LangChain після створення циклу агента
Пояснює, як LangChain, LangGraph та подібні SDK-и інтегрують один і той самий основний цикл агента, створений з нуля, та коли використання фреймворку допомагає чи шкодить.
На цьому етапі ви створили повного агента з первинних матеріалів — цикл, пам’ять, інструменти, підагенти, елементи кріплення — використовуючи лише базовий Anthropic SDK. Жодних фреймворків не було використано.
Саме зараз час поговорити про фреймворки, адже тепер відбувається щось корисне: оскільки ви самостійно побудували весь механізм, жоден фреймворк більше не здаватиметься вам таємничим.
Назви, які ви постійно чуєте
LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. The OpenAI Agents SDK.
Кожен з них має власну термінологію та власний спосіб організації того, що, здається, є однаковим базовим завданням. Якщо ви новачок у цій галузі, велика кількість опцій може здатися приголомшливою.
Є одне розуміння, яке усуває цю плутанину:
Кожен із цих фреймворків — це просто обгортка для того самого циклу, який ви вже створили раніше в цій серії.
Це справді весь секрет. Жоден з них не містить прихованої „магії“. По суті, усі вони виконують однакову послідовність: надсилають повідомлення, перевіряють причину зупинки, запускають інструменти та повертають отримані результати. Це точно такий самий цикл, який ви вже добре розумієте.
Це та пропозиція, яку пропонує кожна фреймворк-система: ви жертвуєте частиною контролю заради більшої швидкості.
Побачити на власні очі
Давайте розглянемо того самого агента, реалізованого двічі — один раз вручну, а інший раз за допомогою фреймворку.
Ось приблизний вигляд вашого агента з використанням сирого SDK, версії, яку ви тепер повністю розумієте:
messages = [{"role": "user", "content": user_message}]
while True:
# call the API — this runs again every time the model asks for a tool
response = client.messages.create(
model="claude-sonnet-4-6",
tools=tools,
messages=messages,
) # if the model is done, stop
if response.stop_reason == "end_turn":
break # otherwise it asked for a tool: run it, append the result, loop again
messages.append(response_as_message)
messages.append(tool_result_message)
Це саме той цикл, який був представлений раніше в серії. Виклик API знаходиться всередині while-циклу, тому що він виконується багаторазово — спочатку для отримання початкової відповіді, потім знову після кожного результату від інструменту — доки модель не дасть сигнал про завершення.
Тепер порівняйте це з приблизно таким самим агентом, створеним у LangChain:
from langchain.agents import create_agent
agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})
П’ять рядків замість тридцяти. На перший погляд, це здається очевидним покращенням.
Але зверніть увагу, що зникло. Цикл зник. Перевірка на stop_reason зникла. Ручна обробка повідомлень зникла. Жодна з цих логік не зникла по-справжньому — вона все ще працює, просто захована всередині create_agent, де ви більше не можете її побачити.
Коли все працює без проблем, ви економите час. Коли щось ламається, ви застрягаєте, намагаючись відлагодити процес, який неможливо переглянути.
Це напруження — ось справжня сутність фреймворків. Усе інше — це лише деталі, які додаються зверху.
Що ви насправді робите vs що робить фреймворк
Ось те, що часто застає людей зненацька. Як тільки ви починаєте використовувати фреймворк, ви більше ніколи не дивитеся безпосередньо на stop_reason. Ви більше ніколи не перевіряєте блок tool_use. Ви більше ніколи не додаєте tool_result вручну. Ви взагалі більше не пишете цикл.
Натомість ваша робота зводиться до трьох кроків:
- Напишіть функції вашого інструменту точно так, як ви б це зробили з базовим SDK.
- Зареєструйте ці функції у агенті за допомогою щось на кшталт
create_agent(tools=[...]). - Викличте
agent.invoke(...)один раз.
Це весь процес. Ви під’єднуєте інструменти та запускаєте виклик один раз.
За цим єдиним викликом фреймворк тихо виконує всю циклічну структуру, яку ви створили раніше: надсилає повідомлення, перевіряє причину зупинки, помічає, що моделі потрібен інструмент, викликає вашу функцію, додає результат, знову входить у цикл та повторює цей процес, поки модель нарешті не поверне end_turn. Лише тоді він передає вам готову відповідь.
Отже, фреймворк не просто приховує сам цикл — він також приховує всю механіку, яка забезпечує роботу викликів інструментів. Той, хто вивчає агентів, починаючи з фреймворку, навіть не дізнається про існування причини зупинки на кшталт end_turn чи про те, що виклики інструментів вирішуються через повторні ітерації. Для нього це просто виглядатиме як „Я зареєстрував інструмент, і він автоматично був використаний“.
Це нормально, поки виклик інструменту не почне поводитися некоректно. У такому випадку ви залишаєтесь перед чорною скринькою, адже ніколи не бачили механізму, який працює під спудом. Натомість ви самі створили цю механіку своїми руками, тож точно знаєте, що відбувається всередині неї.
LangChain, LangGraph — у чому різниця?
Ви будете постійно стикатися з обома назвами, тож ось коротка версія.
LangChain — це сама фреймворк-структура. Він надає визначення інструментів, з’єднання моделей та функцію create_agent — ту саму скорочену форму для приховування циклів, про яку йшлося вище.
LangGraph — це більш низькорівневий движок виконання, на якому базується LangChain. До нього звертаються, коли потрібен більш точний контроль — зупинка агента для схвалення кроку людиною, координація логіки розгалужень між кількома агентами чи збереження стану, щоб сервер після збою міг продовжити роботу саме з того місця, де зупинився.
Проста ментальна модель: LangChain — це швидкий, високорівневий вхідний пункт. LangGraph — це те, що використовується, коли цього вхідного пункту недостатньо. З кінця 2025 року LangChain було перебудовано на основі LangGraph, тож це вже не конкуруючі інструменти — це два рівні однієї системи: один простий, інший потужний.
Якщо ви тільки починаєте, ймовірно, вам поки що нічого з цього не потрібно. Чистий SDK, який ви вже розумієте, може допомогти вам просунутися на дивовижну відстань.
Коли корисна фреймворк
Фреймворки за своєю суттю не є пасткою. У деяких ситуаціях використання фреймворка справді є правильним рішенням.
Вам потрібні готові інтеграції. Припустимо, ваш агент має отримувати дані з бази даних Pinecone та документи з Google Drive. Скласти обидва з’єднувачі вручну за допомогою чистого SDK можливо, але це складно та тривало. LangChain постачає їх вже готовими — вам лише потрібно їх імпортувати та під’єднати. Це справжня економія часу.
Ви створюєте прототип під терміном. Ваш керівник хоче побачити працюючу демонстрацію вже завтра вранці. У такому разі внутрішня структура ще не має значення — вам просто потрібно щось функціональне якнайшвидше. П’ятирядкова налаштування може допомогти вам досягти цілі вже сьогодні ввечері.
Вам потрібна оркестрація, яку справді складно створити. Уявіть агента, який зупиняється посеред завдання, чекає, поки хтось натисне „схвалити“, перш ніж здійснити оплату, а потім продовжує роботу саме з того місця, де зупинився — навіть після перезапуску сервера. Деякі фреймворки забезпечують таку поведінку вже готовою. Створити її з нуля — це значний інженерний зусилля.
Коли фреймворк завдає проблем
Виправлення помилок стає складним. Уявіть, що ваш агент іноді повертає порожню відповідь, і ви не можете зрозуміти чому. У коді, який ви самі написали, ви б додали оператор виведення, простежили ланцюг виконання та знайшли проблему за кілька хвилин. У фреймворку та сама помилка знаходиться десь у функції create_agent — коді, який не належить вам. Вам доводиться переглядати вихідний код фреймворку на GitHub, щоб зрозуміти, що робить ваш власний агент.
Абстракція починає «текти». Фреймворки оптимізовані для типових ситуацій. Уявіть, що вам потрібен результат роботи інструменту у нестандартному форматі або політика повторних спроб, пристосована до вашої конкретної налаштовки. Фреймворк ніколи не передбачав такого. Тепер вам доводиться використовувати складні обхідні шляхи, щоб змусити його виконати те, що тридцять рядків власного коду могли б зробити безпосередньо.
У підсумку ви вивчаєте інструмент, а не саму концепцію. Початок роботи з фреймворком навчає вас «як працює LangChain», а не того, як насправді функціонують агенти. Потім API LangChain змінюється — що вже траплялося неодноразово — і ваші знання миттєво стають застарілими. Логіка, про яку йшлося раніше в цій серії, не змінювалася з моменту створення агентів і не збирається змінюватися.
Правило, якого варто дотримуватися
Почніть з базового SDK. Створюйте цикл вручну. Таким чином ви точно будете знати, що робить ваш агент, і зможете простежити кожен крок у разі проблем. Для більшості агентів це справді все, що вам коли-небудь знадобиться.
Використовуйте фреймворк лише тоді, коли він краще, ніж ви самі, вирішує певну проблему — готова інтеграція, стан, який зберігається після збою, кроки схвалення з участю людини. Використовуйте його свідомо саме з цієї причини, а не як стандарт.
Не вдаються до фреймворку лише для того, щоб уникнути вивчення циклу. Це справжня пастка. Якщо пропустити цей крок, у вас залишиться «чорна скринька», побудована на ідеях, які ви насправді не засвоїли.
Спочатку зрозумійте цикл. Після цього фреймворк стане інструментом, який ви оберете усвідомлено — а не опорою, на яку покладаєтесь через відсутність знань основ.
Чому ця серія створює все з нуля
Саме це є причиною того, чому ми відкладали використання фреймворків до цього моменту.
Якби ця серія починалася з рекомендації «встановити LangChain та викликати create_agent», у вас був би працездатний агент, але без реального розуміння його функціонування. Ви б не знали, що таке блок tool_use, чому результати паралельних викликів інструментів об’єднуються в одне повідомлення, чи чому логіка авторизації має знаходитися у хуку.
Тепер, коли ця основа вже у вашому розпорядженні, лексика будь-якої фреймворк-системи може бути миттєво перекладена. Те, що вона називає „агентом“, насправді є просто тим самим циклом усередині. Те, що вона називає „пам’яттю“, — це не що інше, як список повідомлень, з яким ви вже знайомі. Те, що вона позначає як „інструменти“, безпосередньо відповідає блокам tool_use, якими ви керували вручну. А те, що вона просуває як „мідлвер“, — це просто інша назва для гаків, які ви самі створили.
Ось таке положення варте досягнення. Не „Я знаю LangChain“ — а „Я розумію, як працюють агенти, і LangChain — це лише один з способів його опису“.
Фреймворки будуть продовжувати розвиватися. Кожні кілька місяців з’являються нові. Але цикл усередині залишається незмінним. Формуйте свої знання на основі тієї частини, яка не змінюється.
Пов’язана література
- Чатботи проти AI-агентів: що насправді розділяє їх поза межами LLM — Дізнайтеся, чому справжня різниця між чатботами та AI-агентами полягає у архітектурі навколишньої системи — інструментах, плануванні та діях — а не в самому LLM.
- Розуміння AI-агентів: цілі, інструменти, пам’ять та цикл агента — Просте пояснення для початківців про те, чим AI-агенти відрізняються від чатботів, з описом ключових компонентів, циклу прийняття рішень, рівнів автономії та прикладів їх використання у реальному світі.