ШІ-агент може зламати все однією дією – Microsoft навчилася знаходити цей момент

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

Microsoft Research розробила для цього AgentRx – систему діагностики збоїв ШІ-агентів. Вона аналізує траєкторію виконання завдання крок за кроком і намагається визначити critical failure step – першу критичну помилку, після якої агент уже не може нормально завершити поставлене завдання.

Дослідники Microsoft Research створили benchmark із 115 вручну розмічених невдалих траєкторій у трьох різних середовищах і сформували дев'ять категорій помилок ШІ-агентів.

Результат показує, наскільки серйозною стає проблема в міру переходу ШІ від розмови до реальних дій. AgentRx покращив точність локалізації помилки на 23,6% в абсолютному вираженні та визначення першопричини на 22,9% порівняно з prompting-базовими підходами.

Що таке AgentRx від Microsoft

AgentRx – це автоматизована система діагностики, яка аналізує невдале виконання завдання ШІ-агентом і намагається визначити перший критичний крок, що призвів до провалу. Microsoft розшифровує назву як Agent Diagnosis.

Система не просто отримує фінальний результат і намагається вгадати, що могло піти не так. AgentRx аналізує execution trajectory – послідовність дій, інструментів, відповідей і проміжних рішень агента.

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

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

Чому помилки ШІ-агентів так складно знаходити

Помилки ШІ-агентів складно діагностувати через три особливості таких систем: довгі траєкторії, ймовірнісну поведінку та взаємодію кількох агентів або інструментів. Microsoft Research прямо називає ці фактори серед причин, через які root cause може загубитися всередині виконання.

ШІ-агент може виконувати десятки дій протягом одного завдання. Частина з них буде правильною, частина може містити дрібні неточності, а деякі помилки система здатна виправити самостійно.

Тому остання неправильна дія не обов'язково є справжньою причиною провалу. Критична помилка могла статися значно раніше.

Додаткова складність виникає через probabilistic, тобто ймовірнісну поведінку ШІ. Однакове завдання не обов'язково щоразу породжує абсолютно однакову послідовність дій.

На Gosta вже детально розібрано, чому ШІ відповідає по-різному на те саме і чому ця проблема стає особливо важливою саме для агентів: https://gosta.ua/tekhnolohii/chomu-shi-vidpovidaye-po-riznomu-na-te-same-microsoft-znayshla-prychynu/

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

Що Microsoft називає критичною помилкою ШІ-агента

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

Це важлива різниця. У довгому завданні агент може припуститися кількох помилок, але не кожна з них обов'язково призведе до провалу.

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

AgentRx цікавить не просто список усіх відхилень. Його головна задача – знайти перший critical failure step, після якого правильне завершення конкретної траєкторії вже стає неможливим.

Як AgentRx знаходить момент, коли ШІ-агент помилився

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

Microsoft побудувала процес так, щоб система не покладалася лише на припущення однієї мовної моделі.

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

Які правила AgentRx перевіряє під час роботи

AgentRx створює executable constraints – правила, які можна перевірити на конкретних етапах траєкторії. Вони формуються на основі схем доступних інструментів і політик середовища.

Простий приклад із документації Microsoft – API має повернути коректну JSON-відповідь. Інший тип правила може вимагати, щоб агент не видаляв дані без підтвердження користувача.

При цьому правило не повинно застосовуватися там, де воно не має сенсу. Тому Microsoft використовує guarded evaluation: перевірка запускається лише тоді, коли виконана відповідна умова.

У результаті AgentRx створює validation log – журнал порушень із доказами. Уже після цього LLM-judge використовує журнал та розроблену Microsoft класифікацію помилок, щоб визначити critical failure step.

Які 9 помилок можуть робити ШІ-агенти

Microsoft Research сформувала дев'ять категорій збоїв на основі аналізу реальних невдалих траєкторій у benchmark. Вони показують, що проблема ШІ-агентів значно ширша за звичайні "галюцинації".

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

Чому ШІ-агент може виконати майже все правильно і все одно провалити завдання

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

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

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

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

На яких завданнях Microsoft перевіряла AgentRx

Microsoft створила AgentRx Benchmark із 115 вручну розмічених невдалих траєкторій. Вони охоплюють три різні типи середовищ – структуровані API-процеси, управління реальними інцидентами та відкриті завдання з вебом і файлами.

Для benchmark використані τ-bench, Flash і Magentic-One.

