Типи AI-агентів: які бувають і що вони вміють

Які бувають типи AI-агентів

Типи AI-агентів поділяють за однією таксономією: агенти з простими рефлексами, рефлексивні агенти на основі моделі, агенти на основі цілей, агенти на основі корисності та агенти, що навчаються. Кожна назва описує один аспект: скільки інформації агент зберігає та наскільки наперед планує свої дії. Ще два терміни — multi-agent і hierarchical — описують спосіб взаємодії кількох агентів, а не принцип ухвалення рішень окремим агентом.

Цей перелік з’явився раніше за всі моделі, якими ви користувалися. Він походить зі стандартного підручника з AI і зберіг актуальність після появи великих мовних моделей, оскільки порушує питання, яке й досі визначає архітектуру: що саме цей компонент має знати перед виконанням дії? Якщо ви ще визначаєте, де закінчується агент і починається чат-асистент, спочатку прочитайте про різницю між AI-агентом і LLM, на якій він працює. Ця сторінка починається після цього розмежування.

Прості рефлекторні агенти: одна умова, одна дія

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

Ви майже напевно вже використовували такий агент. Webhook, який запускає workflow в n8n, читає дані, надіслані з форми, і записує рядок у базу даних, є простим рефлекторним агентом. Він залишається таким навіть тоді, коли між webhook і базою даних працює мовна модель, яка вибирає категорію для цього рядка. Запитайте агента, що він робив годину тому, і він не зможе відповісти, оскільки відповідь ніхто не зберіг.

Цей тип працює правильно частіше, ніж очікують. Його недорого запускати, а причину помилки легко визначити: умова виконалася або ні. Якщо завдання справді має вигляд «коли надходить X, виконати Y», пам’ять створює додаткові можливості для помилки й не дає переваг. Агент n8n, якого запускає webhook — це цей клас таксономії з інтерфейсом користувача.

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

Агенти рефлексів на основі моделі: збереження стану між подіями

Агент рефлексів на основі моделі зберігає внутрішнє уявлення про середовище та оновлює його, коли надходять нові дані. Тут слово «модель» означає модель світу, а не нейронну мережу. Цей термін з’явився приблизно на сорок років раніше за сучасне значення, тому під час першого читання він майже всіх бентежить.

Правило home automation, яке вимикає світло після двадцяти хвилин без руху, є моделезалежним. Інакше бути не може. «Зараз руху немає» і «руху немає з 21:40» — однакові вхідні дані для простого агента рефлексів. Відрізнити їх дає лише збережений стан.

Версія для LLM — це будь-який агент зі сховищем пам’яті: поточним стислим підсумком розмови або звичайним markdown-файлом, який агент читає на початку кожного запуску. Локальний сервіс пам’яті для агента — це реалізація цієї ідеї у вигляді окремого сервісу. Механізм не змінюється. Уявлення агента про світ зберігається довше, ніж подія, яка його створила.

Стан має ціну. Застарілий факт гірший за відсутність факту, оскільки агент діє на його основі з повною впевненістю та без попередження. Для всього, що ви зберігаєте, потрібен механізм автоматичного завершення дії або повторної перевірки. Інакше агент продовжить міркувати про сервер, який ви вивели з експлуатації у March.

Агенти, орієнтовані на цілі: планування до стану, який можна перевірити

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

Найнаочніший приклад, який можна запустити самостійно, — агент для роботи з кодом. Вказівка «Зроби так, щоб тест із помилкою пройшов» не визначає ні файлів, ні кроків. Агент читає тест, формує план, щось змінює, запускає тест, читає помилку та пробує знову. Цикл завершується перевіркою, яку він може фактично виконати. Саме тому така вказівка працює, а «покращ цей код» — ні. Ціль, яку агент може оцінити, — це ціль, якої агент може досягти. Ціль, яку він не може оцінити, перетворюється на нескінченний цикл із нарахуванням витрат. Запуск агента для роботи з кодом на власному VPS дає змогу розмістити цей цикл у середовищі, де він може працювати без залучення вашого ноутбука.

