Worker–Reviewer Loop (HOA): независимая проверка результата второй сессией агента, которая не видит рассуждений первой

ШАГ 1: Исполнитель получает задачу + план приёмки + (в след. раундах) замечания
       → кандидат-результат (версия N)
ШАГ 2: [по необходимости] Исполнитель формулирует конкретный пробел в знаниях
       → запрос в вики → берёт запись с указанием источника → правит результат
ШАГ 3: [по необходимости] Объективная проверка (тесты, компилятор, расчёт)
       → статус + журнал ошибок
ШАГ 4: Ревьюер (новая сессия, без истории исполнителя) проверяет «замороженный» результат
       по исходной задаче и плану приёмки
       → список замечаний ИЛИ «принято»
ШАГ 5: Есть замечания → вернуться к шагу 1 (исполнитель закрывает КАЖДОЕ)
       Принято И все объективные проверки пройдены → стоп
       Кончился бюджет → стоп

Шаги идут в отдельных сессиях. Один промпт здесь не подходит: независимость ревьюера и есть суть метода.

Задача: Селлер на Ozon просит агента в Cursor написать скрипт расчёта юнит-экономики. Риск в том, что агент посчитает «красиво» на двух удобных товарах, молча упростит формулу (забудет невыкупы или налог УСН) и доложит «готово».

Промпт (для ревьюера, новая сессия, без истории чата с исполнителем):

Ты — независимый ревьюер. Ты не писал этот код и не видел, как он создавался.
Твоя задача — решить, выполнена ли ИСХОДНАЯ задача целиком, а не её упрощённая версия.
Ты не правишь код. Ты только возвращаешь замечания.



Скрипт на Python читает выгрузку товаров селлера Ozon (CSV) и считает
юнит-экономику каждой позиции: прибыль на единицу и маржу в процентах.
Учесть: закупочную цену, комиссию категории, логистику до покупателя,
процент невыкупов (возврат — логистика в обе стороны), налог УСН 6% с выручки,
расходы на рекламу (ДРР). Результат — таблица CSV с итогами и пометкой
товаров с отрицательной прибылью.



1. Каждая статья расходов из задачи учтена в формуле.
2. Невыкупы считаются корректно, а не вычитаются как фиксированная сумма.
3. Скрипт работает на пустых значениях, нулевой цене и товарах без рекламы.
4. Есть тест с ручным расчётом хотя бы на одном товаре, и он проходит.
5. Скрипт решает именно поставленную задачу, а не соседнюю (например, считает
   не валовую маржу вместо прибыли после налога).



Файл unit_economics.py и tests/test_unit.py (версия 3, только чтение).



Исполнитель сообщает: «Добавлен учёт ДРР, тесты зелёные».



- Сверь кандидата с OriginalTask и AcceptancePlan пункт за пунктом.
- Запусти тесты на неизменённом коде.
- Ищи: пропущенные случаи, неверные формулы, проверку только удобных данных,
  подмену задачи более лёгкой.
- Верни список замечаний: «пункт плана → что не так → как проверить».
- Если все пункты выполнены, напиши ровно: ПРИНЯТО.

Результат: Ревьюер вернёт либо пронумерованный список замечаний по пунктам плана приёмки (например, где невыкупы посчитаны неверно или какой случай не покрыт тестом), либо «ПРИНЯТО». Исполнитель в основной сессии получит этот список, обязан закрыть каждый пункт, запустить тесты и сдать новую версию. Ревью повторяется, пока не придёт «ПРИНЯТО».

Слабость. Модель плохо проверяет свою же работу. В одной сессии она видит собственные рассуждения и привыкает к ним (эффект «якоря»). Если ранний шаг был ложным, дальше она выстраивает на нём всё остальное. Простая просьба «проверь себя» без внешнего сигнала часто не работает. Ещё один риск: агент подменяет задачу удобной версией и считает цель достигнутой.

Сильная сторона. Модель хорошо находит ошибки в чужом готовом тексте, если у неё есть исходное задание и чёткие критерии. Ей не нужно вспоминать, как она к этому пришла. Достаточно сравнить «что просили» и «что получилось».

