Дистрибуции профиля: делимся целым агентом

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

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

Два способа поделиться профилем

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

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

Выбирайте файл экспорта, если хотите просто прямо сейчас передать кому-то своё окружение — или переезжаете на новый ноутбук. Ни репозитория, ни манифеста: запустите /export в чате, передайте файл, получатель запускает /import. См. Экспорт и импорт файла профиля.

Эти два способа не исключают друг друга. Многие авторы сначала обкатывают профиль сами, отправляют его коллеге через /export за вторым мнением, а уже потом публикуют как дистрибуцию, когда она становится достойна версионирования.

Что это значит на практике

До появления дистрибуций поделиться агентом Hermes означало отправить кому-то:

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

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

С дистрибуциями всё это лежит в одном git-репозитории:

my-research-agent/
├── distribution.yaml    # manifest: name, version, env-var requirements
├── SOUL.md              # the agent's personality / system prompt
├── config.yaml          # model, temperature, reasoning, tool defaults
├── skills/              # bundled skills that come with the agent
├── cron/                # scheduled tasks the agent runs
└── mcp.json             # MCP servers the agent connects to

Получатель запускает:

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

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

Почему именно git?

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

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

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

Когда стоит использовать дистрибуцию?

Хорошо подходит, если:

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

Не подходит, если:

• Вы хотите разово, прямо сейчас, передать кому-то своё окружение. Дистрибуции нужны репозиторий, манифест и .gitignore. /export обходится без всего этого — см. Экспорт и импорт файла профиля. То же самое, если вы делаете резервную копию профиля или переносите его на новую машину.
• Вы хотите поделиться темой и раскладкой десктопного приложения. Дистрибуция несёт агента — SOUL, конфигурацию, навыки, cron, MCP, плагины. Экспорт, сделанный из десктопного приложения, дополнительно несёт внешний вид: скин, светлую/тёмную тему, пользовательские темы, цвет боковой панели и раскладку окна.
• Вы хотите передать API-ключи вместе с агентом. auth.json, .env и остальные хранилища учётных данных, которые Hermes читает из профиля (.op.env, npmrc, файлы OAuth и токенов ботов, honcho.json, mem0.json, teams_pipeline_store.json, mcp-tokens/, vault/, proxy/, профили браузера, сессии платформ, а также .ssh/, .aws/, .gnupg/, .kube/, .docker/, .azure/, .config/gh/, .config/gcloud/ и .envrc в корне или внутри навыка), намеренно исключены из дистрибуций. Каждый, кто устанавливает агента, приносит собственные учётные данные. (Файлы экспорта тоже их вырезают.)
• Вы хотите поделиться воспоминаниями / сессиями / историей переписки. Это пользовательские данные, а не содержимое дистрибуции. Они никогда не передаются. (С файлами экспорта иначе — прочитайте что входит в файл экспорта, прежде чем его отправлять.)

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

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

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

Шаг 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: "Autonomous research assistant with arXiv and web tools"
hermes_requires: ">=0.12.0"
author: "Your Name"
license: "MIT"

# Tell installers which env vars the agent needs. These are checked against
# the installer's shell and existing .env file so they don't get nagged
# about keys they already have configured.
env_requires:
  - name: OPENAI_API_KEY
    description: "OpenAI API key (for model access)"
    required: true
  - name: SERPAPI_KEY
    description: "SerpAPI key for web search"
    required: false
    default: ""

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

Шаг 3 — создайте .gitignore до первого коммита

Создайте ~/.hermes/profiles/research-bot/.gitignore как минимум со следующим содержимым:

# Credentials & secrets — NEVER commit
auth.json
.env
.env.EXAMPLE    # generated by install, not authorship domain

# Runtime databases & state
state.db
state.db-shm
state.db-wal
hermes_state.db
response_store.db
response_store.db-shm
response_store.db-wal
gateway.pid
gateway_state.json
processes.json
auth.lock
active_profile
.update_check

# User data — NEVER commit
memories/
sessions/
logs/
plans/
workspace/
home/

# Caches & generated artifacts
image_cache/
audio_cache/
document_cache/
browser_screenshots/
cache/

# Infrastructure (should not be in profile dir, but safe to exclude)
hermes-agent/
.worktrees/
profiles/
bin/
node_modules/

# User customization namespace — your local overrides
local/

# Checkpoints & backups (can be huge)
checkpoints/
sandboxes/
backups/

# Logs
errors.log
.hermes_history

