AI-агенти

Цикл і чого він коштує

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

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

Робочий процес чи агент

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

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

Що потрібно агенту, щоб бути безпечним

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

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

Як це виявляється в реальній поставці

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

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

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

Де це вироджується

• Агент там, де вистачило б робочого процесу: платите вартістю, затримкою й налагоджуваністю за непотрібну гнучкість.
• Відсутність жорсткого ліміту кроків чи витрат: одна задача працює, доки хтось не помітить рахунок.
• Інструменти, що віддзеркалюють внутрішній API по одному виклику: одна робота стає десятьма шансами помилитися.
• Аргументи інструментів, яким довіряють тому, що їх видала модель, без перевірки у вашому коді.
• Неідемпотентні побічні ефекти: повтор надсилає другий лист, якого ніхто не просив.
• Права сервісного акаунта замість прав користувача: агент дістає те, чого користувач дістати не може.
• Запити підтвердження, настільки часті, що стають рефлексом: вони імітують нагляд, не забезпечуючи його.
• Оцінювання лише підсумкової відповіді: прогін, що дійшов правильного результату хибним шляхом, виглядає успішним.

Коли це застосовувати

Пов’язані сторінки

• РозробкаОснови LLMВелика мовна модель (LLM) робить рівно одну річ: маючи наявний текст, вона оцінює кожен можливий наступний токен, а щось один із них обирає. Чат, виклики інструментів, міркування й агенти — усе це та сама операція, повторена багато разів. На цій сторінці — що таке токен, скільки насправді коштує контекстне вікно, чому модель вигадує факти з цілковитою впевненістю і які налаштування справді змінюють відповідь.
• РозробкаRAG-архітектураRetrieval-augmented generation (RAG) — це спосіб змусити модель відповідати про дані, на яких її не навчали: спершу знайти доречні фрагменти, покласти їх у промпт і вимагати, щоб відповідь походила саме з них. Тому RAG — це пошукова система з мовною моделлю на кінці, і тому майже кожна хибна відповідь є збоєм пошуку, а не генерації. На цій сторінці — обидва конвеєри, як вимірювати пошук окремо, і проблема прав доступу, що перетворює демо на інцидент.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу, побудовану на мовній моделі, і вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що той самий ввід дає той самий вивід. LLM-функції це припущення ламають, тож практики доводиться перебудовувати навколо цього. На цій сторінці — що заступає набір тестів, чим насправді є артефакт розгортання, що записувати на кожному виклику і як поводяться вартість і затримка, коли приходить справжній трафік.