TL;DR
RuHarness — цикл улучшения агента без дообучения модели. Агент прогоняется на задачах, провалы разбираются, из них выводится список проверяемых критериев поведения (рубрика). Берутся только самые актуальные нерешённые критерии, и по ним правится обвязка агента: системный промпт, описание инструментов, правила работы с памятью и остановки. После каждого круга список критериев пересобирается заново.
Главная находка неожиданная. Статичная рубрика, составленная один раз в начале, хуже, чем её полное отсутствие. Агент чинит главные ошибки, на их месте вылезают другие, а старый список продолжает толкать правки туда, где уже всё хорошо. Вторая находка: если скормить доработке весь пул критериев, а не топ самых значимых, результат тоже хуже. Лишние сигналы мешают.
Суть метода в четырёх ходах: собрать провалы в критерии → оценить критерии на траекториях, не показывая судье итог → взять топ-10 по пользе → внести небольшие правки в инструкции и принять их, только если они улучшили результат на отдельном наборе задач. Критерии и инструкции обновляются по очереди, пока есть прирост.
Схема метода
ШАГ 1: Прогон агента на наборе задач (evolution) → траектории (логи)
ШАГ 2: Отчёт о каждом провале → структурированные причины
ШАГ 3: Агрегация по задачам → новые критерии поведения (проверяемые по логу)
ШАГ 4: Судья оценивает критерии по логам, НЕ зная исхода → Satisfied / Violated / N/A
ШАГ 5: Birth check: выкинуть редкие, не ловящие провалы, срабатывающие на всём → пул
ШАГ 6: Жизненный цикл: probation → active → dormant → retired
ШАГ 7: Ранжирование active-критериев (различает успехи/провалы, покрывает провалы,
предсказывает провал, ловит новое, не дублирует) → топ-10 (frontier)
ШАГ 8: До 3 кандидатов правок обвязки (каждый ≤3 компонентов) под топ-10
ШАГ 9: Верификатор: «правка соответствует диагнозу?» (только да/нет, не переписывает)
ШАГ 10: Проверка на ОТДЕЛЬНОМ наборе (validation) → принять, только если лучше на порог
ШАГ 11: Новый круг с обновлённой обвязкой → заново с шага 1
В чате это отдельные запросы. Прогоны агента и подсчёт идут вне чата.
Пример применения
Задача: Продавец на Wildberries и Ozon настроил ИИ-агента отвечать покупателям на вопросы и отзывы. Системный промпт писался «на глаз». Накопилось 40 диалогов, где покупатель остался недоволен или вопрос ушёл менеджеру зря. Нужно улучшить промпт так, чтобы правки работали и на новых диалогах, а не только на этих сорока.
Делим логи: 20 диалогов идут в «доработку», 20 откладываем и до самого конца не смотрим (это валидация).
Промпт (шаг: вывести критерии из провалов):
Ты аналитик качества агентов поддержки. Твоя задача — превратить
разборы провальных диалогов в проверяемые критерии поведения.
Агент отвечает покупателям на Wildberries и Ozon (одежда,
сезонные товары). Системный промпт агента — ниже.
Ниже — отчёты о 20 провальных диалогах
(покупатель недоволен или эскалация была лишней).
{вставить текущий системный промпт агента}
{вставить 20 коротких отчётов: что спросил покупатель,
что ответил агент, где пошло не так}
1. Найди повторяющиеся поведенческие паттерны, которые встречаются
минимум в 3 разных диалогах.
2. Для каждого сформулируй критерий: «Агент должен / не должен ...».
3. Критерий должен проверяться по тексту диалога, без знания, чем
всё закончилось.
4. Не пиши критерии, которые срабатывают почти всегда или почти никогда.
5. Максимум 12 критериев. Формат: ID, формулировка,
в каких диалогах нарушен, как проверить по логу.
Результат: Модель вернёт список до 12 проверяемых критериев с ID. Для каждого будут формулировка, номера диалогов с нарушением и способ проверки по тексту. Дальше критерии прогоняются через судью, который не знает итога диалога, и отбираются топ-10. Затем модель предлагает до трёх правок системного промпта, и они проверяются на отложенных 20 диалогах.
Почему это работает
Слабость: сигнал «задача провалена» или «не провалена» слишком грубый. Он не говорит, что именно агент делает не так. Но ещё хуже сигнал, который устарел. Починили главную ошибку, а список критериев продолжает про неё твердить. Правки идут не туда, а на месте старых провалов появляются новые.
Сильная сторона LLM: модель хорошо читает логи и находит в них повторяющиеся паттерны. Она может сформулировать их как проверяемые утверждения и оценить по тексту. Судье, который не знает исход, труднее подгонять оценку под результат, поэтому критерий оценивается по поведению, а не по итогу.
Как метод это использует: критерии становятся «живыми». Их пересобирают после каждой правки, держат в работе только то, что различает успехи и провалы и покрывает нерешённое. Отдельный валидационный набор не даёт принимать правки, которые только подогнаны под логи, по которым их писали.
Рычаги управления: - Размер топа (K = 10) → меньше критериев для простого агента, больше для сложного. Но в абляции весь пул вредил. - Число кандидатов (до 3) и правок в каждом (≤3 компонентов) → меньше правок за круг даёт чище понимание, что сработало. - Порог принятия (ε = 0,05) → выше порог означает меньше случайных «улучшений». - Что можно править: промпт, инструменты, память, остановка. Авторы разбили обвязку на шесть частей: Equip, Instruct, Act, Observe, Remember, Terminate. Проверь, что правка попадает именно в ту часть, где причина провала. - Выбор судьи → «не знает исход» можно убрать, но тогда критерии тянутся к «провал = нарушил».
Шаблон промпта
Готовых промптов в основной части статьи нет. Ниже реконструкция по описанию механики: шаги и структура сохранены, формулировки мои.
=== ШАГ 1. Отчёт о провале (по одному прогону) ===
Ты аналитик логов агента.
Вот лог одного провального прогона и условие задачи: {лог}.
Составь структурированный отчёт:
- Где агент отклонился от нужного поведения (шаг, цитата)
- Что он должен был сделать вместо этого
- Какая часть обвязки отвечает: Instruct / Equip / Act /
Observe / Remember / Terminate
=== ШАГ 2. Критерии из отчётов ===
Ты аналитик качества агентов.
{отчёты из шага 1}
{текущие критерии или «нет»}
1. Найди паттерны, повторяющиеся минимум в {мин_задач} разных задачах.
2. Сформулируй критерии: «Агент должен / не должен ...».
3. Критерий проверяется ТОЛЬКО по логу, без знания исхода.
4. Не дублируй существующие критерии.
5. Максимум {число} новых. Формат: ID | формулировка | как проверить.
=== ШАГ 3. Судья (outcome-blind) ===
Ты судья поведения агента.
Тебе НЕ сообщают, успешно ли завершён прогон. Оценивай только
поведение в логе.
Для критерия {критерий} и лога {лог} выдай один из вариантов:
- Satisfied — поведение встретилось и обработано правильно
- Violated — поведение встретилось и нарушено
- N/A — ситуация, на которую критерий рассчитан, не возникала
Дай краткую цитату-доказательство.
=== ШАГ 4. Подсчёт и отбор (в таблице, вручную или попросить модель) ===
Для каждого критерия:
- Различает: доля Violated в провалах vs в успехах
- Покрывает: какую долю провалов ловит
- Не дублирует другие критерии
- Birth check: убрать, если почти всегда N/A, не ловит
нарушения в провалах или срабатывает и в успехах, и в провалах
Оставь топ-{K} (в статье K = 10).
Пометь: probation → active → dormant → retired.
=== ШАГ 5. Кандидаты правок ===
Ты инженер обвязки агента.
{текущий системный промпт, описание инструментов,
правила памяти и остановки}
{топ-K критериев с примерами нарушений}
Предложи до 3 кандидатов правок. Каждый кандидат:
- Гипотеза: какой критерий и почему исправит
- Правки: не более 3 компонентов обвязки
- Конкретный новый текст
Правки одного кандидата вносятся вместе, не по отдельности.
=== ШАГ 6. Верификатор ===
Верификатор.
Для кандидата {кандидат}: соответствуют ли правки диагнозу и
доказательствам из логов? Ответь только ПРИНЯТЬ или ОТКЛОНИТЬ
и дай одну причину. Не переписывай кандидата и не оценивай,
улучшится ли результат.
=== ШАГ 7. Проверка (вне чата) ===
Прогони текущую версию и кандидатов на ОТДЕЛЬНОМ наборе задач.
Выбери лучшего. Прими, только если выигрыш больше порога {порог}.
Иначе оставь текущую версию.
Что подставлять: {лог} и {отчёты} — тексты прогонов вашего агента. {мин_задач} — 3 при 20 прогонах. {K} — 10 или меньше. {порог} — например, +5 процентных пунктов успеха на валидации.
🚀 Быстрый старт — вставь в чат:
Вот шаблон RuHarness для доработки инструкций агента по логам провалов.
Адаптируй под мою задачу: {опиши своего агента и что считается успехом}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, как выглядит твой агент и что считается «провалом», как выглядят логи, сколько их есть, и что именно можно править. Это нужно, чтобы критерии были проверяемыми по твоим логам, а правки попадали в то, что ты реально можешь менять.
Ограничения
⚠️ Нужен проверяемый исход. Метод опирается на сигнал «успех / провал» для каждой задачи и на отдельный набор задач для проверки. Если у агента нет ясного критерия успеха, цикл теряет якорь.
⚠️ Эффект умеренный. Против лучшего из конкурирующих методов прирост на новых задачах — около 4–5 пунктов. Метод не чудо, а аккуратная дисциплина доработки.
⚠️ Полная версия — код. Ранжирование критериев со статистикой (байесовские оценки, взвешенная формула) и прогон на сотнях задач в чате не воспроизвести. В чате получится упрощённая ручная версия, которую авторы не проверяли.
⚠️ Малые модели. Эксперименты шли на двух недавних открытых моделях средней силы, и они же были и агентом, и «доработчиком». На фронтирных моделях (Claude, GPT) результат не проверяли.
⚠️ Статичные критерии вредят. Если один раз составили чек-лист и больше не обновляете, лучше не использовать его вообще.
⚠️ Не раздувай пул. Больше критериев не значит лучше. В абляции использование всего пула вместо топа снизило результат.
Как исследовали
Авторы взяли пять областей агентной работы: поиск информации, математику, исправление багов в коде, написание кода и офисные задачи (знаниевая работа). Две открытые модели, Qwen3.5-35B-A3B и GLM-4.7-Flash, играли и агента, и «улучшателя». Сравнивали RuHarness с пятью современными методами самоулучшения: ACE, EvoSkill, Self-Harness, AHE и Meta-Harness. Задачи делили на три части: на одной эволюционируют, на второй проверяют кандидатов, на третьей, которую не видели, считают итог.
На новых задачах средний результат Qwen вырос с 44,2 до 53,7, а у лучшего конкурента — до 49,2. У GLM рост с 24,5 до 38,0 против 32,7 у лучшего конкурента. Разрыв между «знакомыми» и «новыми» задачами у RuHarness меньше: правки меньше подогнаны под учебные логи.
Самое интересное — абляция. Убрали рубрики совсем: на новых задачах 45,8. Оставили начальную рубрику неизменной: 44,4, то есть хуже, чем без рубрики. Использовали весь пул без отбора топ-10: 49,0 против 53,7 у полной версии. Вывод для практики: критерии полезны, только пока они свежие и отобранные.
Анализ показал, что список критериев после первых правок резко отдаляется от исходного, а потом меняется постепенно. Первые правки перекраивают картину слабостей, и дальше идёт тонкая настройка.
Адаптации и экстраполяции
🔧 Техника: судья не знает исхода → оценка поведения, а не результата
В любом ручном разборе агента скрывай исход диалога от оценщика (человека или модели). Добавь в промпт оценки:
Тебе не сообщают, чем закончилась задача. Оцени только,
соблюдено ли поведение: {критерий}. Ответ: Соблюдено / Нарушено / Не применимо + цитата.
Так критерий не превращается в «был провал → значит, нарушил».
Экстраполяция: ревизия CLAUDE.md после серии сессий (мой перенос принципа, авторы такого не проверяли).
Вот CLAUDE.md и {N} логов сессий, где ты (агент) ошибался или меня
приходилось поправлять.
1. Выведи до 10 повторяющихся поведенческих критериев
(«агент должен / не должен ...»).
2. Отметь критерии, которые уже соблюдаются (устарели) — убери их
из внимания.
3. Предложи до 3 правок CLAUDE.md под оставшиеся.
Каждая правка — конкретный текст.
Не переписывай файл целиком.
Через неделю повтори с новыми логами, а не с теми же.
Ресурсы
- Статья: When the Critic Falls Behind: Co-Evolving Rubrics and Harnesses for Continual Agent Self-Improvement (RuHarness).
- Авторы: Hao Chen, Yukun Yan, Ziyu Han, Ye He, Chuanzhe Guo, Shangzhan Li, Qi Shi, Qingfu Zhu, Maosong Sun, Wanxiang Che. Harbin Institute of Technology; Tsinghua University.
- Бенчмарк: EvoAgentBench (Gao et al., 2026). Базовый агент: DeepAgent (Li et al., 2026c).
- Сравнивали с: ACE, EvoSkill, Self-Harness, Meta-Harness, Agentic Harness Engineering.
- Часть анализа (раздел 5.4) и приложения в предоставленном тексте обрезаны. Промпты авторов, вероятно, в приложении.