Как организовать работу с Hermes: чаты, сжатие контекста и папки проектов

Длинные диалоги с AI-агентом быстро превращаются в рабочую среду. В них появляются решения, ссылки, ошибки, файлы, планы, исследования и десятки промежуточных идей.

Но у любого чата есть контекстное окно. Поэтому рано или поздно возникает вопрос: начинать новый диалог или позволить агенту сжимать старую историю?

Я разбирался с этим на примере Hermes Agent и собрал рабочую систему. Она подходит для личных задач, разработки, исследований, автоматизаций, контента и клиентских проектов.

Главная мысль простая: один долгий проект — один постоянный чат. А важные знания должны храниться не только в чате, но и в файлах проекта.

Когда мы создаём новый чат после каждой большой задачи, агент теряет рабочий контекст.

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

Это особенно заметно в разработке. Сегодня вы обсуждали сайт, завтра — деплой на Railway, послезавтра — ошибку в API.

Если каждый раз начинать с нуля, агенту приходится восстанавливать картину по обрывкам.

Hermes умеет сжимать старую часть переписки. Обычно сжатие запускается примерно на половине доступного контекстного окна.

Старая история превращается в компактную сводку, а актуальная часть диалога сохраняется подробнее. После этого чат снова растёт, затем при необходимости сжимается ещё раз.

Это штатный режим работы, а не признак того, что диалог «сломался».

Сжатие не является идеальной памятью. Оно может сохранить логику и решения, но не обязано дословно удержать каждый старый лог, URL или параметр.

Поэтому задача пользователя — не избегать сжатия, а правильно организовать информацию по проекту.

Автосжатие — это оперативная память проекта.Файлы, документы и репозиторий — его долговременная память.

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

Например, у предпринимателя или консультанта могут быть отдельные сессии для личного здоровья, здоровья близкого человека, личного планирования, исследования конкурентов, контентной системы, разработки сайта, Apify-парсеров и технических автоматизаций.

Смысл такого разделения в том, что агент не смешивает факты и решения из разных сфер.

В чате по исследованию рынка не должны всплывать детали тренировок. В чате по проекту клиента не должны смешиваться заметки по личному планировщику.

Тематически чистая история полезна ещё и потому, что агенту проще качественно сжать её.

Если внутри одного диалога находятся разработка, медицина, покупки, идеи для постов и обсуждение cron-задач, итоговая сводка неизбежно становится более шумной.

Иногда две темы можно держать вместе. Например, исследование конкурентов и cron-задачи допустимо вести в одном чате, если расписание напрямую собирает данные по этим конкурентам.

Но общую техническую инфраструктуру, которая обслуживает несколько проектов, лучше вынести в отдельную сессию.

Каждый разговор Hermes автоматически сохраняет как сессию. Сессию можно назвать и потом открыть снова по имени или через список сохранённых чатов.

Практичный вариант — сразу после создания задать понятное название:

text
/title Исследование конкурентов

Или:

text
/title Apify парсеры и cron

Можно также начать первый запрос с понятного заголовка. Но явная команда /title надёжнее: название будет коротким, единообразным и его проще найти позднее.

Для навигации удобно использовать:

text
/sessions

Эта команда открывает список сохранённых чатов, где можно выбрать нужный проект.

Если вы помните название, можно быстро вернуться в конкретную сессию:

text
/resume Исследование конкурентов

Команда /status нужна для другого: она показывает, где вы находитесь сейчас.

Там можно проверить название текущего чата, активную модель, объём контекста и другие параметры сессии.

Она не переключает между проектами.

В терминале можно использовать такие команды:

bashhermes -c

Эта команда продолжает последнюю сессию.

bashhermes -r "Исследование конкурентов"

А эта открывает сессию по названию.

Особая ситуация возникает, когда вы переключаете модели с разным размером контекстного окна.

У одной модели окно может быть 1 миллион токенов, у другой — 256 тысяч.

Если сжатие задано только процентом, поведение будет заметно различаться.

Например, порог 50% означает сжатие примерно на 500 тысячах токенов для модели с окном 1 миллион и примерно на 128 тысячах для модели с окном 256 тысяч.

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

