Чому штучні інтелектуальні агенти спалюють бюджет, не завершуючи роботу, та як це зупинити
Дізнайтеся, чому агенти з викликом інструментів постійно повторюють цикл, коли поняття „завершено“ не визначене, куди йде витрачання токенів, та які умови зупинки є ефективнішими за просте підвищення лімітів кроків чи бюджету.
Автономний агент, який збивається, легко керувати. Насправді дорогим є той випадок, коли агент ніколи не збивається: він продовжує викликати інструменти, створювати кроки, які виглядають розумними, і ніколи не досягає кінцевої мети, поки йде використання токенів. У цій статті пояснюється механізм такої поведінки, де зазвичай накопичується витрата ресурсів у агенті, що вийшов з-під контролю, та конкретні умови зупинки, які це запобігають, щоб ви могли проектувати цикли агентів, які знають, коли вони завершені, замість того, щоб покладатися на більший бюджет для поглинання зайвих витрат.
Розгляньмо скромний приклад: пробіжка після обіду без нагляду, яка коштує 40 доларів та не приносить жодних результатів. Згідно зі стандартами роботи агентів це незначна сума; команди діляться історіями про неконтрольовані нічні виконання завдань, які коштували кілька тисяч доларів. Важлива не сума, а те, що вона купила. Агент не застряг та не створив жодної помилки, на яку можна було б вказати. Він був зайнятий усій час, але працював над нічим.
Як виглядає агент, що вийшов з-під контролю, у записах
Якщо відкрити журнал агента, який відхилився від заданого маршруту, то рідко можна знайти стек-трейс. Те, що там є, нагадує записи сумлінного працівника, який втратив уявлення про те, що саме мав робити.
Агент відкриває файл та узагальнює його зміст, потім відкриває той самий контент у трохи іншій формі та знову його узагальнює. Він виконує пошук, вважає отриману відповідь недостатньо задовільною та знову формулює запит, змінивши кілька слів. Кожен окремий крок є обґрунтованим. Саме тому цю схему важко помітити при поверхневому огляді: жоден окремий етап не виглядає неправильним. Процес просто ніколи не доходить до завершення.
Чому модель вирішує, коли все готово
У цій поведінці є конкретна причина, яку варто зрозуміти, якщо ви створюєте або керуєте агентами. Кожна відповідь від моделі, яка використовує інструменти, такої як Claude, закінчується причиною зупинки, взятою з короткого фіксованого списку. посібник Anthropic щодо роботи з причинами зупинки охоплює кілька випадків; два з них є найважливішими для циклів агентів. Перша причина свідчить про те, що модель вважає свою роботу завершеною:
"stop_reason": "end_turn"
Друга причина свідчить про те, що модель хоче викликати інструмент та продовжити роботу:
"stop_reason": "tool_use"
Цикл агента — це звичайний код додатку. Він надсилає запит, виконує будь-який інструмент, про який просить модель, надсилає результат назад та повторює цей процес, поки модель не поверне значення end_turn. Ніщо ззовні моделі не оголошує про завершення завдання. На кожному кроці модель сама здійснює цей виклик, оцінюючи, чи завершено роботу, яка перед нею. Існують ще причини зупинки, наприклад, досягнення ліміту токенів виводу, але це перерви, а не сигнали про завершення роботи.
Саме цей факт пояснює всю невдачу. Коли ціль занадто розпливчата, щоб модель могла визначити, що до неї досягнуто, завжди існує ще щось, що варто перевірити, і цикл триває доти, доки не втрутиться щось ззовні — зазвичай попередження про бюджет. Щодо детального розгляду проектування циклів на рівні коду, дивіться обмежені агентні цикли та надійні шаблони TypeScript для використання з інструментами LLM.
Наскільки це поширено
Хочеться вважати це просто особливістю певного інструменту. Однак більше доказів свідчать про інше. Дослідження RAND Corporation, засноване на інтерв’ю з 65 досвідченими фахівцями з обробки даних та інженерами, показує, що рівень невдач у проектах з ШІ становить понад 80 відсотків, що приблизно вдвічі більше, ніж у звичайних IT-проектах. Це дослідження стосується проектів з ШІ в цілому, а не конкретних агентів, проте цикли, які працюють без досягнення результату, є однією з повсякденних причин таких втрат. Їх ніколи не розглядають у ключових доповідях на конференціях; вони з’являються у рахунках-фактурах.
Існують також більш детальні версії цієї історії. часто цитуваний звіт розповідає про один рекурсивний цикл, витрати якого досягли п’ятизначних цифр ще до того, як хтось втрутився. Цю цифру не підтверджено незалежно, і будь-яка подібна вражаюча цифра заслуговує на скептицизм. Однак механізм справжній, і він лише зростає: той самий цикл, який витрачає 40 доларів за один полудень, може витратити 4 000 протягом непильнованих вихідних.
Де накопичуються витрати
Якщо розглянути неконтрольовані витрати та порівняти їх з даними, які надають оператори великих флотів агентів, то гроші, як правило, накопичуються в кількох однакових місцях:
- Нескінченне пошукове дослідження в Інтернеті. Кожна завантажена сторінка та кожен повторний пошук мають свою вартість. Без обмежень дослідження триває, поки модель вважає, що може існувати ще якийсь корисний джерело інформації.
- Дорога модель для простих завдань. Моделі Frontier коштують дорожче, тому що вони краще міркують, але багато кроків агента, таких як переформатування файлу, перевірка статусу чи повторна спроба зв’язку, не вимагають таких можливостей. Менша модель зможе виконати їх за значно нижчу ціну.
- Теми, які ніколи не закінчуються. Агент, який працює в межах однієї довгої розмови, щоразу перепроцесовує всю накопичену історію, через що тема, яка існує вже кілька тижнів, коштує дорожче за кожен запит, навіть якщо цей запит дуже простий. Кешування запитів може полегшити ситуацію, якщо це підтримується вашим постачальником, але контекст все одно зростає.
Жоден з цих факторів не є чимось екзотичним. Разом вони діють як забута підписка, яка бере оплату за кожен токен замість щомісячної оплати. Щоб краще зрозуміти, як ці витрати накопичуються, у статті чому витрати на агентський ШІ стрімко зростають наведено більш детальний аналіз.
Виправте умову зупинки, а не верхню межу
Після дорогого запуску інстинктивною реакцією є підвищення лімітів кроків чи витрат. Це зазвичай має зворотний ефект, адже вища верхня межа дозволяє тій самій застряглій петлі працювати довше, перш ніж вона зіткнеться з нею. Насправді допомагає надати петлі можливість помічати, що прогрес зупинився, що є іншим питанням, ніж те, чи використала вона свою кількість кроків.
Розмістіть лінію фінішу в меті
Визначте поняття „готово“ як частину завдання, а не як щось, що додається пізніше. Інструкція на кшталт „виправте несправний тест“ залишає простір для додаткових завдань, таких як впорядкування імпортів чи переформатування всього файлу. „Зробіть цей один тест працездатним, а потім закінчуйте“ надає чітку мету, яку модель може розпізнати. Чим більш очевидним є критерій завершення, тим легше моделі повернути end_turn у правильний момент.
Зробіть результати інструментів однозначними
Зворотний зв’язок від інструменту має чітко вказувати, чи успішно була виконана дія чи ні. Неоднозначний результат сприймається агентом як заклик до повторної спроби, а не як сигнал про зупинку. Чіткі поля статусу та зрозумілі повідомлення про помилки усувають невизначеність, яка спонукає до повторних спроб.
Виявляйте повторення замість підрахунку кроків
Фіксований лічильник кроків є грубим інструментом. Той самий лічильник може перервати коректну роботу, яка вимагає 15 кроків, на 11-му кроці, водночас дозволяючи циклу з 2 кроками витратити кілька додаткових, дорогих викликів, перш ніж він буде завершений. Набагато кращим сигналом є повторення: фіксування послідовних викликів одного інструменту з ідентичними аргументами дозволяє безпосередньо виявити описану раніше закономірність, не караючи за ті завдання, які просто є довгими.
Додайте людський контрольний пункт та захист від надмірних витрат
Будь-яка робота, яку залишають без нагляду на кілька хвилин чи більше, має передбачати момент, коли людина перевіряє прогрес виконання. Автоматизовані механізми контролю допомагають у цьому. Наприклад, gh-aw від GitHub пропонує інструмент контролю витрат, який можна налаштувати так, щоб зупинити робочий процес у момент, коли його витрати перевищують встановлений ліміт, замість того щоб залишати перевірку на тому, хто читає рахунок-фактуру. Такий механізм є запобіжним засобом, а не заміною належних умов зупинки, проте він обмежує збитки у разі провалу інших заходів.
Активність — це не прогрес
Найбільш тривожною частиною неконтрольованого виконання роботи є не сама вартість, а впевненість у правильності дій. Результати роботи агента ніколи не містять застережень чи визнання невизначеності щодо того, чи допомагає якась з дій у досягненні мети. Він генерує логічні кроки виконання, поки щось ззовні — часто людина, яка зацікавилась несподіваним рахунком — не зупинить його.
Урок полягає не у тому, щоб повністю не довіряти агентам. Він полягає у тому, щоб перестати плутати рух із прогресом — як у автоматизованих системах, так і в багатьох людських завданнях.
Ключові висновки
- У циклі виклику інструментів модель сама вирішує, коли завершити роботу, повертаючи
end_turn; якщо у завданні немає чітко визначеної кінцевої точки, вона може цього ніколи не зробити. - Неконтрольовані витрати концентруються у необмежених дослідженнях, надто великих моделях для простих кроків, постійно зростаючих завданнях та забутих запланованих операціях.
- Підвищення бюджету чи лімітів кроків лише відкладає ту саму проблему; краще чітко визначити завершення завдання безпосередньо в його описі.
- Необхідно повертати однозначні результати використання інструментів та виявляти повторні однакові виклики, замість того щоб покладатися на кількість кроків.
- Для автономних виконань слід поєднувати людські контрольні точки з жорсткими обмеженнями витрат.
Пов’язана література
- AI Agents проти Agentic AI: Практичний план впровадження в корпораціях — Дізнайтеся, як відрізняти AI-агенти від систем Agentic AI, та як застосувати структуровану схему для вибору шляхів впровадження, керування ризиками та планування майбутньої архітектури.
- Chatbot проти AI Agent: Що насправді їх розділяє окрім LLM — Дізнайтеся, чому справжня різниця між чат-ботами та AI-агентами полягає у архітектурі навколишньої системи — інструментах, плануванні та діях — а не в самому LLM.