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

Галлюцинация агента — это уверенно сформулированный факт, который выглядит абсолютно нормально, встраивается в рабочий процесс и начинает жить собственной жизнью. Например, маленькая помарка в протоколе встречи через три недели может стать «фактом проекта». Разница в том, что AI slop человек видит сразу, а галлюцинацию агента почти никогда.

Живой пример Недавно гонял Claude Code на незнакомом legacy Java-проекте, чтобы посмотреть, как агент ведёт себя на чужом коде без подсказок. На одном из первых этапов агент должен был проанализировать репозиторий и выдать свои находки. Совпадение с моим личным анализом было хорошее - 4 из 6 находок, но одна находка агента оказалась галлюцинацией. Он сделал вывод о содержимом теста, глядя только на имя файла и его размер — не открывая и не читая сам файл. Вывод был сформулирован так же уверенно, как и все остальные, ничем не отличался по тону от тех выводов, которые были сделаны через чтение и анализ исходного кода.

И это пугает больше всего: галлюцинация не звучит как галлюцинация. Она звучит как факт. Отличить её от настоящего вывода на глаз — нельзя. Можно только проверить.

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

У человека-разработчика в такой цепочке рано или поздно кто-нибудь усомнился - «ты впариваешь мне какую-то дичь». А работу агента так пристально никто не рассматривает и это проблема.

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

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

3. Независимая параллельная проверка. Как человеком, так и другим агентом. Главное, чтобы у второго агента не было доступа к контексту от слова совсем. Любые расхождения в результатах проверки - повод обратить внимание.

4. Тесты как сеть безопасности. Тесты — это то немногое, что можно объективно прогнать и получить “да/нет”. Однако, могут быть свои галлюцинации - тесты сами по себе должны быть проверены.

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

6. Здоровый скепсис самого агента к себе. Если явно попросить агента относиться к собственной уверенности с подозрением, он иногда это делает. Однажды агент написал код, тесты прошли с первого раза, и он сам насторожился, что это было подозрительно гладко. Как итог - непокрытая тестами ветка в коде.

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

Рабочая позиция ближе к тому, как индустрия исторически справлялась с любым новым источником шума в информации (спам, невалидируемый веб-контент и так далее): не запрет и не слепое доверие, а конкретные механические фильтры. Но, раньше на выработку таких фильтров уходили годы. Сейчас же все гораздо проще и быстрее, а инструменты из списка выше — это не просто правила хорошего тона, а скорее необходимая гигиена против агентских витаний в облаках.