Що таке AI Agents

Що таке AI Agent

AI Agent — це програмна система, яка використовує модель штучного інтелекту для досягнення певної мети, самостійно обираючи наступні кроки та взаємодіючи із зовнішніми інструментами.

Простіше кажучи, агент — це не лише модель, яка генерує текст. Це комбінація:

• LLM, що інтерпретує запит і приймає рішення;

• інструментів для роботи із зовнішнім світом;

• пам’яті або стану виконання;

• циклу, у якому агент планує дію, виконує її, аналізує результат і вирішує, що робити далі;

• правил завершення та обмежень безпеки.

Наприклад, звичайний чат-бот може відповісти на запитання про статус замовлення. Агент здатен:

1. зрозуміти запит користувача;

2. визначити, що потрібно перевірити базу даних;

3. викликати відповідний інструмент;

4. проаналізувати результат;

5. за потреби перевірити ще одну систему;

6. сформувати фінальну відповідь.

Звичайний виклик LLM

У найпростішому випадку застосунок працює за схемою:

запит користувача → LLM → відповідь

Програма передає моделі текст і отримує згенерований текст у відповідь.

Наприклад:

const answer = await llm.generate({
  messages: [
    {
      role: "user",
      content: "Поясни, що таке HTTP"
    }
  ]
});

Така модель може добре:

• пояснювати поняття;

• створювати текст;

• перекладати;

• підсумовувати документи;

• генерувати код;

• класифікувати запити.

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

Якщо потрібно виконати дію, це має зробити код, який викликає модель.

Що змінюється в агента

В агентній системі модель може не лише створити відповідь, а й попросити програму виконати певну дію через інструмент.

Типовий процес має такий вигляд:

запит
  ↓
модель аналізує ситуацію
  ↓
модель обирає інструмент
  ↓
програма виконує інструмент
  ↓
результат повертається моделі
  ↓
модель вирішує, що робити далі
  ↓
фінальна відповідь або наступний виклик інструменту

Ключова відмінність — цикл прийняття рішень і виконання дій.

Одного виклику LLM недостатньо, щоб система стала агентом. Важливо, що модель бере участь у виборі наступного кроку, а система може виконувати цей крок і повертати результат назад у контекст.

Інструменти агента

Інструмент — це контрольована функція, яку агент може викликати для виконання конкретної операції.

Прикладами інструментів можуть бути:

• пошук товару в каталозі;

• отримання даних про замовлення;

• запит до CRM;

• виконання SQL-запиту через безпечний шар;

• пошук у внутрішній документації;

• створення чернетки електронного листа;

• виклик зовнішнього API;

• запуск розрахунку;

• створення задачі в системі підтримки.

Інструмент зазвичай має:

• назву;

• опис призначення;

• список параметрів;

• правила валідації;

• обмеження доступу;

• передбачуваний формат результату.

Модель не повинна отримувати необмежений доступ до системи. Замість цього їй надають вузькі функції з чіткими параметрами.

Наприклад, краще надати інструмент getOrderStatus(orderId), ніж дозволити моделі виконувати довільні SQL-запити до всієї бази даних.

Агентний цикл

Спрощений агентний цикл можна описати так:

async function runAgent(userRequest) {
  const messages = [
    {
      role: "system",
      content: "Ти допомагаєш користувачам перевіряти статус замовлень."
    },
    {
      role: "user",
      content: userRequest
    }
  ];

  for (let step = 0; step < 5; step++) {
    const decision = await llm.generate({
      messages,
      tools: [
        {
          name: "getOrderStatus",
          description: "Отримати статус замовлення за його ідентифікатором",
          parameters: {
            type: "object",
            properties: {
              orderId: { type: "string" }
            },
            required: ["orderId"]
          }
        }
      ]
    });

    if (decision.type === "final_answer") {
      return decision.content;
    }

    if (decision.type === "tool_call") {
      const args = validateToolArguments(
        decision.toolName,
        decision.arguments
      );

      const result = await executeTool(
        decision.toolName,
        args
      );

      // Результат інструмента додається до контексту для наступного кроку
      messages.push({
        role: "assistant",
        content: decision
      });

      messages.push({
        role: "tool",
        content: JSON.stringify(result)
      });
    }
  }

  throw new Error("Досягнуто максимальну кількість кроків");
}

