Трейсинг AI-агентів: де втрачається контроль над сесією
Агент відповідає клієнту неправильно — і дізнаються про це лише зі скарги.
В інтерфейсі видно фінальний текст, у журналі застосунку — успішну відповідь сервісу, а між ними порожньо: не записано, які кроки виконав агент, які інструменти викликав і на якому проміжному рішенні звернув не туди. Розбір інциденту починається з нуля і часто закінчується фразою «відтворити не вдалося».
Без трейсингу AI-агентів ланцюжок викликів агента не зберігається як єдине ціле. Запит до пошуку пішов з одним формулюванням, у контекст потрапив застарілий документ, модель двічі перепитала саму себе — кожен крок живе у своєму журналі або не живе ніде.
Зіставити їх за часом можна лише вручну, і то якщо збігаються ідентифікатори запиту, яких зазвичай немає.
Звідси два наслідки. Непояснювану відмову неможливо відрізнити від збою зовнішнього сервісу: винні пошук, промпт чи саме формулювання задачі — незрозуміло.
І відтворюваність сесії дорівнює нулю: під час повтору агент відповідає інакше, бо не зафіксовано ні версію промпту, ні склад переданих документів, ні порядок викликів.
Поки ці дані не записуються, будь-яка правка поведінки агента — вгадування: стало краще чи просто пощастило на іншому наборі прикладів.
Далі розбираємо, як це закривається — що саме потрапляє в трасу сесії, як за нею відновлюється ланцюжок і як відрізнити деградацію моделі від помилки в інструменті.
Що дає спостережуваність ланцюжків викликів інструментів
Без трейсингу агентна система поводиться як чорна скринька: користувач отримав неправильну відповідь, усередині — десяток викликів зовнішніх сервісів, і який із них дав збій — незрозуміло. Відтворити ситуацію також не вдається: на тому самому запиті агент може повестися інакше.
Спостережуваність агентних ланцюжків фіксує кожен крок: який інструмент викликано, з якими аргументами, що повернулося, скільки крок тривав і де ланцюжок обірвався.
Розбір інциденту перетворюється на читання однієї траси замість перебору гіпотез за логами різних сервісів — час розбору скорочується з годин до хвилин.
Частка пояснених відмов — друга вимірювана величина. Замість «модель помилилася» з’являється причина: недоступність зовнішнього сервісу, обрізаний контекст, вибір не того інструмента, вичерпаний ліміт кроків. Поки ця частка зростає, команда закриває класи збоїв, а не окремі випадки.
Повторюваність запусків робить результати порівнюваними. Один і той самий набір запитів проганяється на незмінній конфігурації, тому розбіжності пояснюються правками в системі, а не випадковістю — версії до й після зміни порівнюються на одному зрізі.
Звідси виростає контроль якості відповідей: регресійний набір запитів з очікуваними результатами, частка коректних відповідей, кількість кроків на запит.
Правка системної інструкції або підключення нового інструмента перевіряється на наборі до викату — деградація видна заздалегідь.
Трейсинг AI-агентів: порівняння режимів збору даних
Режим збору даних визначає, що взагалі потрапить у трасу, і його обирають до впровадження, а не після першого розбору інциденту. Нижче — варіанти, між якими реально обирають інженерні команди, з їхньою застосовністю та обмеженнями.
| Режим | Коли підходить | Обмеження підходу |
|---|---|---|
| Перехоплення викликів у коді агента | Власний код: є доступ до обгорток навколо моделей, інструментів і звернень до пам'яті | Бачить лише інструментовані ділянки; під час рефакторингу обгортки потрібно підтримувати, інакше кроки випадають із траси |
| Прикордонний шар на периметрі | Закриті та сторонні сервіси: потрібен незалежний слід без правок їхнього коду | Фіксує лише мережевий обмін — внутрішні кроки, стан пам'яті та проміжні рішення залишаються поза журналом |
| Розбір журналів застосунків | Спадщина та сервіси без доступу до коду, де немає іншого джерела | Затримка між дією та записом; зв’язки між кроками відновлюються за здогадками, а правила розбору ламаються зі зміною формату |
По розборах великих збоїв Google SRE понад половина інцидентів пов’язана зі змінами та неповною спостережуваністю — тому на практиці перехоплення викликів і прикордонний шар поєднують: перший дає кроки агента зсередини, другий — незалежну перевірку того, що пішло за периметр.
Розбір журналів залишають як страховку для сервісів, куди інакше не зазирнути, і як друге джерело під час звірки. Головне обмеження будь-якого режиму — неповнота: якщо крок не записано, відновити його постфактум неможливо, тому склад даних фіксують на етапі проєктування траси.
Етапи впровадження: від аудиту сесій до передавання регламентів
Трейсинг AI-агентів не вмикається одним перемикачем: події народжуються в різних місцях — у викликах моделі, зверненнях до інструментів, користувацьких сесіях. Тому впровадження йде етапами, і кожен закінчується артефактом, який можна перевірити.
- Обстеження систем. Інвентаризуємо сервіси, черги та зовнішні виклики, знаходимо місця, де втрачається ідентифікатор сесії. На виході — карта потоків і перелік точок, які потрібно інструментувати.
- Схема збору. Узгоджуємо структуру події: обов’язкові поля, кореляція за ідентифікатором сесії, що семплуємо і що зберігаємо повністю. Окремо вирішуємо, де знеособлюються персональні дані — до запису, а не після.
- Налаштування. Піднімаємо приймач подій, підключаємо агентів та інструменти, задаємо строк зберігання й розмежування доступу. Перевіряємо, що запис не подовжує відповідь агента.
- Перевірка на реальних сценаріях. Проганяємо типові та аварійні ланцюжки: відмова інструмента, таймаут, повторний виклик, петля в міркуванні. Кожен збій має читатися в трейсі повністю, а не фрагментом.
- Розбір інциденту разом із командою. Показуємо, як від аномалії в метриках дійти до конкретного кроку агента за хвилини. Це і є перевірка, що дані придатні для роботи.
- Передавання регламентів. Віддаємо опис полів, правила іменування, політику зберігання та порядок розбору інцидентів. Далі команда веде систему сама, а ми підключаємося зі зміною схеми.
Конфігурація та артефакти, які залишаються у замовника
Передаємо не звіт, а робочу конфігурацію: трейсинг живе у вашому репозиторії та розгортається вашими ж засобами доставки. Інакше за пів року ні інцидент не розібрати, ні деталізацію запису змінити без зовнішньої команди.
- Конфігурації збору. Що агент пише в трейс — виклики інструментів, аргументи, відповіді, розгалуження, помилки; рівень деталізації та правила семплування: частина звернень зберігається повністю, решта — лише метаданими.
- Схема потоків даних. Від виклику агента до сховища: де події записуються, де агрегуються, скільки живуть, що йде в зовнішній контур, а що не залишає ваш.
- Правила доступу. Хто бачить сирі трейси повністю, хто лише агрегати й метрики; облікові записи беруться з вашого каталогу користувачів, окремий список не заводиться.
- Маскування полів. Персональні та чутливі дані вирізаються на етапі збору, до запису, а не чистяться постфактум: що не потрапило в трейс, те неможливо злити.
- Інструкції для команди. Як прочитати трейс і знайти корінь збою, як додати новий крок агента до трасування, як розібрати інцидент за кроками.
- Регламенти та оповіщення. Порогові значення за часткою помилок і часом відповіді, панелі моніторингу та правила оповіщення зберігаються як конфігурація, а не як ручні налаштування в інтерфейсі.
Усе перелічене залишається у вашому контурі, під вашим контролем доступу та з документацією російською: розвивати трейсинг зможе будь-який ваш інженер, а не лише той, хто його впроваджував.
Кейс: розбір інциденту за години замість тижнів
Замовник — продуктова команда з діалоговим агентом, який обробляє звернення клієнтів і сам викликає внутрішні сервіси: білінг, доставку, перевірку залишків.
Вісім діалогів із десяти проходили штатно, але розбір решти перетворювався на ручний перебір логів і листування між підтримкою та розробкою.
Симптоми надходили у вигляді «агент відповів не те» або «замовлення зависло». Відтворити збій вдавалося приблизно в кожному п’ятому випадку: не зберігалося ні вхідних даних, ні послідовності викликів, ні відповідей зовнішніх сервісів.
Локалізація причини займала робочі дні, а підтримка кожне звернення перетворювала на ручну реконструкцію діалогу.
Що змінили
Ми пов’язали кожен крок агента — план, виклик інструмента, відповідь моделі — в єдину трасу та прив’язали її до ідентифікатора звернення.
Сховище трас розгорнули на Langfuse: пошук за діалогом, вхідними параметрами та кодом помилки з’явився одразу, без власного інтерфейсу розбору.
Навколо трас побудували відтворення — інцидент прокручується з тими самими входами на ізольованому контурі, включно із записаними відповідями зовнішніх сервісів.
Метрики до та після
- Частка відтворюваних збоїв: 20% → 85%.
- Час локалізації причини: 2-4 робочі дні → 2-4 години.
- Ручна робота підтримки скоротилася втричі: типові звернення закриваються за трасою, без розробника.
- Ескалацій до інженерів стало менше вчетверо — залишаються тільки ті, де потрібна правка коду або промпту.
Окремо залишили запис невдалих прогонів: новий дефект тепер перевіряється на накопичених трасах як на регресійному наборі, тому повторна поява того самого класу збою видна на етапі викату.
Що робити, якщо система вже працює без контролю?
Працюючу систему не переписують заради спостережуваності. Перший крок — поставити знімання на межах: на вході запиту та на виході відповіді, там, де сервіси вже спілкуються мережею.
Такий посередник фіксує ідентифікатор запиту, вхід, результат і час обробки, не втручаючись у сам обробник, — поведінка системи для користувача залишається незмінною.
Далі обираємо критичні сценарії, а не покриваємо все одразу. Це шляхи, де збій коштує найдорожче: оформлення замовлення, списання, видача документа, звернення до підтримки.
Їх підключаємо першими, решту — у міру того як стабілізується потік даних і налаштовуються правила зберігання.
Увімкнення йде у дві ступені. Спочатку тіньовий режим: події лише записуються й ні на що не впливають — так перевіряємо, що контекст розмічається повністю, а ланцюжок викликів між сервісами не рветься на нештатних гілках.
Потім у збір іде частина трафіку, метрики звіряються з логами застосунку, і частка зростає тільки тоді, коли розходження в межах норми.
Міграція без зупинки: вузли підключаються по одному, перемикач увімкнення живе в конфігурації, а не в коді. Відкат — це вимкнення збору, а не розгортання попередньої збірки; якщо приймач даних недоступний, запити продовжують іти звичайним шляхом.
Порядок дій такий: опис викликів, відбір критичних шляхів, знімання на межах, звірка в тіньовому режимі, розширення охоплення на решту сценаріїв.
Технічні сумніви: зберігання, навантаження, доступ
Збір трасування не має ставати вузьким місцем у діалозі з агентом: ми розводимо гарячий шлях відповіді та запис телеметрії.
Події йдуть у локальний буфер і надсилаються окремим каналом, не блокуючи генерацію; якщо приймач недоступний, буфер переживає перезапуск і надолужує запис пізніше, а діалог продовжується у штатному режимі.
Зберігання історії, знеособлення та доступ описуються політиками, а не правками в коді агента — правила змінюються без перезбирання. Нижче — відповіді на те, що інженерні команди найчастіше уточнюють перед стартом.
Збір даних сповільнить відповіді агента?
Запис асинхронний: подія кладеться в неблокувальний буфер, відправник надсилає їх пакетами поза шляхом відповіді. Окремо заміряємо внесок у відгук на профілі навантаження замовника до промислового запуску — якщо він помітний, правимо конфігурацію, а не миримося.
Як знеособлюються персональні дані?
Маскування йде на боці агента, до запису: імена, контакти та документи замінюються ідентифікаторами за словником відповідностей. Словник зберігається окремо, зі своїми правами та строком життя. У трасі залишається структура діалогу та рішення агента, але не чутливий контент.
Скільки зберігається історія і чи можна змінювати строки?
Строки задаються політиками за класами даних: повні траси з вмістом живуть обмежене вікно, агрегати та метрики якості — довше. Політику змінюють без перезбирання агента, а після закінчення строку дані видаляються автоматично.
Як розмежовується доступ до трас?
Ролі визначають глибину видачі: інженер розбирає повну трасу, аналітик працює з агрегатами, керівник — зі зведеною панеллю. Будь-яке читання траси потрапляє в журнал доступу, чутливі поля приховуються на рівні видачі.
Що якщо збір потрібно призупинити або відкотити політику?
Трейсинг вмикається прапорцем конфігурації: збір вимикається без випуску нової версії агента, агент працює як звичайно, історія просто не пишеться. Відкат — повернення попереднього профілю, уже записані дані залишаються доступними за тими самими правилами.
Обговоримо задачу: схема збору та план впровадження
Щоб порахувати обсяг робіт, нам потрібні вихідні дані щодо вашого агента: які виклики моделей і зовнішніх інструментів він робить, де зараз осідають логи і як вони пов’язані між собою. Без цього схема збору трейсингу вийде умоглядною, а оцінка — приблизною.
На першій зустрічі ми розбираємо потік подій, позначаємо точки, які потрібно інструментувати, і домовляємося, що вважаємо успішним прогоном.
Зі свого боку приносимо чернетку схеми збору: які події фіксуємо, що кладемо в контекст кроку, як пов’язуємо виклики за ідентифікатором сесії, де зберігаємо і як віддаємо в аудит. До неї — план впровадження за етапами, щоб було видно порядок і залежності.
Що корисно підготувати до розмови:
- перелік сценаріїв агента та його зовнішніх викликів — за ними будується карта трасування;
- зразки поточних логів або вивантажень, навіть неповних: за ними видно формат і прогалини;
- вимоги до строку та глибини зберігання: що потрібно для розбору інциденту, а що для звітності;
- ролі та права доступу — хто читає трейси, хто може вивантажувати, хто адмініструє;
- обмеження контуру: закритий периметр, власні сховища, заборона на винесення даних;
- точки інтеграції: черги, сповіщення, системи інцидентів і чергувань;
- критерії приймання — як ви зрозумієте, що прозорість справді з’явилася.
Наступний крок — зустріч на 40–60 хвилин: розбираємо ваші вхідні дані, показуємо чернетку схеми та повертаємося з оцінкою обсягу робіт і планом впровадження за етапами. Опишіть задачу у двох-трьох абзацах — цього вистачить, щоб прийти підготовленими.
