Hermes Agent вместо Claude Code

Личный боевой дневник: от установки до автономного ассистента с памятью на Hindsight, самообучающимися скиллами, cron-напоминаниями и Telegram-интеграцией. Со всеми граблями, на которые я наступил.

TL;DR

Hermes Agent — ИИ-агент с открытым исходным кодом (MIT) от Nous Research, вышедший в начале 2026 года. Живёт в терминале, веб-интерфейсе и мессенджерах (Telegram, Discord, Slack и ещё десяток), работает с любым LLM-провайдером.

Главная ценность Hermes для меня — это память, самообучающиеся скиллы и независимость от вендора. Агент не начинает каждый разговор с чистого листа: он помнит, кто я, какие у меня предпочтения и окружение, и накапливает рабочие процедуры в виде повторно используемых «скиллов» — со временем он становится полезнее именно под мои задачи. Это не «ChatGPT в терминале», а ассистент, который растёт вместе с тобой. А поскольку Hermes не привязан к одному поставщику, весь этот накопленный контекст не становится заложником чужих цен и решений: модель можно сменить одной командой, ничего не потеряв.

Что я в итоге построил: Hermes на Mac, память на Hindsight (граф знаний поверх PostgreSQL), Docker-бекенд для изоляции инструментов, набор скиллов под мою рутину (дайджест Telegram-канала, напоминания о платежах, передача показаний, интеграция с TickTick). Управляю из терминала и с телефона через Telegram — один и тот же агент. И это только начало: система постепенно обрастает новыми скиллами и сценариями.

Кому будет полезно: технарям-энтузиастам, которые хотят собрать персонального автономного ассистента и готовы повозиться с настройками. Русскоязычных вводных руководств по Hermes уже хватает, а вот живых боевых разборов — с конкретными граблями, дырами в безопасности и неочевидными нюансами конфигурации — мне попадалось мало. Эту нишу статья и закрывает: экономит вам время на шишках, которые я уже набил.

Оглавление

• Главная ценность: память, скиллы и независимость
• Почему Hermes, а не Claude Code
• Архитектура Hermes
• Мой стек
• Docker-бекенд: главные грабли
• Безопасность: слои защиты
• Память: от Holographic к Hindsight
• Скиллы: самообучающийся агент
• Cron и напоминания
• Telegram-интеграция
• Практический пример: TickTick API
• Контекст и сжатие
• Что дальше
• Источники и инструменты

Главная ценность: память, скиллы и независимость

Начну с главного, потому что именно это отличает Hermes от очередной обёртки над LLM.

Какую-то память сейчас прикрутили почти все, так что сам факт «агент что-то помнит» уже никого не удивляет. Интереснее другое: насколько эта память глубокая и работает ли она без ручного «запомни это». В Hermes таких механизма два, и оба заточены на то, чтобы агент со временем становился полезнее именно под тебя, — долговременная память и процедурная память (скиллы).

Память. Агент помнит контекст между сессиями: кто я, мои предпочтения, моё окружение, договорённости. Я перепробовал несколько провайдеров памяти и остановился на Hindsight — граф знаний с автоматическим извлечением фактов и семантическим поиском (подробно ниже). Результат: я не объясняю одно и то же по второму разу.

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

Третья ценность — независимость от вендора — заслуживает отдельного разговора (он ниже). А gateway и cron — это уже инфраструктура, которая делает память и скиллы практичными. Поэтому именно с памяти и скиллов я и начал.

Почему Hermes, а не Claude Code

Я поставил Hermes Desktop на свой Mac (он у меня всегда включён). Это оказалось на удивление просто: одна установка — и агент готов, без возни с зависимостями. Терминал у меня вынесен в Docker-контейнер через OrbStack, общаюсь через Telegram и CLI.

Уход от привязки к одному поставщику (vendor lock-in). Самые заметные проприетарные ИИ-агенты для разработки завязаны каждый на своего вендора: Claude Code — на Anthropic, Codex CLI — на OpenAI, Copilot — на GitHub/Microsoft. У каждого своя модель, свой API, своя экосистема. Поставить рядом другой инструмент никто не мешает, и кое-что даже переносимо: скиллы — это обычно просто markdown-файлы, а самостоятельно поднятую память (например, Hindsight) можно делить между инструментами (я так и делаю между Hermes и Claude Code). Но завязка на вендора всё равно сильная — модель, цены и экосистема у каждого свои, единой кнопки «перенести всё» нет, и на практике смена инструмента означает, что многое приходится обустраивать заново.

