Пайплайн зелёный, evals зелёные, ревью закрыто, а пользователь всё равно получил неправильный ответ от AI-агента. Это главный нерв материала The New Stack: трассировка AI-агентов становится не красивым дополнением к observability, а способом понять, что реально произошло между запросом, инструментами, контекстом и финальным ответом.
Повод выглядит знакомо любому инженеру, который хоть раз выпускал изменение в прод: diff показывает намерение разработчика, но не доказывает, что система поведёт себя правильно в живом сценарии. Для классического кода это давно очевидно: тесты проверяют выбранные случаи, CI подтверждает сборку и набор контрактов, ревью снижает риск. Но в агентных системах появляется слой, который плохо укладывается в привычный diff: модель выбирает шаги, вызывает инструменты, интерпретирует промежуточные данные и может уверенно прийти к неверному выводу.
В статье речь не о том, что CI внезапно стал бесполезен. Проблема тоньше и неприятнее: привычные проверки фиксируют лишь часть поведения. Если AI-агент прошёл заранее подготовленные evals, это ещё не значит, что он корректно обработает новый контекст клиента, не перепутает состояние, не подхватит лишний документ, не выберет неверный инструмент и не выдаст ответ, который формально звучит убедительно, но по делу ошибочен.
Для разработчиков это сдвиг от вопроса «прошли ли тесты?» к вопросу «можем ли мы восстановить ход рассуждения и действий системы?». Трассировка AI-агентов здесь работает как журнал полёта: какие сообщения попали в контекст, какой prompt использовался, какие tool calls были сделаны, какие результаты вернулись, где модель изменила план, на каком шаге появилась ошибка. Без такого следа команда видит только финальный ответ и начинает гадать, что сломалось: код, данные, retrieval, prompt, модель или всё вместе.
Контекст у этой темы простой: компании всё активнее переносят агентов из демо в рабочие процессы. Они отвечают клиентам, помогают саппорту, пишут код, ищут документы, заполняют CRM, запускают внутренние операции. Чем ближе агент к реальному бизнес-процессу, тем дороже ошибка. Неправильный ответ уже не просто плохой benchmark score, а тикет, потерянная сделка, неверная рекомендация инженеру или лишний ручной контроль со стороны команды.
Отдельная боль — evals. Их часто воспринимают как аналог unit-тестов для LLM-систем, но это скорее контрольные вопросы на выбранной выборке. Они полезны, когда помогают ловить регрессии, сравнивать версии prompt и моделей, проверять критические сценарии. Но evals редко покрывают всю комбинацию пользовательских запросов, состояния продукта, прав доступа, внешних API и ошибок данных. Поэтому фраза «прошло evals» в агентной разработке звучит примерно как «на моей машине работало», только дороже и убедительнее.
Для бизнеса вывод тоже не самый уютный. Если команда внедряет AI-агента в поддержку, продажи, аналитику или разработку, ей нужен не только показатель точности на тестовой выборке. Нужны процедуры расследования инцидентов: как быстро понять, почему агент ответил неверно, можно ли воспроизвести цепочку, кто владелец ошибки, какие изменения выкатывались рядом, затронуло ли это других пользователей. Без этого AI-проект легко превращается в чёрный ящик с красивым интерфейсом и нервным продактом рядом.
Для инженерных команд это означает новую дисциплину на стыке AI engineering и observability. Логи должны перестать быть свалкой строк, а traces — стать продуктовым инструментом: пригодным для отладки, аудита, сравнения версий и обучения команды. Особенно это важно там, где агент не просто отвечает текстом, а действует: вызывает API, меняет данные, создаёт задачи, запускает workflow. Ошибка в таком сценарии уже имеет побочные эффекты, и «модель так решила» не годится даже как внутренняя шутка.
Главный тренд выглядит так: проверка AI-систем смещается от статического контроля изменений к наблюдаемости поведения в рантайме. CI и evals останутся обязательными, но перестанут быть последним словом перед релизом. Следующий уровень зрелости — трассировка AI-агентов, которая позволяет не верить зелёной галочке, а разбирать конкретную цепочку решений. И чем больше автономии получают агенты, тем меньше у команд права выпускать их без такого чёрного ящика наоборот — прозрачного, подробного и пригодного для неприятных разговоров после продакшен-инцидента.