agentic-eval

Навык agentic-eval предназначен для задач, где одного ответа AI-агента недостаточно и результат нужно последовательно проверить, раскритиковать и улучшить. Его исходный документ описывает общий цикл Generate → Evaluate → Critique → Refine → Output: сначала агент создаёт результат, затем сверяет его с заранее заданными критериями, формирует обратную связь и повторяет улучшение. Такой подход подходит для генерации кода, отчётов и аналитики, когда заранее можно описать требования к точности, полноте, стилю или формату. Навык не заменяет сами критерии качества: без измеримого условия цикл превращается в субъективное повторение. Базовый паттерн Reflection строится вокруг списка criteria и ограниченного числа итераций. После генерации результата отдельный вызов LLM должен вернуть структурированный JSON с полями статуса PASS или FAIL и пояснением по каждому критерию. Если все проверки пройдены, исходный результат возвращается сразу; если нет, в следующий запрос передаются только неуспешные пункты и их feedback. Исходный пример использует лимит до трёх итераций, поэтому процесс имеет конечную границу и не должен бесконечно исправлять уже принятый результат. Практический сценарий — проверить отчёт по обязательным разделам, код по тестируемым условиям или ответ по внутреннему style guide. В паттерне Evaluator-Optimizer генерация и оценка разделены на разные компоненты. Generator создаёт результат, Evaluator возвращает JSON с общей оценкой от 0 до 1 и оценками измерений, а Optimizer получает обратную связь и выпускает следующую версию. Порог score_threshold определяет, когда можно остановиться; пример по умолчанию использует 0,8 и максимум три прохода. Такое разделение помогает явно увидеть, какая часть процесса отвечает за создание, какая — за проверку, а какая — за исправление, но не гарантирует объективность оценки, если сама рубрика или запрос к judge сформулированы плохо. Для кода источник отдельно показывает test-driven refinement: агент создаёт реализацию и тесты, запускает их, а затем исправляет результат по фактической ошибке до ограничения итераций. Для других задач доступны outcome-based проверка ожидаемого результата, LLM-as-a-judge для сравнения двух вариантов и rubric-based оценка по взвешенным измерениям. Пример рубрики распределяет вес между accuracy, clarity и completeness; конкретные веса нужно выбирать под задачу, а не считать универсальными. Главные рабочие правила навыка — определить критерии до генерации, задать порог и предел итераций, отслеживать улучшение между проходами, сохранять историю и использовать структурированный JSON для надёжного разбора. Исходный SKILL.md даёт шаблоны и паттерны, но не предоставляет конкретного провайдера LLM, реализации функции llm, системы запуска тестов или защиты от ошибочного judge-ответа. Перед применением нужно добавить обработку некорректного JSON, выбрать безопасный лимит стоимости и проверить результат независимым тестом там, где ошибка может повредить данным или пользователю.