Різноманітність тут принципова. AgentRx задуманий як domain-agnostic framework, тобто система, яка не повинна працювати лише з одним конкретним агентом або одним типом задач.

Водночас 115 невдалих траєкторій не означають, що Microsoft перевірила AgentRx на всіх можливих сценаріях використання ШІ-агентів. Результати потрібно трактувати в межах середовищ і методики, описаних авторами.

Наскільки точно AgentRx знаходить помилки ШІ-агентів

У тестах AgentRx перевершив LLM-based prompting baselines за двома основними показниками. Microsoft повідомляє про +23,6% абсолютного покращення точності локалізації помилки та +22,9% покращення визначення першопричини.

Перша метрика відповідає на питання "де саме сталася критична помилка". Друга – "до якого типу належить причина провалу".

Це різні завдання. Можна правильно знайти проблемний крок, але неправильно пояснити його природу.

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

Саме поєднання локалізації та root-cause attribution робить AgentRx цікавішим за просту перевірку фінального результату.

Чому 115 невдалих траєкторій важливі

115 траєкторій – це не 115 окремих неправильних відповідей чат-бота. Кожна траєкторія містить послідовність кроків, які агент виконував до провалу.

Дослідники вручну розмітили їх, вказавши critical failure step та категорію помилки. Це дозволило створити еталон, із яким можна порівнювати автоматичну діагностику.

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

Microsoft також відкрила benchmark разом із AgentRx. Тому його можна використовувати для подальших досліджень діагностики ШІ-агентів.

Чим ШІ-агент відрізняється від звичайного чат-бота

Головна відмінність ШІ-агента – здатність не лише генерувати відповідь, а й виконувати послідовність дій за допомогою доступних інструментів. Саме ця автономність робить проблему AgentRx актуальною для звичайних користувачів.

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

На Gosta вже розібрано показовий приклад такого переходу – OpenAI Dots, які можуть працювати за користувача 24/7 без постійних промптів: https://gosta.ua/tekhnolohii/openai-zapustyla-dots-shi-pratsyuye-za-vas-24-7-bez-postiynykh-promptiv/

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

Чи може ШІ-агент сам зрозуміти, що він помилився

Іноді агент може помітити проблему й скоригувати наступні кроки, але AgentRx створений саме тому, що покладатися на таке самовиправлення недостатньо. У складній траєкторії система може не розпізнати власну критичну помилку.

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

З технічного погляду виклик пройшов успішно. З погляду подальшого рішення траєкторія вже пішла неправильним шляхом.

Інший варіант – агент вигадує інформацію, якої не було у trace або tool output. Якщо наступні дії будуються вже на вигаданому факті, проблема може поширитися на весь подальший процес.

Чому галюцинація ШІ-агента небезпечніша за помилку чат-бота

Галюцинація чат-бота може залишитися неправильною фразою на екрані. Галюцинація ШІ-агента потенційно може стати вхідними даними для наступної реальної дії.

Саме категорія Invention of New Information входить до дев'яти типів збоїв AgentRx. Йдеться про ситуацію, коли агент використовує факт, який не підтверджується траєкторією або результатом інструмента.

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

Перехід від "ШІ говорить" до "ШІ діє" змінює ціну помилки. Саме тому діагностика траєкторії стає окремою технічною задачею.

Чи може AgentRx запобігти помилці до того, як вона сталася

AgentRx у представленій роботі насамперед діагностує вже невдалу траєкторію. Його головна задача – визначити критичний крок та першопричину після того, як виконання завершилося провалом.

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

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

Це може допомогти виправляти самих агентів, інструменти, правила та orchestration. Але AgentRx не робить будь-якого ШІ-агента автоматично безпомилковим.

Чи може AgentRx виправити ШІ-агента

AgentRx – насамперед діагностична система, а не оголошена Microsoft універсальна функція автоматичного ремонту агентів. Вона знаходить критичну помилку та класифікує її причину.

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

Microsoft Research окремо працює над напрямом reliable and self-repairing agents, де діагностика може бути частиною ширшого циклу diagnosis-to-repair. Але результати AgentRx не слід автоматично трактувати як доказ того, що система сама виправляє будь-який знайдений збій.

AgentRx відповідає передусім на питання "де і чому все пішло не так". Наступне питання – як виправити проблему так, щоб вона не повторилася.

Що означає AgentRx для звичайного користувача

Для звичайного користувача AgentRx важливий не як нова кнопка Microsoft, а як відповідь на проблему, яка ставатиме помітнішою разом із поширенням автономних агентів. Чим більше дій людина передає ШІ, тим важливіше розуміти, чому він іноді не виконує доручення правильно.

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

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

