Введение: проблема избыточной настройки
Современные LLM-агенты всё чаще берут на себя управление критической инфраструктурой — от систем охлаждения до электросетей. Но чтобы агент мог работать, ему нужно окружение, которое определяет доступные данные, инструменты и допустимые действия. В большинстве систем это окружение одинаковое для всех задач: полный набор прав, вся доступная информация, все возможные функции.
Такой подход кажется универсальным, но у него есть существенные минусы. Во-первых, это лишние затраты: каждый запрос к полному набору инструментов обрабатывает большой объём данных, тратит токены и время. Во-вторых, избыток возможностей может мешать: агент может «утонуть» в лишней информации или выбрать неверный инструмент. В-третьих, управление правами и безопасность тоже страдают, когда агент имеет доступ ко всему сразу.
Подход: сопоставление ресурсов задачи и возможностей
Ключевая идея исследователей — рассматривать настройку harness как задачу сопоставления ресурсов. У каждой задачи есть требования к данным, инструментам и действиям, а у окружения — предоставляемые возможности. Надо найти оптимальное соответствие, а не выдавать максимальный набор «на все случаи».
Для этого задачи, возникающие при управлении критической инфраструктурой, классифицируют на основе математического описания управляемой системы. Например, задача контроля температуры в жидкостном охлаждении отличается от задачи балансировки нагрузки в электросети: у них разные параметры, временные масштабы и риски.
Конфигурации harness, в свою очередь, ранжируются по количеству и типу информации, которую они дают агенту. Так формируется карта возможных «степеней свободы» для каждой категории задач.
Откуда берутся карты соответствий
Карты «задача — harness» строятся двумя способами. Первый — анализ профильной литературы: что обычно используют агенты при решении конкретных задач? Второй — измерение реального поведения агентов в контролируемых экспериментах: что реально нужно, а что не влияет на результат. Это даёт более надёжную основу, чем чисто теоретические предположения.
Алгоритм управляемой эскалации
На основе таких карт авторы предлагают алгоритм map-guided escalation. Агент сначала получает минимальный набор прав, который соответствует его задаче по карте. После выполнения работы агент проводит самопроверку: достаточно ли было ресурсов, правильно ли решена задача? Если самопроверка показывает неудачу, harness расширяется — возможно, до следующего уровня или до полного. Этот цикл повторяется до тех пор, пока задача не будет решена успешно или не будет достигнут максимум.
Прелесть подхода в том, что он не требует априорно выбирать настройки для каждой задачи — эскалация происходит автоматически и только тогда, когда это необходимо. Простые задачи почти всегда решаются с минимальным набором, а сложные получают дополнительные ресурсы по мере необходимости.
Эксперименты: что показали тесты
Исследователи проверили подход на двух сценариях. В жидкостном охлаждении точность агента при использовании нового метода составила 0.715, что выше, чем 0.652 при полном provision. При этом расход токенов оказался почти вдвое меньше — экономия в 48%. Более того, точность оказалась сопоставима с известным методом самокоррекции Reflexion, но без его затратности.
В электросетях результаты оказались иными. Полный набор инструментов по-прежнему даёт максимальную точность, поэтому отказываться от него нецелесообразно, если качество критично. Однако картографический provisioning предлагает более дешёвые альтернативы — для задач, где допустимо небольшое снижение качества в обмен на экономию ресурсов.
Выводы и практические рекомендации
Главный вывод: не существует единственно правильной настройки для всех. Каждая предметная область имеет свою границу Парето — оптимальный баланс между точностью и стоимостью. Для одних доменов экономные конфигурации выигрывают, для других полный набор остаётся необходимым.
Практикам стоит:
- строить и поддерживать карты соответствий задач и harness;
- начинать с минимально достаточного набора, расширяя его только после неудачной самопроверки;
- принимать решения об оптимуме не «в среднем», а под конкретный домен.
Такой подход помогает экономить ресурсы без потери качества там, где избыточность не оправдана, и оставлять полный набор в тех случаях, когда он действительно нужен.