Витрати виникають саме в цьому циклі. Кожен крок планування — це ще один виклик моделі з передаванням усієї накопиченої історії. Тому завдання з десяти кроків коштує не вдесятеро дорожче за завдання з одним кроком, а ще більше. Найважливіше в інженерній реалізації — структура циклу та умова його завершення. Саме цьому присвячено розділ про проєктування циклів.

Агенти на основі корисності: вибір між кількома прийнятними відповідями

Мета є бінарною. Корисність — це оцінка. Агент на основі корисності має кілька прийнятних результатів і вибирає той, що отримує найвищу оцінку за визначеною вами функцією.

Резервне копіювання, яке має завершитися до початку робочого дня, не перевантажуючи uplink, є задачею оптимізації корисності. Єдиного правильного варіанта немає, є лише компроміс. Маршрутизатор, який вирішує, яка модель оброблятиме конкретний запит, зважуючи вартість і якість відповіді, працює за тим самим принципом.

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

Навчальні агенти: тип, який більшість людей вважає вже наявним

Навчальний агент змінює власну поведінку на основі зворотного зв’язку про попередні результати. Йому потрібен компонент, який оцінює результат, і компонент, який відповідно змінює політику.

Дуже мало self-hosted систем відповідають цьому визначенню. Агент, який читає нотатки, записані ним минулого тижня, є model-based агентом із файлом пам’яті. Його ваги не змінилися. Його політика не змінилася. Retrieval не є навчанням, і ця відмінність має практичне значення: система на основі пам’яті повторюватиме помилку без кінця, якщо хтось не змінить пам’ять, тоді як навчальна система має припинити її робити.

Якщо вам потрібна частина, що відповідає за навчання, спочатку побудуйте оцінювання. Набір тестів з оцінками, запуск вашої зміни на цьому наборі та рішення залишити або відхилити зміну утворюють замкнений цикл, у якому компонентом навчання єте ви. Це повільніше, ніж здається, але сьогодні це єдина версія, яка працює на self-hosted компонентах. Саме з цього починається Self-hosting інфраструктури для оцінювання.

Багатоагентні та ієрархічні системи: схеми взаємодії, а не типи

Це не шостий і сьомий типи. Вони описують спосіб організації агентів.

Багатоагентна система одночасно запускає кілька агентів у спільному середовищі, наприклад у черзі або git-репозиторії. Оскільки середовище спільне, агенти конфліктують у ньому. Редагування одного файлу двома агентами — типова причина збою. Для цього потрібні блокування або робоча черга. Жоден prompt не усуває цю проблему.

Ієрархічна система розміщує над виконавцями супервізора. Супервізор розбиває завдання, розподіляє його частини та об’єднує отримані результати. Такий підхід популярний, бо відповідає людському способу розподілу роботи. Водночас він потребує більше ресурсів, оскільки контекст супервізора зростає з кожним прочитаним звітом. Багатоагентний harness показує, як це підключається на практиці.

Один агент, який працює, кращий за чотирьох, які здебільшого працюють.

Кожна передача результату — це місце, де можна втратити інформацію. Почніть з одного циклу. Розділяйте його лише тоді, коли можете назвати крок, який є вузьким місцем.

Чому майже кожна реальна система є гібридною

Розглянемо deployment agent, який можна запускати самостійно. Webhook запускає його — це рефлексивний рівень. Агент зчитує поточний стан релізу — це модельний рівень. Він планує кроки від запущеної версії до цільової — це цільовий рівень. Він вибирає вікно розгортання на основі поточного навантаження — це рівень, орієнтований на корисність. Агент не змінює власну політику, тому він не є системою, що навчається.

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

Який тип підходить для якого завдання

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

Чи можна розмістити цих агентів на власній інфраструктурі та скільки це коштує?

Так, і витрати складаються з двох частин. Оркестрація коштує недорого. Екземпляр n8n або цикл агента на Python більшу частину часу очікує на мережеві виклики, тому для нього достатньо 2 vCPU і 4 GB RAM. Основні витрати припадають на модель.

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