Для користувача всі ці випадки виглядають однаково – "ШІ не впорався". Для розробника це п'ять різних проблем, які потребують різних способів виправлення.

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

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

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

Саме тому taxonomy AgentRx окремо містить System Failure та Guardrails Triggered. Вони дозволяють не записувати кожний невдалий результат у "ШІ погано міркує".

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

Чому AgentRx важливий для майбутнього ChatGPT, Copilot та інших агентів

AgentRx не оголошений функцією ChatGPT, Microsoft Copilot чи іншого конкретного масового чат-бота. Але проблема, яку він вирішує, безпосередньо стосується розвитку всієї категорії автономних ШІ-систем.

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

Цей напрям уже добре видно за головними анонсами OpenAI DevDay 2026, де значна частина нових можливостей пов'язана саме з агентами, інструментами та автоматизацією: https://gosta.ua/tekhnolohii/openai-rozkryla-holovne-na-devday-2026-ponad-20-velykykh-anonsiv/

У такому світі важливим стає не лише питання "наскільки розумна модель". Не менш важливо, чи можна відтворити її роботу, знайти помилку, пояснити причину провалу й перевірити, що проблема справді виправлена.

Чи означає AgentRx, що ШІ-агентам можна довіряти більше

Сам факт існування AgentRx не робить ШІ-агентів надійними автоматично. Система діагностики та система, яка виконує завдання, вирішують різні проблеми.

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

Але користувачеві все одно не варто автоматично передавати автономному ШІ незворотні або критичні дії лише тому, що існують інструменти для аналізу помилок.

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

Як зменшити ризик помилки ШІ-агента

Для звичайного користувача найкращий захист – не намагатися самостійно діагностувати траєкторію за методикою AgentRx, а правильно визначати межі автономності агента. Чим серйозніші наслідки дії, тим важливішою стає контрольна точка з підтвердженням людини.

Перед передачею складного завдання ШІ-агенту корисно:

1. Чітко сформулювати кінцеву мету.

2. Вказати важливі обмеження.

3. Не надавати більше доступів, ніж потрібно для задачі.

4. Вимагати підтвердження перед незворотними діями.

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

6. Не покладатися на агента як на єдине джерело критично важливої інформації.

7. Зберігати можливість зупинити або скасувати процес там, де це підтримується.

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

Чому AgentRx і дослідження LLM-42 доповнюють одне одного

AgentRx і LLM-42 вирішують різні проблеми, але обидві стають важливішими саме через розвиток ШІ-агентів. AgentRx шукає критичну помилку в траєкторії, а LLM-42 досліджує проблему відтворюваності роботи мовних моделей.

На Gosta вже є окремий матеріал про LLM-42 – Microsoft знайшла системну причину, чому ШІ може відповідати по-різному на однаковий запит: https://gosta.ua/tekhnolohii/chomu-shi-vidpovidaye-po-riznomu-na-te-same-microsoft-znayshla-prychynu/

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

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

Чи можна вже встановити AgentRx

AgentRx не є звичайною програмою Microsoft для кінцевого користувача й не з'являється як нова функція Windows або Copilot. Це дослідницький framework для діагностики агентних систем.

Microsoft Research відкрила код AgentRx та повний анотований benchmark. Це дозволяє дослідникам і розробникам використовувати framework для власних агентних workflow та вивчати його методику.

Для пересічного користувача окремо встановлювати AgentRx для ChatGPT або Copilot не потрібно. Microsoft не оголошувала, що AgentRx інтегрований у споживчі версії Copilot або автоматично аналізує помилки звичайних чатів.

Що Microsoft AgentRx змінює в розмові про ШІ-агентів

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

У простого чат-бота користувач бачить відповідь і може одразу помітити очевидну помилку. У довгому агентному workflow причина може бути захована на десятому кроці з п'ятдесяти.

Саме тому Microsoft намагається перейти від ручного пошуку помилок до системної діагностики. У тестах AgentRx дав +23,6% абсолютного покращення локалізації критичного збою та +22,9% покращення визначення його першопричини відносно prompting baselines.

У міру того як ШІ отримує більше автономності, питання "що він уміє?" поступово доповнюється іншим: "чи можна точно зрозуміти, де і чому він помилився?" Для систем, яким люди передають реальні дії, друга частина може виявитися не менш важливою за першу.