Мы уже проходили это: агент работает, пока работает подписка. Модель выводят из эксплуатации — рабочий процесс встал. Вендор закрыл доступ из вашего региона — встал. Подписка подорожала или изменила условия — снова встал, потому что поверх неё был построен целый участок работы. А самая обидная разновидность: специалист, который настраивал агента, увольняется — и вместе с ним уходят знания, как этот агент должен был работать.
Проблема не в моделях. Модели хорошие, и их много. Проблема в том, что вместе с моделью многие купили агента: его память, его процедуры, его расписание, его интеграции. Этот слой лежит на территории вендора, и при смене поставщика он не переезжает вместе с вами — он остаётся там, в виде истории чатов и гайдов, которые больше никто не откроет.
Hermes — наш ответ на такую конструкцию. Сам агент, память между сессиями, скиллы-процедуры и крон живут у нас: в нашем репозитории, у нас на серверах, под нашим контролем. А модель — сменный картридж: вытащили один, вставили другой, агент продолжает делать работу.
Table Of Contents
Агент, купленный вместе с подпиской
Вендорский замок в ИИ устроен хитрее, чем замок на двери. Он не запрещает уйти — он делает уход дорогим. Каждый месяц работы с агентом «из коробки» нарастает слой, который вы не контролировали: настройки промптов, сохранённые диалоги с контекстом, автоматизации, привязанные к конкретному API. В какой-то момент выясняется, что замена возможна, но вместе со старым сервисом придётся выбросить всё, что вокруг него наросло.
Мы подробно разобрали этот механизм в статье «Разбор вендорского замка» — там по слоям расписано, где именно проходит разрыв между «мы пользуемся моделью» и «модель пользуется нашей инфраструктурой». Кратко отсюда: разделять нужно раньше, чем понадобится уходить. Идеально — с самого первого дня, когда настраивать нечего и переносить нечего.
Hermes ровно это и разделяет. Слой агента — память, процедуры, расписание, доступы — открыт и принадлежит вам. От вендора зависит только то, что и должно от него зависеть: качество конкретной модели.
Что такое Hermes
Hermes — открытый агентный фреймворк от Nous Research под лицензией MIT. Код, поведение и документация публичные: вы можете прочитать, как агент думает, и поменять, если что-то не так. Никакого «доставляем по SaaS и не показываем внутренности»: слой агента — обычный код на вашем диске, его можно прочитать, форкнуть и переписать.
Практически важно, где агент живёт. Hermes работает в терминале, в IDE и в мессенджерах: Telegram, Slack, Discord, WhatsApp, Signal, Email, Matrix плюс вебхуки. Это значит, что агенту не нужен «свой кабинет»: он приходит туда, где сотрудники и так сидят весь день. Задача из чата поддержки, уведомление о деплое, отчёт по расписанию — всё приходит в обычный мессенджер.
Модельная часть: 20+ провайдеров, переключение модели и провайдера на ходу, без перенастройки агента. Пулы ключей автопереключаются, когда очередной ключ исчерпан, — рутина «поменяйте ключ в настройках» исчезает. Бэкенд терминала выбирается под задачу: локальный, docker, ssh или modal — агент может исполняться там, где ему положено, а не там, где хочется вендору.
Info
Hermes — открытый проект: агент Nous Research, лицензия MIT. Полная документация — hermes-agent.nousresearch.com/docs: установка, провайдеры, скиллы, крон, мессенджеры. В репозитории проекта около 3000 автотестов — для открытого инструмента это признак того, что поведение не «как получится», а проверяемое.
Четыре вещи, которые дают эффект
Дальше — то, ради чего всё это читается. У Hermes много функций; на результат в реальной работе влияют четыре.
Память между сессиями
Без памяти каждый запуск — новый стажёр: заново объясняй, кто ты, какие правила, что уже пробовали и почему отвергли. Память Hermes переживает перезапуск: агент помнит, кто он, какие у него правила и какой опыт у команды с этой задачей. Встроенной памяти хватает для старта; подключаются и внешние бэкенды — если нужно своё хранилище знаний или общий контекст между несколькими агентами.
Это скучный, фундаментальный слой. Именно он превращает «поговорили с ChatGPT» в «сотрудник, который в курсе».
Скиллы: процедуры, которые агент сохраняет сам
Скилл — markdown-процедура: пошаговый рецепт решения класса задач. «Как выложить релиз», «как разобрать инцидент», «как посчитать отчёт». Скиллы подгружаются под конкретную задачу — агент не тащит всю базу знаний в каждом запросе, а берёт нужный рецепт, когда он релевантен.
Ключевое: агент может создавать и править скиллы сам. Отработал задачу, заметил граблю — дописал шаг в процедуру. Знания перестают быть магией в голове сотрудника и становятся файлом в репозитории: его можно посмотреть, отревьюить, откатить, передать новому человеку. Сотрудник уходит — скиллы остаются.
Субагенты: параллельно и изолированно
Один агент с одним контекстом — это один поток работы. Hermes умеет выставлять субагентов: изолированный контекст, свой терминал, параллельные батчи. Большая задача нарезается на независимые куски, каждый кусок делает отдельный субагент, и они не засоряют друг другу контекст догадками со своей ветки.
Для нас это способ перестать выбирать между «сделать хорошо» и «сделать сегодня»: объём работы растёт не за счёт скорости одного потока, а за счёт количества параллельных.
Крон: работа по расписанию, без дежурного
Агент, которого нужно дёргать руками, — это всё ещё работа для человека. Крон Hermes живёт по-настоящему по расписанию: задача вида 0 9 * * * утром сама стартует, сама делает, сама доставляет результат. У каждой задачи — свои скиллы, своя модель и свой способ доставки. Утренний мониторинг — дешёвой и быстрой модели, дневной разбор инцидента — тяжёлой, отчёт в Telegram — тем текстом и туда, куда настроено.
Профили дополняют картину: несколько независимых агентов с разными конфигами. Поддержечный агент не знает и не должен знать конфиг отчётного; каждый живёт в своей песочнице, со своей памятью и своими правами.
Что Hermes делает у нас каждый день
Теория кончается там, где начинаются дежурства. Вот четыре регулярных применения, которые прямо сейчас работают у нас.
Пул агентов второй линии поддержки. Обращения, с которыми не справилась первая линия, разбирают агенты из пула: каждый берёт обращение, поднимает историю, проверяет по документации и данным, отвечает или эскалирует человеку. Как устроен сам пул — разобрали отдельно: «Пул агентов второй линии».
Мониторинг ошибок → исследование → PR. Агент видит новую ошибку в мониторинге, находит её в коде, разбирается в причине и открывает pull request в наш Gitea. Человек подключается на ревью, а не на копание в логах среди ночи.
Read-only доступ к данным через MCP. Прод-базы агенту не выдают SQL с правами бога — работает через MCP-шлюз в режиме только для чтения. Как это построено и почему так, а не иначе: «Корпоративный MCP».
Разбор скриншотов от клиентов. «Что-то не работает, вот картинка» — теперь не деградация в текстовое описание проблемы: агент читает скриншот как есть и отвечает по существу.
Warning
Единственное правило, нарушение которого превращает агента из инструмента в инцидент: права доступа выдаются до того, как агент начал работать, а не после первого «ну он же правильно сделал». Мы начинаем с read-only и узких терминалов в изолированных контейнерах, и расширяем доступ только тогда, когда видим стабильно правильные действия. Агент, у которого «временно» права администратора, остаётся с ними навсегда.
Почему это не «просто Codex» и не «просто Claude»
Формулировка «просто возьмём Codex / Claude» звучит практично: продукт есть, работает, деньги заплачены. Мы прошли мимо неё сознательно, и вот почему.
У агентов от поставщиков моделей есть невидимая граница: их поведение, их интеграции и их память развиваются туда, куда решил вендор, и живут на территории вендора. Смена модели внутри такого продукта обычно означает смену продукта — со всеми потерями слоя, о котором мы писали выше.
В Hermes модель-агностичность — не настройка «на всякий случай», а базовый режим: 20+ провайдеров, переключение на ходу, пулы ключей. Наши правила и знания при этом лежат не в облаке поставщика, а в репозитории скиллов: версионируются, ревьюятся, переезжают вместе с нами. Когда выходит модель лучше — мы меняем картридж. Когда вендор меняет условия — мы меняем картридж. Агент, память, процедуры и расписание не меняются никогда.
Что нужно бизнесу и чем это закрывает Hermes
| Что нужно бизнесу | Чем закрывает Hermes |
|---|---|
| Не зависеть от одного вендора модели | 20+ провайдеров, смена модели и провайдера на ходу, пулы ключей с автопереключением |
| Работа там, где сидят сотрудники | терминал, IDE, Telegram, Slack, Discord, WhatsApp, Signal, Email, Matrix, вебхуки |
| Знания остаются в компании, а не в голове сотрудника | память между сессиями + скиллы-процедуры в репозитории |
| Рутина идёт без дежурного человека | крон: расписание, у каждой задачи свои скиллы, модель и доставка |
| Параллельные задачи без взаимного мусора | субагенты: изолированный контекст, свой терминал, батчи |
| Безопасный доступ к системам и данным | бэкенды терминала (локальный, docker, ssh, modal), MCP, профили с разными правами |
| Предсказуемость инструмента | открытый код под лицензией MIT, ~3000 автотестов в репозитории |
Итог: что это значит для вас
- Разделяйте агента и модель. Всё, что вы настраиваете — память, процедуры, расписание, доступы, — должно принадлежать вам, а не подписке. Модель имеет право быть картриджем, остальное нет.
- Проверяйте, где живут ваши знания. Если правила работы агента записаны только в голове специалиста или в чатах облачного сервиса — это не процесс, это риск увольнения.
- Начинайте с read-only. Агент с доступом к данным только для чтения и запуском в изолированном контейнере — это скучно и правильно; права расширяют по факту надёжной работы.
- Автоматизируйте расписание, а не только ответы. Крон с доставками в мессенджеры превращает агента из «интересной игрушки для запросов» в регулярную рабочую силу.
- Хотите построить у себя то же, что работает у нас, — приходите: внедрение ИИ. Разберём ваши процессы, подберём модели и соберём агента, которого нельзя отключить.