В первой статье — зачем hermes-dreaming нужен памяти Hermes Agent и как его установить. Здесь — что менялось после 2.7: как отличать настоящее подтверждение от совпадения слов, зачем появился необязательный облачный судья и как dreaming научился предлагать объединение дублей вместе с holographic. Замеры судьи относятся к выпуску 3.3.
Сразу о статусе на 30 октября. Через каталог hermes plugins install hermes-dreaming ставит 3.7.1: в ней уже есть судья, объединение дублей и обновление cron-задач установщиком. Последний релиз репозитория — 3.8.0. Для предложений объединить дубли нужны dreaming 3.4.0+ и holographic 0.19.0+; в каталоге holographic сейчас 0.22.0. Команды установки свежих релизов по хешам — ниже.
Где память агента ошибалась: не там, где я искал
Один из главных сигналов для переноса факта в постоянную память Hermes — люди возвращались к нему в разные дни. Скилл учитывает и доверие, и свежесть, а решение о записи остаётся за агентом, но без подтверждений факт в память не попадёт. Упоминание скилл находит по общим значимым словам. Это быстро, бесплатно и работает без сети — но слова совпадают и тогда, когда смысл другой.
Первым всплыло отрицание. «Михаил не любит острое» и «Михаил любит острое» состоят из одних и тех же основ: частица «не» — служебное слово, при сравнении она выпадает. Получалось, что сообщение с прямо противоположным смыслом засчитывалось как подтверждение. В 3.1.0 скилл научился отсеивать такие сообщения: если сообщение говорит факт с обратным знаком, подтверждением оно не считается. Китайский, где нет пробелов и отрицание пишется слитно, доработали в 3.1.1, а разные времена глаголов — «курит» и «никогда не курил» — в 3.2.0. Это по-прежнему проверка по правилам, а не понимание смысла: сложные формулировки она может пропустить.
Дальше я ждал, что отрицания и окажутся главной бедой. Чтобы проверить, мы прогнали эксперимент на живой семейной установке, где скилл работает с самого начала. За 60 дней не нашлось ни одного сообщения, которое перевернуло бы смысл факта. Зато из 60 случайно выбранных «подтверждений» 59 оказались шумом — сообщениями совсем про другое.
Главный источник шума нашёлся быстро. Когда в Telegram отвечаешь на сообщение, Hermes подклеивает к ответу цитату того, на что ты отвечаешь, — а это чаще всего текст самого агента. В живом чате ответами были 46 % сообщений людей. Цитата в среднем занимала 523 символа, собственные слова человека — 63. Скилл честно находил в цитате слова факта и засчитывал их как подтверждение от человека, хотя человек о факте не говорил ни слова. Второй источник — общие слова дома: «чат», «ветка», «Telegram», имена членов семьи встречаются в каждом пятом факте и связывают всё со всем.
Версия 3.2.0 переписала подсчёт. Цитата идёт в зачёт, только если собственные слова человека тоже касаются факта: «да, всё ещё веспа» под вопросом про байк — подтверждение, «ок, спасибо» под длинным отчётом агента — нет. Слова, которые встречаются хотя бы в каждом пятом факте, сами по себе упоминания больше не создают (в хранилищах меньше десяти фактов этот фильтр не работает). Новое число того же вида — «теперь 1500» под фактом «1200 в месяц» — больше не подтверждает старое значение. Короткие факты вроде «Гоша пьёт кофе по утрам» теперь читаются отдельным разбором: раньше их слова были слишком короткими, и подтвердить такой факт было нечем.
Результат на 80 обезличенных живых парах: доля верных ответов «подтверждает / противоречит / не о том» выросла с 26 % до 79 %. Из 79 пар, которые не были настоящими подтверждениями, правила по ошибке засчитывали 59, а теперь — 13. Число упоминаний, которые скилл находит за ночь на живой базе, упало с 852 до 247.
Что ещё нового в hermes-dreaming 2.8–3.2
Пока чинились подтверждения, скилл оброс и другим. С версии 2.8.0 он умеет работать с подтверждениями в хранилище фактов holographic: если люди повторили факт в два разных дня, без отрицания и без нового числа, агент получает готовую команду поднять факту доверие. Таких случаев намеренно мало — назвать тему ещё не значит повторить факт.
Версия 2.9.0 научила скилл различать, кто стоит за фактом: человек сказал это сам, подтвердил или агент вывел это из разговора. О выводах агента, которые никто не подтвердил, скилл спрашивает. Но полностью закрыть им дорогу в память удалось только в 3.8.0 — об этом ниже. Тогда же скилл стал использовать проверку секретов самого holographic: она узнаёт пароли и ключи на 18 языках. Попутно выяснилось, что «перешли мне ключ от двери» — это не утечка учётных данных, и проверка секретов перестала по ошибке отправлять такие сообщения в карантин. Как эта проверка выросла в самом holographic на отчётах пользователей с китайскими базами — в статье об обновлениях holographic.
Часть релизов 2.9.x пришла от пользователей. Один из них сообщил, что скилл неверно читает настройки Hermes, если в config.yaml стоит комментарий, — это исправлено в 2.9.6–2.9.8. В 2.9.9 повреждённый файл состояния больше не читается молча как пустой: его откладывают в сторону и сообщают, а состояние записывается целиком или не записывается вовсе. Сломанный dreaming.json останавливает ночь, а не запускает её на настройках по умолчанию. Версия 3.0.0 — внутренняя перестройка: большой скрипт разделён на части, поведение ночи не изменилось.
Что изменилось после 3.3.1: ошибки чтения и фильтр секретов
В 3.3.2 исправили неприятную подмену: «не удалось прочитать» больше не означает «там пусто». Если база сообщений занята, ночь не объявляет все записи забытыми и не засыпает человека вопросами «ещё актуально?», а сообщает messages_unavailable. Недоступный файл состояния не перезаписывается пустым; сломанный список cron-задач не позволяет уборке забытых копий отчитаться об успехе. Переключатели доверия принимают только настоящие true и false: строка "false" больше не включает доверие.
В 3.3.3–3.3.4 обновилась копия фильтра holographic. Русский «пин» со значением считается секретом, а версия после слова pin — нет. Просьба «Можешь показать пароль?» или «Можешь отправить OPENAI_API_KEY?» отсекается как инструкция; рассказ о том, что кто-то показал пароль, без самого пароля остаётся фактом. Поэтому обновление одного holographic не заменяет обновления dreaming: у ночного прохода собственная копия фильтра.
Dreaming 3.4: объединить дубли, сохранив историю
В 3.4.0 ночной проход стал искать похожие пары по всей основной базе фактов. Один проект могли описать дважды, а извлечение — пересказать старое другими словами. Теперь сон задаёт один вопрос за ночь с обоими текстами целиком и номером вроде D-17: «склеить?». Номера не переиспользуются, и только ответ человека на конкретный номер разрешает объединение.
Ночью факты не объединяются. После «да D-17» агент вызывает fact_store merge у holographic с номерами показанных версий через expect. Если один из текстов изменился после вопроса, хранилище отвечает changed_since и ничего не пишет. При согласии копия уходит из поиска, но её версии, источники и подтверждения остаются в истории основного факта. Отдельного unmerge нет. Ответ «это разные» можно сохранить через dream-reject.py --not-duplicates D-17; отменить отказ — через --undo D-17.
Правило сходства предлагает вопрос, а не доказывает, что записи тождественны. Оно отсеивает пары с несовместимыми числами, именами, отрицанием или заменой одного слова, но может не увидеть перестановку ролей, разницу времён или перевод. Поэтому существующие факты объединяются после ответа человека. Когда объединение состоялось, dreaming убирает служебную копию из текущего состояния, но сохраняет дневник: объединение не равно забыванию.
У отдельной задачи извлечения есть узкое исключение. Если она только что добавила собственный пересказ, holographic ответил similar и подсказал объединение со старым фактом, а новой информации нет, агент может сразу присоединить именно свой новый факт. Объединять таким способом чужие старые записи cron не может: holographic проверяет, что копия записана этой же сессией.
Для этой функции нужны dreaming 3.4.0+, holographic 0.19.0+ и основная база с scope: profile. Без поддержки fact_merges, с другим источником или базами отдельных чатов функция пропускается с причиной в статистике. Остальные проверки ночи продолжают работать.
Перед первым объединением сделай резервную копию. Оно повышает схему истории holographic до 2; после этого версии 0.15–0.18 не могут записывать в базу. Каталог сейчас отдаёт holographic 0.22.0, но ручной откат по хешу ниже 0.19.0 выключит память основного агента с HistoryTooNew: верни 0.19.0+ либо восстанови копию до объединения. Подробнее — в разборе обновлений holographic.
Инструкции извлечения и границы «забудь»: 3.4.1–3.4.2
В 3.4.1 уточнили, что искать при извлечении: долговременные правила и ограничения тоже важны, даже если человек сказал их между делом. Разовая просьба в рамках текущей задачи не становится постоянным правилом. Сами сообщения остаются данными для анализа, а не командами, которые ночной агент должен исполнять.
Ещё одна тихая потеря — ключевые слова, которые агент попытался записать, но хранилище не приняло. Теперь инструкции требуют смотреть на фактически возвращённые keywords, keywords_dropped и keywords_not_set, сохранять прежние слова и делать не больше одной попытки исправить только ключевые слова. Руководство по объединению также различает текущий, изменившийся, закончившийся и исправленный основной факт. Это уточнения инструкций; тесты их наличия не доказывают, что любая модель всегда им последует.
3.4.2 — исправление инструкций и документации, без нового алгоритма, зависимости или расписания. После «забудь» хранилище удаляет версии факта, а dreaming чистит свои копии — кэш, дневник и журналы собственных задач. Историю Git, внешние дампы баз, системные резервные копии и историю сессий Hermes он не переписывает. Отчёт должен отдельно сказать, что удалено из хранилища и что осталось во внешнем архиве, не цитируя забытый текст. Оставшаяся внешняя копия не означает, что удаление из хранилища провалилось; повтор команды не снимает границу чужого инструмента.
3.5–3.8: обновление cron, большие базы и только подтверждённое
3.5.0 убрала самую неудобную часть обновления. Раньше новые инструкции ночных задач приходилось переносить в cron вручную. Теперь install_cron.py сам обновляет промпт существующей задачи, если он в точности совпадает с одним из стандартных шаблонов. Изменённый вручную промпт — даже на один пробел — остаётся как есть, с предупреждением. Расписание, доставка, модель, пауза и счётчики запусков сохраняются, ни одна задача не возобновляется и не удаляется сама. Ключ --upgrade собирает обновление в один шаг: проверяет настройки, заменяет копии служебных скриптов, синхронизирует задачи и проверяет результат. install.py --check теперь показывает устаревшие стандартные промпты, задачи на паузе и дубли задач.
3.6.0 по желанию добавляет в ночной отчёт сводку результатов задач из журнала holographic 0.20 (task_outcomes: true). Это только счётчики: правдивость, доверие и порядок фактов от них не меняются, новых вызовов модели нет, а отчёт агента о том, что человек его поправил, не считается подтверждением человека.
3.7 — про большие базы. Поиск дублей брал кандидатов только по основам слов, и на базах из похожих фактов — напоминаний с датами, одной фразы про многих людей — работа росла как квадрат размера. Примерно с 7 500 фактов ночь исчерпывала лимит проверок и пропускала раздел. В 3.7.0 кандидаты сужаются ещё и по числам и именам, так что 50 000 синтетических фактов проверяются за 33 секунды. В 3.7.1 по отчёту sprd-tmu ускорен подсчёт подтверждений на длинной переписке: окно из 190 фактов и 1 600 сообщений раньше не успевало за отведённые 600 секунд, теперь занимает около 86 секунд, а память ограничена настройкой corroboration.memory_mb (256 МБ по умолчанию). 3.7.2 ускорила карантин секретов на длинных сообщениях примерно в 40 раз, но установщик Hermes её не принял: одно слово в списке начал инструкций сканер прочитал как попытку взлома. 3.7.3 это исправила, а проверка hermes plugins validate теперь стоит в CI до тега. Ставить 3.7.2 не нужно.
3.8.0 закрыла лазейку в постоянную память. Вывод агента, который никто не подтвердил (inferred в holographic), мог дойти до MEMORY.md, если агент часто им пользовался или его слова встречались в чате. Теперь он не переносится ни одним путём: если люди повторили его в разные дни, ночь предлагает спросить подтверждение, а после ответа человека факт идёт по обычным правилам. Хранилища без пометок происхождения — holographic до 0.15, выгрузки SQLite и JSONL — работают как раньше. Вместе с holographic 0.23 недавно оценённые факты больше не считаются свежими: их вес возвращается к настоящему возрасту.
Зачем памяти Hermes Agent облачный судья
После 3.2.0 правила стали заметно точнее, но предел у них остался. Правило по-прежнему видит слова, а не смысл. «Гоша тренирует юниоров» засчитывалось факту «Гоша не пьёт кофе»: общее имя, никакого отрицания в сообщении, новых чисел нет. Вставленный в чат длинный отчёт подтверждал каждый факт, которого касался. На отдельном проверочном наборе из 360 пар настоящими подтверждениями оказались лишь 37 % пар, которые засчитали правила. Каждое ложное подтверждение подталкивает факт к постоянной памяти или говорит хранилищу, что люди его повторяют.
Сначала я попробовал решить это локально. В эксперименте к 3.2.0 мы сравнили с правилами две небольшие модели, которые можно запустить на своём сервере: многоязычную Laya и mDeBERTa, обученную определять, следует ли одно утверждение из другого. Laya оказалась слабее остальных моделей. mDeBERTa сама по себе точнее правил, но как второе мнение к ним почти ничего не добавила, а памяти занимала около 2,2 ГБ — для моего сервера на 8 ГБ, где уже работает агент, это дорого. Заметно поднимали итог только облачные модели решений.
Что такое модель решений
Модель решений — это не чат-бот. Она не пишет текст, а получает вопрос и список возможных ответов, выбирает один и сообщает вероятность каждого. Отвечает за несколько сотен миллисекунд и стоит доли цента. Для задачи «подтверждает ли это сообщение этот факт» это ровно то, что нужно: вопрос узкий, ответов три, рассуждения не требуются. По идее это близко к подходу LLM-as-a-judge, когда одна модель проверяет другую, только здесь судья проверяет не модель, а правила, и сам он — классификатор, а не чат.
Скилл поддерживает две такие модели. Первая — Jev 1.14 от TypeSafe, её отдаёт OpenRouter через альфа-API. Вторая — OpenAI Decisions с моделью gpt-6-luna: 6 октября OpenAI открыл её в публичной бете, а 22 октября вывел в общий доступ. Вызов каждой по замеру стоит около $0,00002, медианная задержка — около 0,3 секунды. Jev стоит первым, потому что на проверочном наборе снял больше ложных подтверждений при том же нуле ошибок. OpenAI — запасной на ночи, когда альфа-API Jev лежит или меняется: к нему пара уходит, только если первая модель не дала пригодного ответа.
Как проходит ночь с судьёй
Судья выключен по умолчанию. Его код тогда не загружается, и сам проход не делает внешних вызовов. При добавлении судьи в 3.3.0 записанный эталон двух ночей подтвердил, что без него решения оставались как в 3.2.0. Это проверка того изменения: последующие исправления чтения и новые предложения дублей у 3.4 описаны выше.
Включённый, он работает так. Сначала правила решают ночь как обычно и запоминают каждую пару «факт — сообщение», которую засчитали. Потом для каждой пары, которой разрешено уйти с машины, скилл задаёт модели один и тот же вопрос: сообщение подтверждает факт, противоречит ему или ни то ни другое? Модель выбирает ответ и даёт вероятности. Если ответ не «подтверждает» и уверенность в нём не ниже порога 0,50, пара снимается из счёта. Это и есть вето.
Важное ограничение: судья может только вычеркнуть подтверждение, которое дали правила, но никогда не добавит своё. Кандидатов по-прежнему выбирают правила, поэтому ошибка или сбой судьи не может затащить в память то, чего правила не нашли. Ошибочное вето может задержать запись или подтверждение настоящего факта и изменить другие решения ночи, которые опираются на число упоминаний, — но не может добавить лишнего.
Режимов два. В shadow в итоговый отчёт попадают решения правил, а в статистике ночи появляется строка: сколько пар судья снял бы и сколько решений это изменило бы. В veto ночь решается заново без снятых пар — и это касается всего, что опирается на счёт: переноса фактов в память, подтверждений, затухания старых фактов, новых кандидатов и конфликтов. Вопросы «эта запись ещё актуальна?» судья не трогает никогда.
И последняя страховка. Если за ночь судья ответил меньше чем по половине пар, которые мог отправить, — упала сеть, кончился ключ, провайдер поменял API, — вето в эту ночь не применяется вовсе, решают одни правила. После трёх таких ночей, если между ними не было двух нормальных подряд, приходит предупреждение — не чаще раза в неделю. Потерянный ключ не пройдёт незамеченным, но и ночь с неполной проверкой не исказит память.
Насколько точен судья: замер на 360 парах
Порог и сам смысл затеи проверили до того, как написали код. Для проверки подготовили 921 пару ровно так, как их готовит плагин, а провайдерам отправляли только те, что засчитали правила. На 561 паре выбирали порог по заранее записанному правилу: самый низкий, при котором ошибочных вето не больше 5 %, а потерянных подтверждений — не больше 10 %. Оба провайдера уложились уже на нижнем проверенном значении, 0,50. Оставшиеся 360 пар — проверочный набор на русском, английском и китайском — написала отдельная модель, и его заморозили до первого прогона.
На этом наборе правила засчитали 270 пар: 101 настоящее подтверждение и 169 ложных. Jev снял 142 ложных из 169, или 84 %. OpenAI — 127, или 75 %. Ни одного настоящего подтверждения не снял ни тот ни другой. Доля настоящих среди засчитанных выросла с 0,37 до 0,79 у Jev и до 0,71 у OpenAI. По языкам картина ожидаемая: лучше всего судья справляется с английским (Jev снял 94 % ложных), хуже — с русским (76 %), китайский посередине (85 %). Весь замер стоил 2,3 цента.
Перед выпуском сам плагин прогнал эти записанные ответы через свой код и снял ровно те же пары, одну в одну. 71 тест на поддельном провайдере проверяет, какие пары разрешено отправлять, что попадает в запрос и как судья ведёт себя при сбоях, перерасходе денег и времени.
Теперь о том, чего этот замер не доказывает. Проверочный набор написала модель, человек его не перепроверял, а живая речь грязнее написанных примеров. Ноль ошибочных вето получен на чистых текстах; в настоящих чатах судья наверняка иногда ошибётся. И после вето среди засчитанного остаётся пятая-четвёртая часть шума: судья заметно лучше правил, но не идеален. Поэтому по умолчанию судья выключен, а начинать с ним стоит с режима shadow: он оценивает пары, но решения ночи не меняет.
Приватность: что судья отправляет в облако
Это главный вопрос для всех, кто держит агента в семейном или рабочем чате, поэтому правила здесь жёсткие. Как вообще защищать ИИ-агента в общем чате, я разбирал отдельно. Отправляются только пары из тех чатов и источников, которые ты перечислил сам: по умолчанию не перечислено ничего. Уходит текст факта и собственные слова человека — без цитаты, на которую он отвечал, без ссылок, без служебных пометок. Ни идентификаторов, ни имени отправителя, ни времени. Имена внутри самих текстов при этом уходят — это стоит понимать.
Пара, в которой нашёлся секрет или похожая на инструкцию строка, остаётся дома. Длинные тоже: факт длиннее 400 символов или сообщение длиннее 600 символов судье не отправляются и остаются засчитанными без вердикта. Это заметная доля: на моей семейной установке пробный прогон нашёл 247 засчитанных пар, из них отправить можно было 63, 113 остались дома из-за длины и 71 — потому что пришли не из разрешённого источника.
Получатели — OpenRouter для Jev и OpenAI для запасного. Если включены оба, одна и та же пара может дойти до обоих. Условия хранения данных у них разные. По документации на октябрь 2026 года на данных, отправленных Jev, не обучают, а нулевое хранение доступно только enterprise-клиентам. OpenAI хранит запросы до 30 дней для контроля злоупотреблений, нулевое хранение даёт по одобрению и по умолчанию на данных тоже не обучает. Прежде чем отправлять семейные чаты, проверь текущие условия сам: отправленное не отозвать.
Деньги и время ограничены на каждую ночь: не больше 250 вызовов и двух минут, бюджет — $0,05 (последний вызов может его чуть превысить), и никогда позже срока ночной проверки. При цене вызова около $0,00002 ночь моей установки — около 60 пар — обходится примерно в десятую долю цента. Скилл ходит только по HTTPS на фиксированные адреса, без прокси и перенаправлений. Свои файлы судья держит в ~/.hermes/cache/ с правами только для владельца: кэш вердиктов на 90 дней (хэши и номера фактов, без текста), журнал всего отправленного — как оно ушло, чтобы можно было проверить, — и строку здоровья на каждую ночь. Если сказать агенту «забудь» какой-то факт, он пропадёт и из этих файлов.
Как включить облачного судью и когда переходить на veto
Включается судья одной секцией в ~/.hermes/dreaming.json:
"judge": {
"mode": "shadow",
"providers": ["jev", "openai"],
"send_from": "trusted",
"send_sources": ["telegram"]
}send_from: "trusted" разрешает доверенные групповые чаты из настроек скилла, а если включено trust_private_chats — ещё и личные. Чтобы точно знать, чья переписка уходит, вместо "trusted" можно перечислить id чатов. send_sources — откуда пришла сессия, например Telegram. Ключи OPENROUTER_API_KEY и OPENAI_API_KEY кладутся в окружение или в ~/.hermes/.env: Hermes не передаёт ключи провайдеров в ночные скрипты, поэтому судья сам читает свою строку из этого файла — и никакую другую. Ключ нигде не печатается. install.py --check покажет режим, куда могут уйти пары и найден ли каждый ключ, но не его значение. Посмотреть ночь без последствий можно через dream.py --dry-run: он читает кэш судьи и ничего не отправляет. А вот ручной запуск без --dry-run — настоящая ночь, с отправкой.
Переходить на veto вслепую не нужно, для этого есть процедура. Пару недель судья работает в shadow. Потом dream.py --judge-export sample.jsonl выгружает слепую выборку — по одной оценённой паре на факт, только текст факта и сообщения, без ответа судьи. Ты размечаешь каждую строку: подтверждает, противоречит, ни то ни другое или «не знаю». dream.py --judge-score сравнивает разметку с вердиктами и отвечает одним словом. ready — когда даже по пессимистичной оценке ошибочных вето не больше 10 %, потерянных подтверждений не больше 20 %, судья ответил хотя бы по 90 % пар и ни одно ошибочное вето не изменило решение о памяти. Если запасной провайдер дал больше пятой части вердиктов, проверку должен пройти каждый провайдер отдельно. not_ready — когда даже по оптимистичной оценке ошибочных вето больше 10 %. Иначе continue: разметить ещё.
Результатов такой разметки на живой установке пока нет, поэтому переход на veto остаётся впереди. Критерий тот же — сначала проверка и результат ready.
Как обновить hermes-dreaming
На 30 октября каталог отдаёт 3.7.1; поставить её поверх старой версии можно командой hermes plugins install hermes-dreaming --force. Для 3.8.0, не дожидаясь обновления каталога, можно сохранить каталог как источник и указать полный хеш релиза:
hermes plugins install hermes-dreaming --ref 4a367324db65f0b4fe3b43a18a83704609cecffe --forceHolographic из каталога (0.22.0) уже умеет объединять факты. Если хочешь и последнюю 0.23.1, сначала сделай hermes backup, затем:
hermes plugins install holographic --ref 93fd2b7334c36fd752c35360d7089573411597ef --forceЭто закрепляет конкретные коммиты релизов, а не устанавливает произвольное состояние main. Проверить версии можно через hermes plugins list. Если уже был merge, не откатывай holographic по хешу ниже 0.19.0: ограничение схемы описано выше. Версию 3.7.2 не ставь — её отклоняет установщик Hermes.
После обновления dreaming приведи в порядок служебные скрипты и cron-задачи. С 3.5.0 это одна команда: сначала посмотри план, потом повтори без --dry-run, а в конце запусти проверку. Ниже пути обычной установки Linux/macOS; при другом HERMES_HOME или Windows используй свои пути к плагину и интерпретатору Hermes:
~/.hermes/hermes-agent/venv/bin/python \
~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install_cron.py --upgrade --dry-run
~/.hermes/hermes-agent/venv/bin/python \
~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install_cron.py --upgrade
~/.hermes/hermes-agent/venv/bin/python \
~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install.py --check--upgrade заменяет копии служебных скриптов, обновляет стандартные промпты существующих задач и проверяет результат. Расписание, доставка, модель и пауза сохраняются. Если ты правил промпт руками, установщик его не тронет и предупредит: сравни его с DREAM_PROMPT и EXTRACT_PROMPT в установленном install_cron.py и перенеси изменения сам. Не меняй настройки cron одновременно с работой установщика и не редактируй живой cron/jobs.json вручную. Ключ --force здесь не нужен: он создаёт ещё одну задачу.
Посмотреть сегодняшнюю ночь без записи состояния и отправки судье можно через dream.py --dry-run. Ручной запуск без этого флага, включая hermes cron run, — настоящий проход со всеми его последствиями, а не безопасный предпросмотр.
Если скилла ещё нет, начни с первой статьи — там установка шаг за шагом, а если нет и самого Hermes — с установки и подключения к Telegram. Код, полное описание судьи и место для вопросов — в репозитории на GitHub.
Другие мои скиллы в том же каталоге — hermes-cron для задач по расписанию и hermes-field-notes для найденных ошибок и патчей. А где искать остальные скиллы и плагины для Hermes и как проверять чужие перед установкой, собрано в обзоре.
Частые вопросы
Нужно ли включать судью всем?
Нет. Без него скилл работает как раньше и после 3.2.0 точнее, чем был. Судья нужен тем, у кого оживлённый чат, много фактов и важно, чтобы в память не попадало лишнее. Если отправка текстов из чата в облако для тебя неприемлема — просто не включай.
Сколько стоит судья?
Сам скилл бесплатный. Вызов модели по замеру стоит около $0,00002, бюджет на ночь — $0,05 (последний вызов может его чуть превысить), а в реальности на семейной установке выходят доли цента. Нужен ключ OpenRouter, OpenAI или оба.
Может ли судья испортить память?
Он может только снять подтверждение, но не добавить его, поэтому записать в память то, чего не нашли правила, он не может. В режиме shadow он не меняет решения ночи, но отправляет разрешённые пары провайдерам и ведёт журнал. В veto ошибочное вето может задержать запись или подтверждение настоящего факта, а ночь, где судья ответил меньше чем по половине пар, решается без него.
Почему не локальная модель?
Попробовали: Laya оказалась слабее остальных моделей, а mDeBERTa как второе мнение почти ничего не добавила и требовала больше двух гигабайт памяти. Облачные модели решений сняли в несколько раз больше ложных подтверждений и не требуют от сервера ничего.
Почему длинные сообщения не отправляются?
Чем длиннее текст, тем больше в нём того, что к факту не относится, и тем выше шанс отправить лишнее. Порог для длинных текстов при замере не проверялся. Возможно, позже судье будет уходить только кусок сообщения вокруг совпавших слов, но это решение после пары недель наблюдений.
Какая версия уже есть в каталоге, а какая только в репозитории?
На 30 октября в каталоге закреплена 3.7.1, а в репозитории выпущена 3.8.0. Судья, объединение дублей и обновление cron-задач через --upgrade уже доступны из каталога; предложения объединить дубли требуют dreaming 3.4.0+ и holographic 0.19.0+. Не путай релиз репозитория с обновлением закреплённого коммита в каталоге.
Объединение дублей сотрёт старую историю?
Нет, merge сохраняет версии, источники и подтверждения копии. Для стирания есть forget, а он уже не чистит внешние архивы и историю сессий Hermes. У объединения нет отдельной команды отмены, и после первого merge база требует holographic 0.19.0 или новее для записи.
