TL;DR
VeriHarness — схема проверки работы агента. Задачу прогоняют несколько раз (в исследовании — 10), а потом отдельный проверяющий агент (та же модель, с доступом к файлам задачи) разбирает результаты на утверждения. Он делает две разные проверки. Разрешитель споров берёт места, где прогоны разошлись, и сверяет варианты с источниками. Оспариватель консенсуса берёт места, где все согласны, и ищет, как они могут быть неверны и что все забыли сделать.
Главная находка: согласие прогонов не означает правду. Примерно в трети значений, которые во всех прогонах совпали, была ошибка. В спорных местах правильный вариант чаще всего уже есть среди кандидатов, но самый популярный ответ верен меньше чем в половине случаев. Голосование большинством и «модель-судья читает и оценивает» опираются только на то, во что модель уже верит. Файлы, версии и метаданные при этом никто не открывает.
Метод работает в три шага. Два расследования идут в раздельных контекстах. Потом третий, чистый контекст выносит вердикт: какой прогон взять за основу, что исправить и что осталось нерешённым. В итоге получается исправленный документ и журнал проверок. Помогают навыки (скилы): короткие описания типовых ошибок и способов их проверить. Они подсказывают, что проверять, а инструменты лишь выполняют проверку.
Схема метода
ШАГ 0: Запустить задачу N раз → N папок с результатами (артефакт + файлы + ход работы)
ШАГ 1а (контекст 1): РАЗРЕШИТЕЛЬ СПОРОВ
найти расхождения между прогонами → выбрать проверку, которая отличает кандидатов
→ сверить с источником → отсеять опровергнутых → запись: утверждение/проверка/доказательство/вердикт
ШАГ 1б (контекст 2): ОСПАРИВАТЕЛЬ КОНСЕНСУСА
взять то, в чём все согласны → предположить, как это может быть неверно
→ проверить: значения (пересчёт, подписи vs метаданные), прочтения, упущенные требования
→ запись в том же формате
ШАГ 2 (контекст 3, чистый): СУДЬЯ
читает обе записи + задачу + прогоны → (основа, план правок, нерешённое)
ШАГ 3: ДОСТАВКА
применить план правок к основе → итоговый файл + журнал проверок
Шаги 1а и 1б идут в разных сессиях, чтобы споры не отвлекали внимание от консенсуса. Судья не видит переписки следователей, только их записи.
Пример применения
Задача: Вы собираете для собственника годовой отчёт по выручке селлера на Wildberries и Ozon. В папке лежат выгрузка из 1С, черновик отчёта v1, финальный отчёт v3 и договор с маркетплейсом. Вы прогнали Claude Code три раза. Два прогона взяли цифру из черновика (100 млн), третий из финала (120 млн). Во всех трёх документах написано «руб.», хотя в метаданных выгрузки валюта другая. Простое голосование выберет 100 млн и «руб.», и обе ошибки уйдут собственнику.
Промпт (сессия 1, разрешитель споров):
Ты — разрешитель споров. Твоя работа — найти утверждения, по которым
три прогона расходятся, и сверить их с источниками. Ты не пишешь отчёт заново.
Задача: /task/description.md
Источники: /task/sources/ (выгрузка 1С, черновик v1, финал v3, договор)
Прогоны: /runs/run_1/, /runs/run_2/, /runs/run_3/ (каждый: итоговый отчёт + ход работы)
1. Сравни отчёты и найди утверждения с разными значениями
(числа, трактовки, наличие разделов). Считай одинаковыми то, что
записано разными словами. Отсутствие раздела — тоже значение.
2. Для каждого спора выпиши кандидатов и откуда взят каждый.
3. Выбери проверку, которая лучше всего отличит кандидатов
(история версий, пересчёт из сырых данных, метаданные файла).
4. Выполни проверку. Исключи кандидатов, которым она противоречит.
5. Если опровергнуты все — запиши новое значение, ТОЛЬКО если доказательства
его устанавливают. Иначе оставь вопрос открытым.
6. Остановись, когда новые проверки вряд ли изменят итог.
- Проверка версии: какой документ заменяет какой, смотри дату и статус.
- Проверка периода: охватывает ли показатель те годы, что указаны в подписи.
Сессия 2 (оспариватель) и сессия 3 (судья) строятся по шаблону ниже.
Результат: Разрешитель выдаст таблицу споров с проверками и вердиктами. Скорее всего, он выяснит по версиям файлов, что финал v3 заменяет черновик. Оспариватель в отдельной сессии проверит согласованные значения (например, сверит валюту в подписи с метаданными) и поищет требования из задачи, которых нет ни в одном отчёте. Судья выберет основу и составит план правок со ссылками на доказательства. В конце вы получите исправленный отчёт и журнал проверок, где неподтверждённые места помечены как открытые.
Почему это работает
Слабость. Модель, которая читает несколько ответов и выбирает лучший, опирается на собственные убеждения. Если все прогоны сделали одну ошибку, то у каждого уже есть общий «слепой угол». Голосование его только усилит. Он выглядит как уверенность: чем больше совпадений, тем меньше желание перепроверять. К тому же в консенсусе нет конкурирующего значения, с которым можно сравнить, и проверять нечего.
Сильная сторона. Та же модель умеет хорошо действовать в среде: открыть файл, пересчитать сумму, посмотреть метаданные, прочитать условие задачи ещё раз. Спор между прогонами сам указывает, где копать: два разных числа — это готовая тема для проверки. А для консенсуса помогают навыки: описание типовой ошибки («знак вычета», «валюта в подписи против валюты в источнике») даёт конкретное свойство, которое можно проверить, даже когда все значения совпали.
Как метод это использует. Две разные работы разведены по разным контекстам: расследование споров и атака на согласие. Решение принимает третий чистый контекст, который не унаследовал чужих рассуждений. Все выводы привязаны к доказательствам (утверждение → проверка → результат → вердикт), поэтому правки прослеживаются, а нерешённое остаётся нерешённым.
Рычаги управления: - Число прогонов. Для простых задач хватит 3–5. Для долгих и дорогих — больше. В исследовании было 10. - Навыки. Добавляйте типовые ошибки вашей предметной области (валюта, период, знак, версия файла). Это самый сильный рычаг: без них оспаривать консенсус нечем. - Режим «только выбрать». Если не нужна правка, пусть судья просто вернёт лучший прогон без изменений. Правка даёт дополнительный выигрыш, но стоит ещё одного прохода. - Условие остановки. «Остановись, когда новые проверки вряд ли изменят итог» можно заменить лимитом шагов, чтобы экономить токены. - Раздельные контексты. Не склеивайте разрешителя и оспаривателя в один чат. Авторы специально разделили их, чтобы споры не оттягивали внимание от консенсуса.
Шаблон промпта
Это три отдельные сессии. Структуру сохраняйте как есть.
Сессия 1 — разрешитель споров:
Ты — разрешитель споров. Найди утверждения, по которым прогоны расходятся,
и проверь их по источникам. Не переписывай результат с нуля.
Задача: {путь_к_задаче}
Источники: {путь_к_источникам}
Прогоны: {пути_к_прогонам}
1. Найди утверждения с разными значениями (числа, трактовки, наличие разделов).
Одинаковые по смыслу значения считай одним. Отсутствие — отдельное значение.
2. Для каждого спора выпиши кандидатов и их источники.
3. Выбери проверку, которая лучше всего отличит кандидатов.
4. Выполни её. Исключи кандидатов, которым доказательства противоречат.
5. Если опровергнуты все — запиши новое значение только при наличии доказательств.
Иначе оставь вопрос открытым.
6. Остановись, когда новые проверки вряд ли изменят итог.
{навыки_твоей_области: тип ошибки → как проверить}
Сессия 2 — оспариватель консенсуса:
Ты — оспариватель консенсуса. Ищи, где совпадающие во всех прогонах
утверждения могут быть неверны, и проверяй это по источникам.
{то_же_рабочее_пространство}
1. Выпиши утверждения, в которых все прогоны согласны.
2. Для каждого предложи, как оно могло бы оказаться неверным.
Сначала приоритет тем гипотезам, которые вероятнее всего вскроют
существенную для задачи ошибку.
3. Проверь три вида:
а) ЗНАЧЕНИЯ: пересчитай из исходных данных; сверь подписи
(валюта, единицы, период) с метаданными источника.
б) ПРОЧТЕНИЯ: сверь общую трактовку с файлом, который назван в задаче,
с периодом из источника, с определением из самой книги/документа.
в) УПУЩЕННОЕ: сверь итоговые файлы с текстом задачи — какие требования
не выполнил ни один прогон.
4. Остановись, когда новые проверки вряд ли дадут находки.
{навыки_типовых_ошибок: знак, период, валюта, версия, определение}
Сессия 3 — судья (чистый контекст):
Ты — судья. Ты не видел переписки следователей. Оцени их записи заново.
Задача: {путь_к_задаче}
Прогоны: {пути_к_прогонам}
Запись разрешителя: {путь_1}
Запись оспаривателя: {путь_2}
1. Каждую находку подтверди, отмени или оставь нерешённой.
2. Выбери основу — прогон с наименьшим числом подтверждённых дефектов
по существенным требованиям задачи. Если ни один не годится, основа = пусто.
3. Составь план правок: что менять и какое доказательство это подтверждает.
4. Составь список нерешённых утверждений.
Затем в отдельной сессии (или тем же агентом) примените revision_plan к основе. Нерешённые места пометьте в итоговом документе, и если формат позволяет, покажите оба прочтения.
Что подставлять: {путь_к_задаче}, {путь_к_источникам}, {пути_к_прогонам} — папки и файлы. {навыки} — 3–10 коротких строк «тип ошибки → как проверить» из вашей области.
🚀 Быстрый старт — вставь в агента (Claude Code, Cursor, Codex):
Вот шаблон трёхшаговой проверки VeriHarness. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Агент спросит, какие файлы лежат в рабочей папке, сколько прогонов у вас есть, какие типовые ошибки бывают в вашей области (валюты, периоды, версии, знаки). Это нужно, потому что именно навыки подсказывают оспаривателю, что искать там, где все согласны. Он возьмёт структуру шаблона и соберёт промпты под вашу задачу.
Ограничения
⚠️ Нужна среда с источниками: метод проверяет утверждения по файлам, данным и ограничениям задачи. Для вопроса «из головы» без источников почвы для проверки нет.
⚠️ Дорого: нужно несколько прогонов одной задачи плюс три прохода проверки. Для коротких и дешёвых задач это не окупается. Авторы сами потратили на пул прогонов больше $100 000.
⚠️ Выигрыш скромный: это единицы пунктов шкалы бенчмарка. Лучший возможный выбор из готового пула (оракул) даёт заметно больше, чем любой метод. Правильный ответ часто есть среди прогонов, но метод находит его не всегда.
⚠️ Один доступ к файлам не спасает: агент с теми же инструментами, но без протокола и навыков, получил примерно половину выигрыша. «Дать агенту проверять» без структуры и списка типичных ошибок почти не работает.
⚠️ Перенос между инструментами неравномерен: в Gemini CLI, Claude Code и Codex большая часть выигрыша сохраняется. Но с Opus на некоторых бенчмарках (JobBench, а у Claude Code ещё и SpreadsheetBench 2) результат упал до уровня одного прогона.
⚠️ Консенсус без навыков оспаривать нечем: сам пул прогонов не подсказывает, как обычно ломаются такие артефакты. Это знание приходится вкладывать в навыки вручную.
⚠️ Ограничение по материалу: в доступном тексте обрезан раздел о самообучении навыков, а приложения с полным списком навыков и точными промптами не видны. Приведённые выше промпты написаны по описанию протокола, а не скопированы из статьи.
Как исследовали
Идея была простой: если несколько прогонов одной задачи содержат разные куски правды, то надёжная проверка позволит собрать из них лучший результат. Команда Google и Кембриджа взяла пять сложных бенчмарков с рабочими файлами: отчёты в банках и юриспруденции, таблицы, код, многофайловые задачи. Они прогнали две сильные модели по 10 раз на каждую задачу. Всего получилось около 26 000 прогонов. Проверяющий и генератор были одной и той же моделью, а оценочные рубрики проверяющему никогда не показывали.
Сначала посмотрели на разметку одного бенчмарка. Среди 917 утверждений, где все 10 прогонов совпали, 34% оказались неверными. Среди 775 спорных утверждений в 74% случаев правильный вариант присутствовал среди кандидатов, но самый частый был верен лишь в 47%. Из этого родилась схема «два разных расследования».
Сравнивали с пятью методами: голосование, лучший по оценке судьи, турнир попарно, прежний лучший метод LLM-as-a-Verifier и агентный проверяющий с доступом к файлам, но без протокола и навыков. VeriHarness выиграл на всех бенчмарках у обеих моделей. Выбор лучшего прогона поднял средний результат примерно на 4 пункта, а проверка плюс правка по доказательствам — на 6,2 и 6,4 (Flash и Opus). Простое «слияние прогонов в новый документ» без проверок осталось ниже: значит, выигрыш даёт именно проверка, а не переписывание.
Удивило два вывода. Первый: доступ к файлам без протокола даёт лишь половину эффекта. Второй: навыки, самостоятельно выращенные моделью из ошибок на тренировочных задачах (от пустой библиотеки), на новых задачах обошли библиотеку, написанную человеком. А если начать с человеческой и дать ей «дорасти», добавлялось ещё 6,8 пункта на APEX-Agents и 3,7 на SpreadsheetBench 2. Вывод для практики: ваш список типовых ошибок — главный актив, и его стоит пополнять после каждого провала.
Адаптации и экстраполяции
💡 Адаптация для одиночного ответа без нескольких прогонов: возьмите только половину метода — оспаривателя. Он не требует спорящих прогонов, ему нужны только ваш результат и источники.
Ты — оспариватель. Перед тобой готовый результат и исходные файлы.
Не оценивай качество. Найди, как каждое важное число, трактовку
и вывод могло оказаться неверным, и проверь это по источникам.
Отдельно сверь результат с текстом задачи: какие требования не выполнены.
Для каждого пункта: утверждение | как могло быть неверно | проверка | вердикт.
Это моя адаптация. В статье полная схема проверена только на пулах прогонов.
🔧 Техника: пополнять навыки после провалов. Когда агент ошибся, попросите описать тип ошибки и способ её проверки, без привязки к ответу этой задачи.
Разбери ошибку выше. Сформулируй навык для проверки:
1) какая типовая ошибка случилась (без цифр и имён из этой задачи);
2) как её обнаружить (что открыть, что пересчитать, с чем сверить).
Не включай правильный ответ. Добавь навык в раздел файла CLAUDE.md.
Это перенос идеи «навыков из ошибок» из раздела 5 в обычный файл инструкций. Статья проверяла этот механизм с автоматическим отбором по тренировочным задачам, а у вас отбор — ваше собственное решение.
Ресурсы
- VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks
- Код: github.com/google-research/veriharness
- Датасет: huggingface.co/datasets/caiqizh/veriharness
- Сайт: veriharness.com
- Caiqi Zhang, Nigel Collier (University of Cambridge); Rujun Han, Zifeng Wang, Zoey CuiZhu, Tomas Pfister, Chen-Yu Lee (Google Cloud AI Research)
- Бенчмарки: APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2, JobBench
- Прежний лучший метод для сравнения: LLM-as-a-Verifier (Kwok et al., 2026)