AI-агенти

Робочий процес чи агент: вирішіть це першим

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

Цикл і арифметика, що ним керує

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

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

Поверхня інструментів і є проєктом

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

Гранулярність — це те місце, де арифметика складання стає проєктним правилом. Віддзеркалити внутрішній API по одному ендпойнту здається нейтральним вибором, але ним не є: одна одиниця роботи перетворюється на пʼять шансів моделі обрати неправильно, а порядок, валідація й транзакція переїжджають із коду в цикл, який не можна протестувати. Інструмент create_invoice лишає одне рішення й тримає всі три там, де їм місце. Перевірка проста: чи відповідає інструмент тому, що людина назвала б задачею, а не тому, що база назвала б операцією.

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

Пʼять режимів збою, які існують лише в циклі

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

Що стоїть між моделлю й наслідком

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

1. 1.Межі

   1. 1.1Агент починає лише з читанням, і кожне право на запис заробляється записом траєкторій.
   2. 1.2Є записаний список того, що йому дозволено, і він коротший за список того, що він міг би.
   3. 1.3Кожну задачу, чиї кроки можна перелічити, спершу перенесено в робочий процес.

2. 2.Жорсткі ліміти, забезпечені кодом

   1. 2.1Максимальна кількість кроків на задачу, забезпечена виконавцем, а не попрошена в промпті.
   2. 2.2Стеля токенів і витрат на задачу, що перериває прогін, а не пише попередження в лог.
   3. 2.3Тайм-аут за реальним часом і спосіб для людини спинити прогін, що вже триває.

3. 3.Інструменти

   1. 3.1Кожен інструмент робить одну осмислену одиницю роботи, а не віддзеркалює один ендпойнт API.
   2. 3.2Опис кожного інструмента каже, коли його застосовувати не слід, а не лише що він робить.
   3. 3.3Кожен аргумент перевіряється вашим кодом як недовірений ввід — точно як тіло запиту.
   4. 3.4Кожен інструмент, що змінює стан, приймає ключ ідемпотентності з перевіркою на сервері.

4. 4.Права

   1. 4.1Інструменти працюють із правами цього користувача — ніколи з правами сервісного акаунта.
   2. 4.2Усе безповоротне стоїть за людським підтвердженням, достатньо рідкісним, щоб його справді читали.
   3. 4.3Бойові дані й бойові облікові дані недосяжні з девелоперського чи тестового прогону.

5. 5.Спостережуваність

   1. 5.1Записується вся траєкторія: кожен виклик, кожен аргумент, кожен результат, кожне рішення.
   2. 5.2Користувач бачить, що агент робить, поки він це робить: інструмент, ціль, результат.
   3. 5.3Траєкторія показується після завершення, щоб хибний підсумок можна було зрозуміти, а не лише про нього повідомити.

6. 6.Оцінювання

   1. 6.1Фіксовані сценарії проганяються в пісочниці із заздалегідь підготованими даними й інструментами, що записують замість діяти.
   2. 6.2Дві речі оцінюються окремо: чи дійшов він правильного кінцевого стану і чи зробив щось, чого не мав.
   3. 6.3Вартість і кількість кроків на задачу ведуть як розподіли, бо середнє ховає прогін, що зʼїв бюджет.

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

Оцінюйте траєкторії, а не відповіді

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

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

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

Пʼять прогонів — і чого кожен коштував

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

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

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

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

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

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

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