Отладка AI-агентов: ваша панель мониторинга знает стоимость, но не причину

Отладка AI-агентов начинается там, где заканчивается ваша панель observability. Когда AI-агент для написания кода что-то ломает, а запуск уже завершён, панель может сообщить, сколько стоил запуск (токены, доллары, задержка), но промолчит о единственном вопросе, который вас действительно волнует: почему агент изменил этот файл? Артефакт, который даёт ответ, — это записанный трейс, который можно открыть, прочитать и воспроизвести, потому что он возвращает вам запуск целиком, а не описывает его со стороны.

Это перестало быть редким событием в тот момент, когда агенты начали выполнять реальную работу. Агент прочёсывает репозиторий, правит несколько файлов, запускает проверки и сообщает об успехе — и всё это между двумя запросами, которые вы отправили с разницей в несколько минут. Если одна из правок ошибочна, вы узнаёте об этом позже: после того как терминал закрыт, после того как буфер прокрутки исчез, после того как завершился процесс, который мог бы всё объяснить. Что произойдёт дальше, целиком зависит от того, что вы сохранили. Если ответ — панель затрат, вас ждёт археология. Если ответ — запись, вас ждёт чтение.

Сбой, который вы не можете воспроизвести

Вот как это выглядит. Вы возвращаетесь в репозиторий и обнаруживаете, что файл, который вы никого не просили трогать, переписан, удалён или из него удалена функция, от которой зависит всё остальное. Вы спрашиваете агента, что произошло; сессия закрыта, и даже там, где сохранилась расшифровка, рассказ агента о собственном запуске — это реконструкция, а не запись. Поэтому вы делаете то, что естественно: запускаете его снова — и получаете другой запуск. Другие вызовы инструментов, другие правки, а возможно, вообще без сбоев, потому что исходная траектория зависела от сэмплирования, состояния репозитория и тайминга. Того запуска, который вам нужно изучить, больше не существует.

Это хуже, чем невоспроизводимо. Это невоспроизводимо и при этом помечено как успех. Запуск завершается с кодом 0, когда агент завершается с кодом 0, даже если проверка внутри запуска завершилась с кодом 1: пайплайн может быть зелёным, в то время как шаг верификации внутри запуска не сработал, а код выхода, которому вы по привычке доверяете, не говорит вам ничего.

Неважно, какую модель роутер выбрал для запуска (GLM 5.3 Flash или любую другую): как только процесс завершается, рассуждения исчезают вместе с ним. Доказательства существовали только пока запуск был активен: промпты, вызовы инструментов, выходные данные, диффы. Если их никто не записал, у вопроса «почему он изменил этот файл» нет ответа. Есть только теории.

Это режим отказа, который отделяет ИИ-агентов для программирования от всех инструментов, которые были до них: ущерб и объяснение происходят в одном месте, и это место закрывается.

Что измеряет приборная панель и что она упускает?

Инстинкт после неудачного прогона — открыть дашборд наблюдаемости, и дашборд действительно хорошо делает своё дело. Его дело — трафик: токены в день, стоимость за модель, задержки, частота ошибок. Для планирования мощностей и выставления счетов это именно тот инструмент, и если вы запускаете агентов в продакшене, он должен быть у вас открыт.

Но ваш вопрос не агрегатный. Он единичный и причинный: почему именно этот запуск изменил этот файл? Агрегирование проходит ровно мимо той гранулярности, которая даёт ответ. Усредняя по всем запускам, интересующий вас запуск — это шум; внутри этого запуска интересующий вас вызов инструмента — снова шум.

Панель мониторинга описывает запуск со стороны: что он произошёл, каков был его вес, какова была его цена. Она не может вручить вам сам запуск, и «почему» — не свойство описания. Это свойство последовательности.

• Сколько стоил запуск? — Панель затрат отвечает на это, а записанный трейс тоже отвечает на это

• Почему агент изменил этот файл? — Панель расходов Нет ответа против записанной трассировки Правка в последовательности с её diff

• Какая проверка не удалась в зелёном прогоне? — Панель затрат: «Нет ответа» против «Записанной трассировки». Проверка с её кодом выхода.

• Можно ли снова воспроизвести точный сбой? — Панель затрат: нет; записанная трассировка: да, офлайн, без затрат.

Слой, который отвечает на этот вопрос, находится ниже: записанные журналы запросов, зафиксированные по ходу запуска, с каждым отправленным промптом, каждым сделанным вызовом инструмента и каждым полученным ответом — по порядку. Не сводка о запуске. Сам запуск.

Чтение одного запуска как временной шкалы

С записью отладка перестаёт быть археологией и становится чтением. Археология — это то, чем ты занимаешься без неё: git reflog, stash-записи, история команд в шелле, собственная память о том, что ты просил ранее в тот день. Чтение — это то, что ты делаешь с ней: открываешь таймлайн и листаешь.

