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

ЦИКЛ (пока агент не закончил):
  агент предлагает шаг (мысль + действие)

  если прошло I шагов с прошлой проверки:
    МОНИТОР (LLM) читает: задачу + шаги с прошлой проверки + предложенный шаг
      → вердикт: advisory | replacement + текст подсказки

    advisory (здоров или мелкие огрехи):
      шаг ВЫПОЛНЯЕТСЯ → подсказка добавляется в контекст
      → интервал: I = min(I + 2, 20)

    replacement (сбился с цели, повторяет неудачи):
      шаг ОТБРАСЫВАЕТСЯ → подсказка в контекст → агент переделывает шаг
      → интервал: I = 5

  иначе: шаг просто выполняется

Стартовые параметры: базовый интервал 5, прирост 2, максимум 20.

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

Задача: Вы чините с помощью Claude Code баг в интернет-магазине на Django. После оплаты через ЮKassa заказ остаётся в статусе «ожидает оплаты». Агент уже 10 шагов правит обработчик вебхука и гоняет одни и те же тесты, а они всё красные. Вы подозреваете, что он ковыряет не тот файл.

Промпт (во второй чат-монитор, на шаге проверки):

Ты — надзиратель за кодирующим агентом. Ты не чинишь баг сам.
Ты оцениваешь, здорово ли идёт работа, и выбираешь тип вмешательства.



Баг: после успешной оплаты через ЮKassa заказ остаётся в статусе
«ожидает оплаты». Нужно найти причину и исправить.



Шаги 6–10 агента (мысль → действие → результат):
6. Решил, что вебхук приходит с другой подписью → правит verify_signature() → тесты красные
7. Снова правит verify_signature() → тесты красные
8. Добавил логирование в обработчик → лог пустой
9. Снова правит verify_signature() → тесты красные
10. Предлагает ещё раз изменить verify_signature()



Здоровая работа: есть устойчивый прогресс к решению, возможны мелкие
огрехи в отдельных шагах.
Нездоровая работа: агент ушёл от цели, прогресса нет, повторяются
одни и те же неудачные попытки.



Verdict: advisory ИЛИ replacement
Guidance: 2–4 предложения — что агенту делать дальше

Результат: Монитор оценит последние шаги и скорее всего признает работу нездоровой: повторяются однотипные правки без результата, а пустой лог намекает, что вебхук, возможно, до обработчика не доходит. Вы получите вердикт replacement и короткую подсказку для агента, например сменить гипотезу и проверить маршрут или получение вебхука. Предложенный десятый шаг вы не даёте агенту выполнить и просите его переделать шаг с подсказкой. Следующую проверку делаете через 5 шагов, а не через 10.

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

Сильная сторона LLM. Модель хорошо читает короткий фрагмент работы и отвечает на узкий вопрос: идёт ли прогресс. Диагностика сбоев хорошо представлена в обучающих текстах (разборы отладки, форумы), а длинные траектории восстановления после ошибок — редкость. Авторы объясняют успех тем, что задача монитора превращается из «реши задачу» в «оцени здоровье последних шагов». Это их гипотеза, прямо они её не проверяли.

Как метод это использует. Монитор получает узкий кусок траектории и высокоуровневое определение «здоров / нездоров». Определение намеренно не привязано к типам ошибок: разные агенты по-разному справляются с одной и той же ошибкой. Вердикт заодно служит «пульсом» для расписания. Это даёт рычаги:

• Базовый интервал (5): для коротких задач уменьшайте, для длинных и дорогих — увеличивайте.
• Прирост и максимум (+2, 20): растёт только после совета. Чем больше максимум, тем меньше расход на надёжном агенте.
• Два уровня вмешательства: если «замена» пугает (нельзя отменять шаги), оставьте только совет, но теряете способность ломать цикл ошибок.
• Определение здоровья: подгоняйте под свой тип задач, но держите на уровне «есть ли прогресс», а не «нет ли ошибки X».
• Сильный монитор: авторы подчёркивают, что декомпозиция не заменяет мощную модель. Слабый монитор остаётся слабым.

Точный промпт из Рис. 4 статьи в доступном тексте не воспроизведён. Шаблон ниже собран по описанию: сохранены высокоуровневое определение здоровья, два уровня вмешательства и работа с отрезком траектории.

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



{описание_задачи}



Шаги с прошлой проверки до текущего (мысль → действие → результат):
{последние_шаги}



Шаг, который агент собирается выполнить (ещё НЕ выполнен):
{предложенный_шаг}



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



1. Сравни последние шаги с целью задачи: приближают ли они к решению?
2. Найди повторы: нет ли одних и тех же неудачных попыток?
3. Оцени предложенный шаг: он продолжает прогресс или усугубляет сбой?
4. Если здоровье удовлетворительное → advisory.
   Если нездоровое → replacement.