Как метод это использует. Ревьюер получает только задачу, результат и критерии. Он не видит скрытых рассуждений исполнителя, результат для него заморожен (только чтение). Поэтому он не повторяет чужие ошибки и не «чинит молча». Исполнитель лишён права принимать свою работу, и это закрывает лазейку «сказал, что готово». Рычаги управления:

• План приёмки → чем конкретнее пункты, тем острее ревью. Без него ревьюер проверяет «в целом».
• Лимит раундов или бюджета → уменьши для простых задач, увеличь для сложных. Авторы показали, что для трудных задач польза растёт с длительностью цикла.
• Объективные ворота (тесты, расчёт, компиляция) → добавь везде, где есть что запускать. Ревью проверяет смысл, а запуск — факт.
• Что видит ревьюер → не давай ему историю исполнителя и его оправдания. Только задача, результат, план и краткая сводка раунда.
• Роль «пробел в знаниях» → разрешай исполнителю обращаться за справкой только с конкретным вопросом, а не «найди что-нибудь».

Два промпта в двух разных сессиях.

Сессия 1 — исполнитель:

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


{исходная_задача}


{критерии_приёмки: нумерованный список проверяемых пунктов}


{доступные_инструменты: запуск кода, тесты, поиск по базе знаний}

{лимит: число раундов или время}


{замечания_ревьюера_и_журнал_проверок; в первом раунде: "нет"}



- Закрой КАЖДОЕ замечание из PriorFeedback и по каждому напиши, что изменено.
- Не упрощай и не заменяй задачу. Если считаешь, что её нужно сузить,
  скажи об этом явно, не делай молча.
- Если не хватает знания — сформулируй конкретный вопрос
  {к_базе_знаний_или_источнику} и укажи источник, откуда взял ответ.
- Запускай объективные проверки ({тесты_или_расчёт}) до сдачи.
- В конце выдай версию результата и список закрытых замечаний.

Сессия 2 — ревьюер (новая, без истории исполнителя):

Ты — независимый ревьюер. Ты не создавал этот результат и не видел,
как он создавался. Ты не правишь результат, только проверяешь.


{исходная_задача}

{критерии_приёмки}

{замороженный_результат — только чтение}

{краткая_сводка_раунда_от_исполнителя}


- Сверь результат с OriginalTask и AcceptancePlan пункт за пунктом.
- Запусти {объективные_проверки} на неизменённом результате.
- Ищи отдельно:
  1. пропущенные случаи;
  2. неверные выводы и расчёты;
  3. решение не той задачи (подмена, упрощение, проверка удобных случаев).
- Верни список замечаний: «пункт → что не так → как проверить».
- Если всё выполнено и проверки пройдены, напиши ровно: ПРИНЯТО.

Что подставлять: {исходная_задача} — задание дословно, без пересказа. {критерии_приёмки} — 3–7 проверяемых пунктов. Каждый должен позволять ответить «выполнено или нет». {объективные_проверки} — всё, что можно запустить: тесты, пересчёт на примере, линтер, сверка с таблицей. Если запускать нечего, оставь только смысловое ревью.

🚀 Быстрый старт — вставь в чат:

Вот шаблон worker–reviewer loop (исполнитель + независимый ревьюер).
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

⚠️ Потолок задаёт базовая модель: ревьюер не добавляет знаний. У слабых моделей прирост от петли был скромным: на части олимпиад результат почти не вырос. Сильный эффект получился на более сильных моделях.

⚠️ Вклад каждой части не разделён полностью: в экспериментах петля, вики и верификатор работали вместе. Сколько даёт именно ревьюер без объективных проверок, по статье точно сказать нельзя.

⚠️ Лучше всего работает там, где есть проверяемый результат: задачи олимпиад, доказательства, код. Для субъективных задач (тексты, стратегия, креатив) метод авторы не проверяли.

