Наблюдения за экосистемой Jev (часть 2): 30 проектов по защите агентов — что они блокировали, а что пропустили

В предыдущей статье мы сделали обзор первых четырёх дней развития экосистемы Jev. Здесь подробно разбираем главный сценарий — надзор за агентами. За 72 часа после выпуска Jev компанией TypeSafe только в категории «безопасность и надзор за агентами» появилось более 30 проектов. К четвёртому дню быстрая коммодитизация заставила специалистов назвать эту нишу «красным океаном», что подтверждает реальный спрос. В статье мы делим эти проекты на четыре типа, сравниваем их на кейсах с числовыми данными и отвечаем на практический вопрос: какой защитный механизм выбрать для вашего агента?

Сначала о доказательной базе: приведённые ниже цифры по проектам заявлены их авторами (с оценками A/B/C по силе доказательств), а задержки и стоимость измерены на уровне проектов. Полный репозиторий кейсов доступен в jev-radar, для каждой записи указан первоисточник.

Почему защитные механизмы вдруг заработали

Защитные механизмы для агентов — не новая идея; раньше их внедрению мешала экономика. Чтобы LLM оценила, опасен ли вызов инструмента, требовалось несколько секунд и несколько центов на один инференс. Встраивание такой проверки в каждый шаг цикла агента приводило к тайм-аутам. В README pi-warden приводится новый расчёт: около 1 000 входных токенов, около $0,00004 и примерно 0,3 секунды на проверку (по данным автора). Впервые стало практически целесообразно запускать проверку при каждом вызове защитного механизма. Поэтому защитные механизмы и стали главным сценарием: снижение задержки и удельной стоимости превратило пошаговый надзор из роскоши в настройку по умолчанию.

Четыре архитектуры защитных механизмов

Если разделить 30+ проектов по тому, что они оценивают и блокируют ли они, получится четыре разных подхода:

• Теневой надзор: оценивает соблюдение правил, шум, топтание на месте и заявления о завершении без тестов. Ничего не блокирует, а добавляет оценки в контекст для самокоррекции. Примеры: pi-warden, Foreman.
• Жёсткие границы с оценкой серой зоны: оценивает вызовы вне белого списка. Блокирует, но приоритет у жёстких правил, а Jev оценивает только серую зону. Примеры: jevgate, rh-guard.
• Шлюзы одобрения: служат последним барьером перед дорогими или рискованными шагами и блокируют их до проверки человеком или понижают уровень. Примеры: toolgate, noulgate, hermes-approvals.
• Сверка заявлений: сверяет заявления агента с тем, что произошло на самом деле, и выявляет расхождения после выполнения, без блокировки в реальном времени. Пример: clear-head.

У теневого надзора самая сильная доказательная база. pi-warden с помощью Jev проверяет операции записи на соответствие файлам правил проекта и добавляет сведения о нарушенных правилах в контекст агента. Агент получает поправку без вмешательства пользователя. Стоит обратить внимание на две метрики, приведённые автором: в 150 парных headless-запусках правила нарушались 6 раз при отключённой защите и 0 раз при включённой. В 321 реальной сессии и 17 160 вызовах защитного механизма выполнение было приостановлено всего 42 раза: в 5 случаях блокировку сняло следующее сообщение автора, а в 37 она осталась в силе. Эффективная защита вмешивается редко, а не блокирует всё подряд. Ещё одна деталь: когда возможность выявлять уход от задачи показала слабые результаты в тестах автора, её не удалили, а понизили до мягкой подсказки.

Сочетание жёстких границ с оценкой серой зоны стоит взять на вооружение. rh-guard нацелен на манипулирование вознаграждением (reward hacking) у агентов для программирования: вмешательство в работу проверяющих систем, просмотр скрытых тестов или манипуляции процессом оценки. Архитектурный принцип зафиксирован в README: сначала запросы отклоняют структурированные жёсткие правила, а Jev оценивает оставшуюся серую зону. В записанных демо изменения проверок assert с помощью sed блокируются, а безобидные команды echo проходят. Разработчики из того же семейства формулируют принцип ещё прямее: jevgate служит белым списком разрешённых операций, Jev оценивает всё, что находится за его пределами, а мягкие оценки никогда не дают права на единоличное вето (fail-open). Калибровка вероятностей может давать сбои, поэтому вероятностная оценка не может служить единственным барьером. В этом семействе даже появился слой проектных решений (Augustus), который отвечает на вопрос, когда Jev использовать не стоит.

Шлюзы одобрения ставят контрольную точку перед дорогими шагами. hermes-jev-approvals приводит редкие сравнительные цифры: по данным автора, он в 8,7 раза быстрее и в 4 раза дешевле исходного решения. toolgate по умолчанию работает в теневом режиме: только наблюдает и ведёт логи, пока не будет установлено доверие, и лишь затем начинает блокировать.

Сверка заявлений — самый новый и лёгкий подход: когда агент сообщает о завершении, clear-head сверяет то, что агент якобы прочитал, с реальными чтениями с диска и ловит именно невыполненные заявления.

Контрпример

Бенчмарк WebMCP (nekuda-ai, с открытым исходным кодом и воспроизводимый) помогает трезво оценить проекты защитных механизмов: Jev без дополнительного слоя, подключённый к браузерной обвязке, успешно решил 25 из 49 веб-задач, а добавление слоя WebMCP, который сжимает последовательности кликов в одиночные вызовы инструментов, повысило результат до 49/49. Этот вывод применим и к проектированию защиты: выбрать правильную допустимую кнопку — не то же самое, что выбрать правильный следующий шаг. Ценность слоя суждений зависит от переданного ему представления состояния. То же верно для защитных механизмов: узкие вопросы и точные состояния дают надёжные оценки.

Если вы внедряете защитный механизм

Пять принципов проектирования, выведенных из 30+ проектов, в порядке важности:

1. Сначала жёсткие правила, Jev — для серой зоны: задачи, которые можно выразить белыми списками и структурированными правилами, не должны зависеть от вероятностных оценок. Jev обрабатывает то, что правила не покрывают.
2. Fail-open: мягкие оценки никогда не дают единоличного вето. Откалиброванные вероятности могут ошибаться, и при сбое нужно запрашивать проверку человеком, а не останавливать процесс.
3. Теневой режим до принудительного применения: сначала ведите журнал и сохраняйте данные без вмешательства, а перед включением блокировки оцените долю ложных срабатываний — именно так по умолчанию работает toolgate.
4. Узкие вопросы: проверяйте отдельные критерии с чётким набором ответов — например, необратимость действия или его соответствие намерению, — вместо субъективной оценки качества (урок Supercov напрямую применим к защитным механизмам).
5. Ограничивайте возможности, показывающие слабые результаты, вместо того чтобы удалять их: если сохранить такую возможность, но урезать её права, полезного сигнала останется больше, чем при полном удалении (как в подходе pi-warden к выявлению ухода от задачи).

Возможности за пределами красного океана

После того как более 10 проектов реализовали один и тот же подход, пути дифференциации для новых проектов стали очевидны: ориентироваться на специализированные среды (jury.nvim для Neovim, jev.el для Emacs, git-judge-jev для GitHub Actions, плагины OpenCode), осваивать новые типы оценок (целостность процесса оценки в rh-guard, сверка заявлений в clear-head) или сосредоточиться на слое проектных решений (Augustus о том, когда Jev использовать не стоит). Вывод для новичков: ниши универсальных защитных механизмов заняты, но каждая новая среда и каждое новое нарушение границ создают новую точку для защитного шлюза.

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