это хороший вопрос, честно я даже о нем не думал, видимо это еще впереди, и с учетом того что тул в н8н может поправить любой из команды, выглядит как большая дырка пока что
Перед запуском тест забирает из production MCP актуальный список инструментов, их схемы и контракты. Затем реальной модели задаётся сохранённый вопрос (из истории, отобранный вручную). Когда модель вызывает tool, запрос перехватывается. Вместо обращения в прод источники тест возвращает готовый ответ (в виде raw метрик и логов), ранее полученный в реальной проблеме (для нас это ок, поскольку тулы в mcp узкопрофилированые, при правильных входных данных отдадут правильную выборку). При этом проверяются имя инструмента и его аргументы: кластер, namespace, сервис, время и окно поиска. Если агент выбрал другой ЦОД, потерял время или вызвал неподходящий tool, сохранённый ответ не подставится и тест завершится ошибкой. После этого проверяется итоговый ответ от самой модели по сырым данным: присутствуют ли подтверждённые факты, не появилась ли выдуманная причина, не назвал ли агент недоступный источник исправным. Один сценарий запускается несколько раз, чтобы увидеть нестабильность выбора инструментов.
Все это работает сейчас долго, и честно хочется универсальности и чуть быстрее получать результат теста, но пока не получилось ничего лучше...
это хороший вопрос, честно я даже о нем не думал, видимо это еще впереди, и с учетом того что тул в н8н может поправить любой из команды, выглядит как большая дырка пока что
Перед запуском тест забирает из production MCP актуальный список инструментов, их схемы и контракты. Затем реальной модели задаётся сохранённый вопрос (из истории, отобранный вручную). Когда модель вызывает tool, запрос перехватывается. Вместо обращения в прод источники тест возвращает готовый ответ (в виде raw метрик и логов), ранее полученный в реальной проблеме (для нас это ок, поскольку тулы в mcp узкопрофилированые, при правильных входных данных отдадут правильную выборку). При этом проверяются имя инструмента и его аргументы: кластер, namespace, сервис, время и окно поиска. Если агент выбрал другой ЦОД, потерял время или вызвал неподходящий tool, сохранённый ответ не подставится и тест завершится ошибкой.
После этого проверяется итоговый ответ от самой модели по сырым данным: присутствуют ли подтверждённые факты, не появилась ли выдуманная причина, не назвал ли агент недоступный источник исправным. Один сценарий запускается несколько раз, чтобы увидеть нестабильность выбора инструментов.
Все это работает сейчас долго, и честно хочется универсальности и чуть быстрее получать результат теста, но пока не получилось ничего лучше...
может быть было проще взять Flagger для Canary, ведь он давно все умеет в автомате и даже с анализом и вебхуками.