Пояснення агентського харнесу: компоненти, які перетворюють LLM на агента

У 2023 році описати роботу з мовною моделлю було легко. Ви вводили запитання, наприклад «напиши функцію на Python, яка сортує масив чисел», і відповідь надходила майже миттєво. Модель не переходила у жодний видимий режим мислення. Це була проста LLM без додаткових функцій, які є у сучасних агентських системах: інструментів, пам’яті, навичок тощо. Саме ці додаткові елементи перетворюють звичайну LLM на штучного інтелектуального агента.

Як змінилася гонка

Протягом 2023 та 2024 років конкуренція полягала у моделях. У OpenAI була провідна універсальна модель, у Anthropic — провідна модель для програмування, і всі намагалися перевершити один одного у таких тестах, як MMLU та SWE-bench. Зрештою ця гонка почала стабілізуватися, і на перший план вийшли здатність до міркувань та робота з довгим контекстом. У інтерфейсах чату почав з’являтися індикатор «модель міркує...», і люди цікавилися, що відбувається за цим.

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

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

До 2026 року той самий користувач може написати: «Виправте баг, який з’явився у питанні №122 на GitHub». У цьому одному реченні приховано кілька кроків. Модель 2023 року відповіла б, що не може отримати доступ до вашого репозиторію. Модель, яка працює в рамках хорошого інструментарію, входить у цикл мислення: аналізує ситуацію, планує дії, обирає інструмент чи метод, його застосовує, спостерігає за результатом, а потім повторює процес чи зупиняється.

Що таке інструментарій

Усі ці додатки, які оточують ШІ (контекст, інструменти, пам’ять тощо), потребують організованого способу взаємодії з моделлю. Ця система має назву, і її звичайне визначення є коротким. Це шар інфраструктури, який оточує ШІ-агента, відповідальний за його інтеграцію, керування, тестування, моніторинг та оцінку результатів. Простіше кажучи, це операційна система для ШІ.

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

Чому це необхідно

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

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

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

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

Компоненти

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

• Стан агента: де зараз знаходиться виконання завдання? Він відстежує поточне завдання, кроки, спостереження та рішення. Якщо план складається з чотирьох кроків, стан фіксує, які з них вже виконані, який триває та які ще не розпочаті. Без цього агент, якого перервали, не може продовжити з того місця, де зупинився.
• Інструменти: які дії є доступними? Це найбільш помітна частина. Тут знаходяться виконання коду, браузер, API, бази даних та оболонка. Для агента-програміста функція read_file є однією з основних.
• Планування: що буде далі? Він вирішує, що буде робитися далі, та складає або коригує план. Для завдання з програмування це може бути послідовність з чотирьох або п’яти кроків.

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

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

Керування контекстом: що має бачити LLM прямо зараз? Вона вирішує, що потрапить у вікно контексту на кожному кроці.

Безпека та управління: що дозволено? Сюди належать дозволи, ізоляція, механізми схвалення, правила, обмеження та автентифікація. Навіть якщо моделі дозволено редагувати файли, доцільно заборонити їх видалення.

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

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

Агент для програмування від початку до кінця

Візьміть агента для програмування з кріпленням та дайте йому запит «виправте баг у питанні №122 на GitHub». Це не прохання «поясніть мені це». Це справжнє завдання, яке вимагає планування, використання інструментів та зберігання інформації в пам’яті. Один з логічних підходів виглядає так:

1. Інформація від користувача потрапляє до контексту. Модель аналізує її та формулює мету, яка залишається в контексті до її досягнення.
2. Модель планує роботу: переглядає пов’язані баги, виправляє потрібний файл, компілює код, запускає тести та оновлює пам’ять.
3. Для першого кроку кріплення отримує інформацію з векторної бази даних — а саме деталі минулих багів, пов’язаних із цим. Інформація, пов’язана з автентифікацією, отримується як найбільш відповідний результат та додається до контексту.

Використовуючи цей контекст, модель вирішує відкрити auth.py та виправити помилку автентифікації. Для цього потрібні інструменти read_file та write_file, які вона використовує для редагування та збереження файлу.

Далі вона тестує зміни через термінал, використовуючи один із доступних інструментів термінала. Система забезпечує належний рівень доступу як до термінала, так і до файлів.

Модель переходить до наступного кроку плану та запускає тестові випадки, що потребує додаткових інструментів. Кожен крок оновлює контекст, щоб модель знала, де вона знаходиться та що залишилося зробити.

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

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

Куди рухаємося

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

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