Hermes Agent profiles: как разделить клиентов, проекты и доступы

Обновлено 
Hermes Agent profiles: как разделить клиентов, проекты и доступы

Hermes Agent profiles нужны, когда один AI-агент уже обслуживает не одну задачу, а несколько клиентов, отделов или проектов: отдельный профиль даёт свой конфиг, ключи, память, сессии, навыки, cron-задачи и gateway-состояние, поэтому контекст и доступы не смешиваются. Для бизнеса это не «косметическая папка», а способ разделить риски: агент для продаж не должен помнить черновики разработки, а клиентский бот не должен видеть чужие токены.

Если вы только ставите Hermes Agent, сначала достаточно одного профиля и базового сценария из гайда по Hermes Agent setup для бизнеса. Но как только появляются разные роли — контент-агент, агент поддержки, агент для разработки, агент для конкретного клиента — общий профиль превращается в источник ошибок. В этой статье разберём, когда создавать отдельные profiles, как их именовать, что клонировать, где не ждать «песочницы» и как внедрить схему без хаоса.

Когда бизнесу нужны отдельные Hermes Agent profiles? 🧩

Главный сигнал — у задач появились разные границы доступа. Один агент может писать SEO-статьи, второй отвечать в Telegram, третий работать с GitHub, четвёртый запускать регулярные отчёты. Пока всё лежит в одном профиле, любая настройка становится общей: модель, переменные окружения, история сессий, memory, skills, cron и gateway. Это удобно для личного эксперимента, но опасно для операционной работы.

Отдельный профиль стоит заводить в четырёх случаях. Первый — разные клиенты. Например, агент ведёт публикации для сайта A и аналитику для сайта B: у них разные CMS-ключи, логи, tone of voice и расписания. Второй — разные роли внутри компании: sales assistant, support bot, researcher, coding agent. Третий — разные уровни риска: read-only аналитик и агент, который может деплоить или публиковать. Четвёртый — тестовая среда: новый набор tools/skills лучше проверять в отдельном профиле, а не на боевом агенте.

Важно не путать profiles с рабочими папками. Рабочая директория отвечает за то, откуда стартуют terminal-команды. Profile отвечает за состояние самого Hermes: конфиг, .env, память, сессии, навыки, cron, gateway, логи. Поэтому профиль решает проблему смешивания агентского контекста, но не заменяет файловую изоляцию, права Linux-пользователей, Docker, отдельный VPS или sandbox.

Как устроена изоляция: что реально разделяется? 🔐

По официальной логике Hermes Agent, профиль — это отдельный Hermes home directory. У него свои config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs, gateway state, логи и служебные базы. После создания профиля появляется отдельная команда-алиас: например, профиль salesbot можно запускать как salesbot chat, salesbot setup, salesbot gateway start или salesbot skills list. То же самое можно делать явно через hermes -p salesbot ....

Практически это означает простую вещь: профиль «контент» может иметь ключи Ghost и WordPress, профиль «поддержка» — Telegram bot token и доступ к базе FAQ, профиль «разработка» — GitHub и terminal-tools. Даже если провайдер модели один и тот же, окружение лучше разводить. Так проще понять, какой агент сделал действие, где смотреть логи и какой токен нужно отозвать при инциденте.

Есть два полезных способа старта. hermes profile create NAME создаёт пустой профиль со свежей памятью и состоянием. hermes profile create NAME --clone копирует базовый конфиг, .env и SOUL.md, но оставляет новые сессии и память. Это удобно, если нужно быстро размножить одинаковую модель и провайдера, но не переносить старый контекст. --clone-all копирует всё, включая память, cron, skills и историю; для боевой работы с клиентами его лучше использовать как snapshot/backup, а не как стандартный способ запуска нового клиента.

Для задач, где агент общается с людьми, profiles особенно полезны вместе с gateway. Сценарии подключения каналов уже разбирались в статье про Hermes Agent и Telegram Gateway: если у разных отделов разные чаты, разные правила ответа и разные токены, лучше не держать их в одном профиле.

Практический план внедрения profiles для клиентов и проектов ⚙️

Начните не с команды в терминале, а с карты ролей. Выпишите, какие агенты реально нужны: «контент», «продажи», «поддержка», «разработка», «аналитика», «клиент-acme». Для каждого укажите владельца, каналы связи, данные, допустимые tools, расписания и действия, требующие согласования. Если два сценария используют одни и те же данные и одного владельца, им, возможно, не нужен отдельный профиль. Если различаются ключи, клиенты или уровень риска — нужен.

Дальше создайте минимальный профиль и настройте его как отдельного сотрудника. Примерный порядок:

  • 🧭 создать профиль: hermes profile create client-acme;
  • 🔧 запустить настройку: client-acme setup или hermes -p client-acme setup;
  • 🗝️ положить только нужные ключи в профильный .env;
  • 🧠 описать роль в SOUL.md: что агент делает, чего не делает, кому пишет отчёты;
  • 🧰 включить только нужные tools и skills, без лишнего доступа к системе;
  • ⏱️ добавить cron-задачи только после ручной проверки сценария;
  • 📜 проверить логи, тестовый запуск и понятный rollback-план.

