Prism и Premortem. Hermes Agent.. Hermes Agent. premortem.. Hermes Agent. premortem. prism.. Hermes Agent. premortem. prism. инженерная методология.. Hermes Agent. premortem. prism. инженерная методология. структурный анализ архитектуры.

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

На фото изображен редкий экземпляр вайбкодера из первой статьи

На фото изображен редкий экземпляр вайбкодера из первой статьи

Привет, меня зовут Николай, я 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 Берём каждое утверждение о том, как система должна работать, и проверяем, правда ли оно:

  1. Пользователь говорит “запомни факт X”

  2. Агент решает, какой уровень использовать

  3. Данные сохраняются в выбранный уровень

  4. При следующем запросе данные извлекаются

  5. Контекст подаётся модели

Результат: шаг 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 – не панацея. Они не найдут каждую дыру. Но они дают повторяемый процесс, который регулярно находит проблемы, которые иначе я бы пропустил.


Ссылки

  1. Prism – репозиторий: github.com/Cranot/super-hermes

  2. Premortem – оригинал, Klein «The Power of Intuition»

  3. 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)

Автор: Aule

Источник