Хронология показывает запуск в том порядке, в котором он происходил: запрос, который его запустил, каждый вызов инструмента, каждая правка файла с её диффом, каждая проверка, каждый код выхода. Снимок файловой системы делается один раз за ход, а не один раз за вызов инструмента, — этого достаточно, чтобы видеть состояние репозитория на каждом шаге разговора, не утопая в шуме от каждого вызова. Что делает это отладкой, а не просмотром, — это смежность: правка и проверка, которая её поймала, находятся рядом друг с другом, по порядку, и между ними нет ничего, о чём можно было бы строить догадки. «Почему» — это в основном свойство смежности.

Конкретный пример из записанного исправления: 14 событий, включая изменение файла, выведенное как +1 -3, и упавшую проверку с кодом выхода 1. Правка, а затем упавшая из-за неё проверка — в записи они соседствуют. В этом и заключается вся разница между восстановлением запуска по фрагментам и чтением готовой записи. Это важнее всего для агентов, пишущих код в терминале, чьё рабочее пространство — терминал, который закрывается, как только задача выполнена: хронология — это буфер прокрутки, переживающий это закрытие.

Записано или выведено: что знает трассировка, а что она вычислила

Временная шкала показывает, что произошло и в каком порядке. Граф причинно-следственных связей показывает, что к чему привело, а разрыв между этими двумя — то место, где доверие необходимо заслужить.

Граф связывает события: это изменение, затем эту не прошедшую проверку. Некоторые из этих рёбер — зафиксированные факты: вызов инструмента, создавший дифф, находится прямо в трассировке. Другие — выводы: заключение графа о том, что проверка упала из-за этого диффа. orca graph помечает каждое ребро как зафиксированное или выведенное и в обоих случаях называет использованное правило, так что вы всегда знаете, смотрите ли вы на то, что сделал прогон, или на то, что инструмент выяснил о прогоне.

Это различие жёстко обеспечивается, а не остаётся благим пожеланием: выведенные рёбра никогда не записываются обратно в трассировку. Трассировка остаётся достоверной записью того, что произошло; вывод — это представление поверх неё, которое можно изучать, ставить под сомнение и оспаривать. Это особенно важно, когда задействовано несколько агентов. Когда агент, выполняющий рефакторинг, и агент, пишущий тесты, затрагивают одни и те же файлы, вопрос «какой из агентов это вызвал» — это и есть тот самый вопрос.Мультиагентная атрибуциясуществует, чтобы ответить на него. Ребро, которое незаметно превращает себя из вывода в факт, — это именно то, как вы в итоге отлаживаете историю, а не запуск.

Воспроизводить его сколько угодно раз бесплатно

Чтение объясняет. Воспроизведение доказывает. Когда у вас есть гипотеза (проверка не прошла, потому что правка удалила вызов сброса), вы хотите запустить её снова и увидеть, как это происходит. Повторный запуск живого агента даёт вам новую траекторию и новый счёт.

Воспроизведение записи даёт вам тот же прогон: повторный запуск выполняется с заблокированной сетью, поэтому не тратит токены и не имеет вариативности. Те же события, каждый раз, офлайн. Именно это свойство превращает отладку агентов из азартной игры в инженерное дело: сбой стал детерминированным, а детерминированные сбои исправляются.

Инструментарий тоже не является чёрным ящиком. OrcaReplay имеет открытый исходный код и распространяется под лицензией Apache-2.0, а формат трассировки — CC BY 4.0, поэтому любой может реализовать его заново: ваши записи не заложники проприетарного формата, как и наши. Он проверяется на практике, а не просто демонстрируется: 1393 теста на Node 20 и Node 22. Вы можете прочитать исходный код, проверить формат и самостоятельно запустить набор тестов, прежде чем доверить ему какие-либо из прогонов вашей команды.

Главный вывод

{{1}}Дашборд — это счёт. Записанный трейс — это и есть запуск.{{/1}} {{2}}Если ваш план отладки ИИ-агентов заканчивается на дашборде затрат, у вас нет плана отладки: у вас биллинговая система.{{/2}} {{3}}Дашборд всегда сможет сообщить, сколько стоил запуск, но никогда не сможет объяснить, почему агент удалил ваш файл, потому что «почему» живёт в последовательности, а последовательность существует, только если вы её сохранили.{{/3}}

Весь метод состоит из четырёх шагов:

• Записывайте прогоны.

• Прочитайте временную шкалу.

• Проверьте рёбра графа.

{{1}}Пересматривайте пугающие вас моменты бесплатно и сколько угодно раз.{{/1}}

Примечание об источниках: Каждая цифра в этой статье предоставлена вендором — из нашего собственного продукта, а также из репозитория OrcaReplay и его документации: поведение кода возврата при запуске, записанное исправление из 14 событий с его диффом +1 −3 и проверкой кода возврата 1, разметка рёбер в графе orca, периодичность создания снимков раз за ход, офлайн-воспроизведение при заблокированной сети и набор из 1393 тестов на Node 20 и Node 22. Никакие сторонние измерения нигде в этой статье не цитируются. Набор из 1393 тестов — единственное утверждение, которое можно проверить самостоятельно, клонировав репозиторий и запустив его. Все пункты были в последний раз проверены 04.09.2026.