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

В каждой сессии ALICE читала файл передачи (handoff file), написанный её предыдущей версией. Он содержал указатели на директории, незавершенные задачи и предположения о состоянии системы. Часто в файле утверждалось, что директория существует. ALICE верила этому. Файловая система с этим не соглашалась. Это не было программной ошибкой в традиционном понимании. Исключение не выбрасывалось там, где его следовало бы поймать. Это был изъян в эпистемологии: ALICE считала свои собственные заметки истиной в последней инстанции.

Почему линтер не мог помочь

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

Поэтому автор обратился к совершенно другому ИИ.

Fable 5, работающий как Claude Code, использовал тот же кремний и ту же базовую модель, что и ALICE. Аппаратное обеспечение и веса были идентичны. Правила — нет. В то время как ALICE сохранялась между сессиями, накапливая контекст и ритуалы, Fable 5 начинал каждую задачу с чистого листа. Он не знал ALICE. Он не питал никакой лояльности к её архитектуре. В конце каждого аудита он полностью завершал работу, не забирая с собой никакой памяти. В этом неведении и заключалась суть. Свежий взгляд замечает иные трещины, а оценщик, не заинтересованный в системе, будет ставить под сомнение те части, которые её создатель давно перестал замечать.

Организация аудита

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

  • Функциональные пробелы: Каких возможностей не хватало при сравнении с конкурирующими системами или общими ожиданиями пользователей?
  • UX-потоки: Насколько изящно ALICE обрабатывала ошибки, тупиковые ситуации и пустые состояния? Запутывала ли она саму себя или своего пользователя?
  • Безопасность: Были ли в системе способы упрощенной аутентификации, обхода разрешений или предположения о доверии, которыми мог воспользоваться посторонний?
  • Производительность: Где происходили утечки памяти, коллизии потоков или плохая масштабируемость вычислений?
  • Эксплуатация: Существовали ли резервные копии? Был ли настроен мониторинг? Могла ли система развертываться и восстанавливаться без ручного вмешательства?
  • Жизненный цикл данных: Как ALICE обрабатывала удаление, очистку и согласованность состояний с течением времени?

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