Распространение профиля: публикация целого агента

Распространение профиля упаковывает целого агента Hermes — личность, навыки, cron-задачи, MCP-подключения, конфигурацию — в виде git-репозитория. Любой, у кого есть доступ к репозиторию, может установить всего агента одной команды, обновлять его на месте, сохраняя при этом свои собственные воспоминания, сеанс и ключи API нетронутыми.

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

Что это значит

Чтобы распространить информацию о распространении, чтобы поделиться агентом Hermes, нужно было отправить:

1. Ваш SOUL.md
2. Список инструментов для установки
3. Ваш config.yaml, без секретов
4. Описание того, какие MCP-серверы вы подключили
5. Все cron-задачи, которые вы запланировали.
6. Инструкции по установке переменных окружения.

…и надеюсь, что они соберут всё правильно. Каждое обновление версии или исправление ошибки повторной передачи.

С распространением всё это живёт в одной git-репозитории:

my-research-agent/
├── distribution.yaml    # манифест: имя, версия, требования к переменным окружения
├── SOUL.md              # личность агента / системный промпт
├── config.yaml          # модель, температура, рассуждения, настройки инструментов по умолчанию
├── skills/              # встроенные навыки, поставляемые с агентом
├── cron/                # запланированные задачи, которые выполняет агент
└── mcp.json             # MCP-серверы, к которым подключается агент

Источники управления:

hermes profile install github.com/you/my-research-agent --alias

…и теперь у них есть целый агент. Они задают свои собственные ключи API (.env.EXAMPLE → .env) и могут запустить my-research-agent Chat или обратиться к нему через Telegram/Discord/Slack/любую шлюзовую платформу. Когда вы устанавливаете новую версию, они выполняют обновление профиля Гермеса, мой исследовательский агент и получают ваши изменения — их память и сессия остаются на месте.

Почему мерзавец?

Мы рассматривали tarball'ы, HTTP-архивы, небольшой формат. Ни один из них не превзошёл git:

• Новый этап сборки для авторов. Отправляете на GitHub; установка пользователя. Нет цикла «упакуй это, загрузи то, обнови индекс».
• Теги, ветки и коммиты уже являются системой версионирования. Отправка тега, делающего для нас то, что для других инструментов делает "упакуй + загрузи релиз".
• Обновления — это fetch. Не повторная загрузка всего архива.
• Прозрачность. Пользователи могут просматривать репозитории, читать различия между версиями, открывать проблемы, форкать для кастомизации.
• Приватные репозитории работают бесплатно. SSH-ключи, помощники git credential, сохранённые учётные данные GitHub CLI — любая аутентификация, которая уже настроена на вашем терминале, работает прозрачно.
• Воспроизводимость — это SHA коммита. То же самое, что записывают pip и npm.

Компромисс: получателям нужен установленный git. На любой машине, где работает Hermes в 2026 году, это уже так.

Когда следует использовать распространение?

Хорошо подходит:

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

Не подходит:

• Вы просто сделайте резервную форму профиля на своей машине. Используйте hermes Profile Export / Import — для этого они и приводят.
• ** Вы хотите поделиться ключами API вместе с агентом. ** auth.json и .env намеренно исключены из-за распространенности. Каждый установщик генерирует собственные учетные данные.
• ** Вы хотите поделиться воспоминаниями / сессиями / историческими разговорами. ** Это пользовательские данные, а не обязательное распространение. Никогда не по именися.

Жизненный цикл: от автора к установщику и обновлению

Ниже описан полный сквозной процесс. Выберите ту сторону, которая вас интересует.

Для авторов: распространение публикации

Шаг 1 — начало с рабочего профиля

Создайте и доработайте агента как любой другой профиль:

hermes profile create research-bot
research-bot setup                    # настройте модель, ключи API
# Отредактируйте ~/.hermes/profiles/research-bot/SOUL.md
# Установите навыки, подключите MCP-серверы, запланируйте cron-задачи и т.д.
research-bot chat                     # тестируйте, пока не будете довольны

Шаг 2 — Добавьте distribution.yaml

создадим ~/.hermes/profiles/research-bot/distribution.yaml:

name: research-bot
version: 1.0.0
description: "Автономный исследовательский ассистент с инструментами arXiv и веб-поиска"
hermes_requires: ">=0.12.0"
author: "Ваше Имя"
license: "MIT"

# Сообщите установщикам, какие переменные окружения нужны агенту. Они проверяются
# в оболочке установщика и существующем файле.env, чтобы не надоедать
# с ключами, которые у них уже настроены.
env_requires:
  - name: OPENAI_API_KEY
    description: "Ключ API OpenAI (для доступа к модели)"
    required: true
  - name: SERPAPI_KEY
    description: "Ключ SerpAPI для веб-поиска"
    required: false
    default: ""

Это весь манифест. Каждое поле, кроме имени, имеет разумное значение по умолчанию.

Шаг 3 — Отправка в git-репозиторий

cd ~/.hermes/profiles/research-bot
git init
git add.
git commit -m "v1.0.0"
git remote add origin git@github.com:you/research-bot.git
git tag v1.0.0
git push -u origin main --tags

Репозиторий теперь распространяется. Любой, у кого есть доступ, может его установить.:::примечание Git-репозиторий содержит все в каталоге профилей, кроме того, что уже исключено из распространенности: auth.json, .env, memories/, sessions/, state.db*, logs/, workspace/, *_cache/, local/. Они на вашем компьютере. Вы также можете добавить .gitignore, если вам нужен дополнительный путь.