Verdict: advisory | replacement
Guidance: 2–4 предложения для агента
  (advisory — как действовать дальше;
   replacement — почему шаг отброшен и что сделать вместо него)

Правило интервала (для вас или оркестратора):

Старт: проверять каждые {базовый_интервал} шагов.
После advisory: интервал + {прирост}, но не больше {максимум}.
После replacement: интервал снова = {базовый_интервал}.

Что подставлять: {описание_задачи} — исходная постановка, {последние_шаги} — шаги с прошлой проверки (скопируйте из лога агента), {предложенный_шаг} — шаг, который агент хочет выполнить. Интервалы из статьи: 5 / 2 / 20.

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

Вот шаблон монитора для кодирующего агента (метод Cadence). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

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

LLM спросит про цель задачи, как выглядят шаги вашего агента и сколько шагов обычно в сессии. Эти данные нужны, чтобы настроить определение «здоровья» и подобрать стартовый интервал. Она возьмёт структуру из шаблона и адаптирует её под вашу работу.

⚠️ Нужен код, а не только промпт: полноценный Cadence — это планировщик плюс отбрасывание шага до выполнения. В готовых агентах (Claude Code, Cursor) это вручную не воспроизвести: в лучшем случае имитация через второй чат и ручное копирование шагов.

⚠️ Один бенчмарк и один тип задач: проверка шла только на исправлении багов в Python-репозиториях. Авторы говорят, что метод обобщается, но на других типах задач (новые фичи, не-Python, нетестируемые задачи) в доступном тексте этого не показано.

⚠️ Нужен сильный монитор: декомпозиция не заменяет мощную модель. Слабая модель-надзиратель ошибётся в оценке здоровья, а ошибочный вердикт «замена» выбросит хороший шаг.

⚠️ Дополнительные токены и вызовы: надзор стоит денег. Метод экономнее конкурентов, но дороже агента без надзора.

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

Сначала авторы показали, чем плохи существующие подходы. Они взяли 300 задач SWE-bench Lite и прогнали агента без надзора. Получились 145 решённых и 155 нерешённых задач. Два эксперта вручную просмотрели все траектории и подтвердили, что группы реально различаются: в одной агент шёл по делу или сам оправлялся от мелких промахов, в другой накапливались необратимые сбои. Дальше они ставили монитор с фиксированным интервалом 3, 5, 9 и 15 шагов.

Получилась зеркальная картина. У «здоровых» запусков успех почти не зависел от интервала (≥88%), а токены падали с ростом интервала (0,45M → 0,30M). У «больных» редкий надзор ронял долю решённых с 23,87% до 14,19%. Отсюда идея: интервал должен зависеть от состояния агента.

Затем проверили правила-триггеры на мониторе LivePlan. Из 300 задач агент не справился в 152, и в 35 из них монитор не сработал ни разу. Эксперты разобрали эти случаи и выделили три типа необнаруженных ошибок: неверное место правки, неверная логика и неполная правка. Все они — ошибки рассуждения, а не внешние сбои.

Cadence сравнивали с фиксированным интервалом, LivePlan, статичными правилами и агентом без надзора, на двух агентах (mini-swe-agent и Moatless). Результат: +76 решённых задач (+25,33 п.п.) на первом и +47 (+15,67 п.п.) на втором. Расход токенов на задачу: 1,03M против 1,47M у сильнейшего аналога на mini-swe-agent и 0,48M против 0,51M на Moatless. Неожиданный и полезный практический вывод: проблема не в том, «умеет ли монитор давать советы», а в том, когда он их даёт.

🔧 Техника: ручной «пульс» в инструкции агенту → самопроверка по расписанию

Если у вас Claude Code или похожий инструмент, полноценный внешний монитор не нужен. Попросите агента самого делать стоп-проверку. Это моя адаптация, в статье такой версии нет, и эффективность самопроверки не измерена:

Каждые 5 шагов останавливайся и выполняй чек-здоровья:
1. Я приблизился к цели или хожу по кругу?
2. Повторял ли я одно и то же неудачное действие?
3. Не правлю ли я не то место?
Если всё ок — напиши «ок» и продолжай, следующая проверка через 7 шагов (потом 9, до 20).
Если нет — откажись от последнего шага, смени гипотезу,
а следующую проверку проведи через 5 шагов.

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

• Работа: Cadence: Strategic Guidance for Coding Agents
• Авторы: Minxing Wang, Yintong Huo (Singapore Management University); He Ye, Earl T. Barr (University College London)
• Бенчмарк: SWE-bench Lite (300 задач)
• Агенты в экспериментах: mini-swe-agent, Moatless
• Сравнение с: Wink (периодический надзор), LivePlan (надзор на правилах)