Якщо запускати модель на власному обладнанні, обсяг RAM визначає, що саме можна запустити. Нижче наведено типові опубліковані розміри файлів для 4-bit quantised weights станом на August 2026, а поруч — орієнтовний загальний обсяг RAM, оскільки для context window і runtime потрібен додатковий простір.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Для моделі 8B у форматі 4-bit потрібно приблизно 4.9 GB під weights, а система з 10 GB RAM запускає її без використання swap. Модель 70B із таким самим рівнем квантизації займає 43 GB під weights і потребує близько 64 GB RAM. Зверніть увагу, чого ці числа не враховують: швидкості. На VPS без GPU модель 8B у форматі 4-bit генерує однозначну кількість токенів за секунду. Цього достатньо для агента, який обробляє чергу протягом ночі, але недостатньо для інтерактивних операцій, на які очікує користувач. Використовуйте локальний inference для пакетної обробки, а для інтерактивних операцій — GPU або API. У матеріалі Короткий список AI-агентів для розміщення на власній інфраструктурі описано, які проєкти варті дискового простору, а в матеріалі Навчальний маршрут для агентів у 2026 році — що і в якій послідовності вивчати.

Коли таксономія перестає допомагати

Вона нічого не говорить про інструменти або дозволи. У підручнику агенти сприймають інформацію та виконують дії. Авторів того розділу не турбувало, що агент може мати production API token. Goal-based agent із доступом до shell і goal-based agent з одним read-only підключенням до бази даних опиняються в одному рядку таблиці, але створюють зовсім різні ризики. Визначте, до чого агент може отримувати доступ, перш ніж вирішувати, наскільки складним він має бути, і прочитайте як не зберігати секрети в AI-агенті, перш ніж передавати йому облікові дані.

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

FAQ

Які існують п’ять типів AI-агентів?

Агенти з простими рефлексами, рефлексами на основі моделі, цільові, на основі корисності та агенти, що навчаються. Вони впорядковані за обсягом інформації, яку агент має до початку дії. Агент із простими рефлексами бачить лише поточний вхідний сигнал. Агент на основі моделі зберігає стан свого середовища. Цільовий агент планує досягнення цільового стану. Агент на основі корисності оцінює кілька прийнятних результатів і вибирає найкращий. Агент, що навчається, змінює власну політику на основі зворотного зв’язку, хоча в self-hosted середовищі майже ніхто фактично так не працює.

Який тип AI-агента слід використовувати для простої автоматизації?

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

Чи можна запускати власних AI-агентів на VPS?

Так. Рівень оркестрації не потребує значних ресурсів, тому 2 vCPU і 4 GB RAM достатньо для комфортної роботи workflow engine або agent loop. Насправді потрібно вирішити, де запускати модель. Hosted API дає змогу залишити сервер компактним і перенести витрати на tokens. Для локальної моделі потрібен обсяг RAM, пропорційний кількості її параметрів. Без GPU вона генерує однозначну кількість tokens за секунду, тому підходить для пакетної роботи в черзі, а не для chat window.

Чи є large language model AI-агентом сам по собі?

Ні. Модель перетворює вхідний текст на вихідний текст і зупиняється. Вона стає агентом, коли певна оболонка запускає її в циклі, який може діяти у зовнішньому середовищі та передавати результат назад. Для цього потрібні інструменти, які вона може викликати, і умова, що визначає момент завершення циклу. Оболонка є агентом. Модель є одним із його компонентів.

Чи потрібна мені multi-agent system?

Зазвичай ні. Один цикл із кількома інструментами виконує більшість завдань і значно простіше налагоджується. Кілька агентів корисні, коли частини завдання справді незалежні та можуть виконуватися одночасно або коли для однієї з частин потрібна інша модель. Недолік полягає в координації: спільний стан і supervisor, контекст якого збільшується з кожним звітом worker, який він читає. Додавайте другого агента, коли можете вказати на етап, що працює повільно.