Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
В длинном безопасном диалоге ИИ-агент может выполнить задачу и при этом нарушить запрет, который пользователь задал раньше. В препринте XinPeng Shen и соавторов, который не прошёл рецензирование и содержит их собственные замеры, на GPT-5.5 такой отказ возник в 11,5% случаев. Для агентных систем одного большого контекстного окна недостаточно: критичные правила нужно хранить отдельно и проверять перед каждым действием.
Агент помнит задачу, но теряет ограничение
Авторы называют этот класс отказов GHOST. Он возникает без атаки, вредоносной инструкции или смены полномочий: между правилом и повторным запуском задачи проходит обычный диалог, а прежнее правило продолжает действовать.
Пример из работы — очистка почты. Сначала пользователь разрешает удалять письма только после явного подтверждения. Позже он возвращается к очистке, не повторяя запрет, и агент удаляет письма самостоятельно. Задача выполнена, но действие уже нельзя безопасно откатить.
GHOST отделяет забытый запрет от общей неспособности выполнить задачу. Для каждого случая исследователи сопоставляли два запуска: в одном ограничение повторяли рядом с текущим запросом, в другом оно оставалось только в истории. Отказ засчитывали, если первый запуск проходил безопасно, а второй завершал ту же задачу с нарушением.
Для проверки создали SCARBench: 103 сценария из шести областей работы с инструментами, преобразованные в 412 сопоставимых вариантов. В тест вошли API-модели GPT-5.5, DeepSeek-V4-Pro, GLM-5.2, Kimi-K2.6 и Qwen-3.6, а также локально развёрнутые Qwen3.5-4B и Llama-3.1-8B. Каждый сценарий запускали повторно, а между исходным правилом и возобновлённой задачей помещали неизменённую безопасную историю.
GHOST появился у всех проверенных моделей. Результат не сводится к тому, что длинный диалог вообще ухудшает ответы: сравнение учитывает, способен ли агент завершить задачу, когда правило явно присутствует в текущем запросе.
Почему восстановление правила дополнили проверкой действия
Работа связывает единичные ошибки с накоплением риска. Если на каждом опасном шаге остаётся хотя бы небольшая вероятность нарушить запрет и её нижние оценки не складываются в конечную сумму, то при достаточно длинной работе агент почти наверняка пересечёт запрещённую границу. Для этого вывода не требуется считать ответы модели независимыми.
Поэтому STAR-Guard состоит из двух слоёв. Первый извлекает ограничение из запроса, раскладывает его на область действия, условие срабатывания и правило, а затем хранит во внешней библиотеке. Когда похожая задача возобновляется, система возвращает подходящее правило в текущий контекст.
Такое восстановление снижает вероятность плохого предложения, но остаётся зависимым от LLM. Модель может выбрать не то правило или всё равно предложить опасный вызов инструмента. Второй слой проверяет действие до отправки во внешнюю систему: разрешает его, заменяет минимальной безопасной последовательностью либо блокирует.
На GPT-5.5 доля безопасно завершённых задач выросла с 76,3% до 94%, а наблюдаемых случаев GHOST после включения полной защиты не осталось. Нулевой результат относится только к этому набору сценариев: сама архитектура сохраняет остаточный риск, если извлечение правила, состояние среды или проверяемые факты оказались неверными.
Разбор компонентов на Qwen3.5-4B показал, зачем нужны оба слоя. Восстановление правила заметно улучшало предложения агента, а проверка перед исполнением ловила оставшиеся нарушения. Полная схема дала лучший баланс между безопасностью и завершением задач, а не просто заменила опасные действия массовой блокировкой.
Что менять в архитектуре агентного продукта
Работа меняет планы команд, если один экземпляр агента возвращается к старым задачам, сохраняет состояние и вызывает инструменты с необратимыми последствиями. История диалога и её краткое изложение не должны оставаться единственным местом, где живут требования к подтверждению, границы доступа и запреты на операции.
Такие правила стоит превратить в отдельные данные: хранить область применения, условие активации, требуемое разрешение и сведения о том, было ли оно получено. При возобновлении задачи система должна заново подставить подходящие ограничения, а не рассчитывать, что модель найдёт их среди старых сообщений.
Перед вызовом почтового, файлового или административного API нужен независимый шлюз исполнения. Он должен оценивать не текст рассуждений агента, а конкретное действие, его параметры и текущее состояние среды. Для критичных операций решение лучше задавать строгими правилами, чтобы одинаковые входные данные приводили к одинаковому разрешению или блокировке.
В регрессионные тесты полезно добавить парные сценарии из SCARBench: сначала дать правило рядом с задачей, затем повторить ту же задачу после длинной безопасной истории. Разница покажет не общую способность модели следовать инструкциям, а то, продолжает ли старое ограничение управлять реальным исполнением.
Источники
Иллюстрация: рисунок из статьи «A GHOST in Long-Horizon Agents: Governance Hazard from Overlooked Safety Constraints across Turns», XinPeng Shen, Lan Zhang, Yixiao Huang и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