Я и сейчас пользуюсь Claude Code (Pro/Max-подписка, OAuth), и он хорош. Но когда Anthropic поднимает цены или меняет модель — выбора у меня нет, я на их рельсах. А искать запасной вариант меня подтолкнула новость, что для пользовательских подписок Anthropic вводит проверку личности — государственное удостоверение и селфи (через сторонний сервис Persona, с 8 июля 2026).

Hermes решает это архитектурно. Независимость от провайдера: 20+ провайдеров из коробки, переключение модели — одна команда hermes model, и ни память, ни скиллы, ни cron к провайдеру не привязаны. Плюс открытый исходный код (MIT) — никакого чёрного ящика, можно копаться в коде, чинить, дорабатывать. Для меня это означало одно: я могу выбрать DeepSeek для повседневных задач, Claude для сложного кода и локальную модель для конфиденциального — и весь накопленный контекст (память, скиллы, cron) переезжает между ними без потерь.

Будем честны: ничего принципиально уникального Hermes не делает. Те же память, самообучающиеся скиллы, мультиплатформенный gateway есть и в Claude Code, и в Cowork. Разница в одном, но для меня решающем: там ты привязан к вендору, здесь — нет. И честно в обратную сторону: для чистого кодинга специализированные агенты — тот же Claude Code или opencode — Hermes обойдут. Hermes — универсал, а универсал почти всегда уступает специалисту на его поле. Я выбрал Hermes не потому, что он «лучший агент», а потому, что он мой и не заложник чужих цен и решений. Из открытых альтернатив я смотрел в сторону OpenClaw, но на тот момент остановился на Hermes — он показался надёжнее и зрелее.

Архитектура Hermes: как это устроено

Если описать словами: всё работает на хосте (у меня — macOS). В центре — цикл агента (run_conversation): он собирает системный промпт, подмешивает память и скиллы, отправляет всё в LLM, получает запросы на вызов инструментов, выполняет их — и так по кругу, пока задача не решена; при приближении к лимиту контекста старое сжимается в сводку.

Цикл опирается на несколько источников знания, и у каждого своя роль:

• Системный промпт — базовые правила самого Hermes.
• SOUL.md — личность агента: тон, манера речи, что для него важно. Это про то, кто он и как говорит, а не про то, что он знает.
• AGENTS.md — операционные инструкции: как действовать, чего избегать, рабочие договорённости.
• Память — что агент знает о мире и обо мне: MEMORY.md (стабильные факты про меня, окружение и соглашения; размер ограничен, лимит настраивается — у меня ~2200 знаков) плюс Hindsight (долговременная, с семантическим поиском).
• Скиллы — процедурное знание: как решать конкретные задачи.

Всем этим цикл пользуется вместе с набором инструментов (terminal, browser, file, web, memory, cronjob, delegate_task и др.). Снаружи к нему подключены два канала: gateway (Telegram, Discord, Slack…) и планировщик cron. А инструменты вроде terminal и file исполняются в терминальном бекенде. По умолчанию это сам хост, но я переключил его на Docker-контейнер с Linux (через OrbStack) ради изоляции — туда проброшен общий том /workspace/project.

Ключевые компоненты:

Gateway: один агент, много платформ

Gateway — это многоплатформенный слой, который позволяет одному и тому же агенту работать в Telegram, Discord, Slack, WhatsApp, Signal, Email, Matrix и ещё десятке платформ. Не «бот для Telegram» и отдельно «командная строка для терминала» — это один мозг с одной памятью и одними скиллами.

Схематично: и Telegram, и CLI ведут к одному и тому же циклу агента и его инструментам. Общие для всех каналов — память (MEMORY.md + Hindsight), скиллы и cron-задачи. А контекст текущей сессии у каждого канала свой (об этом — чуть ниже).

Как это работает на практике:

