Большинство инженерных команд всё еще оценивают ИИ-агентов так же, как они проверяют домашние задания по математике. Они смотрят на конечный результат. Если

Большинство инженерных команд до сих пор оценивают ИИ-агентов так же, как проверяют домашние задания по математике. Они смотрят на конечный результат. Если ответ верный, они дают зеленый свет релизу и идут дальше. Это опасный путь. Правильный ответ может скрывать глубоко сломанную систему.

Настоящая история кроется в пути, который прошел агент. Этот путь называется траекторией агента (agent trajectory). Он включает в себя каждый вызов инструмента, каждое решение о маршрутизации, каждую паузу, когда агент останавливается, чтобы переосмыслить действия. Это можно представить как след из хлебных крошек. И если вы проверяете только пункт назначения, вы упускаете все предупреждающие знаки, разбросанные по пути.

Проблема запутанных путей

Агент может прийти к правильному ответу, ведя себя при этом как нетрезвый водитель. Он мечется между неверными инструментами, возвращается к роутеру и ходит по кругу в избыточных рассуждениях, прежде чем случайно наткнуться на верное решение. Пользователь видит чистый результат. Но за кулисами система теряет ресурсы и накапливает риски.

Как этот хаос выглядит на практике?

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

Затем идет паттерн «сначала неверный инструмент». Агент-программист может попытаться найти в интернете определение функции, которая уже есть в локальном репозитории. Или агент поддержки может обратиться к billing API, когда вопрос пользователя явно требует использования инструмента настроек аккаунта. Каждый неверный выбор сжигает токены, увеличивает задержку и повышает вероятность того, что лимиты контекста будут исчерпаны еще до начала реальной работы.

Циклы роутера — еще один тревожный сигнал. Узел принятия решений не может определиться. Он отправляет задачу в ветку А, передумывает, отзывает ее, пересылает в ветку Б, а затем без причины направляет через универсальный fallback-узел. Каждый цикл добавляет сетевой переход (network hop) и еще один уровень путаницы в итоговый лог отладки.

Наконец, существует повторный анализ. Агент продолжает заново выводить одно и то же заключение на каждом шаге вместо того, чтобы считать его принятым. Это похоже на плотника, который замеряет доску десять раз перед каждым распилом. Первый замер был правильным. Следующие девять — это пустая трата движений.

Эти лишние шаги имеют реальные последствия. Задержки накапливаются. В синхронном чат-интерфейсе лишние три секунды кажутся вечностью. В масштабе эти секунды превращаются в тысячи долларов затрат на вычисления. Риск сбоя также растет. Каждый ненужный переход — это еще один шанс для того, чтобы внешний API выдал таймаут, контекстное окно переполнилось или возникло состояние гонки (race condition). А когда что-то действительно ломается, удачи с отладкой трассировки, которая похожа на спагетти. Вы потратите часы, восстанавливая, почему агент сделал седьмой шаг, только чтобы понять, что седьмого шага вообще не должно было быть.

Что на самом деле означает конвергенция

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

Это не то же самое, что точность (accuracy). Точность — это грубый инструмент. Она отвечает на вопрос, является ли конечное состояние верным. Конвергенция же спрашивает, был ли путь разумным. Агент с высокой точностью и низкой конвергенцией — это обуза в костюме успеха. Агента с высокой конвергенцией и средней точностью обычно легче исправить, потому что его логика чиста, а ошибки локализованы.

Вы можете рассчитать примерный показатель конвергенции, сравнив шаги, которые агент предпринимает на самом деле, с кратчайшим путем, определенным вами для данного класса задач. Если стандартный запрос на возврат должен требовать ровно три вызова инструментов, а агент использовал девять, ваш коэффициент конвергенции падает. Вы можете уточнить этот показатель, присваивая веса различным типам потерь. Один неверный вызов инструмента может стоить дороже, чем один избыточный вызов, в зависимости от задержки и стоимости инструмента. Цикл роутера, не приносящий никакой пользы, может повлечь за собой самое тяжелое наказание, так как он сигнализирует об архитектурных