Це концептуальний приклад. Конкретний формат виклику інструментів залежить від використовуваної LLM-платформи та SDK.

Важливі частини циклу:

1. Модель отримує запит і доступні інструменти.

2. Модель повертає або фінальну відповідь, або виклик інструмента.

3. Застосунок перевіряє параметри.

4. Застосунок виконує інструмент.

5. Результат додається до контексту.

6. Модель отримує можливість зробити наступний крок.

Приклад роботи агента

Нехай користувач запитує:

Чи доставили моє замовлення і які товари були в ньому?

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

1. Визначити номер замовлення з повідомлення або попросити його в користувача.

2. Викликати getOrderStatus.

3. Отримати статус і список товарів.

4. Якщо статус незрозумілий, викликати getDeliveryDetails.

5. Об’єднати результати.

6. Пояснити відповідь зрозумілою мовою.

Звичайний виклик LLM не може самостійно отримати ці дані. Йому потрібно передати їх у запиті. Агентна система може організувати отримання даних у процесі виконання.

Чим агент відрізняється від автоматизації

Не кожна система, яка виконує кілька кроків, є агентом.

Жорстко задана автоматизація

У звичайній автоматизації сценарій визначений заздалегідь:

отримати замовлення
→ перевірити статус
→ надіслати повідомлення

Програма завжди проходить однаковий шлях. Умови можуть змінюватися, але правила написані розробником.

Агент

Агент має більше гнучкості:

• сам визначає, який інструмент потрібен;

• може обрати різний порядок дій;

• адаптується до результатів попередніх кроків;

• може поставити уточнювальне запитання;

• може завершити виконання, коли вважає мету досягнутою.

Однак агентність не означає повну незалежність. У production-системах агент зазвичай працює в межах чітких правил, лімітів і дозволів.

Основні компоненти AI Agent

Модель

LLM відповідає за інтерпретацію запиту, вибір інструмента, аналіз результатів і створення відповіді.

Модель не виконує бізнес-операції безпосередньо. Вона пропонує дію, а оркестратор вирішує, чи можна її виконати.

Оркестратор

Оркестратор — це код, який керує агентним циклом.

Він:

• передає моделі контекст;

• описує доступні інструменти;

• обробляє виклики;

• перевіряє параметри;

• виконує функції;

• контролює кількість кроків;

• обробляє помилки;

• визначає умови завершення.

Саме оркестратор перетворює набір викликів LLM на працюючу систему.

Інструменти

Інструменти надають агенту можливість взаємодіяти із зовнішніми системами.

Їх потрібно проєктувати так, щоб вони були:

• вузькими за призначенням;

• безпечними;

• ідемпотентними, якщо це можливо;

• зрозумілими для моделі;

• простими для тестування.

Стан і пам’ять

Агенту потрібно знати, що вже відбулося під час поточного виконання. Для цього зберігають:

• історію повідомлень;

• викликані інструменти;

• їхні результати;

• поточну мету;

• помилки;

• проміжні дані.

Окремо можна зберігати довготривалу пам’ять: налаштування користувача, попередні звернення або факти, які дозволено використовувати в майбутніх сесіях.

Пам’ять не є обов’язковою ознакою агента. Агент може працювати лише з контекстом одного завдання.

Політики та обмеження

Застосунок має визначати:

• які інструменти доступні;

• які користувачі можуть їх викликати;

• які дії потребують підтвердження;

• скільки кроків дозволено;

• скільки коштів або часу можна витратити;

• що робити при помилці;

• коли потрібно передати задачу людині.

Рівні агентності

Термін «AI Agent» використовують для систем різної складності.

Один виклик інструмента

Модель аналізує запит і викликає одну функцію. Після її результату застосунок формує відповідь.

Це вже може бути корисною агентною поведінкою, хоча цикл дуже короткий.

Багатокроковий агент

Модель може послідовно викликати кілька інструментів, оцінюючи результат кожного з них.

Наприклад:

знайти клієнта
→ перевірити його замовлення
→ перевірити оплату
→ створити відповідь

Агент із плануванням

Система спочатку формує план, а потім виконує його кроки. План може змінюватися, якщо інструмент повернув неочікуваний результат.

Команда агентів

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

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

Коли потрібен агент