• Начал задачу в терминале (hermes chat) — поработал над кодом
• Ушёл с компьютера — пишу в Telegram с телефона. Важный нюанс: Telegram — это отдельная сессия, а не продолжение терминальной. Живая переписка из терминала туда сама не переносится
• Но память и скиллы у них общие, поэтому агент по-прежнему знает, кто я и каков контекст проекта; а недостающее можно поднять из памяти или через session_search («вспомни, что мы делали в терминале»)
• Cron-задачи (дайджест канала, напоминания) доставляются в Telegram автоматически

Настройка gateway: hermes gateway setup → выбрать платформу → прописать токен/ключи в .env → hermes gateway install (как служба systemd/launchd для работы 24/7).

Важно: один gateway = один токен бота. Нельзя запустить два gateway с одним Telegram-токеном — второй заблокируется. Поэтому если хочется несколько экземпляров Hermes с Telegram, нужны отдельные боты.

Профили: изолированные личности агента

Профили — это независимые экземпляры Hermes со своими конфигурациями, скиллами и cron-задачами (память — по желанию: отдельная у каждого или общая). Живут в ~/.hermes/profiles/<name>/.

Зачем нужны профили:

Ключевое свойство: по умолчанию профили изолированы — у каждого свои конфигурация, скиллы и cron-задачи (скилл, созданный в default, не виден в coder). Но что именно разделять, а что использовать совместно — дело настройки. Память я, наоборот, свёл воедино: один и тот же Hindsight подключён ко всем профилям и даже к Claude Code. Hindsight так умеет — каждый профиль пишет в свой банк, но может получить доступ на чтение к чужому (например, к банку основного Hermes). Сама же изоляция профилей позволяет:

• Разделять роли. Разработчик работает с кодом, админ — с системой, основной — общается в Telegram.
• Разделять уровень риска. default в Docker-контейнере (безопасно для автоматических задач), local-admin на хосте (только вручную, для привилегированных операций).
• Использовать разные модели под разные задачи. Claude для сложного кода, DeepSeek для повседневных задач, локальная модель для конфиденциальных.

Создание профиля: hermes profile create coder → hermes --profile coder для запуска, или hermes profile alias coder для удобного hermes-coder.

Общие скиллы между профилями: Hermes поддерживает профили-репозитории — общую директорию скиллов, на которую ссылаются другие профили. Без этого каждый профиль дублирует скиллы.

Мой стек

Mac (работает постоянно):

• Hermes Agent (на macOS):
  • Профиль: default
  • Модель: deepseek-v4-pro (основная), deepseek-v4-flash (лёгкие задачи)
  • Провайдер: opencode-go (основной), z.ai/GLM (резерв)
  • Reasoning: high
  • Память: Hindsight (pgvector) + MEMORY.md
• Docker (через OrbStack) — терминальный бекенд:
  • Linux (Debian), Python
  • /workspace/project — общий том (rw)
  • ~/.hermes/skills/ — монтирование (ro)
  • ~/.hermes/cache/ — монтирование (rw)

Почему Docker-бекенд:

• Изоляция. Инструменты агента (terminal, file, browser) работают в контейнере, не на хосте.
• Безопасность. Даже если агент сделает rm -rf /, пострадает контейнер, а не сам Mac.
• Воспроизводимость. Окружение фиксировано — Debian, известные версии пакетов.

Docker-бекенд: главные грабли

Это самая богатая на открытия тема. Docker-бекенд Hermes работает не так, как ожидаешь.

Проблема 1: .env не виден в контейнере

~/.hermes/.env на хосте содержит конфигурацию и переменные окружения. Но в Docker-контейнер монтируются только skills/ (ro) и cache/ (rw). Сам .env и config.yaml — нет.

Решение: docker_forward_env в config.yaml:

yaml

terminal:
  docker_forward_env:
    - TZ
    - HINDSIGHT_URL
    - WINDMILL_BASE_URL
    # ... несекретные переменные окружения, нужные в контейнере

Hermes пробрасывает указанные переменные из .env на хосте в контейнер при создании сессии. Сюда я кладу только несекретные параметры — адреса сервисов, таймзону и подобное. Настоящие секреты в контейнер не попадают вовсе: для них есть Agent Vault.

Проблема 2: /reload не подхватывает docker_forward_env

