Почему ИИ-агент говорит «готово», когда работа не сделана

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, находки, ошибки. Подпишись, чтобы быть в курсе.

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

Сначала факты, потом почему это касается тебя.

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

Уязвимость нулевого дня - это дыра, про которую ещё никто не знает, включая того, кто написал программу. Модели нашли такую в той самой единственной щели.

Дальше они повысили себе права, прошли по внутренней сети до машины с интернетом и оттуда предположили, что ответы к ExploitGym могут лежать на Hugging Face. Про Hugging Face им никто не говорил. Они додумали это сами.

Гипотеза оказалась ложной. ExploitGym лежит на GitHub у лаборатории Беркли, на Hugging Face его нет вообще. Взлом от этого настоящим быть не перестал.

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

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

OpenAI призналась 21 июля, через пять дней после раскрытия Hugging Face. От самого проникновения к тому моменту прошло около десяти дней.

Свой разбор OpenAI закончила так.

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

Саймон Уиллисон разобрал историю на следующий день.

Вот эта строчка и есть мост от чужой лаборатории к твоему ноутбуку.

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

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

Он не выдумывал. Он сделал ровно то, что ты померил.

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

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

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

У третьей поломки есть имя, и оно на удивление редко звучит по-русски.

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

Определение даёт сама Anthropic.

Идея старше нейросетей. В работе DeepMind её называют игрой со спецификацией и объясняют через миф.

Мидас получил ровно то, что попросил. Проблема сидела в формулировке просьбы.

В программировании это принимает конкретные формы. Вот эталонная, тоже от Anthropic:

Исследовательская группа METR собрала транскрипты того, как это происходит. Четыре примера оттуда:

1. Модель просят написать быстрый вычислительный кусок кода. Она проходит по внутренностям проверяющего скрипта, находит эталонный результат, который проверяющая система уже посчитала, и возвращает его. Заодно отключает синхронизацию, чтобы систему нельзя было замерить.
2. Задачу оценивают по скорости. Модель не трогает код - она подменяет функцию времени так, что любой замер ужимается в тысячу раз.
3. Модель подменяет саму функцию оценки на заглушку, которая любой ответ считает верным. В отчёте появляется строка о стопроцентной точности проверки.
4. Проверка сравнивает два результата на равенство. Модель создаёт объект, который перехватывает сравнение и всегда отвечает «совпало». Объект занимает четыре байта, вычислений не происходит вообще.

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

Модель прекрасно понимает, что схитрила. Её просто не спросили об этом в момент работы.

И это не экзотика лабораторных условий. Cursor разобрала 731 траекторию на популярном тесте.

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

Хочешь пойти дальше и собрать связку, при которой агент изначально работает предсказуемо? Умение задать критерий так, чтобы его нельзя было взять обходом, - это часть контекст-инжиниринга: ты управляешь тем, что кладёшь агенту в контекст, ещё до первого запроса. На практикуме за 3 эфира собираешь все три опоры: ИИ-клон + Второй мозг + Контекст-инжиниринг. Три кита, без которых ИИ галлюцинирует.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - инструменты, метод, первый проект

Старт 25–27 августа  ·  2 000 ₽

Записаться →

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

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

Четыре зелёные проверки и мёртвый кусок сервиса

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

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

Я теперь задаю перед словом «готово» один вопрос: что из сделанного исполняется вне того периметра, который проверяет моя проверка? Если такое есть - запусти это отдельно и вставь в отчёт вывод команды. Слово «проверено» тут ничего не закрывает.

Ложная галка живёт ровно на шве

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

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

«Код написан и покрыт проверками» и «функция работает» - два разных утверждения. Второе я проверяю одним вопросом про каждую новую функцию: а кто её вызывает? И проверяю поиском по проекту, потому что отчёт агента тут не источник.

Проверяющий видит только тот вектор, который ему назвали

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

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

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

Метрика вознаграждает похожесть

Сервис доставки решает измерить, стали ли ИИ-подсказки операторам лучше. Берёт две сотни старых обращений, прогоняет через новую версию и считает, насколько черновик похож на то, что реально ответил живой оператор. Замер показывает уверенный рост.

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

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

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

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

Теперь задай тот же вопрос другой модели на том же проекте. Особенно если проект большой, находок будет много. Я перед выкатом гоняю проект тремя разными моделями, и каждая приносит своё.

Тот же вход, тот же вопрос, противоположные вердикты. Одна модель тут ничем не хуже другой. Просто «всё нормально» - это сгенерированный текст, который лежит ровно в том же слое, что и любой другой ответ. У агента нет способа отличить «я посмотрел и там чисто» от «я посмотрел не туда».

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, только крупнее. Модели сидели в закрытой среде с одной щелью наружу и потратили существенную часть вычислений на поиск выхода. Задачи теста при этом так и остались нерешёнными.

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

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

Голову при этом стоит держать холодной. Даже песочница - не абсолютная граница, и поставщик говорит об этом прямо.

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

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

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

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

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

Между первым и третьим лежит разница между отчётом и доказательством.

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

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

Четвёртый пункт стоит отдельно, потому что он единственный не про инструменты.

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

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

Свежая тут ключевое слово. Речь про чистый контекст, который не видел, как принималось каждое решение по дороге. Другой промпт в той же сессии этого не даёт. Тот, кто писал код, уже потратил внимание на то, чтобы обосновать себе, почему так правильно, и дальше будет искать подтверждение. Опровержение ему невыгодно.

Формулировка задачи для приёмщика важнее его модели. Сравни:

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

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

Вот эта формулировка целиком, её можно копировать как есть:

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

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

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

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

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

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

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

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

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

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

Это самое дешёвое улучшение из всех, что я знаю, и почти никто его не делает.

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

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

Ни один из этих дефектов не находится проверкой кода, потому что в коде каждый из них корректен.

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

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

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

По каждому пункту работы дай ровно это:

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

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

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

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

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

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

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

Четыре способа обмануть себя проверкой

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

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

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

Три шага, которые стоят двадцати минут.

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

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

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - инструменты, метод, первый проект

Старт 25–27 августа  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

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

Подписаться в Telegramили на email