Агентний підхід доречний, якщо:

• задачу неможливо описати одним стабільним сценарієм;

• потрібен вибір між кількома інструментами;

• кількість кроків залежить від отриманих результатів;

• користувачі формулюють запити у вільній формі;

• система має адаптуватися до непередбачуваних ситуацій;

• важливо обробляти неповні або неоднозначні інструкції.

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

Коли агент не потрібен

Агент може бути зайвим, якщо:

• процес має стабільну послідовність кроків;

• усі умови можна описати звичайним кодом;

• потрібна сувора передбачуваність;

• помилки мають високу ціну;

• немає потреби в інтерпретації природної мови;

• достатньо одного виклику LLM.

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

Безпека агентів

Агент, який може викликати інструменти, потенційно здатен завдати шкоди. Тому його дії потрібно обмежувати на рівні застосунку, а не лише інструкціями в системному промпті.

Валідуйте аргументи

Усі параметри, які пропонує модель, потрібно перевіряти:

• типи даних;

• допустимі значення;

• формат ідентифікаторів;

• права доступу;

• належність ресурсу конкретному користувачеві.

Розділяйте читання і запис

Інструменти для отримання даних зазвичай менш ризиковані, ніж інструменти, які:

• видаляють записи;

• здійснюють платежі;

• змінюють налаштування;

• надсилають повідомлення;

• публікують контент.

Для критичних дій бажано вимагати явне підтвердження користувача.

Додавайте ліміти

Корисні обмеження:

• максимальна кількість кроків;

• тайм-аут;

• ліміт вартості запитів;

• обмеження кількості викликів одного інструмента;

• максимальний розмір контексту;

• заборона повторення невдалої дії.

Не довіряйте даним із зовнішніх джерел

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

Логуйте виконання

Для налагодження важливо зберігати:

• початковий запит;

• рішення моделі;

• виклики інструментів;

• аргументи;

• результати;

• помилки;

• причину завершення.

Водночас журнали не повинні містити секрети та зайві персональні дані.

Типові помилки

Вважати будь-який чат-бот агентом

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

Дозволяти моделі довільний доступ

Не варто передавати агенту універсальний доступ до бази даних, shell-команд або внутрішніх сервісів. Надійніша модель — невеликий набір спеціалізованих функцій із перевіркою параметрів.

Покладатися лише на промпт

Інструкція на кшталт «не видаляй дані без дозволу» корисна, але не є механізмом безпеки. Критичні обмеження мають бути реалізовані в коді та системі прав доступу.

Не встановлювати умови завершення

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

Робити всі дії автономними

Для платежів, видалення даних, публікації матеріалів та інших незворотних операцій краще додати підтвердження людини.

Використовувати агента там, де достатньо звичайного коду

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

Не тестувати окремі інструменти

Інструменти потрібно тестувати незалежно від LLM. Так легше відокремити помилку бізнес-логіки від помилки вибору дії або неправильних аргументів моделі.

Як проєктувати агента

Практичний підхід може складатися з таких кроків:

1. Визначити мету.
   Описати, яку задачу агент має розв’язувати і що вважається успішним результатом.

2. Перевірити, чи справді потрібна агентність.
   Порівняти агентний підхід зі звичайним алгоритмом або фіксованим workflow.

3. Створити мінімальний набір інструментів.
   Кожен інструмент має виконувати одну зрозумілу операцію.

4. Визначити межі.
   Додати ліміти кроків, тайм-аути, перевірки доступу й умови завершення.

5. Передбачити помилки.
   Інструмент може бути недоступним, повернути неповні дані або повідомити про помилку.

6. Додати спостережуваність.
   Логувати кроки, час виконання, кількість викликів і причини невдач.

7. Перевірити систему на реальних сценаріях.
   Потрібно тестувати не лише правильні запити, а й неоднозначні, шкідливі та неповні інструкції.

Підсумок

AI Agent — це система навколо LLM, яка може:

• інтерпретувати мету користувача;

• обирати наступну дію;

• викликати інструменти;

• отримувати результати;

• продовжувати виконання в циклі;

• завершувати задачу або передавати її людині.

Звичайний виклик LLM має схему «запит — відповідь». Агент додає до неї стан, інструменти, оркестрацію та цикл прийняття рішень.

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