/reload перечитывает .env для самого процесса Hermes, но новые переменные не прокидываются в уже работающий Docker-контейнер на лету — они «запекаются» при создании сессии (init_session()). Чтобы изменения в docker_forward_env подхватились, нужно перезапустить gateway: при первом же следующем обращении контейнер заберёт обновлённые переменные окружения. Вручную сносить контейнер (docker rm -f) для этого не требуется.

Проблема 3: Общий том — не для секретов

/workspace/project/ — общий том (shared volume) на чтение и запись между хостом и контейнером. Удобно для кода, опасно для секретов. Любой секрет, положенный сюда, читаем агентом (поверхность для внедрения вредоносных инструкций) и любым кодом в контейнере.

Проблема 4: Контейнер постоянный, не одноразовый

Контейнер переиспользуется по меткам, а не пересоздаётся каждый раз. Это значит, что pip install и другие изменения в контейнере переживают перезапуски Hermes. С одной стороны удобно, с другой — можно забыть, что контейнер «грязный», и удивляться поведению.

Безопасность: слои защиты

Отдавать автономному агенту доступ к терминалу и своим аккаунтам — это всерьёз про безопасность. Hermes построен по принципу defense-in-depth: защита тут не одна галочка, а несколько слоёв. Коротко — что есть из коробки и что я добавил сверху.

Встроено в Hermes:

• Подтверждение опасных команд. Режим задаётся в ~/.hermes/config.yaml (approvals.mode): manual — спрашивать всегда, smart — только на рискованных операциях, off — не спрашивать. Рискованные команды (рекурсивное удаление, chmod, запись в чувствительные файлы) Hermes опознаёт по набору regex-паттернов и выносит на подтверждение.
• Жёсткий запрет катастрофичных действий. Часть команд настолько необратима (стирание файловой системы, fork-бомбы, запись напрямую в блочное устройство), что Hermes откажется их выполнять при любых настройках — флага-обхода нет.
• Маскирование секретов. Regex-маскирование вырезает API-ключи и токены из логов и вывода инструментов, чтобы они не утекли в историю или в ответ модели. Вдобавок Hermes фильтрует окружение, которое отдаёт менее доверенным компонентам: ключи провайдеров и токены gateway по умолчанию вырезаются.
• Песочница. Весь процесс агента (shell, выполнение кода, MCP, файловые инструменты, плагины, хуки, загрузка скиллов) можно завернуть в песочницу с едиными политиками по файловой системе, сети и процессам. А отдельный терминальный бекенд гоняет команды модели в контейнере, на удалённом хосте или в облачной песочнице — у меня это как раз Docker (см. выше).
• Авторизация и изоляция. В gateway можно ограничить, кто вообще вправе общаться с агентом; сессии изолированы друг от друга, а сетевой доступ ограничивается.

Что я добавил сверху: Agent Vault.

Даже с маскированием остаётся неприятный класс рисков: если секрет в принципе попадает в контейнер или в контекст агента, его можно попытаться вытащить — например, через prompt injection. Я закрываю это Agent Vault от Infisical — прокси-«сейфом» для агентов. Секреты лежат в сейфе, а агент ходит во внешние API только через прокси: в запросе стоит лишь заполнитель, а настоящий ключ Agent Vault подставляет на лету, перехватывая исходящий HTTPS. Агент даже не знает, что прокси есть, — значит, и красть из его контекста нечего. Так у меня подключён, например, TickTick (тот самый AV_PROXY из примера ниже).

Полный разбор встроенной модели безопасности — в документации Hermes.

Память: от Holographic к Hindsight

Раз память — главная ценность Hermes для меня, расскажу подробно, как я к ней пришёл.

Holographic (старт)

Hermes по умолчанию предлагает Holographic — алгебраическую память на HRR (holographic reduced representations). Без внешних зависимостей, отклик за доли миллисекунды, оценка доверия к фактам. Идеально для старта: hermes memory setup → holographic → работает.

Минусы: полностью ручная. Агент должен явно вызвать fact_store, чтобы запомнить факт. Нет автоизвлечения, нет семантического поиска, нет графа знаний.

Поиск «идеальной» памяти

Я хотел память, которая работает сама — без постоянных «запомни это». Рассматривал три варианта:

