Obsidian как shared memory для AI-агентов: единая база знаний для Hermes, Claude Code и Codex

Когда у тебя несколько AI-агентов, рано или поздно возникает проблема: каждый агент живёт в своём контексте. Hermes знает одно, Claude Code — другое, Codex — третье. Информация дрейфует, агенты противоречат друг другу, ручной перенос контекста съедает время.

Я прошёл этот путь на своём стеке: Hermes Agent (оркестратор), Claude Code и Codex (инженерные агенты). Решение оказалось неожиданно простым — Obsidian vault как shared memory.

В этой статье — как это работает, почему это лучше альтернатив и какие грабли я собрал по пути.

Проблема: контекстная фрагментация

Каждый AI-агент по умолчанию работает в изоляции. У него своя история чата, свои файлы конфигурации, своё понимание «как устроен сервер». Это приводит к трём проблемам:

Дрейф знаний — Claude Code «знает», что база данных на порту 5432, а Codex думает, что на 5433. Кто прав? Никто не помнит.
Дублирование работы — оба агента пишут один и тот же playbook, потому что не видят работу друг друга.
Ручной sync — ты тратишь время на копирование контекста между агентами.

Я перепробовал несколько подходов: отдельные базы знаний для каждого агента, общий канал в Telegram, Google Docs. Всё это работало ровно до первого серьёзного изменения конфигурации.

Решение: один Obsidian vault на всех

Вместо того чтобы давать каждому агенту свою базу знаний, я сделал один Obsidian vault — и дал к нему доступ всем трём агентам.

┌─────────────────────────────────────────────┐
│           Hermes Agent                      │
│     (оркестрация, контент, Telegram)         │
├────────────────┬────────────────────────────┤
│  Claude Code   │         Codex CLI          │
│  (инженерия)   │     (код + поддержка)       │
├────────────────┴────────────────────────────┤
│           Obsidian Vault                    │
│     Единая shared memory для всех агентов    │
└─────────────────────────────────────────────┘

Как это работает технически

Vault — это просто директория с Markdown-файлами, доступная через файловую систему контейнера. Никакого Obsidian Desktop на сервере не нужно. Агенты подключаются к vault через MCP-сервер (bronevik_knowledge_fs), который даёт инструменты для чтения, поиска и записи заметок.

Ключевое решение: разделение по папкам, а не по базам знаний. Вместо «vault Hermes» и «vault Codex» — один vault, где каждый раздел отвечает за свой тип информации:

00-inbox/ — сырой входной материал
10-sources/ — источники и исследования
20-projects/ — активные проекты
30-wiki/ — evergreen-знания
40-playbooks/ — повторяемые процедуры
50-agents/ — роли агентов, handoff-инструкции
60-content/ — контент-системы
70-seo/ — SEO-стратегия
80-youtube/ — видео-воркфлоу
90-archive/ — архив

Почему один vault, а не несколько

Я рассматривал вариант с отдельными базами знаний для каждого агента. Отказался по трём причинам:

Единый источник правды — информация не дрейфует, потому что физически лежит в одном месте. Если Claude Code обновил конфигурацию сервера, Hermes и Codex видят это сразу.
Obsidian-ссылки работают внутри одного vault — [[AI_SERVICE_STACK]] резолвится только если обе заметки в одном хранилище. Раздельные vaults = никаких wikilinks между агентами.
Handoff без копирования контекста — агенты оставляют друг другу заметки в 50-agents/AGENT_HANDOFF. Никакого «перешли мне тот файл в Telegram».

Структура shared memory: что куда писать

Главное правило, которое мы выработали за 6 месяцев работы: каждый тип информации — в свою папку. Звучит банально, но именно на этом всё и держится.

30-wiki: вечные знания

Сюда попадает всё, что не меняется каждый день: архитектура стека, принципы работы агентов, методология. Например, заметка AI_SERVICE_STACK.md описывает, какие Docker-образы используются и какие порты открыты. Если агент хочет понять, как устроен сервер — он идёт сюда.

40-playbooks: процедуры

Любая операция, которая повторяется больше двух раз, должна стать playbook-ом. У нас есть playbook для синхронизации агентов, для проверки здоровья vault, для офсайт-бэкапа. Playbook — это одна страница с чеклистом. Не больше.

50-agents: кто за что отвечает

Здесь лежат роли агентов и handoff-инструкции. Когда Hermes понимает, что задача требует shell-доступа, он пишет заметку в AGENT_HANDOFF и делегирует Codex или Claude Code. Агент-исполнитель читает handoff, делает работу и обновляет статус.

20-projects: активные проекты

Каждый крупный проект — отдельная заметка с текущим статусом, open risks и next action. Это заменяет Trello, Notion и любые другие доски.

Agent handoff: как агенты передают работу

Самый интересный механизм — agent handoff. Когда один агент не может или не должен выполнять задачу, он оставляет структурированную заметку в 50-agents/AGENT_HANDOFF:

## 2026-06-10 14:30 — От Hermes → Codex

Task: Проверить здоровье диска и обновить конфигурацию бэкапов
Current state: NVMe заполнен на 78%, последний бэкап — 3 дня назад
Files/paths: /etc/restic-config, /opt/bronevik-maintenance/
Verification: `sudo hermes-backup-status` должен показать snapshot < 24h
Open risks: нет
Next action: Запустить restic backup, проверить лог

Формат жёсткий, но именно это и нужно: никакой воды, только факты. Агент-исполнитель читает, делает, обновляет.

Vault health: как не потерять данные

Когда vault становится критической инфраструктурой, его нужно мониторить. У нас есть скрипт bronevik-vault-status, который проверяет:

Git status — нет ли незакоммиченных изменений
Wikilinks — не битые ли ссылки
Frontmatter — у всех ли заметок есть YAML-шапка
Secret-like paths — не попали ли случайно ключи или токены

Ожидаемый healthy output:

git_dirty_count=0
obsidian_config=present
missing_required_count=0
missing_frontmatter_count=0
broken_wikilinks_count=0
secret_like_paths_count=0
content_overall=ok
overall=ok

Если vault нездоров — агенты не начинают новую работу, пока он не починен. Это жёсткое правило, и оно окупается: ни разу не было ситуации, когда агент «забыл» важную информацию.

Что дала shared memory на практике

После 6 месяцев использования могу подвести конкретные итоги:

Плюсы:

Агенты перестали противоречить друг другу — единый источник правды работает
Handoff занимает 2 минуты вместо 15 минут ручного копирования контекста
Новый агент (когда мы добавляли Codex) встал в строй за час — просто прочитал vault
Все решения зафиксированы и доступны через поиск — никаких «а кто выключал тот сервис?»

Минусы:

Нужна дисциплина: агенты должны писать в vault, а не держать всё в памяти сессии
Vault нужно мониторить — битые ссылки накапливаются, если не чистить
Не всё можно хранить в Markdown — бинарные файлы и скриншоты приходится класть рядом

Выводы

Obsidian vault как shared memory для AI-агентов — это не про «красивую базу знаний». Это про работающую архитектуру, где информация не теряется между сессиями, агенты не спорят о фактах, а handoff происходит без твоего участия.

Главный урок: не пытайтесь сделать идеальную структуру с первого дня. Начните с трёх папок (inbox, wiki, playbooks), добавьте агентов, и структура вырастет сама. Мой vault начинался с 5 заметок — сейчас их 40+, и каждая на своём месте.

Если у вас несколько AI-агентов и вы ещё не дали им общую память — начните сегодня. Obsidian vault на сервере без GUI ставится за 5 минут, а эффект от shared memory вы увидите в первый же день.