Агенти ламаються після дрібних змін
Розробник на Reddit описав типову проблему в AI Agents: у минулому проєкті команда витрачала години щотижня на ручну перевірку запусків агентів. Навіть невеликі зміни моделі або контексту могли непомітно зламати downstream tool calling — вибір інструмента, параметри запиту чи відновлення після помилки API.
Звичайні unit-тести тут погано працюють, бо LLM недетерміновані. А багато eval-фреймворків оцінюють лише фінальну текстову відповідь, не перевіряючи проміжну траєкторію викликів інструментів. Тому питання зміщується до регресійного тестування агентів у CI/CD, зокрема GitHub Actions або GitLab.
Що це означає для бізнесу: якщо агент працює з API, CRM, платежами чи внутрішніми системами, тестувати треба не тільки відповідь, а весь ланцюг дій до продакшену.
Що саме перевіряли вручну
Першоджерело — допис користувача Reddit /u/JuniorLeg6988 про досвід у попередньому проєкті. Автор не називає компанію, продукт або галузь, тому цей випадок не можна подавати як кількісне дослідження ринку. Це опис практичної проблеми однієї команди: після невеликих змін моделі або контексту вона щотижня витрачала години на ручну вибіркову перевірку запусків агентів.
Причиною перевірок були тихі збої на наступних етапах роботи з інструментами. Фінальна відповідь могла не показати, де саме виникла регресія. Автор виділяє три окремі об’єкти контролю:
- чи обрав агент правильний інструмент;
- чи передав коректні параметри;
- чи зміг відновити роботу після помилки API.
Чому оцінки кінцевої відповіді недостатньо
За спостереженням автора, традиційні unit-тести погано відповідають недетермінованій природі LLM. Водночас більшість eval-фреймворків, про які йдеться в дописі, оцінюють кінцевий текст, а не проміжну траєкторію викликів інструментів. Тому після зміни промпта, моделі або контексту окрема дія агента може працювати неправильно, навіть якщо перевіряється лише фінальна відповідь.
Йдеться не про доведений універсальний недолік усіх систем оцінювання, а про проблему, сформульовану одним розробником на основі досвіду попереднього проєкту. У джерелі немає результатів тестів, порівняння фреймворків або даних про частоту конкретних типів помилок.
Яке рішення лише розробляється
Автор повідомляє, що працює над інструментами для автоматизованого регресійного тестування агентів і детермінованої валідації викликів інструментів у CI/CD. Але допис не є анонсом готового продукту: у ньому немає назви, опису функцій, посилання на документацію чи репозиторій, дати запуску та умов доступу.
GitHub Actions і GitLab згадані як варіанти, про які автор запитує спільноту, а не як уже підтверджені інтеграції. Так само джерело не стверджує, що автоматизація вже замінила ручний QA: автор з’ясовує, чи запускають інші команди такі тести в CI/CD, чи перевірка досі переважно ручна та ситуативна.
Що це означає для команд зараз
Практичний висновок джерела обмежений постановкою задачі: перед випуском оновлення слід виявляти, чи не зламало воно tool calling агента. Перевірка має охоплювати не лише текстовий результат, а й послідовність проміжних дій. Конкретної методики, набору тестів або готової схеми впровадження автор не наводить.
Поки залишаються без відповіді ключові питання:
- який саме інструмент створюється і коли він стане доступним;
- які моделі, API та середовища CI/CD він підтримуватиме;
- як визначатиметься допустима варіативність недетермінованого агента;
- скільки коштуватиме рішення та за яких умов ним можна буде користуватися;
- наскільки підхід скорочує час ручних перевірок і кількість регресій у продакшені.