§4.06 Взаимная проверка в контексте агентов
Время: 45 мин чтение + 30 мин
В одном предложении: Человек думает, что если агент создал артефакт, его можно принимать как есть, потому что агент не устаёт и не ленится, а на самом деле агенты ошибаются, галлюцинируют и упускают очевидное, и пока вы не проверили артефакт агента, вы не приняли решение, а делегировали ответственность машине, которая ответственности не несёт.
Мем, который снимается. «Агент написал код — я его не читаю, а сразу запускаю. Агент составил отчёт — я его не проверяю, а сразу отправляю. Агент не ошибается.» На самом деле агенты ошибаются. Они галлюцинируют: придумыют функции, которых нет. Они упускают очевидное: не замечают, что код не компилируется. Они следуют устаревшему контексту: используют метод, который вы уже отменили. Принятие артефакта агента без проверки — это не доверие, это беспечность. И беспечность дорого обходится: ошибка, пропущенная на стадии создания, исправляется в десять раз дороже на стадии использования.
Понятия. Peer-review в IWE — перекрёстная проверка артефактов между агентами и пилотом. Агент создаёт, другой агент или пилот проверяет. Верификация — проверка результата, а не процесса создания. Важно не то, как агент пришёл к решению, а то, верно ли решение. Трассировка — прослеживание каждого решения до источника: откуда агент взял это утверждение? На каком принципе оно основано? Какому требованию соответствует? Peer-review предотвращает три типа ошибок: галлюцинации (агент придумал то, чего нет), упущения (агент не заметил важного), дрейф (агент использовал устаревший контекст). Проверка может выполняться другим агентом (с другой ролью, другим контекстом) или пилотом.
Объяснение. Верификация в IWE имеет три уровня. Первый — автоматический: скрипты проверяют формальные критерии. Код компилируется? Тесты проходят? Формат соответствует шаблону? Этот уровень быстрый, но ограничен: он не проверяет смысл. Второй — агентный: другой агент проверяет артефакт. Диагност проверяет код Портного. Навигатор проверяет план Диагноста. Преимущество агентной проверки — другой контекст: агент-верификатор видит то, что создатель не заметил. Недостаток — агент тоже может ошибаться. Третий — пилотный: пилот проверяет критические артефакты лично. Этот уровень самый надёжный, но самый затратный. Резонное сочетание: автоматический для всех, агентный для важных, пилотный для критических. Трассировка — не бюрократия, а защита. Когда вы знаете, откуда взялось каждое решение, вы можете проверить его основания. Без трассировки артефакт — чёрный ящик: он работает, но вы не знаете почему. И когда перестаёт работать — не знаете, с чего начинать.
На практике. Практика «Peer-review одного артефакта» (30 мин):
- Выберите один артефакт, созданный агентом за последнюю неделю. (5 мин)
- Проверьте его по чеклисту: соответствует ли шаблону? Нет ли галлюцинаций? Нет ли упущений? Соответствует ли текущему контексту? (15 мин)
- Зафиксируйте замечания: что верно, что нужно исправить, что неясно. Создайте задачу на исправление. (10 мин)
Типичный кейс. Разработчик использовал Kimi для написания функции обработки данных. Kimi написал код, который выглядел правильно. Разработчик запустил тесты — они прошли. Он закоммитил код. Через неделю в продакшне обнаружилась ошибка: функция обрабатывала данные неправильно в граничном случае, который тесты не покрывали. Разработчик потратил день на отладку. После введения peer-review: другой агент (в роли Диагноста) проверял код перед коммитом. Диагност нашёл граничный случай, который Портной упустил. Ошибка была исправлена до попадания в продакшн. Время на peer-review — двадцать минут. Время, сэкономленное на отладке — целый день.
Типичная ошибка. «Peer-review замедляет работу. Мне нужна скорость.» Peer-review замедляет создание, но ускоряет доставку. Артефакт без проверки может оказаться браком, и тогда вы потратите время на переделку, а не на движение вперёд. Другая ошибка: «Я доверяю своему агенту. Он не ошибается.» Доверие — хорошо. Слепое доверие — опасно. Даже лучший агент ошибается. Вопрос не в том, доверяете ли вы, а в том, проверяете ли вы.
Степени мастерства:
- Объяснение. Могу объяснить разницу между верификацией и валидацией, и назвать три типа ошибок, которые предотвращает peer-review. Критерий перехода: провёл peer-review одного артефакта.
- Умение. Для каждого важного артефакта, созданного агентом, провожу peer-review перед принятием. Критерий перехода: двадцать артефактов проверены.
- Навык. Системно организую peer-review: чеклисты, роли верификаторов, трассировка. Критерий перехода: коллега использовала ваш чеклист peer-review.
- Мастерство. Проектирую систему верификации для команды: уровни, ответственности, автоматизация, метрики качества. Критерий перехода: другой человект провёл peer-review по вашей системе без вашей помощи.
Проверка себя.
- Могу объяснить разницу между верификацией и валидацией
- Проверяю артефакты агентов перед принятием: не менее 50% важных артефактов
- Использую чеклист peer-review, зафиксированный в Pack
- Могу проследить решение в артефакте до источника (трассировка)
- Нашёл и исправил ошибку в артефакте агента за последний месяц
На практике. Возьмите последний артефакт, созданный агентом. Задайте три вопроса: 1) Соответствует ли он шаблону? 2) Есть ли явные ошибки или галлюцинации? 3) Соответствует ли текущему контексту? Если на любой вопрос ответ «не уверен» — проведите peer-review. Это займёт двадцать минут, но может сэкономить часы.
См. also: Агент — PD.GUIDE.3.S4.SS1, Подключение Kimi — PD.GUIDE.3.S4.SS5.
Что дальше. Следующий подраздел — о различии между агентом и автопилотом: почему агент — не замена пилота, а его усилитель.