Это лето для меня проходит под одним очень конкретным флагом: война с галлюцинациями агентов.
Не в абстрактном смысле «модели иногда врут». Это все уже знают. А в практическом, инженерном смысле: как заставить агентную систему стабильно выполнять задачу, не съезжать в фантазии, не забывать правила, не игнорировать PRD, не закрывать задачу раньше времени и не притворяться, что работа выполнена.
В Datarim, внутри экосистемы агентных систем Arcanada, я всё больше прихожу к простой мысли: агентам нужна мотивация.
Звучит странно. У агента нет личности, эмоций, амбиций и человеческого желания сделать хорошо. Но под «мотивацией» я имею в виду другое: агенту нужно очень ясно объяснить, что от него ожидают.
Не просто: «сделай задачу». Не просто: «реализуй фичу». Не просто: «исправь баг».
А нарисовать ему чёткую картину результата.
Что должно получиться. Какие пункты должны быть закрыты. Как будет выглядеть правильное решение. Какие тест-кейсы должны пройти. По каким признакам оператор, ревью-агент или система поймут, что работа действительно выполнена.
Лучше всего это работает не как абстрактный текст, а как чек-лист. Потому что чек-лист превращает ожидание в контракт.
Если каждый пункт закрыт, задача может считаться выполненной. Если хотя бы один пункт не закрыт, задача не выполнена. Если пункт закрыт «на словах», но нет доказательства, задача не выполнена. Если ревью-агент нашёл замечание, задача возвращается на доработку. И возвращается столько раз, сколько нужно.
Даже если цикл получится бесконечным. Потому что альтернатива хуже: агент бодро сообщает, что всё готово, хотя на самом деле он просто потерял часть условий, придумал недостающие детали и закрыл задачу в своей голове.
Главный вопрос к агенту
Самый простой и самый полезный вопрос, который я теперь задаю агенту перед каждым этапом имплементации:
«Покажи, как ты это будешь делать?»
Казалось бы, глупость. Агент просто возьмёт и перечислит план. Напишет, какие файлы посмотрит. На какие правила и скиллы будет опираться. Какие связанные задачи перечитает. Какие тесты запустит. Какие ограничения учтёт.
Но именно в этот момент происходит важная вещь: агент начинает не фантазировать, а ориентироваться.
Он заново перечитывает PRD. Поднимает предыдущие похожие задачи. Смотрит правила проекта. Сопоставляет текущую задачу с уже существующими решениями. И только потом начинает действовать.
Когда этого шага нет, модель слишком легко начинает галлюцинировать. Особенно это проявляется в «тупом» режиме Клода: когда контекст уже забит, когда окно, по моим ощущениям, переваливает за 20%, когда задача длинная, когда пунктов в плане много, когда модель начинает экономить внимание или проваливается в более слабый режим рассуждения.
Иногда это выглядит так, будто вместо нормального Клода задачу пытается решать какая-то боковая модель. Условная Haiku, которая вроде бы старается, но уже не держит всю картину.
И вот что интересно: даже слабая модель начинает работать заметно лучше, если перед ней есть чёткая картинка результата и если её заставить проговорить план. Не просто «делай». А сначала: «покажи, как ты это будешь делать».
Почему это снижает галлюцинации
Галлюцинация агента часто начинается не там, где он пишет код. Она начинается раньше — в моменте, когда он неправильно понял задачу, но не показал это оператору.
Он не перечитал PRD. Не проверил старую реализацию. Не нашёл связанный паттерн. Не сверился с правилами проекта. Не понял, какие тест-кейсы являются обязательными. Но уже начал действовать.
В обычной разработке человек тоже может так ошибиться. Но человек хотя бы иногда останавливается и спрашивает: «Подожди, а мы это точно так делаем?» Агент сам по себе часто не останавливается. Его нужно научить останавливаться.
Поэтому вопрос «покажи, как ты это будешь делать» работает как принудительная пауза перед действием. Это не просто планирование. Это проверка понимания.
Если агент показывает неправильный план, я сразу вижу проблему и говорю: «Перечитай условия ещё раз. В прошлой задаче мы делали по-другому.»
И дальше происходит полезная магия: агент возвращается к контексту, находит старую задачу, перечитывает правила и часто сам показывает уже правильный план. То есть ошибка ловится до имплементации, а не после сломанного кода.
Чек-лист важнее ощущения готовности
В Datarim я всё больше закладываю именно такой принцип: задача не считается выполненной, пока не закрыт чек-лист тест-кейсов. Причём закрыт не «по ощущениям», а доказательно.
Для каждого пункта должно быть понятно:
- что именно проверялось;
- где это проверялось;
- каким результатом подтверждается;
- что осталось спорным или непроверенным;
- есть ли замечания ревью-агента.
Если пункт не закрыт, задача возвращается. Если доказательства нет, задача возвращается. Если ревью-агент нашёл проблему, задача возвращается. Если агент «думает», что всё готово, но не может показать, почему, задача возвращается.
Да, это может создавать длинные циклы. Да, иногда это раздражает. Да, иногда кажется, что агент застрял. Но это всё равно лучше, чем автоматизация, которая уверенно производит мусор.
Автономность без проверки — это не автономность. Это генератор технического долга.
Проблема финального этапа
Есть ещё один важный момент. Агенты часто забывают делать рефлексию перед закрытием или архивацией задачи.
Даже если скилл самообучения уже написан. Даже если граф правил уже сто раз переписан. Даже если в системе явно указано, что после задачи нужно извлечь уроки и сохранить их в память проекта. Всё равно агент может пропустить этот этап.
Поэтому мне приходится вручную напоминать:
«Сделай compliance-check и покажи извлечённые уроки и ошибки, которые нужно внести в память проекта.»
Это отдельная часть борьбы. Потому что агентная система не должна просто выполнить задачу. Она должна после выполнения стать немного лучше.
Если агент ошибся — это должно попасть в память. Если агент нашёл новый паттерн — это должно попасть в правила. Если PRD был неоднозначным — это нужно зафиксировать. Если тест-кейс оказался важным — он должен стать частью будущих проверок. Если ревью-агент поймал типовую проблему — это должно усилить следующий цикл.
Иначе мы не строим систему. Мы просто каждый раз заново разговариваем с забывчивым исполнителем.
Что я теперь меняю в Datarim
Сейчас я учу оркестратор делать такие перепроверки автоматически.
Перед каждым этапом задачи агент должен показать:
- Как он понял задачу.
- На какие PRD, правила, скиллы и предыдущие задачи он опирается.
- Какой план реализации предлагает.
- Какие тест-кейсы будут доказывать выполнение.
- Какие риски и неоднозначности он видит.
После этапа он должен показать:
- Что именно было сделано.
- Какие пункты чек-листа закрыты.
- Чем это доказано.
- Что не проверено.
- Какие замечания есть у ревью-агента.
- Какие уроки нужно сохранить в память проекта.
Это превращает агента из «генератора действий» в участника управляемого процесса. Он уже не просто что-то делает. Он должен объяснить, почему он делает именно так. Доказать, что сделал. И передать системе новый опыт.
Война с галлюцинациями
Галлюцинации агентов нельзя победить одной магической инструкцией. Нельзя просто написать в system prompt: «не галлюцинируй». Это не работает.
Нужна архитектура. Нужны PRD. Нужны чек-листы. Нужны тест-кейсы. Нужны ревью-агенты. Нужны циклы возврата. Нужна память проекта. Нужна рефлексия после выполнения. И нужен простой человеческий вопрос перед началом работы:
«Покажи, как ты это будешь делать?»
Этот вопрос кажется маленьким. Но он меняет режим работы агента. Он заставляет модель остановиться. Перечитать условия. Найти опоры. Собрать план. Показать свои предположения до того, как они превратятся в код.
И именно здесь проходит граница между хаотичной агентной автоматизацией и настоящей инженерной системой.
Arcanada для меня — это не про то, чтобы агенты просто «что-то делали». Это про экосистему, в которой агенты работают, проверяют друг друга, учатся на ошибках и постепенно становятся надёжнее. Datarim — один из инструментов этой экосистемы.
И моя главная борьба этого лета — сделать так, чтобы агент не просто выполнял задачу, а каждый раз мог честно ответить:
«Вот как я это понял. Вот как я это буду делать. Вот на что я опираюсь. Вот как я докажу, что задача выполнена.»
Пока агент не может это показать — ему рано доверять автономность.