# Distribution-authored scheduler/skills state only
cron/*
!cron/jobs.json
skills/.*

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

Из cron коммитьте только cron/jobs.json. Всё остальное в cron/ Hermes считает состоянием времени выполнения (блокировки, журналы, вывод, подсказки и будущие служебные файлы планировщика) и никогда не устанавливает и не заменяет это из дистрибуции. Скрытые записи на корневом уровне skills/ — тоже локальная служебная информация Hermes; скрытые файлы внутри каталога авторского навыка остаются частью этого навыка.

Шаг 4 — запушьте в 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

Теперь репозиторий — это дистрибуция. Установить её может любой, у кого есть доступ.

Шаг 5 — тегируйте версионные релизы

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

# Отредактируйте distribution.yaml: version: 1.1.0
git add distribution.yaml SOUL.md skills/
git commit -m "v1.1.0: tighter research SOUL, add arxiv skill"
git tag v1.1.0
git push --tags

Получатели, которые запустят hermes profile update research-bot, подтянут последнюю версию.

Как выглядит репозиторий

Полностью оформленная дистрибуция:

research-bot/
├── .gitignore                   # excludes secrets & user data (see Step 3)
├── distribution.yaml            # required
├── SOUL.md                      # strongly recommended
├── config.yaml                  # model, provider, tool defaults
├── mcp.json                     # MCP server connections
├── skills/
│   ├── arxiv-search/SKILL.md
│   ├── paper-summarization/SKILL.md
│   └── citation-lookup/SKILL.md
├── cron/
│   └── jobs.json                # cron definitions; installed paused
└── README.md                    # human-facing description (optional)

Что принадлежит дистрибуции, а что — пользователю

Когда установщик обновляется до новой версии, часть файлов заменяется (домен автора), а часть остаётся на месте (домен установившего). По умолчанию:

Список файлов, принадлежащих дистрибуции, можно переопределить в манифесте:

distribution_owned:
  - SOUL.md
  - skills/research/            # only my research skills; other installed skills stay
  - cron/jobs.json              # canonical cron store; merged job by job

Если это поле не задано, применяются приведённые выше значения по умолчанию — и это то, что нужно большинству дистрибуций.

Для устанавливающих: как пользоваться дистрибуцией

Установка

hermes profile install github.com/you/research-bot --alias

Что происходит:

1. Репозиторий клонируется во временный каталог.
2. Читается distribution.yaml, вам показывают манифест (имя, версию, описание, автора, требуемые переменные окружения).
3. Каждая требуемая переменная окружения проверяется в вашей оболочке и в существующем .env целевого профиля. Каждая помечается как ✓ set или needs setting, чтобы вы точно знали, что нужно донастроить.
4. Запрашивается подтверждение. Передайте -y / --yes, чтобы пропустить этот шаг.
5. Файлы, принадлежащие дистрибуции, копируются в ~/.hermes/profiles/research-bot/ (или туда, куда разрешается name из манифеста). При этом копировании удаляются жёстко исключаемые пути, даже если автор случайно оставил их в репозитории.
6. Записывается .env.EXAMPLE с закомментированными требуемыми ключами — скопируйте в .env и заполните.
7. С флагом --alias создаётся обёртка, чтобы можно было запускать research-bot chat напрямую.

Типы источников

Работает любой git-URL:

# Сокращённая запись для GitHub
hermes profile install github.com/you/research-bot

# Полный HTTPS
hermes profile install https://github.com/you/research-bot.git

# SSH
hermes profile install git@github.com:you/research-bot.git

# Самостоятельно размещённый хостинг, GitLab, Gitea, Forgejo — любой git-хостинг
hermes profile install https://git.example.com/team/research-bot.git

# Приватный репозиторий с использованием вашей настроенной авторизации git
hermes profile install git@github.com:your-org/internal-bot.git

# Локальный каталог в процессе разработки (git push не нужен)
hermes profile install ~/my-profile-in-progress/

Переопределение имени профиля

Два пользователя хотят установить одну и ту же дистрибуцию под разными именами профиля:

# Алиса
hermes profile install github.com/acme/support-bot --name support-us --alias
# Боб (та же дистрибуция, другое локальное имя)
hermes profile install github.com/acme/support-bot --name support-eu --alias

Заполнение переменных окружения

После установки профиль агента содержит .env.EXAMPLE:

# Environment variables required by this Hermes distribution.
# Copy to `.env` and fill in your own values before running.

# OpenAI API key (for model access)
# (required)
OPENAI_API_KEY=

# SerpAPI key for web search
# (optional)
# SERPAPI_KEY=

Скопируйте его:

cp ~/.hermes/profiles/research-bot/.env.EXAMPLE ~/.hermes/profiles/research-bot/.env
# Отредактируйте .env, вставьте свои реальные ключи

Требуемые ключи, которые уже были в вашей оболочке (например, OPENAI_API_KEY, экспортированный в ~/.zshrc), при установке помечаются как ✓ set — дублировать их в .env не нужно.

Проверка того, что вы установили

hermes profile info research-bot

Показывает:

Distribution: research-bot
Version:      1.0.0
Description:  Autonomous research assistant with arXiv and web tools
Author:       Your Name
Requires:     Hermes >=0.12.0
Source:       https://github.com/you/research-bot
Installed:    2026-05-08T17:04:32+00:00

Environment variables:
  OPENAI_API_KEY (required) — OpenAI API key (for model access)
  SERPAPI_KEY (optional) — SerpAPI key for web search

hermes profile list также показывает столбец Distribution, так что с одного взгляда видно, какие из ваших профилей пришли из репозиториев, а какие вы собрали вручную:

 Profile          Model                        Gateway      Alias        Distribution
 ───────────────    ───────────────────────────    ───────────    ───────────    ────────────────────
 ◆default         claude-sonnet-4              stopped      —            —
  coder           gpt-5                        stopped      coder        —
  research-bot    claude-opus-4                stopped      research-bot research-bot@1.0.0
  telemetry       claude-sonnet-4              running      telemetry    telemetry@2.3.1

Обновление

hermes profile update research-bot

Что происходит:

1. Репозиторий переклонируется из сохранённого исходного URL.
2. Заменяются файлы, принадлежащие дистрибуции (SOUL, mcp.json), и поставляемые навыки, затем cron/jobs.json сливается по id задачи. Ваши собственные задачи остаются, определения поставляемых задач обновляются без смены вашего выбора «на паузе / включена», а новые поставляемые задачи приходят на паузе.
3. Сохраняется ваш config.yaml — возможно, вы настроили модель, температуру или другие параметры под себя. Передайте --force-config, чтобы перезаписать.
4. Никогда не затрагиваются пользовательские данные: воспоминания, сессии, авторизация, .env, логи, состояние.

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

Удаление

hermes profile delete research-bot

Перед подтверждением удаления показывается информация о дистрибуции:

Profile: research-bot
Path:    ~/.hermes/profiles/research-bot
Model:   claude-opus-4 (anthropic)
Skills:  12
Distribution: research-bot@1.0.0
Installed from: https://github.com/you/research-bot

This will permanently delete:
  • All config, API keys, memories, sessions, skills, cron jobs
  • Command alias (~/.local/bin/research-bot)

Type 'research-bot' to confirm:

Так вы никогда случайно не удалите агента, не зная, откуда он взялся и как переустановить его заново.

Сценарии использования и паттерны

Личное: синхронизация одного агента между машинами

Вы собрали исследовательского ассистента на ноутбуке. Хотите того же агента на рабочей станции.

# Ноутбук — сначала создайте .gitignore (см. "Для авторов", шаг 3), затем:
cd ~/.hermes/profiles/research-bot
git init && git add . && git status   # убедитесь, что секреты не попали в индекс
git commit -m "initial"
git remote add origin git@github.com:you/research-bot.git
git push -u origin main

# Рабочая станция
hermes profile install github.com/you/research-bot --alias
# Заполните .env. Готово.

Любая доработка на ноутбуке (git commit && push) подтягивается на рабочей станции командой hermes profile update research-bot. Воспоминания остаются привязаны к машине — ноутбук помнит свои разговоры, рабочая станция свои, они не пересекаются.

Команда: выпуск проверенного внутреннего агента

Ваша инженерная команда хочет общего бота для ревью PR — с конкретным SOUL, конкретными навыками и cron, который прогоняет через него каждый PR.

# Технический лид — сначала создайте .gitignore (см. "Для авторов", шаг 3), затем:
cd ~/.hermes/profiles/pr-reviewer
# ... сборка и настройка ...
git init && git add . && git status   # убедитесь, что секреты не попали в индекс
git commit -m "v1.0 PR reviewer"
git tag v1.0.0
git push -u origin main --tags    # запушьте на внутренний git-хостинг вашей компании

# Каждый инженер
hermes profile install git@github.com:your-org/pr-reviewer.git --alias
# Заполните .env своим собственным API-ключом (счёт выставляется на них), .env.EXAMPLE указывает, что требуется
pr-reviewer chat

Когда лид выпускает v1.1 (улучшенный SOUL, новый навык), инженеры запускают hermes profile update pr-reviewer, и через несколько минут все переходят на новую версию.

Сообщество: публикация публичного агента

Вы собрали что-то новое — например, «трейдера Polymarket», «суммаризатора научных статей» или «ассистента по администрированию сервера Minecraft». Хотите поделиться этим.

# Вы — сначала создайте .gitignore (см. "Для авторов", шаг 3), затем:
cd ~/.hermes/profiles/polymarket-trader
# Напишите хороший README.md в корне репозитория — GitHub показывает его на странице репозитория
git init && git add . && git status   # убедитесь, что секреты не попали в индекс
git commit -m "v1.0"
git tag v1.0.0
# Опубликуйте в публичном репозитории GitHub
git remote add origin https://github.com/you/hermes-polymarket-trader.git
git push -u origin main --tags

# Кто угодно
hermes profile install github.com/you/hermes-polymarket-trader --alias

Опубликуйте команду установки в твиттере. Люди, которые попробуют, пришлют вам issue и PR. Если кто-то захочет доработать под себя — форкнет, тот же git-процесс, который все уже знают.

Продукт: выпуск агента с продуманными настройками

Вы построили надстройку над Hermes — например, харнесс для мониторинга соответствия требованиям, стек поддержки клиентов, отраслевую исследовательскую платформу. Хотите распространять это как продукт.

# distribution.yaml
name: telemetry-harness
version: 2.3.1
description: "Compliance telemetry harness — monitors and reviews regulated workflows"
hermes_requires: ">=0.13.0"
author: "Acme Compliance Inc."
license: "Commercial"

env_requires:
  - name: ACME_API_KEY
    description: "Your Acme Compliance license key (email support@acme.com)"
    required: true
  - name: OPENAI_API_KEY
    description: "OpenAI API key for model access"
    required: true
  - name: GRAPHITI_MCP_URL
    description: "URL for your Graphiti knowledge graph instance"
    required: false
    default: "http://127.0.0.1:8000/sse"

Ваши клиенты устанавливают агента одной командой; предварительный просмотр установки точно говорит им, какие ключи держать наготове; обновления выкатываются в момент, когда вы тегируете новый релиз; их данные о соответствии требованиям (memories/, sessions/) никогда не покидают их машину.

Разовое использование: одноразовые скрипты на общей инфраструктуре

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

# Вы — сначала создайте .gitignore (см. "Для авторов", шаг 3), затем:
# Соберите профиль, закоммитьте, запушьте в приватный репозиторий
git push -u origin main

# Каждый дежурный
hermes profile install git@github.com:your-org/incident-2026-q2.git --alias

# Инцидент устранён — сворачиваем
hermes profile delete incident-2026-q2

Цикл «установить-удалить» достаточно дёшев, чтобы быть одноразовым.

Рецепты

Закрепиться на конкретной версии

Сравнить установленную версию с последней

# Ваша установленная версия
hermes profile info research-bot | grep Version

# Последняя версия у автора (без установки)
git ls-remote --tags https://github.com/you/research-bot | tail -5

Сохранить локальные настройки конфигурации при обновлениях

Поведение обновления по умолчанию уже это обеспечивает: config.yaml сохраняется. Для надёжности записывайте свои локальные правки в файл, который дистрибуции не принадлежит:

# ~/.hermes/profiles/research-bot/local/my-overrides.yaml
# (дистрибуция никогда не трогает local/)

…и обращайтесь к нему из config.yaml или из SOUL по мере необходимости.

Принудительная чистая переустановка

# Снести и переустановить с нуля (при этом теряются и воспоминания/сессии)
hermes profile delete research-bot --yes
hermes profile install github.com/you/research-bot --alias

# Обновиться до текущего main, но сбросить config.yaml к значению по умолчанию из дистрибуции
hermes profile update research-bot --force-config --yes

Форк и доработка

Стандартный git-процесс — дистрибуции это просто репозитории:

# Форкните репозиторий на GitHub, затем установите свой форк
hermes profile install github.com/yourname/forked-research-bot --alias

# Дорабатывайте локально в ~/.hermes/profiles/forked-research-bot/
# Редактируйте SOUL.md, коммитьте, пушьте в свой форк
# Изменения из апстрима: подтягивайте их в свой форк обычным способом

Проверить дистрибуцию перед публикацией

С машины автора:

# Установка из локального каталога (git push не нужен)
hermes profile install ~/.hermes/profiles/research-bot --name research-bot-test --alias

# Правьте, удаляйте, переустанавливайте, пока не получится как нужно
hermes profile delete research-bot-test --yes
hermes profile install ~/.hermes/profiles/research-bot --name research-bot-test

Экспорт и импорт файла профиля

Когда версионирование не нужно, репозиторий можно пропустить. /export упаковывает профиль в один .tar.gz; /import на другом конце распаковывает его в новый профиль. Учётные данные вырезаются при упаковке.

Экспорт

В CLI, TUI или чате десктопного приложения:

/export                          # активный профиль → управляемый profile-exports/<name>-<timestamp>.tar.gz
/export research-bot             # профиль по имени
/export research-bot -o ~/Desktop/research-bot.tar.gz

Без -o CLI и TUI кладут архив в управляемую директорию Hermes profile-exports/ внутри домашней директории Hermes по умолчанию, а не в текущую рабочую директорию. Так рутинные экспорты не засоряют исходники и снимок профиля не спутать с файлом из репозитория. Если сама домашняя директория Hermes находится внутри git-репозитория (бывает в некоторых Docker- и кастомных развёртываниях), архив уходит в ~/.hermes-profile-exports/ или, если и это не подходит, в директорию для конкретного пользователя во временной директории ОС — но никогда в сам репозиторий. Если безопасного автоматического места вообще не нашлось (все кандидаты оказались внутри git-репозитория), экспорт отказывает с сообщением «No safe automatic export destination», и путь нужно указать самому через -o. Явно заданный путь -o по-прежнему учитывается, когда вы сами решаете, куда сохранить архив.

Или из шелла — тот же механизм под капотом:

hermes profile export research-bot
hermes profile export research-bot -o ./research-bot.tar.gz

В десктопном приложении есть три пути, и все они ведут к нативному диалогу сохранения:

• ⌘K → Export profile…
• Правый клик по квадрату профиля в боковой панели → Export profile…
• Кнопка импорта рядом с + боковой панели покрывает обратное направление

Десктопный экспорт добавляет один файл, которого нет у CLI: desktop.json — в нём скин, светлая/тёмная тема, определения пользовательских тем, которые нужны скину, цвет боковой панели профиля и раскладка окна. Поэтому профиль, которым поделились из десктопного приложения, у получателя не просто ведёт себя как ваш — он ещё и выглядит как ваш.

Импорт

/import ~/Downloads/research-bot.tar.gz
/import ~/Downloads/research-bot.tar.gz --name research-bot-2

hermes profile import ./research-bot.tar.gz
hermes profile import ./research-bot.tar.gz --name research-bot-2

Имя профиля определяется по архиву, если не передан --name. Импорт поверх уже существующего профиля отклоняется — сначала переименуйте или удалите старый. Обёртка шелла (research-bot → hermes -p research-bot) создаётся, если имя не конфликтует с уже существующей командой.

Импорт в десктопном приложении дополнительно применяет оверлей desktop.json и сразу переключает вас на новый профиль с чистым чатом. Импортировать в CLI архив, сделанный десктопным приложением, тоже можно — файл оверлея просто едет вместе с профилем на диске и применится, когда вы в следующий раз откроете этот профиль в десктопном приложении.

Что входит в файл экспорта

Всегда исключены для обоих типов профиля: auth.json, .env и остальные хранилища учётных данных, которые Hermes читает из профиля (файлы OAuth и токенов ботов, например weixin/accounts/ для WeChat, honcho.json, mcp-tokens/, vault/, ключи iron-proxy в proxy/, профили браузера, включая профиль /browser connect в chrome-debug/, сессии платформ и хранилища сопряжения, teams_pipeline_store.json конвейера Teams вместе с clientState вебхука Graph), а также .ssh/, .aws/, .gnupg/, .kube/, .docker/, .azure/, .config/gh/, .config/gcloud/ и .envrc в корне или внутри навыка. Ваши API-ключи никогда не покидают машину. В honcho.json и mem0.json рядом с настройками может лежать API-ключ провайдера, поэтому после импорта снова запустите hermes honcho setup или hermes memory setup.

Профиль default (~/.hermes) экспортируется через allow-list — попадают только известные артефакты Hermes, так что случайный файл, лежащий у вас в домашнем каталоге, в архив не затянет:

config.yaml, SOUL.md, MEMORY.md, USER.md, todo.json, system_prompt.md, AGENTS.md, CLAUDE.md, .cursorrules, skills/, plugins/, cron/, scripts/, sessions/, memories/, knowledge/, preferences/, а также desktop.json, если его подготовило десктопное приложение.

Именованный профиль (~/.hermes/profiles/<name>) копируется целиком, минус эти хранилища учётных данных, home/ (это HOME подпроцессов инструментов Hermes, где git, ssh, gh, npm и CLI навыков хранят свои учётные данные) и резервные копии, которые Hermes хранит для их восстановления (backups/, state-snapshots/, любые auth.json.* и .env.bak*, а также копии config.yaml.bak-<timestamp>, которые пишет hermes update). Копия, названная вами самостоятельно, например config.yaml.bak-my-note, экспортируется, а её секреты маскируются так же, как в config.yaml. Это шире: если в профиле есть state.db, логи или кэши, они тоже попадут в архив, и файл получится большим.

tar -tzf research-bot.tar.gz | less

Что точно не попадает в дистрибуцию (никогда)

Установщик жёстко исключает эти пути, даже если автор случайно передал их в репозитории. Никакая настройка не позволяет это переопределить — эта защита проверяется регрессионными тестами как неизменное правило:

• auth.json — токены OAuth, учётные данные платформ
• .env — API-ключи, секреты
• memories/ — память переписки
• sessions/ — история переписки
• state.db, state.db-shm, state.db-wal — метаданные сессий
• logs/ — логи агента и ошибок
• workspace/ — сгенерированные рабочие файлы
• plans/ — черновые планы
• home/ — домашний каталог пользователя, смонтированный в Docker-бэкендах
• *_cache/ — кэши изображений / аудио / документов
• local/ — пользовательское пространство для собственных настроек

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

Безопасность и доверие

По умолчанию дистрибуции профилей не подписаны. Вы доверяете:

• Git-хостингу (GitHub / GitLab / где угодно) — что он отдаёт именно те байты, которые запушил автор.
• Автору — что он не передал вредоносный SOUL, навыки или cron-задачи.

Cron-задачи из дистрибуции не планируются автоматически — новые поставляемые задачи устанавливаются на паузе. Просмотрите их через hermes -p <name> cron list и возобновите только те, которым доверяете. SOUL.md и навыки становятся активными сразу же, как только вы начинаете общаться с профилем, поэтому прочитайте их перед первым запуском, если устанавливаете дистрибуцию от кого-то незнакомого.

Грубая аналогия: установка дистрибуции похожа на установку расширения браузера или расширения VS Code. Низкий порог входа, высокая мощность, доверие к источнику. Для внутренних корпоративных дистрибуций используйте приватный репозиторий и свою обычную авторизацию git — настраивать ничего нового не нужно.

В будущих версиях может появиться подписание, файл блокировки (.distribution-lock.yaml) с зафиксированным SHA коммита и флаг --dry-run, который покажет дифф перед применением обновления. Пока ничего из этого не реализовано.

Что под капотом

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

Коротко:

• install, update, info находятся внутри hermes profile — а не в параллельном дереве команд.
• Формат манифеста — YAML с минимальной обязательной схемой (только name).
• Установщик использует ваш локальный бинарник git для клонирования, так что любая авторизация, которую уже обрабатывает ваша оболочка (SSH-ключи, хелперы учётных данных), работает прозрачно.
• После клонирования .git/ удаляется — установленный профиль сам по себе не является git-чекаутом, что исключает ловушки вида «ой, я случайно закоммитил свой .env в git-историю дистрибуции».
• Зарезервированные имена профилей (hermes, test, tmp, root, sudo) отклоняются при установке, чтобы избежать конфликтов с распространёнными бинарниками.

Смотрите также

• Профили: запуск нескольких агентов — базовая концепция
• Справочник по командам профиля — каждый флаг, каждая опция
• hermes profile export / import — CLI-вариант файлов экспорта
• Справочник по слэш-командам — /export, /import и все остальные команды в чате
• Использование SOUL с Hermes — создание личностей
• Личность и SOUL — как SOUL встраивается в агента
• Каталог навыков — навыки, которые можно встроить