Если профиль будет выполнять повторяемые операции — публикации, отчёты, мониторинг заявок — сначала продумайте skills. На AIgentHub уже есть разбор, как Hermes Agent tools и skills помогают собирать бизнес-автоматизацию. Profiles добавляют к этому слой изоляции: навык может быть похожим, но ключи, память, расписания и каналы доставки остаются отдельными.

Для внешних систем используйте принцип минимального доступа. Если профилю нужно читать заявки из CRM, не давайте ему полный административный токен. Если он публикует статьи, отделите production-публикацию от research-профиля. Если подключаете MCP-серверы, сначала проверьте их в read-only режиме: подход к ограничению внешних инструментов подробно описан в материале про Hermes Agent MCP для бизнес-автоматизации.

Типичные ошибки, чеклист и безопасный режим запуска ✅

Первая ошибка — считать профиль полноценной песочницей. Он разделяет состояние Hermes, но не запрещает агенту видеть файлы на той же машине, если terminal backend и права ОС это позволяют. Для клиентов с жёсткими требованиями используйте отдельного системного пользователя, контейнер, отдельный VPS или ограниченный набор toolsets. Profile — это граница контекста и конфигурации, а не юридическая гарантия изоляции данных.

Вторая ошибка — клонировать всё подряд через --clone-all. Вместе с удобством можно перенести старую память, лишние cron jobs и неактуальные токены. Для нового клиента обычно лучше --clone или чистый профиль: модель и базовая конфигурация сохраняются, а история и memory начинаются заново. Третья ошибка — не документировать владельца профиля. Через месяц никто не помнит, почему профиль называется bot2, какие ключи у него есть и можно ли его остановить.

Мини-чеклист перед боевым запуском:

  • Понятно, зачем профиль создан и кто владелец сценария.
  • В .env лежат только нужные ключи, без «универсального админа».
  • Включены только необходимые tools, skills и MCP-серверы.
  • Cron-задачи сначала прогнаны вручную и имеют stop-condition.
  • Gateway подключён к правильному чату или каналу, а не к общему тестовому.
  • Есть логирование: где смотреть сессии, ошибки, доставку и публикации.
  • Для рискованных действий есть human-in-the-loop: согласование перед отправкой, оплатой, удалением или публикацией.

Хороший безопасный старт — один read-only профиль на конкретный бизнес-процесс: например, ежедневный сбор заявок, проверка контента перед публикацией или подготовка отчёта. После недели наблюдения можно добавлять действия: создать черновик, отправить уведомление, поставить задачу, запустить публикацию. Для регулярных процессов полезно связать profiles с расписаниями; общая логика описана в статье про Hermes Agent cron и автопубликацию, но для каждого профиля расписание должно быть отдельным и проверяемым.

Если хотите внедрить Hermes Agent profiles под ваши процессы — от клиентских ботов до автопубликаций и AI-оператора поддержки — напишите в Telegram: @aaakalsin. Поможем выбрать схему профилей, права доступа, gateway, cron и безопасный первый сценарий.

FAQ: частые вопросы про Hermes Agent profiles

Hermes Agent profile — это отдельный агент или просто настройка?

Это отдельное состояние Hermes Agent: свой home directory, конфиг, .env, память, сессии, skills, cron, gateway state и логи. По поведению для бизнеса это почти отдельный агент, хотя физически он может работать на той же машине.

Можно ли держать нескольких клиентов в одном профиле?

Технически можно, но для платных клиентских процессов это плохая практика. Разные клиенты обычно означают разные ключи, документы, стиль общения, расписания и ответственность. Отдельный профиль снижает риск утечки контекста и упрощает аудит.

Profiles защищают файлы на сервере?

Нет. Profiles разделяют состояние Hermes, но не являются sandbox. Если агенту доступен локальный terminal с широкими правами, он может видеть то, что позволяет операционная система. Для строгой изоляции нужны права ОС, контейнеры, отдельный пользователь или отдельный VPS.

Что лучше: создать чистый профиль или использовать clone?

Для нового клиента чаще лучше чистый профиль или --clone, который переносит базовый конфиг и ключи, но не тащит старую память и сессии. --clone-all полезен для backup или форка существующего агента, но требует внимательной проверки.

Нужен ли отдельный profile для каждого cron job?

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

Как понять, что схема profiles стала слишком сложной?

Если вы не можете за минуту ответить, кто владелец профиля, какие ключи в нём лежат и какие действия он может выполнять, схему нужно упростить. Хорошее правило: профиль создаётся под понятную роль, а не «на всякий случай».