Логичнее задать единый ориентир по количеству токенов — например, около 120–150 тысяч, если ваша версия Hermes и выбранный движок контекста поддерживают абсолютный порог.

Процентный порог при этом можно оставить как страховку для модели с меньшим окном.

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

Важно понимать коэффициент target_ratio: 0.20.

Он не означает, что миллионное окно после сжатия превратится в 200 тысяч токенов.

Если сжатие началось на 150 тысячах токенов, то ориентир для свежего сохраняемого хвоста — около 30 тысяч токенов, плюс системные инструкции и итоговая сводка.

В режиме lean итоговый размер не является жёсткой цифрой.

Hermes сохраняет системный контекст, начало сессии, важные технические якоря, недавние сообщения и сводку прошлого.

Поэтому после сжатия может остаться несколько десятков тысяч токенов активного контекста. Обычно этого достаточно, чтобы продолжать сложную задачу без ощущения полного перезапуска.

Даже хороший компрессор не знает, какие детали лично для вас критичны.

Он может правильно сохранить идею проекта, но не выделить один важный URL, версию библиотеки, решение по архитектуре или ограничение клиента.

Поэтому после каждого заметного этапа полезно делать checkpoint — короткий снимок текущего состояния проекта.

Например, после исследования конкурентов, создания MVP, настройки деплоя, согласования структуры сайта или запуска cron-задачи можно попросить агента сформировать такую сводку:

text
Сделай рабочий checkpoint проекта. Укажи цель, что уже сделано и подтверждено, принятые решения и причины, текущую структуру файлов, важные ссылки и идентификаторы, ограничения, нерешённые риски, что уже пробовали, текущую точку работы и следующие шаги. Не добавляй предположений. Непроверенные данные помечай отдельно. Сохрани точные названия файлов, URL, команды, версии и переменные окружения.

Такой checkpoint полезно сохранить в README.md, docs/decisions.md, задаче в планировщике или заметке.

Если потом понадобится новый чат, в него не нужно переносить весь старый лог. Достаточно вставить этот структурированный бриф.

Для серьёзной задачи лучше создать отдельную папку проекта и запускать Hermes именно из неё.

Тогда агент работает в понятном корне проекта: там он может искать инструкции, создавать файлы, работать с кодом и использовать инструменты.

На macOS это может выглядеть так:

bashmkdir -p ~/Projects/competitor-research cd ~/Projects/competitor-research hermes

После этого можно попросить агента организовать структуру: документы, исходные данные, отчёты, промпты, автоматизации и архив.

Я бы не просил агента бездумно создавать десятки папок.

Лучше сначала получить план, затем подтвердить его:

text
Мы находимся в рабочей папке нового проекта. Сначала предложи дерево папок и файлов для проекта. Объясни назначение каждого раздела. Ничего не создавай до моего подтверждения. После подтверждения создай базовую структуру, README.md, AGENTS.md, docs/decisions.md и .gitignore. Не храни ключи, пароли и секреты в файлах проекта. Перед удалением или массовой перезаписью всегда спрашивай.

Для исследования конкурентов структура может включать папки data для выгрузок, sources для реестра источников, reports для выводов, automations для Apify и cron, prompts для повторяемых инструкций, docs для методики и решений, а также archive для старых версий.

В корневой папке особенно полезен файл AGENTS.md.

Это инструкция для AI-агента именно в рамках конкретного проекта.

В нём можно закрепить цель проекта, правила работы, структуру файлов, команды, требования к отчётам и запреты.

В AGENTS.md стоит записать не общие слова, а практические договорённости:

Получается связка, которая даёт намного больше устойчивости, чем один чат.

Сессия Hermes хранит ход обсуждения. AGENTS.md закрепляет правила. README.md объясняет проект. decisions.md сохраняет решения.

Не нужно в первый день строить сложную бюрократию из десятков чатов, папок и документов.

Достаточно ввести несколько правил:

Эта система не отменяет удобство агента.

Наоборот, она позволяет использовать длинные разговоры без страха, что важное исчезнет после очередного сжатия или переключения модели.

AI-агент становится действительно полезным не тогда, когда у него бесконечное окно контекста.

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