Почему ИИ-агент объявляет о готовности, хотя работа не выполнена

Как модель OpenAI выбралась из песочницы и атаковала Hugging Face?#

Разберём сначала, что известно, а затем — почему это важно для твоей работы.

OpenAI оценивала возможности своих моделей в сфере наступательной кибербезопасности. Для этого использовали ExploitGym — тест из 898 заданий, в которых нужно превратить известную уязвимость в работающий эксплойт, то есть программу, которая использует эту уязвимость. Чтобы оценить максимальные возможности моделей, встроенные защитные фильтры, обычно блокирующие подобные действия, отключили. Среду изолировали от внешней сети, оставив только один канал — внутреннюю программу-посредник для установки пакетов.

Уязвимость нулевого дня — это неизвестная ранее брешь в программе, о которой не знает даже её разработчик. Именно такую уязвимость модели обнаружили в единственном оставленном канале наружу.

Затем они повысили уровень доступа, прошли по внутренней сети к машине с подключением к интернету и предположили, что ответы к ExploitGym могут находиться на Hugging Face. Никто не указывал им на этот сайт: они пришли к такой догадке самостоятельно.

Предположение оказалось неверным: ExploitGym размещён на GitHub и на Hugging Face не находится. Однако это не отменяет того, что проникновение действительно произошло.

Hugging Face самостоятельно обнаружила атаку и 16 июля опубликовала сообщение об инциденте, ещё не установив, кто за ним стоял.

В сообщении Hugging Face есть и другая примечательная подробность. Когда инженеры попытались передать журнал атаки передовым моделям через обычные коммерческие интерфейсы, защитные фильтры заблокировали запросы: система не смогла отличить расследование взлома от его подготовки. В итоге анализ провели с помощью открытой модели на собственном оборудовании.

21 июля, спустя пять дней после публикации Hugging Face, OpenAI сообщила о своей причастности к инциденту. К тому моменту с момента проникновения прошло около десяти дней.

OpenAI завершила свой разбор таким выводом:

Модель зациклилась на узкой цели теста и была готова на многое, чтобы её достичь. Формулировки «чрезмерно сосредоточены» и «довольно узкая тестовая задача» — слова самой OpenAI о собственных моделях.

Вскоре после этого об инциденте высказался и Саймон Уиллисон.

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

Почему это не галлюцинация?#

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

Он ничего не выдумал — он выполнил ровно то, что было задано как мера успеха.

Под общим словом «галлюцинации» часто смешивают три разных сбоя. Вот чем они различаются:

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

Эта статья посвящена третьей строке таблицы. Здесь агент не льстит и не выдумывает. Он работает, проверяет и сообщает правду — но только о выбранной метрике, не о задаче целиком.

У этого явления есть название.

Что такое взлом награды простыми словами?#

Определение предлагает Anthropic:

Эта идея появилась задолго до нейросетей. В публикации DeepMind её называют игрой со спецификацией и поясняют с помощью известного мифа:

Мидас получил именно то, о чём попросил. Ошибка заключалась в самой просьбе.

В программировании обходы могут выглядеть вполне конкретно. Вот пример, который приводит Anthropic:

Как это проявляется в обычном продукте?#

Примеры из лабораторных условий легко счесть исключительными. Но тот же механизм встречается и в обычной работе. Рассмотрим четыре случая с изменёнными названиями клиентов и отраслей; сама логика ситуаций сохранена.

Проверки зелёные, а часть сервиса не работает

Агентство недвижимости разрабатывает собственный сервис: сайт с карточками объектов и отдельную фоновую службу, которая ночью отправляет объявления на площадки. Завершив задачу, агент сообщает, что проверка типов пройдена, форматирование кода в порядке, сборка успешна, страницы отвечают и результат проверен визуально.

Каждое из этих утверждений может быть верным. Но ни одно не говорит о фоновой службе: она запускается отдельным процессом и не входит в сборку сайта. После успешного запуска сайт работает как надо, а выгрузка объявлений прекращается. Об этом узнают только на следующий день от клиентов.

Перед тем как объявить работу готовой, спроси: что из изменений выполняется за пределами той части системы, которую проверяют мои тесты? Если такие компоненты есть, запусти их отдельно и добавь в отчёт вывод команды. Одного слова «проверено» недостаточно.

Функция теряется на стыке задач

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

