Наблюдение за агентом с помощью модели принятия решений

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

1. Перед вызовом инструмента: разрешить или нет

Самое прямое место. Хук PreToolUse в Claude Code делает так:

Спросите Noul: эта команда оболочки строго только для чтения? Автоодобрять при 0.95, иначе вернуться к обычному запросу разрешений — и никогда не отклонять.

Три проектных решения стоит назвать:

• 0.95 — это высоко. Планка для автоодобрения стоит заметно выше планки для «это выглядит рискованно». Ложное разрешение стоит машины; ложная блокировка стоит одного лишнего подтверждения. Асимметричные стоимости принадлежат асимметричным порогам.
• Оно никогда не отклоняет. Оно лишь добавляет одобрение; всё остальное возвращается к исходной системе. Шлюз, который только добавляет возможности, куда легче тестировать — его худший случай в том, что он не помог.
• Опасные команды никогда не доходят до модели. Локальный жёсткий список запретов и фильтр инъекций ловят их первыми. Это важнее порога — см. Что должно жить в коде.

Измеренный результат: 0 из 8 команд, меняющих состояние, были автоодобрены.

2. Когда агент хочет остановиться: закончил ли он?

Ещё одно частое место. Хук остановки спрашивает у модели принятия решений, не завершает ли агент слишком рано, предъявляя ей свои правила завершения на простом языке.

Более сдержанная версия работает так:

Потратить один вызов из четырёх вопросов только когда файлы изменились и с тех пор не прошло ни одной успешной проверки. Fail open при любой ошибке.

«Спрашивай только когда стоит спрашивать» — ключ для этого класса — эти хуки запускаются каждый ход, а безусловный вызов умножает стоимость на число ходов. Условие выше — «непроверенные изменения», а это ровно тот момент, когда агент вероятнее всего объявит победу, ничего не проверив.

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

3. Когда контекст заполняется: что ещё нужно?

Третье место — уплотнение контекста, где подходы расходятся сильнее всего.

Традиционное уплотнение суммирует: отдать отрезок разговора модели и получить обратно прозу. Исходник пропадает, а суммирование необратимо.

Подход с моделью принятия решений не переписывает — он только оценивает:

Общая фраза: работа модели принятия решений здесь — бинарное суждение «оставить/убрать», а не переписывание. Именно это она умеет хорошо, а генеративные модели — плохо — и «сложить вместо удаления» превращает неверное суждение из «информация потеряна навсегда» в «одно лишнее expand».

Контраргумент: шлюзы безопасности и шлюзы эффективности отказывают в противоположные стороны

Самый поучительный контраст в этой части экосистемы: на один и тот же вопрос «что происходит при ошибке» проекты выбрали противоположные ответы, и оба правы.

• Судья разрешений: отказывать при ошибке или таймауте.
• Хук остановки: разрешать при любой ошибке.

Критерий — не «что безопаснее», а охраняет ли этот шлюз риск или пропускную способность. Шлюзы, охраняющие риск (разрешения, секреты, опасные команды), лучше заблокируют хорошее, чем пропустят плохое; шлюзы, охраняющие пропускную способность (проверки завершения, проверки формата), лучше пропустят что-то, чем парализуют поток.

В одном предложении

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