Чому штучні інтелектуальні агенти для виробництва зазнають непомітних невдач та як виявити неправильні відповіді
Дослідження дванадцяти штучних інтелектуальних агентів для виробництва показує, чому правдоподібний неправильний результат є справжньою причиною невдачі, та які правила проектування зробили успішні рішення корисними.
Найнебезпечнішою проблемою під час роботи ШІ-агента є не збій чи перевищення тайм-ауту. Це відповідь, яка здається правильною, проходить усі перевірки стану та водночас є неправильною. У наведеному нижче кейс-стаді виводиться історія невеликої програмної компанії, яка протягом одного кварталу запустила у експлуатацію дванадцять агентів, але зберегла лише три; у ньому пояснюється, що відрізняло тих, хто вижив, від решти, щоб ви могли розробити систему виявлення проблем перед їх впровадженням.
Команда, інструменти та основні правила
Це була B2B-компанія з програмними послугами, яка налічувала близько сорока співробітників, зокрема дев’ятьох інженерів; це не була науково-дослідна лабораторія. З 6 січня по 27 березня 2026 року команда запустила дванадцять агентів. Ті, що працювали у репозиторії коду, функціонували на Claude Code; інші були спеціально створеними агентами на основі API Anthropic та розміщувалися за допомогою невеликого внутрішнього сервісу, тож кожен агент мав спільний журнал аудиту та єдиний механізм вимкнення.
З першого дня було застосовано два правила, і обидва виявилися корисними:
- Кожен агент записує кожну дію у канал аудиту, включаючи дії з правом лише на читання.
- Будь-хто з команди може вимкнути будь-який агент у будь-який час, без схвалення та без заявки.
Успіх визначався досить вимогливо. Агент вважався успішним лише тоді, коли продовжував працювати після тридцяти днів, і хтось виступав проти його вимкнення. Показники використання легко завищуються через новизну; людей, які захищають інструмент, від якого залежать, набагато складніше підробити.
Звіт: три агента продовжують працювати, дев’ять вимкнено
Наприкінці кварталу все ще працювали три агента:
- автор описів запитів на зміни
- асистент з підготовки заявок для сортування
- збирач інформації про інциденти
Дев’ять з них було вимкнено протягом місяця: автоматичний переглядач коду, система для відповідей на запитання з аналітики, бот для оновлення залежностей, інструмент для ізоляції нестабільних тестів, система для відповідей на електронні листи клієнтів, перетворювач нотаток зустрічей у тикети, оновлювач документації в wiki, система для реагування на аномалії в журналах та інструмент для публікації списку змін.
Попереджувальне правило, яке не допомогло
Як і більшість команд, ця також почала з попереджувального правила, вбудованого у системні інструкції кожного агента, яке змушувало модель визнавати свою невпевненість, уникати неперевірених значень та посилатися на джерело кожної цифри:
If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.
На практиці ця інструкція майже не мала ефекту, і причина цього є найважливішим уроком усього експерименту. Це детально розглядається у наведеній нижче аналізі невдачі.
Дозволи також були надані обережно: на початку кожен агент мав лише право на читання. Протягом кварталу чотирьом агентам надали право на запис. Три з цих чотирьох згодом були вимкнені.
Що мали спільного агенти, які залишилися
Автор опису запиту на зміни
Цей агент, який працював у Claude Code, міг читати відмінності та пов’язану проблему, а потім писати опис у тілі запиту на зміни. Інженер редагував цей опис та об’єднував зміни. Він обробляв приблизно 35 запитів на тиждень, і описи виявлялися кращими, ніж ті, які писали інженери вручну, головним чином тому, що втомлений розробник наприкінці дня схильний писати „виправити баг“, тоді як агент не втомлюється.
Складач описів для сортування підтримки
Цей агент читав кожен надісланий заявку, присвоював їй мітку та складав варіант відповіді у вигляді внутрішньої записки всередині системи підтримки. Він не мав можливості нічого надсилати. Приблизно 60% його проєктів відправлялися після незначної редагування, а середній час першої відповіді зменшився з трохи більше чотирьох годин до приблизно вісімдесяти хвилин.
Збиральник контексту інциденту
Кожного разу, коли сповіщення викликало когось, цей агент публікував у каналі інциденту рівно одне повідомлення з трьома найновішими оновленнями з часовими позначками, зміною коефіцієнта помилок за кожним сервісом та посиланнями на подібні інциденти за попередні дев’яносто днів. Він не вживав жодних дій та не пропонував діагнозу; він просто збирав панелі керування та посилання, які інженер у режимі чергування інакше б відкрив вручну. Це був найпростіший агент, якого створила команда, і водночас той, якого команда цінувала найбільше.
Анатомія агента, який впевнено робить помилки
На папері агент аналітики був найкраще розробленим із дванадцяти. Він мав доступ до копії даних для читання, ручно написаного документа зі схемою в своєму контексті та інтерфейсу Slack; його завданням було відповідати на запитання щодо показників, щоб команда з обробки даних більше не переривалася двадцять разів на день.
3 лютого хтось запитав його про тижневий дохід. Він сформував запит, який поєднував замовлення з оплатами, причому при цьому рядки про повернення грошей вважалися позитивними сумами. Результат виявився приблизно на 12% завищеним, проте цілком правдоподібним: величина була правильною, тенденція з тижня в тиждень також була правильною, а навіть сезонний спад після закінчення акції у січні був помітний.
Ця завищена цифра з’явилась у пості з показниками за понеділок, а потім і у наступних двох постах за понеділок. Помилка проявилась лише 24 лютого під час закриття звіту за січень, коли загальна сума від фінансової команди та загальна сума від агента не збігалися.
Замисліться над тим, чого не сталося протягом цих трьох тижнів. Не було жодних винятків, жодних попереджень та жодного сплеску затримок. SQL-запит був коректним, дані поверталися, і агент наводив джерело саме так, як це вимагалося. Традиційний моніторинг існує для виявлення систем, які перестають працювати, а ця система ніколи не зупинялась.
Саме тут ламається механізм підказок щодо захисних бар’єрів. Інструкція казати „Я не знаю“, коли є сумніви, працює лише тоді, коли у моделі є внутрішній сигнал її власної невпевненості. Тут модель не була невпевнена — вона просто помилилась. Ззовні впевнена помилка нерозрізнима від правильної відповіді, тому підказки не можуть її виокремити.
Випливає корисний загальний висновок: об’єднання даних, яке тихо змінює знак чи кількість рядків, є класичною помилкою в аналітиці навіть для людей. Різниця полягає у тому, що людський аналітик зазвичай усвідомлює, які числа будуть перевірятися у фінансах, тоді як агент не має інтересу до узгодження даних, якщо ви для нього це не налаштуєте.
Коли правильного агента ігнорують
Автоматичний переглядач коду зазнав невдачі у спосіб, якого багато команд не очікували: він не помилявся. Кожен запит на об’єднання коду отримував близько 40 коментарів; більшість з них мали підстави, а чимало були дріб’язковими зауваженнями щодо найменувань чи стилю обробки помилок.
Протягом трьох тижнів інженери почали вирішувати його коментарі, навіть не читаючи їх. Потім він виявив справді серйозну проблему — запит без фільтра користувача, і цей коментар загубився серед 38 зауважень щодо стилю. Людина знайшла баг два дні пізніше. Переглядач мав рацію, але надмірна кількість коментарів затьмарила його сигнал.
Чому дев’ять систем було закрито
Причини невдач були чітко розподілені:
- шість систем давали впевнені, але неправильні результати
- дві системи давали результати, які ніхто не читав
- одну систему вимкнули, тому що ніхто не міг зрозуміти, чи вона взагалі щось робить
Правило проектування: зупиняйтесь на крок раніше, ніж людина вчинить дію
Три залишені в експлуатації агента мають одну спільну рису, і це не модель, запит чи фреймворк. Кожен з них зупиняється на крок перед людською дією. Вони створюють чернетку, короткий опис чи набір контексту, а людина виконує останній крок. Виконання цього кроку змушує людину прочитати отриманий результат.
Кожен агент, який було припинено в роботі, або діяв самостійно, або створював результати, які перетворювалися на дії без належної перевірки. Показовим прикладом є аналітичний агент: у нього зовсім не було прав на запис, проте його рекомендації потрапляли безпосередньо до бізнес-рішень через людей, які йому довіряли.
Отримана межа є простою. Дозвольте агентам збирати матеріали; не дозволяйте їм контролювати останній крок, коли помилка може мати серйозні наслідки.
Ця межа не є оцінкою можливостей моделі, і потужніша модель її не прибере. Йдеться про виявлення. Типовою проблемою агента є правдоподібна відповідь замість збою, і більшість команд має дуже обмежені інструменти для виявлення неправильних, але правдоподібних відповідей.
Витрати ніколи не були проблемою. Усі дванадцять агентів разом спожили трохи менше 900 доларів на токени за квартал. Обмеженим ресурсом була увага людини.
Три зміни, які ви можете здійснити цього тижня
- Перед розгортанням описайте, як можна виявити впевнену неправильну відповідь. Не те, як ви помітите збій, а те, як будете знати, що результат неправильний. Якщо ви не можете написати це речення, агент повинен лише скласти проєкт, а не діяти.
Звірте число з другим джерелом
Порівняйте цифру агента з бухгалтерською книгою і зупиніться, якщо розрив більший за пів відсотка або одну грошову одиницю.
const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
const delta = Math.abs(agentRevenue - ledgerRevenue);
const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
return { ok: delta <= tolerance, delta };
};Запускайте порівняння за розкладом. Монітор падінь лишиться зеленим, а ця перевірка покличе людину.
Ключові висновки
- Ймовірні неправильні результати, а не перерви у роботі, є основним типом збоїв, на які потрібно проектувати систему; стандартний моніторинг їх не виявить.
- Інструкції щодо рівня впевненості не можуть виявити помилки, про які модель не знає.
- Доступ лише для читання — це не те саме, що безневинність: результати, які впливають на прийняття рішень, фактично є дією.
- Обсяг даних є самостійним способом виникнення проблем; правильний сигнал, загублений у шумі, не має жодної цінності.
- Корисним тестом для будь-якого агента є запитання: чи буде хтось проти, якщо його вимкнути завтра.