Honcho (от Plastic Labs) привлекателен полным автоматизмом — наблюдает диалоги, строит модель пользователя через диалектическое моделирование, сам подмешивает контекст в новые сессии. Но AGPL (строгий copyleft), требует PostgreSQL + Python-сервер, и «холодный старт» (первые сессии модель пустая).

Hindsight (от Vectorize.io) — граф знаний с автоматическим извлечением сущностей и связей, reflect для синтеза выводов, 91.4% на LongMemEval (на момент написания — первая система, перешагнувшая 90%, рекордная точность среди агентных памятей). MIT, разворачивается на своём сервере, PostgreSQL + pgvector. Под капотом — четыре параллельные стратегии поиска на каждый запрос: семантический поиск, BM25, обход графа и анализ по времени.

Выбрал Hindsight. Графовая структура, синтез через reflect, лучшая точность на тесте, лицензия MIT. Работает поверх PostgreSQL на моём Mac.

Как устроена память сейчас

Два слоя:

1. MEMORY.md — оперативная память. Подмешивается в каждое обращение. Хранит поведенческие правила: предпочтения, окружение, соглашения. Лимит размера настраивается (у меня ~2200 знаков) — чтобы память не вытесняла системный промпт.
2. Hindsight — долговременная. Три инструмента:Важно, что Hindsight не ждёт обязательного явного recall: релевантные факты он умеет подмешивать прямо в промпт автоматически — агент получает нужный контекст ещё до того, как сам догадается за ним сходить.
   • hindsight_retain — сохранить факт
   • hindsight_recall — семантический поиск
   • hindsight_reflect — синтез выводов по всем сохранённым фактам

Скиллы: самообучающийся агент

Вторая половина того, что делает Hermes ценным. Скилл — это SKILL.md файл с процедурным знанием: условия срабатывания, пронумерованные шаги, подводные камни, проверка.

Как это работает на практике:

1. Мы решаем сложную задачу (например, настройка чтения приватного Telegram-канала)
2. Агент сохраняет рабочий подход как скилл через skill_manage
3. В следующий раз, когда задача похожая — скилл загружается автоматически, и агент не изобретает велосипед

Примеры скиллов, которые появились за время работы:

• telegram-channel-digest — дайджест приватного Telegram-канала через Telethon/Windmill
• ticktick-api — работа с TickTick API (OAuth2, подводные камни с форматом дат)
• scheduled-reminders — напоминания по расписанию с защитой от повторной отправки
• water-meter-submission — передача показаний счётчиков через сайт ЖКХ
• hermes-agent — знание о самом Hermes (конфигурация, CLI, архитектура)

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

Curator — фоновый процесс, который отслеживает использование скиллов, помечает неиспользуемые как устаревшие, архивирует. Защита от захламления.

Cron и напоминания

Одна из первых практических задач — автоматические напоминания о ежемесячных платежах и передаче показаний.

Все они привязаны к календарю — к известному окну дат:

• передача показаний счётчиков — раз в месяц, в своё окно дат
• коммунальные платежи — в своё окно
• регулярные подписки и услуги — в своё

Механика: cron-задача с окном дат + fact_store, чтобы не дублировать. При каждом запуске cron проверяет fact_store: если я уже подтвердил «передал показания» / «оплатил» — напоминание не отправляется. Если нет — напоминает.

cron: "0 10 20-24 * *"  → каждый день с 20 по 24 число в 10 утра
prompt: "Проверь fact_store. Если water_meter_readings не done — напомни."

Эта логика вынесена в скилл scheduled-reminders.

Telegram-интеграция

Подключение через gateway

Hermes подключается к Telegram через gateway — получает сообщения, отвечает, имеет полный доступ к инструментам. Один бот, один токен. Настройка через hermes gateway setup — стандартная процедура: создать бота у @BotFather, прописать токен в .env.

Чтение приватных каналов

Отдельная эпопея. Задача: читать приватный Telegram-канал, на который я подписан, но не админ. Bot API такие каналы читать не умеет — нужен MTProto, то есть вход под личным аккаунтом (Telethon).

И вот здесь главная проблема: Telegram не даёт ограничить права сессии. Нельзя выпустить «токен только на чтение» или как-то урезать доступ — сессия личного аккаунта это всё или ничего, полный контроль над аккаунтом. Отдавать такую сессию агенту, который крутится в контейнере, — плохая идея.

