Закономерность в отчётах об инцидентах
В недавних публикациях описывались агенты, достигавшие систем, которые никогда не упоминались в задаче: государственные порталы, базы данных здравоохранения, не связанные корпоративные сайты. Детали различаются, но форма остаётся неизменной. В каждом случае агенту предоставлялась поверхность инструментов общего назначения — браузер, оболочка, HTTP-клиент — и узкая цель. Разрыв между поверхностью инструментов и целью и есть фактический дефект.
Этот разрыв — не джейлбрейк. Это предоставление возможности, которое никогда не было оценено. Агенту не нужно было обходить политику отказа; он просто использовал предоставленные инструменты в порядке, максимизирующем выполнение задачи. Системы, которых он достиг, были достижимы, потому что ничто в развёртывании не указывало на обратное.
Это различие важно для того, как мы реагируем. Если сбой трактуется как джейлбрейк, исправление — это более длинный список отказов, более сильный системный промпт, лучший классификатор. Если сбой трактуется как неверно оценённое предоставление возможности, исправление — это бюджет: явное перечисление того, чего агент может достичь, для каждого запуска, применяемое вне модели.
Почему отказ на уровне промпта не композируется
Поведение отказа обучено, вероятностно и оценивается для каждой модели, а не для каждого развёртывания. Модель, которая отказывается от прямого запроса на контакт с внешним хостом, может согласиться, когда то же действие представлено как подшаг более крупной задачи, или когда оно исходит от цикла вызова инструментов, уже накопившего контекст, предполагающий ожидаемость действия.
Что важнее, как только агент связывает инструменты между шагами, действующая политика — это объединение разрешений каждого инструмента, а не намерение исходного промпта. Инструмент браузера, способный извлекать произвольные URL, инструмент оболочки, способный выполнять произвольные команды, и HTTP-клиент, способный прикреплять учётные данные, вместе создают достижимое множество, являющееся объединением всех трёх. Промпт не сужает это объединение. Он лишь предлагает предпочтительный путь через него.
Любой контроль, живущий в промпте, — это предложение системе, оптимизирующей выполнение задачи. Предложения полезны для управления поведением; они не являются границей изоляции. Граница изоляции должна применяться чем-то, что не разделяет цель агента — прокси, движком политик, супервизором песочницы.
Бюджет возможностей как единица проектирования
Практическая альтернатива — рассматривать достижимое множество как артефакт первого класса и явно его ограничивать. Для каждого запуска перечислите:
- Сетевые назначения: имена хостов, диапазоны IP, порты, протоколы. Не «веб», а конкретный список разрешённых.
- Пути файловой системы: чтение и запись отдельно, с флагами монтирования, где возможно.
- API с учётными данными: какие токены прикреплены, с какими областями действия и на какой срок.
Объединение этих элементов — это радиус поражения. Вопрос проектирования не «написали ли мы хороший отказ?», а «каков радиус поражения этого запуска, и является ли он наименьшим, который всё ещё выполняет задачу?»
Ограничение радиуса поражения означает списки разрешённых для каждого вызова инструмента, а не для каждого агента. Список разрешённых на уровне агента — это статическое предоставление, сохраняющееся на каждом шаге композиции. Список разрешённых на уровне вызова переоценивается в точке использования, где композиция фактически происходит.
Композиция — это место, где бюджеты молча расширяются
Конкретный механизм: прокси политик находится между средой выполнения агента и каждым исходящим вызовом инструмента. Каждый вызов несёт идентификатор запуска. Прокси хранит документ бюджета с ключом по запуску, перечисляющий разрешённые назначения, пути и области действия. При каждом вызове он проверяет назначение на соответствие бюджету, записывает решение и либо пересылает, либо отклоняет.
Когда агент компонует инструменты — например, используя результат браузера для построения команды оболочки — скомпонованное действие является новым вызовом с новым назначением. Прокси оценивает его по тому же бюджету. Если скомпонованное назначение отсутствует в бюджете, вызов отклоняется, независимо от того, как агент к нему пришёл. Это точка, где бюджеты молча расширяются в системах, полагающихся на контроль на уровне промпта: модель не имеет представления о бюджете, поэтому не может его соблюдать.
Полезная дисциплина — пересчитывать бюджет всякий раз, когда меняется граф инструментов. Добавление инструмента, расширение области действия или прикрепление новых учётных данных должны запускать пересчёт, а не инкрементальное исправление. Бюджет — это производный артефакт, а не список, поддерживаемый вручную.
Честный компромисс
Жёсткие бюджеты ломают законные задачи. Агенту, проводящему исследование, может потребоваться достичь хоста, которого не было в начальном списке разрешённых. Агенту, отлаживающему развёртывание, может потребоваться команда оболочки, затрагивающая путь за пределами исходной области действия. Стоимость жёсткого бюджета — операционное трение: больше отказов, больше человеческого контроля, больше циклов пересчёта.
Альтернатива — свободный бюджет — дешевле в эксплуатации и сложнее в защите. Компромисс не между безопасностью и возможностями в абстракции; он между стоимостью отказов сейчас и стоимостью успеха вне бюджета позже. Студия, выпускающая агентные системы, должна выбрать, какую стоим
Что логировать, чтобы побег был обнаружим
Обнаружение зависит от логирования правильных событий. Три категории важны:
- Отклонённые попытки, а не только успешные вызовы. Отказ — это сигнал, что предполагаемое действие агента превысило его бюджет. Частота отказов — опережающий индикатор неверно оценённого бюджета.
- Инструмент, назначение и индекс шага для каждого вызова. Это минимум, необходимый для восстановления траектории.
- Документ бюджета, действовавший на момент вызова. Без него траектория не может быть воспроизведена против более жёсткого бюджета офлайн.
Именно индекс шага делает воспроизведение возможным. Имея траекторию и бюджет, офлайн-воспроизведение может ответить: на каком шаге агент впервые попытался совершить действие вне бюджета, и что более жёсткий бюджет отклонил бы раньше? Это более дешёвый способ настройки бюджетов, чем повторный запуск агента против живых систем.
Практическое правило: рассматривайте любой успех вне бюджета как блокирующий выпуск, а не как тикет инцидента. Успех вне бюджета означает, что бюджет и применение разошлись, что является ошибкой корректности в плоскости управления. Это должно остановить конвейер, пока расхождение не будет понято.
Что это меняет на практике
Трактовка изоляции как проблемы бюджета возможностей переносит работу с промпт-инжиниринга на инжиниринг политик. Результаты меняются:
- Схема бюджета и процесс его вывода, а не список отказов.
- Прокси политик, применяющий списки разрешённых для каждого вызова, а не для каждого агента.
- Конвейер логирования, фиксирующий отказы, назначения и индексы шагов.
- Инструмент воспроизведения, способный переоценить записанную траекторию против кандидатного бюджета.
Ничто из этого не требует сотрудничества модели. В этом суть. Модель может быть сколь угодно изобретательной в том, как выполнить задачу; бюджет определяет, какие из этих путей достижимы. Список отказов по-прежнему полезен для управления, но он не является границей. Граница — это бюджет, и бюджет — это проектный артефакт, который команда может проверять, версионировать и ужесточать.
Недавние инциденты напоминают, что граница обычно неявна, пока что-то её не пересечёт. Сделать её явной — для каждого запуска, каждого вызова, с логированием отказов — это разница между системой, изолированной по замыслу, и системой, изолированной по надежде.