Главная фича Hermes Agent v0.2.0 — не очередная интеграция с моделью и не система навыков. Это Multi-Platform Messaging Gateway — один процесс Hermes, который одновременно слушает семь чат-платформ: Telegram, Discord, Slack, WhatsApp, Signal, почту (IMAP/SMTP) и Home Assistant. К релизу 8 апреля список вырос до тринадцати — добавились Matrix, Feishu, WeCom, Mattermost, DingTalk и SMS через Twilio.
Тут легко пропустить суть. Написать одного Telegram-бота — не бог весть какая задача. А вот поднять семь одновременных чат-интеграций, которые делят одного агента, одну память и один реестр инструментов — вот где настоящая архитектурная работа. Этот пост разбирает, как Hermes это устроен изнутри.
Наивный подход и почему он не работает
Если тебе нужен «AI-бот, который отвечает и в Telegram, и в Discord», первый порыв — поднять двух отдельных ботов. У каждого свой процесс, своя база, своё состояние. Оба вызывают один и тот же LLM API. Концептуально пользователь в Telegram и пользователь в Discord получают одного агента, а на практике — двух, которые друг о друге ничего не знают.
Именно так устроено большинство существующих бот-проектов, и проблемы становятся очевидны не сразу:
- •Память расходится. Пользователь сказал в Telegram, что у него аллергия на арахис, — а когда спрашивает про рецепт в Discord, агент об этом не в курсе. Одно и то же приходится объяснять дважды.
- •Состояние инструментов рассинхронизируется. Cron-задача, созданная через Slack, не видна при проверке через Telegram. История сессий фрагментирована. Токены авторизации для общих ресурсов (например, интеграция с Notion) приходится настраивать в каждом боте отдельно.
- •Операционные расходы растут кратно. N ботов — это N процессов, N сервисов, N потоков логов, N конфигов и N точек отказа. Сложность растёт линейно с числом платформ.
- •Правила безопасности расползаются. Ужесточил политику одобрения опасных команд в одном боте — не забудь обновить все остальные. Дрейф безопасности — это состояние по умолчанию.
Hermes идёт другим путём: один процесс агента, одна база сессий, одно хранилище памяти, один реестр инструментов. Платформы — это адаптеры: тонкие «входные двери», которые перенаправляют сообщения в общего агента и обратно.
Устройство шлюза
Внутри Hermes Gateway три слоя.
Нижний слой — сам агент. Тот же Hermes-движок, что работает в CLI-режиме. Он ничего не знает о чат-платформах. Получает сообщения, гоняет свой агентный цикл (вызовы LLM, вызовы инструментов, запросы к памяти, чекпоинты) и выдаёт ответы. Единственный интерфейс к внешнему миру — API на основе очередей.
Средний слой — ядро шлюза: управление сессиями, маршрутизация пользователь/платформа, диспетчеризация одобрений, cron-планировщик, стриминг, обработка медиа. Этот слой превращает «сообщение пришло с платформы X от пользователя Y в канале Z» в «запуск агента в сессии S с такими-то правами». Он же отвечает за общие задачи: rate limits, защита от флуда, дедупликация сообщений, таймауты по неактивности, маршрутизация кнопок одобрения, кросс-платформенное состояние.
Верхний слой — адаптеры платформ. По одному на платформу: Telegram, Discord, Slack и так далее. Задача адаптера узкая — подключиться к платформе (polling, long-poll, WebSocket, webhook — что предлагает SDK), перевести входящие события в внутренний формат шлюза и перевести исходящие ответы обратно в формат платформы (Markdown, MarkdownV2, mrkdwn, Discord rich embeds, Matrix HTML, Slack blocks, email MIME).
Адаптеры намеренно маленькие. Добавить новую платформу (участник сообщества добавил Mattermost менее чем в 300 строк Python в v0.4.0) — это в основном маппинг событий SDK в внутренний формат шлюза и обратно.
Как работают сессии между платформами
Сессия Hermes — это ветка разговора со своим окном памяти, состоянием инструментов и историей. На одной платформе сессии маппятся естественно: один чат в Telegram — одна сессия, один канал в Discord — одна сессия, один тред в Slack — одна сессия. Между платформами всё интереснее.
По умолчанию Hermes считает каждую комбинацию платформа/чат отдельной сессией. Твои DM с ботом в Telegram, тред в Slack и канал в Discord — это три разных разговора с тремя разными контекстами, но все они делят одну долгосрочную память через подключаемый провайдер (Honcho по умолчанию с v0.7.0). Так что информация, которая должна переноситься между сессиями — «у пользователя аллергия на арахис», «пользователя зовут Алиса», «проект пользователя называется Atlas» — едет на слое памяти, а краткосрочный контекст каждого разговора остаётся в рамках платформы.
Именно такой дизайн позволяет одному и тому же ассистенту ощущаться одним и тем же на любой платформе — без превращения каждого сообщения в запутанную глобальную рассылку.
Зачем нужны shared thread sessions
В v0.4.0 Hermes добавил фичу shared thread sessions по умолчанию — в групповых чатах каждый пользователь получает свою сессию внутри общего треда. Звучит мелко, а на деле меняет всё для любого, кто пытался запускать мультипользовательского бота в группе.
Без персональных сессий в групповом чате все сообщения — часть одного разговора. Алиса задаёт боту вопрос, Боб задаёт другой через тридцать секунд — и контекст бота превращается в кашу из обоих. Ответы путаются. Память Алисы загрязняется данными Боба. В gateway-режиме становится только хуже с каждым новым участником.
С shared thread sessions у Алисы и Боба у каждого своя приватная сессия внутри треда. Они видят сообщения друг друга в чате, но агент ведёт отдельные контексты и отдельные записи в память для каждого. В v0.8.0 это стало поведением по умолчанию на всех платформах шлюза. Из тех исправлений, которые незаметны, пока не обожжёшься на альтернативе, — а потом уже не захочешь возвращаться.
Для чего на самом деле нужен шлюз
Если достаточно долго всматриваться в архитектуру, шлюз перестаёт выглядеть как «способ запускать ботов в чат-платформах» и начинает выглядеть тем, чем является на самом деле: слой координации между людьми (в каком бы приложении они ни сидели) и единым AI-ассистентом с общей памятью и общими инструментами.
Чат-платформы — не продукт. Они — точки входа. Продукт — ассистент, который стоит за ними, и тот факт, что тебе вообще не нужно думать, через какую точку входа ты заходишь.
Это то, что Hermes выкатил в первый же день. Всё остальное — история о том, чему этот слой координации научился за следующие четыре недели.