Harness engineering: контроль правил агента и где ломается

Вы дописали правило в .cursor/rules. Агент его прочитал, согласился и через два хода сделал ровно то, что правило запрещает. Иногда с извинением: да, правило было, я его нарушил.

Другой день, другой проект: правило на месте, но в контекст оно не попало вообще, и узнать об этом было неоткуда. Третий случай: попало всё сразу, вместе с вложенными AGENTS.md со всего дерева проекта, и половина окна ушла на инструкции ещё до первой строки кода.

Причины у этих трёх случаев разные: в первом правило конкурирует с задачей внутри промпта, во втором не доходит до модели, в третьем доходит вместе с сотней чужих. Общее одно: вы создали файл в папке проекта, открытой в Cursor, и считаете, что задали агенту дисциплину.

Текст правила не обещает соблюдения

Границу здесь обозначили сами разработчики среды. В треде на форуме Cursor человека спрашивают, как добиться, чтобы агент выполнял требование каждый раз. Отвечает сотрудник Cursor под ником deanrie: “Rules and AGENTS.md get injected into context, but they are a soft constraint”. Правила подмешиваются в контекст, но остаются мягким ограничением.

Механика за этой фразой простая. Правило становится частью промпта и конкурирует там с задачей пользователя, историей чата и системной инструкцией. Модель взвешивает всё это вместе, и «не делай X» проигрывает прямому «сделай Y», особенно когда X выглядит коротким путём к Y. Отсюда и извинения: правило действительно было в контексте, агент его действительно видел, соблюдение из этого не следует.

Запрет, который среда не даст нарушить, живёт не в тексте, а в правах: разрешения инструмента и hooks с deny, где команда просто не выполняется. Деструктивные операции git, удаление файлов, миграции на живой базе. Если у вас на это стоит капсом NEVER в .mdc и больше ничего, у вас пожелание, а не запрет.

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

Что реально лежит в этих файлах

Чаще всего чужой текст. Коллекция awesome‑cursorrules собрала больше 40 тысяч звёзд, и пользуются ей просто: нашли файл под свой стек, скопировали в .cursor/rules/, поставили в шапке alwaysApply: true. Привычка старше нынешнего формата: разбор публичных .cursorrules, того самого одного файла в корне проекта, который Cursor уже считает устаревшим, показал 28,7% дословных копий. Формат сменился на .mdc в .cursor/rules/, способ наполнения остался.

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

Своё правило под свой сбой работает. Но писать его руками не нужно: дайте агенту сбой, документацию инструмента и границу, формулировку он выдаст сам.

Ноль срабатываний или шестьсот тысяч токенов

Один и тот же файл ломается в двух противоположных режимах.

Первый: правило не подмешалось. На форуме Cursor есть аккуратный замер, который легко повторить: два идентичных .mdc, в каждом запуске у агента спрашивают, какое правило активно. С alwaysApply: true правило сработало три раза из трёх, с false ноль из трёх. Сюда же попадает .md без YAML‑шапки в .cursor/rules/: среда такой файл может не читать, а выглядит он как полноценное правило. Часть жалоб «агент игнорирует мои правила» это ровно такой случай: правила в контексте не было.

Второй: подмешалось всё. В монорепозитории Cursor собирает правила и вложенные AGENTS.md со всего дерева, и на простой запрос это выливается в сотни тысяч токенов инструкций, в одном описанном случае около 600k. У Claude Code та же беда по другой причине: правила подмешиваются заново на каждый вызов инструмента, и одни и те же строки уезжают в контекст десятки раз за задачу.

Обе поломки не лечатся спором «.mdc или skills» и «мигрировать ли на AGENTS.md». Первая про загрузку, вторая про бюджет. Формат не отвечает ни на один из этих двух вопросов.

У меня так и устроено: каждый сбой агента я записываю отдельной строкой в файл рядом с проектом, и когда строка повторяется, правило по ней формулирует агент. Замера «копипаст против агента» на одном стеке я не проводил, так что это моя практика, а не результат сравнения. Про блокировки и цикл до merge есть отдельный разбор, здесь я его не повторяю.

Пять проверок в своём проекте

Всё это делается в открытом окне, минут за десять.

1. Спросите агента в новом чате, какие правила у него сейчас активны. Файла нет в списке — дальше разбираться незачем, правило до модели не доходит.

2. Откройте шапку каждого файла. alwaysApply: true грузится всегда, false только при совпадении globs. Во втором случае проверьте, что маска попадает в те файлы, которые агент действительно правит.

3. Сложите строки всех файлов с alwaysApply: true. Это ваш постоянный расход на каждый запрос, до первой строки задачи.

4. Если у вас монорепозиторий, посмотрите, сколько вложенных AGENTS.md подтянулось на обычный вопрос. Ответ обычно неприятный.

5. Прочитайте своё правило, подставив вместо одного проекта другой. Смысл рассыпался — вы описали частность, а не правило.

Дальше начинается то, ради чего проверки и нужны: переписать правило по своим сбоям. У меня для этого есть рецепт, папка recipes/rule-under-a-job/. Там разобрано, из чего состоит правило, как убедиться, что оно срабатывает, и лежат готовые промпты. Их копируете в чат, а текст правила пишет агент из вашего сбоя и документации вашего инструмента. Готовых правил там нет, и это не упущение: моё правило подошло бы вам ровно так же, как файл из коллекции. Рецепт даёт способ, а не текст.

Цифры и цитаты сняты с публичных URL в августе 2026, ваша версия Cursor или Claude Code может вести себя иначе.

Что вы проверяли первым: подмешивание, объём того, что грузится всегда, или нарушение после извинения? И отдельно любопытно: копируете готовые правила с GitHub или поручаете их агенту?