⚠️ Дорого по времени и токенам: лучшие результаты получены на запусках в десятки и сотни часов. Для простой задачи такая петля — перебор.

⚠️ Полный пайплайн статьи — это инженерия: формальный верификатор Lean, песочница, вики с источниками, автоматический «раннер». Без кода повторяется только сам паттерн: две сессии, план приёмки, запуск тестов.

⚠️ Препринт от авторов метода: часть результатов (например, по PutnamBench) авторы сами называют предварительными. Часть оценок выставлял LLM-судья с проверкой людьми.

Команда взяла самые свежие олимпиады 2026 года (математика, физика, химия, программирование), чтобы исключить утечку задач в обучение моделей. Для математики добавили PutnamBench (672 задачи) и Lean-Eval (302 исследовательские задачи). Результат в математике принимался только после проверки компилятором доказательств, на слово модели не верили. Затем сравнили четыре уровня обвязки: чистый вызов API, агент в CLI (инструменты + файлы), агент + вики + верификатор и полный цикл с независимым ревьюером. Это повторили на четырёх моделях: одной закрытой и трёх открытых.

На подмножестве из 50 задач PutnamBench закрытая модель выросла с 3 решённых (API) до 46 (агент) и 50 (полный цикл). Открытая Kimi K3 поднялась с 1 до 4 и затем до 47. Разрыв между открытой и закрытой моделью сузился с 42 задач до 3. На 100 задачах Lean-Eval обычный агент остановился на 34 примерно через 30 часов, а цикл с ревьюером дошёл до 63 за 150 часов: он продолжал находить решения там, где агент без проверки снаружи повторял те же ошибки. Удивил результат на слабых моделях: DeepSeek V4 Pro и GLM-5.3 выросли заметно меньше, а на IMO или IPhO местами совсем не выросли. Практический вывод: независимая проверка превращает время работы в результат, но не заменяет знания и силу модели. Отдельный интересный выбор авторов: вики для физики и кода они не строили, потому что модель и так знает эти области. Вики нужна там, где знаний не хватает.

🔧 Техника: добавить объективные ворота → ревьюер ловит факты, а не только мнения

В статье для кода исполнитель и ревьюер сами пишут тесты и запускают их. Добавь в промпт ревьюера:

Прежде чем писать замечания, запусти код на 3 граничных случаях
(пустой ввод, ноль, очень большое значение) и приведи вывод.

Ревьюер опирается на запуск, а не на «кажется правильным».

🔧 Техника: разделить смысловое ревью и проверку формата → два набора замечаний

Сделай два раздела в ответе ревьюера: «Подмена задачи / логика» и «Технические ошибки». Так исполнитель не потеряет самое важное среди мелочей.

Экстраполяция: вики проекта в файле инструкций агента

В статье вики пополняется принятыми результатами: после приёмки куратор вытягивает из них повторно используемые куски с указанием источника и статусом проверки. Для работы с агентом (Claude Code, Cursor) это можно сделать как файл WIKI.md рядом с CLAUDE.md:

После того как ревьюер написал ПРИНЯТО, добавь в WIKI.md запись:
- что решено (одной строкой);
- где лежит результат (файл/функция);
- как проверено (тест, расчёт);
- дата и версия.
Перед новой задачей ищи в WIKI.md похожие решения и ссылайся на них,
а не пиши заново.

Это моя экстраполяция, авторы проверяли её только на формальной математике и химии.

• Humanize OlympiadAgents: A Multi-Session Workflow for Olympiad Problem Solving with Solve, Review, Wiki, Verify (препринт)
• Код: https://github.com/humanfia/hoa
• Авторы: Zhengyang Zhang, Jing Xiong, Hongzhou Lin, Juihui Chung, Zijian Zhang, Song Han, Sihao Liu, Ligeng Zhu
• Организации: Tsinghua University, NVIDIA, The University of Hong Kong, MIT, Princeton University, Amazon
• Упомянутые основы: Humanize (Liu et al., 2026), Comparator (Lean FRO), Science Mango, Lean-Eval, PutnamBench