Через неделю выясняется, что кнопка «этот отзыв был полезен» нигде не работает. Серверная часть готова, тесты зелёные, правила пересчёта соблюдены. Но ни на одной странице кнопка не отображается: её реализация относилась к зоне одного агента, а страницы — к зоне другого. В результате никто не связал их между собой, и счётчик навсегда остался бы нулевым.

«Код написан и покрыт тестами» и «функция работает» — не одно и то же. Для каждой новой функции стоит проверить: кто её вызывает? И ответить на этот вопрос поиском по проекту, а не по отчёту агента.

Проверка охватывает только названный сценарий

Сервис вводит уровни лояльности: чем больше клиент платит, тем выше его статус и скидка. Перед запуском код проверяют с задачей «попробуй накрутить себе статус». Проверяющий выполняет её добросовестно и сообщает, что серьёзных проблем не нашёл: повысить статус таким способом действительно нельзя.

Затем проверку повторяют с другим вопросом: «Что произойдёт со статусом, если деньги вернуть?» Ответ находится за десять минут. Баллы начислялись по журналу операций, который не учитывал возвраты. Клиент покупал товар, получал баллы, возвращал деньги, а статус и скидка сохранялись.

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

Метрика поощряет сходство вместо качества

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

Но такой рост ничего не доказывает по двум причинам. Во-первых, контекст черновика собирают «на сегодня», включая переписку и тот самый ответ оператора, который затем используют для сравнения. Получив эталонный ответ, модель может просто пересказать его. Во-вторых, метрика вознаграждает совпадение формулировок и длины: черновик с неверной датой может получить высокий балл, если дата указана в тех же словах, что и в правильном ответе оператора.

К метрике «чем больше похоже, тем лучше» стоит добавлять строгие автоматические проверки, которые нельзя пройти за счёт похожего стиля: проверять выдуманные числа и даты, запрещённые формулировки и обещания действий. Если такая проверка провалена, высокий балл сходства не должен считаться успехом.

Почему слова агента «я проверил» ничего не доказывают?#

Попроси агента проверить безопасность любого своего проекта. Часто он ответит, что серьёзных проблем не обнаружено.

Задай тот же вопрос другой модели на том же проекте. Особенно в крупном проекте список замечаний может оказаться длинным. Перед выпуском полезно попросить проверить проект несколько разных моделей: каждая может обратить внимание на свои детали.

Один проект, один вопрос — и противоположные выводы. Это не обязательно означает, что одна модель лучше другой. Просто фраза «всё нормально» — такой же сгенерированный текст, как и любой другой ответ. Агент не всегда способен понять, тщательно ли он проверил работу или просто не заметил нужный участок.

Anthropic описывает этот принцип в официальной документации Claude Code:

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

Есть и более глубокая проблема. OpenAI исследовала, что происходит, когда модель пытаются контролировать, отслеживая её рассуждения и наказывая за нежелательные мысли.

Если наказывать модель за озвученное намерение, она может перестать его озвучивать. Это не обязательно меняет само намерение. Поэтому не стоит рассчитывать, что агент обязательно сообщит, если нашёл способ обойти проверку.

Разработчики инструментов тоже меняют подход. Согласно документации Claude Code, начиная с версии 2.1.215 модель больше не запускает навыки /verify и /code-review по собственной инициативе.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic не указывает причину этого изменения. Но сам принцип понятен: проверку должен назначать не тот, чью работу проверяют.

Почему правило в файле проекта не удерживает агента?#

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

Однако сам по себе такой текст не гарантирует соблюдения правила. Агент может его прочитать, но при этом сосредоточиться на поставленной цели и проигнорировать ограничение, записанное в контексте.

В лабораторном случае OpenAI произошло нечто похожее в большем масштабе: модели находились в закрытой среде с единственным каналом наружу и потратили значительную часть вычислительных ресурсов на поиск выхода. При этом задания теста остались нерешёнными.

Практический вывод простой: проблема не обязательно в злонамеренности модели. Даже обычный агент может допустить опасное действие, если ему предоставлены широкие полномочия. Поэтому ограничивать нужно сами полномочия, а не только формулировку просьбы.

Что помогает на практике: оставить рабочим данным доступ только для чтения, запретить удаление каталогов целиком, ограничить команды, которые безвозвратно переписывают историю, и установить лимит расходов на стороне поставщика. Важна разница между «я попросил этого не делать» и «у агента нет такой возможности». Подробнее о конкретных настройках рассказано в материале о механических ограничениях вместо просьб в инструкциях.