Решение — брокер (обёртка). Сессию Telethon держит отдельный сервис на хосте (у меня — на Windmill), а наружу торчит только узкий HTTP API: получить сообщения канала — и всё. Агент в контейнере общается с этой обёрткой, а не с Telegram напрямую, и физически не может сделать ничего, кроме чтения. Туда же повесил ограничение частоты, чтобы не словить бан на реальном аккаунте.

Практический пример: TickTick API

Интеграция с TickTick для создания задач. Ключевые открытия:

• Достаточно статического токена. Полноценный OAuth2-поток (регистрация приложения, client_id/client_secret, authorization code flow) городить не обязательно — у TickTick есть статический API-токен, им я и пользуюсь.
• Формат дат — только UTC. TickTick молча отбрасывает dueDate и startDate, если смещение часового пояса не +0000. "dueDate": "2026-06-21T20:00:00+0300" — не работает. ✓ "dueDate": "2026-06-21T17:00:00+0000" + "timeZone": "Europe/Moscow" — работает.
• Безопасность в Docker: ключ API передаётся через --oauth2-bearer с заполнителем, реальный ключ подставляется прокси AV_PROXY уже в запросе.

Контекст и сжатие

Важный вопрос: что будет, если писать агенту бесконечно?

• Каждое сообщение — +1 шаг в той же сессии
• Контекст растёт, пока не упрётся в порог (compression.threshold: 0.50)
• Срабатывает сжатие: старые сообщения сжимаются в сводку силами LLM, освобождая место
• Процесс повторяется циклически — сессия может жить сотни сообщений
• Потери детализации на глубокой истории неизбежны, но session_search позволяет перечитать точный журнал любого старого разговора

Сброс сессии: есть опция session_reset — автосброс сессии по бездействию или по расписанию (раз в день). Но с нюансом: старый контекст не подмешивается в новый автоматически.

Что дальше

Признаюсь, начинал я скептически — ну вот, ещё один агент, очередная обёртка над LLM. Но за пару недель Hermes превратился в инструмент, которому я спокойно делегирую реальную рутину, и сейчас я уверен: это отличная вещь, которая стоит внимания.

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

Что работает хорошо:

• Ежедневный дайджест приватного Telegram-канала
• Ежемесячные напоминания о регулярных платежах и показаниях
• Передача показаний через сайт ЖКХ
• Интеграция с TickTick
• Память на Hindsight — факты сохраняются и находятся

О чём думаю сейчас: как сделать всю эту автономию безопаснее, не теряя удобства. Чем больше у агента доступов, тем выше цена ошибки или удачного prompt injection — и баланс между «удобно» и «безопасно» для меня сейчас главный открытый вопрос.

Я начал именно с Hermes, но присматриваюсь и к OpenClaw: говорят, команда проделала большую работу над ошибками. Так что следующий эксперимент — попробовать OpenClaw на тех же задачах и сравнить с Hermes.

Главный урок: Hermes — не просто «ChatGPT в терминале». Это платформа для построения персонального ИИ-ассистента, который со временем накапливает контекст и становится полезнее. Память и скиллы — ядро этой ценности; cron, gateway и независимость от провайдера делают её практичной. Но платформа требует вдумчивой настройки — Docker-бекенд, секреты, модель памяти, формат дат в API — везде есть нюансы, которые всплывают только на практике. Надеюсь, этот дневник сэкономит вам часть набитых мной шишек.

Источники и инструменты

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

Сам агент:

• Hermes Agent — репозиторий, документация и раздел про безопасность
• OpenClaw (openclaw.ai) — альтернативный опенсорсный агент

Память:

• Hindsight (Vectorize) — граф знаний, который я выбрал
• Honcho (Plastic Labs) и Mem0 — альтернативы, которые рассматривал

Безопасность и секреты:

• Agent Vault от Infisical — прокси-сейф для секретов агента
• Проверка личности в Claude — та самая новость Anthropic

Инфраструктура и интеграции:

• OrbStack — Docker для macOS
• Telethon — MTProto-клиент для чтения Telegram
• Windmill — брокер для Telegram-сессии
• TickTick — задачи