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

Ось неприємна правда: більшість цих порівнянь є передчасними. Фреймворки — це не найскладніша частина. Найскладніше те, що ми перестали чітко визначати терміни. Тепер люди називають агентом усе підряд. Виклик інструменту (tool call) — це не агент. Чат-бот — це не агент. Таке недбале визначення веде прямо до поганої інженерії, надто складних систем і збоїв у продакшені, яких можна було б уникнути за допомогою простого скрипта.

Перш ніж обирати фреймворк, визначте, що саме ви насправді будуєте.

Що насправді являє собою агент

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

Уявіть систему підтримки, яка читає вхідний електронний лист, класифікує його як запит на повернення коштів, витягує номер замовлення, робить запит до бази даних доставки, перевіряє термін дії політики повернення, готує чернетку відповіді та позначає тікет як вирішений. Якщо база даних не відповідає, система чекає і повторює запит. Якщо термін дії політики неоднозначний, вона залучає людину. Коли відповідь надіслано, вона зупиняється. Це агент. Обертка навколо одного виклику LLM, що повертає JSON, не є агентом, незалежно від того, скільки наклейок із написом "agent" наклеїть на неї відділ маркетингу.

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

Справжній вигляд AI у продакшені

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

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

Фреймворк — це не продукт

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

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

Якщо ваші передачі завдань розмиті, інструменти ненадійні, а логіка повторних спроб відсутня, логотип у вашому requirements.txt вас не врятує.

Три речі, які справді заслуговують на вашу увагу

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

Проєктування інструментів. Кожна функція, яку може викликати ваш агент, — це ризик, загорнутий в інтерфейс. Проєктуйте їх чітко. Агресивно валідуйте вхідні дані. Повертайте помилки, які дійсно можна прочитати, а не просто дампи 500-ї помилки. Хороший інструмент — це той, про який агент може міркувати, коли щось іде не так.

Обробка помилок. Припускайте, що кожен LLM