Что на самом деле делают новые модели принятия решений
Модель принятия решений — это небольшой быстрый классификатор, который выбирает одну из ветвей. В агентных системах она отвечает на вопросы: какой инструмент должен обработать этот запрос, должен ли планировщик продолжить или эскалировать, какому субагенту следует передать задачу. Модель не хранит учётные данные, бюджеты или долговременное состояние. Она выдаёт метку или структурированный выбор. Затем этот выбор используется вызывающей стороной, которая как раз всем этим располагает.
Бюджеты задержки вынуждают модель видеть сжатое представление выполнения. Чтобы вернуть решение за доли секунды, роутер получает сводку: последние ходы, описание задачи, возможно, список доступных инструментов. Он не видит полный трейс выполнения, накопленные затраты, права пользователя или побочные эффекты предыдущих ветвей. Его решения по построению неполны. Это не дефект; это компромисс проектирования, который делает роутер достаточно дешёвым для частого вызова. Но это означает, что роутер не может быть компонентом, гарантирующим соблюдение ограничения.
Опубликованные бенчмарки для этих моделей измеряют точность маршрутизации на отложенных наборах задач. Они не измеряют сдерживание: может ли неверная ветвь привести к несанкционированному действию, превышению бюджета или утечке данных. Точность и сдерживание — разные свойства. Роутер может быть очень точным и при этом оставаться небезопасной точкой принуждения, если вызывающая сторона считает его вывод авторитетным.
Категориальная ошибка: маршрутизация против принуждения
Принуждение требует компонента, который может отказать. Роутер рекомендует; средство принуждения отказывает. Если роутер носит рекомендательный характер, вызывающая сторона решает, следовать ли рекомендации. Если роутер авторитетен, ему нужны журнал аудита, способ аутентификации входных данных и безопасный режим отказа при ошибке модели. Большинство моделей принятия решений не предоставляют ничего из этого. Они не являются точками принятия политических решений в смысле XACML, которые оценивают запрос по политике и возвращают решение permit или deny с обязательствами. Модель принятия решений возвращает метку ветви. Разница не семантическая; она архитектурная.
Рассмотрим конкретный механизм. Предположим, роутер выбирает между инструментом read_file и инструментом write_file. Роутер видит сжатое представление: пользователь попросил «обновить конфиг». Он выбирает write_file. Если вызывающая сторона воспринимает это как разрешение, запись выполняется. Роутер никогда не проверял, есть ли у пользователя доступ на запись, защищён ли файл или не превышает ли изменение бюджет. Эти проверки относятся к средству принуждения ниже по потоку. Если средство принуждения отсутствует, режим отказа не устраняется; он перемещается с точности роутера на доверие вызывающей стороны.
Честный компромисс в том, что принуждение добавляет задержку и сложность. Средство принуждения ниже по потоку должно оценивать политику, что может требовать обращений к состоянию, криптографических проверок или внешних вызовов. Именно из-за этой стоимости команды поддаются искушению встроить принуждение в роутер. Но быстрый классификатор не может нести вес политики-движка, не став им, а в этот момент он уже не 2B-роутер.
Правило размещения: внутри цикла планировщика, никогда на пути выхода
Помещайте модели принятия решений внутрь цикла планировщика, где они могут формировать план до возникновения каких-либо побочных эффектов. Никогда не размещайте их на пути выхода, где их вывод напрямую запускает внешнее действие. Цикл планировщика может выдержать неверную ветвь, потому что план всё ещё подлежит проверке, симуляции или принуждению ниже по потоку. Путь выхода — нет.
Сопоставляйте каждый роутер со средством принуждения ниже по потоку, которое отказывает безопасно. Средство принуждения должно быть отдельным компонентом с собственной политикой, собственными учётными данными и собственным журналом аудита. Оно должно быть способно отказать в действии, даже если роутер его рекомендовал. Средство принуждения должно отказывать безопасно: если оно не может оценить политику, оно запрещает. Это противоположность режиму отказа роутера, который заключается в угадывании.
Логируйте снимок входных данных роутера, а не только метку его вывода. Снимок входных данных — это сжатое представление, которое модель фактически видела. Без него неверная ветвь необъяснима. С ним вы можете восстановить, почему роутер выбрал именно так и не опустило ли сжат
Последствия для оценки
Оценки роутера нуждаются в состязательных входных данных, а не в отложенных наборах задач. Отложенный набор измеряет, как часто роутер соглашается с меткой. Состязательный набор измеряет, что происходит, когда роутер ошибается: вызывает ли неверная ветвь вред или средство принуждения его ловит? Второй вопрос — тот, что важен для безопасности.
Измеряйте стоимость неверной ветви, а не точность ветви. Для каждого возможного ошибочного маршрута оцените наихудший исход: несанкционированная запись, превышение бюджета, утечка данных, зацикливание. Если стоимость ограничена средством принуждения ниже по потоку, точность роутера — это метрика производительности. Если стоимость не ограничена, роутер — это замаскированная точка принуждения, и это дефект проектирования.
Это переосмысливает цель оценки. Вместо вопроса «как часто роутер выбирает правильный инструмент?» задайте вопрос «каков радиус поражения, когда он выбирает неправильный?» Ответ определяет, может ли роутер быть дешёвым и неполным или его нужно заменить точкой принятия политических решений.
Что это означает для агентных архитектур
Модели принятия решений, такие как Amazon's Strands Decider и Cloudflare's Clef, — полезные примитивы маршрутизации. Они снижают стоимость ветвления и делают агентные циклы более отзывчивыми. Но они не являются поверхностями управления. Рассмотрение их как таковых перемещает режим отказа, а не устраняет его. Правильный паттерн — многослойный: быстрый неполный роутер внутри цикла планировщика, средство принуждения ниже по потоку, которое отказывает безопасно, и журнал аудита, записывающий снимок входных данных роутера. Этот паттерн принимает ограничения роутера и возлагает бремя принуждения туда, где оно должно быть.
Компромисс явен: вы платите за принуждение задержкой и сложностью и получаете сдерживание. Вы не можете получить сдерживание от классификатора, который никогда не видит полное состояние и не может отказать. Инженерная работа — разместить роутер там, где его неполные решения безопасны, и построить средство принуждения, которое ловит остальное.