как я перестать вайбкодить и полюбил находить проблемы

Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)
В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе.
А сегодня я расскажу про два инструмента, которые использую постоянно: Premortem и Prism. Не в теории, а на моём собственном опыте.
Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.
1. Premortem: «Проект запущен. Через месяц — катастрофа. Почему?»
Premortem - это когда ты представляешь, что будущее уже наступило и всё пошло по п***е ( панде), а потом работаешь назад от этого будущего, выясняя причины.
Звучит как эзотерика для тренингов личностного роста? Ну да, но нет. Вот как это выглядит на практике: ты садишься, открываешь шаблон (если есть — если нет, просто текстовый файл) и пишешь сверху: "Это уже сломалось. Почему?".
Дальше — выписываешь всё, что приходит в голову. Без цензуры, без ранжирования. Каждая причина — отдельная строка. Не "что может пойти не так", а "это уже сломалось, вот доказательства".
Пример: моя 4-уровневая память агента (как я гордился что столько умного впихал, выб знали)
В Hermes Agent я сделал четыре уровня хранения данных:
L1: memory() — быстрые факты, инжектятся в каждый turn
L2: HippoRAG — граф знаний, co-occurrence индексация
L3: LLM Wiki — Karpathy-style markdown база
L4: MemPalace — архив на chromadb, 58K чанков - Лилу не может меня обмануть или сделать больно, не может же?
Четыре уровня! "Какой я молодец!" думал я. У каждого уровня своя роль. Избыточность, fault tolerance. Мне больше не грозит потеря контекста! Ни в сессии ни между ними!
Я открыл консоль и написал:
"Система в продакшене 3 месяца. Внезапно агент начал нести херню — забывает факты, путает проекты, переспрашивает одно и то же. Что пошло не так? Почему 4 уровня не спасли?"
И пошло:
Причина 1: Ни один факт не выживает без явной команды. Четыре уровня — это четыре места, куда можно сохранить. Но ни один не работает автоматически. Если я не скажу "запомни это", факт умрёт в конце сессии. Четыре уровня = четыре места забыть.
Причина 2: Каждый уровень может отказать независимо. У HippoRAG есть крон, который может сдохнуть и я не узнаю, пока не проверю вручную. У MemPalace есть chromadb, которая падает при переполнении. У Wiki ручное наполнение, которое я забываю делать. У memory() лимит на количество фактов. Ни один уровень не гарантирован.
Причина 3: HippoRAG cron сдох три дня назад, а я не заметил. HippoRAG индексирует сессии раз в час. Крон был привязан к пайплайну, который сломался, но таймер продолжал тикать. Индекс три дня не обновлялся "О как, а мы и не знали"
Причина 4: MemPalace дублирует то, что уже есть в основной базе. 96% содержимого сырые сессии, которые и так лежат в state.db с полнотекстовым поиском FTS5. 1.1 ГБ, 60 тысяч записей, куча кода ради функциональности, которая уже была из коробки.
Причина 5: Команда управления памятью не реализована. В профиле агента описана команда /kg сохранять, искать, забывать факты. На деле команды нет. Пользователь пишет /kg запиши получает "я не знаю такой команды".
Я выписал пять причин за 20 минут. Не потому что я умный (не очень борат.jpg) . А потому что Premortem заставляет работать от катастрофы, а не от текущего состояния. Разница как между «что делать, чтобы не провалить проект» и «почему мы уже провалились».
2. Prism: "Не ищи проблему - ищи, как артефакт устроен на самом деле"
Prism - это не один инструмент. В репозитории их пять: prism-full, prism-3way, prism-discover, prism-reflect, prism-scan. Каждый делает одно и то же (структурный анализ) - но через разные протоколы. Я опишу на примере prism-full, он главный.
Как работает Prism (на примере prism-full)
Prism-full состоит из трёх фаз. Ни одну нельзя пропустить.
Фаза 0 - Codebase Inventory (необязательная, но критичная)
Перед любым анализом Prism требует: открой файлы. Не документацию, не README - исходный код. Проверь, что описано в теории реально существует. Проверь, что существует - реально работает.
В моём первом анализе памяти я её пропустил - и получил анализ архитектурной мечты, а не реальной системы. Описал 4 уровня, расписал pipeline - и не открыл ни одного .py файла. Когда открыл - обнаружил, что половина хуков синхронизации (sync_turn, on_session_end) существуют как no-op заглушки. Не сломанные - а просто пустые. Код есть, вызывает ничего.
Фаза 1 - Design pipeline
Ты проектируешь 2-4 аналитических прохода, специфичных под этот артефакт. Не generic checklist, а конкретные вопросы к этой системе.
Для моей памяти я спроектировал три прохода:
Проход 1: Claim Extraction & Inversion Берём каждое утверждение о том, как система должна работать, и проверяем, правда ли оно:
Пользователь говорит "запомни факт X"
Агент решает, какой уровень использовать
Данные сохраняются в выбранный уровень
При следующем запросе данные извлекаются
Контекст подаётся модели
Результат: шаг 1 - нет команды, шаг 2 - агент не знает об уровнях, шаг 3 - нет триггера, шаг 4 - из одного уровня да, шаг 5 - с потерями. Четыре из пяти - фикция.
Проход 2: Empirical Claim Audit Берём каждое число из Premortem-анализа и проверяем: 0.42% - из пальца. "900 строк" - реально 774. "96% дублей" - на глаз, не измерено. Результат: Premortem дал качественные находки, но цифры не выдерживают проверки.
Проход 3: Platform Capability Inventory Смотрим что Hermes Agent даёт из коробки. state.db с FTS5 - есть. memory() с auto-inject - есть. session_search - built-in. Результат: 52% моего "кастомного" кода дублировало встроенные возможности.
Фаза 2 - Execute + Adversarial
Выполняем проходы и добавляем обязательный финальный: атакуем собственные находки.
Что я нашёл, атакуя свой анализ:
Overclaim: "4 из 5 шагов - фикция". Шаг 4 и 5 - не совсем, они работают, но с ограничениями
Overclaim: "проблема в архитектуре". Нет, проблема в том что provider: basic возвращал None
Underclaim: я ни разу не посмотрел в конфиг. А там было
memory.provider: basic, который не сохраняет ничего
Фаза 3 - Synthesis: Conservation Law
Conservation Law - это структурное свойство, которое не уходит, сколько ни чини. Для моей памяти оно звучит так:
Память × Автомат = Constant. Чем больше места для хранения, тем меньше автоматов, которые это хранилище наполняют. Четыре уровня - это четыре хранилища, которые надо наполнять руками. Решение не в добавлении уровней, а в том, чтобы хотя бы один наполнялся сам.
Другие скилы Prism
Кроме prism-full есть ещё четыре. Они не про "линзы" - каждый переворачивает задачу по-своему:
prism-3way - три ортогональных вопроса: ГДЕ (структурная археология), КОГДА (темпоральная симуляция), ПОЧЕМУ (структурная невозможность). Расхождение ответов - и есть результат
prism-discover - не анализирует, а перечисляет все возможные углы для анализа
prism-reflect - анализирует анализ: что моя линза максимизировала, чем пожертвовала
prism-scan - генерирует одну динамическую линзу под конкретный артефакт
Все пять лежат в гитхабе, ссылки внизу
3. Как это работает в связке
Premortem нашёл, что "ни один факт не выживает без явной команды". Это симптом.
Prism объяснил, почему это предопределено архитектурно: pipeline из пяти шагов, четыре из которых - дыры.
Вместе они дают не просто список проблем, а ответ на вопрос "что с этим делать".
4. Цифры: что дал анализ
Достоверно, без ИИ-слопа :)
Уровней памяти: было 4, стало 2 (основная база + быстрые факты)
Объём MemPalace: 1.1 GB - почистил, дубликаты удалены
HippoRAG: индексация работает, 6409 документов, cron починен
AGENTS.md: 774 строки, после чистки ~120 актуальных
issue в репо с моделью памяти из коробки как я это вижу
Самое смешное: до запуска Premortem я был убеждён, что у меня продуманная архитектура. После - я понял, что половина кода дублировала то, что уже есть в основной базе с FTS5. Ты не знаешь, что у тебя уже есть, пока не заставишь себя проверить.
5. Premortem для этой статьи
Применяю Premortem к себе:
Статья опубликована. Через неделю - негатив. Почему?
Где код, как этим пользоваться? Ссылка: github.com/Cranot/super-hermes - там пять скилов Prism и premortem-шаблон. Всё в открытом доступе. Запускается через skill_view или прямым импортом.
Это же из менеджмента, при чём тут инженерия? Premortem в менеджменте - "давайте подумаем о рисках". Premortem в инженерии - structured backward reasoning с протоколом. Разница как между "а давайте brainstorm" и "вот чеклист, пройди по пунктам".
Цифры выглядят притянутыми? Справедливо. Я убрал все непроверенные проценты. Оставил только то, что могу подтвердить: строки кода, документы в базе, гигабайты.
6. Что я сделал бы иначе
Главная ошибка: я начал строить четыре уровня памяти, не проверив, что может один. Вместо того чтобы написать "агент запоминает факты -> база -> profit", я сразу пошёл в HippoRAG, chromadb, Wiki. Потому что "так интереснее", потому что "четыре уровня - это надёжно".
Premortem, запущенный на стадии дизайна, сказал бы: "Ты строишь четыре уровня. Каждый - отдельная инфраструктура с отдельным отказом. Ты знаешь, что будет, если один сдохнет? Ты тестировал падение каждого?"
Я бы ответил: "Можно, а зачем?".
И это нормально. Premortem для того и нужен - чтобы задавать неудобные вопросы до того, как они станут дорогими.
Вместо выводов
После двух статей про диагностику проблем AI-агентов я понял одну вещь: симптомов много, а инструментов - единицы. А методологий как говна за баней, поэтому лучше описать то что инженегр сможет проверить сам руками.
Premortem и Prism - не панацея. Они не найдут каждую дыру. Но они дают повторяемый процесс, который регулярно находит проблемы, которые иначе я бы пропустил.
Ссылки
Prism - репозиторий: github.com/Cranot/super-hermes
Premortem - оригинал, Klein «The Power of Intuition»
-
Hipporag - https://habr.com/ru/articles/860426/ https://habr.com/ru/companies/ruvds/articles/1025812/ https://github.com/osu-nlp-group/hipporag
Первая статья: «Cursor всё сломал, но виноват не Cursor» (habr.com/ru/articles/1030946)
Вторая статья: «Больше контекста — хуже результат» (habr.com/ru/articles/1031340)
igumnov
Я бы, наверное, начал не с четырёх уровней памяти, а с одного максимально простого и проверяемого слоя: факт появился - автоматически сохранился - его можно найти - он реально попал обратно в контекст. А уже потом добавлял бы HippoRAG, Wiki, chromadb и всё остальное, когда стало бы понятно, какую конкретно дыру они закрывают.
Жаль, что у вас это получилось через разбор уже построенной системы, а не на этапе проектирования. Но зато кейс показательный: часто архитектура выглядит надёжной именно потому, что в ней много слоёв, хотя на деле каждый новый слой добавляет ещё одну точку отказа, ещё один крон, ещё один конфиг и ещё одно место, где можно забыть проверить реальное поведение.
Из вариантов я бы ещё смотрел в сторону автоматического audit-log для памяти: что агент решил сохранить, куда сохранил, почему выбрал этот уровень, как потом это достал и использовал ли вообще. Тогда Premortem и Prism становятся не разовой ручной диагностикой, а частью нормального инженерного цикла.