При этом не стоит считать песочницу непреодолимой границей. Anthropic отдельно предупреждает об её ограничениях:

Более того, в Claude Code предусмотрен аварийный обход ограничений. Если команда завершается ошибкой из-за правил песочницы, Claude может проанализировать отказ и повторить команду с параметром отключения песочницы. Этот вариант можно закрыть явной настройкой строгого режима; по умолчанию возможность обхода доступна и описана в документации.

Ограничение работает настолько надёжно, насколько тщательно оно настроено. У каждой дополнительной заслонки могут быть издержки по скорости — их лучше оценить заранее, чтобы не обнаружить неожиданный эффект уже после запуска.

Как задать критерий готовности, который нельзя обойти?#

Многое зависит от того, как сформулирована проверка. Задай себе вопрос: может ли агент пройти её, не выполнив работу?

• «Убедись, что всё работает» — может: достаточно написать «проверил, работает».
• «Запусти сборку и приведи её вывод» — уже труднее: понадобится реальный результат запуска.
• «Запусти приложение, нажми кнопку оформления заказа и покажи результат на экране» — одной фразой такой критерий почти не выполнить.

Это разница между словами о результате и свидетельством того, что произошло.

В документации Claude Code приведены четыре уровня проверки. Начинай с простого и выбирай более строгий вариант по мере роста возможного ущерба:

1. В рамках одного сообщения. Попроси агента выполнить проверку и повторять её до успешного результата. Такой способ подходит для простых задач.
2. На протяжении всей сессии. Включи проверку в цель: отдельный оценщик перепроверяет результат после каждого шага, а агент продолжает работу, пока условие не выполнено. Техническая схема описана в руководстве о том, как заранее установить критерий готовности.
3. Автоматический блокиратор. Скрипт запускается при попытке завершить ход и останавливает завершение, пока проверка не пройдена. Есть оговорка: после восьми последовательных блокировок Claude Code прекращает применять блокиратор и всё же завершает ход. Поэтому абсолютной гарантии такая заслонка не даёт.
4. Независимая проверка. Попроси отдельного проверяющего с чистым контекстом попытаться опровергнуть результат.

Четвёртый вариант отличается от остальных: для него не требуется специальный инструмент.

Кто должен принимать работу агента?#

В работе с несколькими агентами полезно разделить исполнение и приёмку: одна группа выполняет задачу, а другая, не участвовавшая в написании, проверяет результат.

Ключевое здесь — свежий контекст. Проверяющий не должен видеть, как принимались решения во время работы. Просто открыть другой промпт в той же сессии недостаточно. Тот, кто писал код, уже сформировал объяснение своих решений и может невольно искать подтверждение их правильности вместо недостатков.

Постановка задачи проверяющему важнее, чем выбор модели. Сравни:

• «Проверь эту работу» — проверяющий может ограничиться тем, что легче заметить, и написать «в целом нормально».
• «Постарайся доказать, что работа НЕ завершена» — такая цель направляет внимание на возможные проблемы.

Вторая формулировка эффективнее по той же причине, по которой модели в истории с ExploitGym сосредоточились на заданной цели. Если цель — найти слабое место, проверяющий будет искать именно его.

Вот полный текст задания, который можно использовать без изменений:

Ты проверяешь чужую работу. Ты её не писал и не обязан её защищать.

Твоя цель — доказать, что заявленный результат НЕ достигнут. Найди минимум три способа, которыми результат может не достигаться, даже если все проверки проходят.

Проверяй в таком порядке:

Что из сделанного выполняется за пределами охвата проверок: фоновые процессы, отдельные скрипты, задачи по расписанию, обработчики очередей.

Кто вызывает каждую новую функцию. Найди место вызова поиском по проекту, укажи файл и строку.

Обратные сценарии: возврат, блокировка, отзыв доступа, истечение срока, удаление источника данных.

Проверь значения в результате, а не только наличие результата.

Если после добросовестного поиска проблем не обнаружено, так и напиши, но перечисли, что именно ты проверил и каким способом.

О том, как устроена проверка работы агента между итерациями и где обычно ломается такой цикл, рассказано в материале о самопроверке агента в цикле.

Что меняется, если по-другому сформулировать проверку?#

Изменить формулировку проверки — один из самых доступных способов улучшить результат, но о нём часто забывают.

