К содержимому
МАТЕРИАЛЫ КУРСА
НАВИГАЦИЯ

Автопроверка PR: что видит агент

Как устроена машинная проверка работ: что агент умеет, чего не умеет и почему это честнее ручной вычитки

Проверяющий агент — не мера строгости, а способ освободить время живого разговора. Пока он читает репозиторий, лаборант не тратит занятие на вопрос «а где у вас ADR» и сразу спрашивает, почему решение принято именно такое.

Этот материал — про то, что агент видит, чего не видит и как с ним спорить.

Что происходит после открытия PR

Агент получает три вещи: ссылку на репозиторий команды, номер PR и список критериев лабы. Критерии те же, что опубликованы на странице лабы — никакого второго, скрытого списка не существует.

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

Почему песочница

Агент запускает команды из критериев — docker compose up, сборку, тесты. Делать это на машине проверяющего нельзя: код студенческий, а изоляция — не паранойя, а гигиена. Заодно песочница гарантирует, что проект поднимается на чистой машине, а не «работает у нас».

Что агент умеет хорошо

Проверять факт. Поднимается ли система одной командой, отвечает ли прод-URL, зелёный ли CI, лежит ли артефакт в репозитории, содержит ли он требуемые разделы. Здесь машина точнее человека и не устаёт к пятнадцатой команде.

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

Отличать содержательный документ от имитации. У критериев типа llm есть два описания: как выглядит выполненный критерий и как выглядит подделка под него. Например, для не-скоупа: хорошо — «два раздела: что делаем и что осознанно не делаем, с причинами»; плохо — «только список задач без границы».

Чего агент не умеет

Отличить понимание от пересказа. Записка о находках эксперимента может быть безупречной по форме и написанной целиком моделью. Агент увидит форму, человек на приёмке — задаст вопрос «что бы вы сделали, если бы цифра оказалась вдвое хуже».

Оценить вкус. Хорошая ли это архитектура для данной задачи, разумная ли цена решения, стоило ли вообще брать RAG — это разговор, а не проверка.

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

Поэтому примерно каждый двенадцатый критерий помечен как человеческий — агент его не трогает, а передаёт вопрос лаборанту.

Как спорить с вердиктом

Спор с агентом — нормальная часть работы, и он ведётся в том же PR.

1. Прочитать обоснование
2. Понять, что именно он не нашёл
3. Доработать или объяснить в PR
4. Попросить перепроверку

Чаще всего вердикт «не закрыто» означает одно из трёх: артефакта действительно нет; он есть, но не содержит того, что требует критерий; он есть и полный, но написан так, что читатель со стороны его не опознаёт. Третий случай — тоже проблема, просто не та, о которой думает команда.

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

Почему это честнее ручной вычитки

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

Машина читает сотую работу так же, как первую, и не помнит ничего. Всё, что она проверяет, опубликовано заранее. Всё, что она решила, объяснено в комментарии.

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

Что это значит для работы с агентами в своём проекте

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

Отсюда практический вывод для команды: критерий, который вы не можете проверить командой или чтением, скорее всего не критерий, а пожелание. То же относится к задачам, которые вы ставите агенту в своём проекте.