Архитектура доверия: почему правила ИИ-агентов часто нарушаются и как их исправить
Интеграция правил в среду разработки ИИ, такие как Cursor, часто превращается в битву за внимание модели. Разработчики сталкиваются с парадоксальной ситуацией: правила прописаны, агент «соглашается» с ними, но через пару шагов выполняет запрещённое действие. Анализ механизмов работы показывает, что текстовые директивы остаются лишь мягкими ограничениями, конкурирующими с задачей пользователя, тогда как истинный контроль возможен только через жесткие системные права и хуки.
# Harness engineering: реальность контроля правил агента
В современной разработке с использованием ИИ-агентов возникла новая дисциплина, которую можно назвать "harness engineering" — инженерией управления. Эта практика направлена на обеспечение дисциплины агента, однако на практике она сталкивается с фундаментальными ограничениями контекстной модели.
Механика мягких ограничений
Разработчики часто создают файлы правил (например, в .cursor/rules), полагая, что это устанавливает жесткие границы поведения. Однако, согласно заявлениям сотрудников компании Cursor, эти правила являются "мягким ограничением" (soft constraint).
Внутри промпта происходит сложное взвешивание факторов: директивы из файлов правил конкурируют с историей чата, системными инструкциями и, что критически важно, с текущей задачей пользователя. Если прямо в запросе содержится указание выполнить действие Y, а правило запрещает его (директива не делай X), модель, стремясь эффективно решить поставленную задачу, может игнорировать запрет. Это объясняет типичные сценарии, когда агент нарушает правила с последующими извинениями: он не "забыл" правило, он просто посчитал задачу пользователя более приоритетной в момент генерации.
Техническое пояснение: В системах промптинга используется механизм внимания, где модель оценивает релевантность каждой части контекста. Если текст запрета краток и конфликтует с длинным и детализированным описанием задачи, вес задачи будет выше. Это не баг, а особенность архитектуры больших языковых моделей.
От текста к правам: истинный контроль
Запрет, который гарантирует соблюдение, не может существовать только в виде текста. Реальный контроль реализуется на уровне доступа и прав.
* Права инструментов и хуки: Для критически важных операций (удаление файлов, деструктивные миграции баз данных) необходимо использовать права доступа и хуки с функциями deny. В этом случае команда не будет исполняться вовсе, независимо от того, как модель интерпретировала промпт. * Бинарная логика: Если в документации к среде (например, в .mdc) указано NEVER для определенных действий, это становится механическим запретом, а не текстовой рекомендацией.
Практический вывод заключается в разделении требований на два класса: 1. Жесткие запреты: Уходят в права доступа и хуки безопасности. 2. Рекомендации по стилю: Описываются в текстовых правилах, с пониманием того, что они могут быть нарушены при прямом конфликте с задачей.
Проблемы контекста: копипаст и наводнения
Существует еще одна причина, почему правила перестают работать — это механизм их загрузки в контекст.
Чужой текст вместо своего решения
Разработчики часто копируют готовые коллекции правил (например, из репозиториев с 40 тысячами звёзд на GitHub) и добавляют их в проекты. Несмотря на то, что форматы эволюционировали от .cursorrules к .mdc, практика дословного копирования осталась массовой. Чужие правила описывают сбои, не относящиеся к текущему проекту, что разбавляет контекст лишней информацией.
Более эффективный подход: предоставить агенту данные о сбое, документацию инструмента и попросить его сформулировать правило самостоятельно. Это гарантирует, что правило будет адресным.
Экономия токенов и переполнение окна
В монорепозиториях системы могут собирать правила и вложенные файлы AGENTS.md со всего дерева проекта. Это приводит к ситуации, когда на простой запрос отправляется сотни тысяч токенов инструкций (в некоторых случаях около 600k).
Две противоположные проблемы: 1. Отсутствие загрузки: Файл правил физически не попадает в контекст из-за ошибок конфигурации (например, отсутствие правильной YAML-шапки или использования устаревшего формата .md). 2. Переполнение контекста: Правило попадает, но вместе с ним загружается огромный массив чужих инструкций, отнимая место у самой задачи пользователя.
Аудит и гигиена правил
Для предотвращения этих проблем рекомендуется регулярная проверка активной среды агента:
1. Проверка загрузок: Запросите у агента в новом чате список его активных правил. Если файла нет в списке, он физически не был загружен. 2. Настройка флагов: Всегда проверяйте настройки alwaysApply: true. Флаги false работают только при совпадении масок (globs), и агент может править файлы, которые не попадают под эту маску. 3. Аудит объема: Просуммируйте количество строк во всех файлах с alwaysApply: true. Если объем огромен, это создает постоянный overhead на каждый запрос. 4. Специфичность: Попробуйте подставить правило в контекст другого проекта. Если смысл исчезает, правило описывает частную особенность, а не универсальное правило.
Рекомендуется формировать правила по фактам: фиксируйте каждую ошибку агента в отдельном файле, и давайте агенту инструкцию переработать это в правило на основе документации. Это создаст адаптивную систему управления, реагирующую на реальные сценарии вашего кода, а не на абстрактные шаблоны.
Цитата из форума разработчиков Cursor
"Rules and AGENTS.md get injected into context, but they are a soft constraint."
(Перевод: "Правила и AGENTS.md встраиваются в контекст, но они остаются мягким ограничением.")
---
*Авторский комментарий: В мире, где мы стремимся делегировать сложные когнитивные задачи алгоритмам, мы часто забываем, что ИИ — это не слуга, а партнер, который пытается угадать ваше намерение. Дисциплина агента строится не на текстах, а на четком разделении того, что для системы недопустимо (права доступа), и того, что является просто желаемым стилем работы.*