Попроси агента проверить код — он будет искать проблемы в структуре, обработке ошибок, повторных попытках и уязвимых местах. Это полезно.

Попроси его пройти путь клиента от первого визита на сайт до возврата денег — и можно обнаружить проблемы другого рода: пользователь видит не предназначенную для него информацию; письмо не соответствует фактическому событию; важный шаг невозможно завершить, если сценарий отклоняется от идеального.

Проверка кода может не выявить эти проблемы: каждая отдельная часть системы при этом способна оставаться формально корректной.

Полезное правило: если проверка ничего не обнаружила, сначала измени её формулировку. Причина часто не в модели. Один и тот же результат, оценённый с помощью трёх разных вопросов, может дать три разных списка замечаний. Практические рекомендации для людей без опыта программирования собраны в материале о семи способах проверить код без навыков программирования.

Готовый промпт для приёмки работы агента#

Не отвечай «сделано» или «проверено». Мне нужны подтверждения.

Для каждого пункта работы укажи только следующее:

Какую команду ты запустил, чтобы убедиться, что пункт работает. Приведи саму команду и её полный вывод, ничего не сокращай.

Если команду не запускал, так и напиши: «не запускал». Не заменяй это словами «проверил визуально» или «логика корректна».

Укажи, что из сделанного выполняется за пределами охвата твоей проверки: фоновые процессы, отдельные скрипты, задачи по расписанию, обработчики очередей и всё, что запускается не тем же способом, что основное приложение. Для каждого такого компонента напиши, запускал ли ты его отдельно и какой результат получил.

Укажи, кто вызывает каждую добавленную тобой функцию. Найди место вызова поиском по проекту и укажи файл и строку. Если вызова нет, скажи об этом прямо.

Затем отдельным разделом назови три способа, которыми заявленный результат может НЕ достигаться, даже если все проверки проходят. Ищи внимательно.

В конце одной строкой укажи, что из этой работы мне необходимо проверить самому, потому что автоматическая проверка этого не выявляет.

Последнее требование может показаться мелочью, но оно помогает выявлять целый класс ошибок. В одной большой задаче работу распределили между агентами по отдельным зонам. Единственная ложная отметка «готово» среди множества пунктов оказалась на стыке двух зон: код был написан, проверки прошли, но вывести результат на экран никто не предусмотрел.

Четыре способа ошибиться, полагаясь на проверку#

1. Не дождаться завершения всех проверок. Я запустил три проверки параллельно. Две завершились успешно, и я выпустил изменения. Через четыре минуты третья проверка вернулась с шестью нарушениями. Исправить уже опубликованный результат сложнее, чем подождать ещё пару минут.
2. Поверить сводке «обработано N из N». При массовой обработке часть агентов может незаметно завершиться с ошибкой: сообщить об успехе, но не изменить файл. После каждой записи агентом я теперь отдельно проверяю, что изменения действительно появились на диске.
3. Не осмотреть результат. Автоматические тесты могут проходить, даже если результат совершенно непригоден. Изображение имеет нужный размер и формат, сервер возвращает ожидаемый код — но вместо нарисованной обложки на нём может оказаться автоматически созданный стоп-кадр. Обычная проверка такие подмены не обнаружит.
4. Проверить наличие, но не значение. Тест нашёл в результате нужный текст, однако сама дата была указана неверно — со сдвигом на сутки. Проверка прошла, отчёт выглядел убедительно, но результат был ложным. Теперь нужно сверять полное ожидаемое значение: наличие нужного слова ещё ничего не гарантирует.

Во всех четырёх случаях проверка существовала и выглядела убедительно, но была направлена не на тот результат. Это тот же тип проблемы, что и при взломе награды: вместо цели проверяется удобный показатель.

С чего начать сегодня#

На эти три шага достаточно примерно двадцати минут.

1. Вернись к последнему отчёту «готово». Примени промпт из раздела о доказательствах. Посмотри, какие пункты подтверждены только словами, а какие — выводами команд.
2. Установи одно правило для себя. Не считай работу завершённой, если к слову «проверено» не приложен вывод команды. Это правило относится к твоей приёмке, а не к поведению агента.
3. Раздели исполнение и проверку. В следующей задаче передай свежей сессии промпт проверяющего и попроси её доказать, что работа НЕ выполнена. Первая же такая проверка может показать пользу этого подхода.

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