Agent Sync Playbook: как синхронизировать Hermes, Claude Code и Codex через Obsidian vault

У меня три AI-агента работают на одном сервере: Hermes Agent (оркестратор), Claude Code (инженерный агент, аудит), Codex (инженерный агент, код, инфраструктура). Идея была красивой: каждый делает свою работу, они дополняют друг друга, я меньше вовлечён в рутину.

Первые две недели это работало. На третью начались проблемы.

Hermes создавал новую заметку в vault и считал задачу выполненной. Codex не знал о ней и через час создавал дубликат в другом разделе. Claude Code вносил изменения в конфигурацию Cloudflare Tunnel, но не записывал это никуда, кроме своего session history — а session history не видит ни один другой агент.

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

Почему агенты дрейфуют

Когда у тебя один агент (например, Claude Code или Copilot в IDE) — проблема синхронизации не стоит. Есть ты, есть агент, есть история чата. Всё прозрачно.

Когда агентов три — контекст умножается на три, и начинается:

Дрейф знаний. На четвёртый день Claude Code думает, что база данных на порту 5432, а Codex — что на 5433. Оба правы в своём контексте, оба ошибаются в реальности.
Дублирование работы. Hermes пишет playbook для деплоя — Codex на следующий день пишет такой же, потому что не видел первый.
Потеря решений. Claude Code находит баг в production, чинит, но решение остаётся только в его истории чата. Через неделю баг возвращается — и никто не помнит, как его фиксили.
Конфликт изменений. Codex меняет структуру vault — переименовывает папки. Hermes продолжает ссылаться на старые пути. Wikilinks бьются.

Решение напрашивалось: нужен единый источник истины и протокол работы с ним. Я выбрал Obsidian vault — и написал Agent Sync Playbook.

Что такое Agent Sync Playbook

Это набор правил и процедур, который каждый агент обязан выполнять: до начала работы, во время работы и после завершения. Playbook живёт прямо в vault — в 40-playbooks/AGENT_SYNC_PLAYBOOK.md. Любой агент может (и должен) прочитать его перед тем, как что-то делать.

Вот его структура:

Перед работой: 4 шага

Шаг 1 — Прочитать Shared Context. Это файл 50-agents/SHARED_CONTEXT.md. Он содержит актуальную информацию о сервере: IP-адреса, основные пути, состояние VM, backup-рутины, активные web-shells. Если что-то изменилось — агент узнает об этом до того, как начнёт ошибаться.

Пример из реальной практики: когда я выключил VM cosmos (освободил 24 GiB для v2), я обновил Shared Context. Codex при следующем запуске прочитал это и не пытался запустить cosmos — в отличие от прошлой недели, когда он потратил 20 минут на дебаг несуществующей VM.

Шаг 2 — Прочитать релевантную agent-заметку. У каждого агента есть роль и процедуры в 50-agents/:

HERMES_AGENT.md — оркестрация, контент, мессенджеры, handoff
CODEX.md — код, серверная автоматизация, аудит, восстановление
CLAUDE_CODE.md — независимый аудит, альтернативные решения, код-ревью

Это не просто описание — это рабочие инструкции со ссылками на конкретные playbook’и.

Шаг 3 — Проверить активные проекты. Папка 20-projects/ содержит все активные многошаговые работы. Агент должен знать, над чем прямо сейчас работает другой агент. Если Hermes пишет roadmap блога на месяц, Codex не должен параллельно менять структуру контент-пайплайна.

Шаг 4 — Поискать перед созданием. Перед тем как создать новую заметку — rg по vault. Дубликаты — главный враг синхронизации.

Во время работы: knowledge flow

Я построил явную модель движения знаний в vault. Это не абстракция — каждый агент обучен следовать ей:

Сырые данные → 00-inbox/. Логи, результаты проверок, необработанные идеи.
Проверенные факты → 30-wiki/. Evergreen knowledge: архитектура сервера, задокументированные решения, Karpathy Agent Method.
Повторяемые процедуры → 40-playbooks/. То, что агент (или человек) будет делать снова и снова.
Handoff-записи → 50-agents/AGENT_HANDOFF.md. Когда агент передаёт работу другому — короткая запись: задача, текущее состояние, файлы, риски.
Связи — через wikilinks. Агенты используют [[Note Name]] вместо копирования текста. Если Codex ссылается на [[50-agents/SHARED_CONTEXT]], а не копирует его содержимое — при изменении Shared Context все ссылки остаются актуальными.

Реальный пример. Claude Code обнаружил, что устаревшие Telegram-скрипты всё ещё лежат на сервере после вывода ботов из эксплуатации. Он не удалил их сам — он создал запись в 00-inbox/ с описанием находки, а Codex позже добавил пункт очистки в Фазу 0.0 roadmap. Синхронизация через vault предотвратила потерю информации и конфликт действий.

После работы: закрытие цикла

Обновить проектную заметку. Если агент работал над проектом из 20-projects/ — обновить статус. Не «я сделал», а «файлы изменены: /path/to/…, проверено: команда X, следующий шаг: Y».

Обновить Shared Context. Если в процессе работы изменилась архитектура сервера, настройки агентов, пути — зафиксировать в SHARED_CONTEXT.md. Это критично: без этого следующий агент будет работать с устаревшей информацией.

Проверить доступность. После изменений в путях или правах — запустить read-check из контейнера. Я однажды потратил час на дебаг, потому что Codex изменил права на папку и Hermes потерял доступ к vault. Сейчас это ловится за 30 секунд.

Запустить backup. После значимых изменений — sudo hermes-backup-now. Vault — production-ресурс, его нужно бэкапить как базу данных. У меня настроены локальные restic-снапшоты и offsite backup на Google Drive через rclone. Restore-drill пройден — проверено.

Реальные грабли: что ломалось без синхронизации

До введения playbook’а я собрал коллекцию дорогих ошибок. Вот три, которые стоили больше всего времени:

Грабли №1: Дрейф путей. Codex переименовал 50-agents/HERMES.md в 50-agents/HERMES_AGENT.md — стандартизация имён. Hermes продолжал ссылаться на старый путь, и 7 заметок получили битые wikilinks. Решение: правило «перед переименованием — поиск ссылок через rg и обновление всех» теперь в playbook’е.

Грабли №2: Потерянное решение. Claude Code починил проблему с Docker-сетью (контейнеры теряли связь после перезапуска cloudflared). Решение было в истории его чата. Через 3 дня проблема повторилась — агент не помнил, что делал. Решение: handoff-записи в AGENT_HANDOFF.md с шаблоном (задача → состояние → файлы → проверка → риски → следующий шаг).

Грабли №3: Конфликт backup-расписания. Hermes создал cron-задачу на ежедневный vault backup в 03:00. Codex, не зная об этом, создал вторую задачу на 03:30 — с другим набором папок. Оба бэкапа работали параллельно, но покрывали разное. Решение: shared backup-конфигурация в SHARED_CONTEXT.md.

Инструменты, которые держат vault в порядке

Playbook — это процесс. Но процессы без автоматизации не работают. Вот что я настроил:

bronevik-vault-status

Скрипт, прогоняющий vault через 8 проверок:

$ bronevik-vault-status

git_dirty_count=0
obsidian_config=present
missing_required_count=0
missing_frontmatter_count=0
broken_wikilinks_count=0

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

Git-целостность

Vault находится под git. После каждой сессии работы агенты делают git add + git commit. Это даёт:

Историю изменений — видно, кто и когда менял заметки
Возможность отката при ошибке
git status как быстрый health-check: грязный репозиторий = незакоммиченные изменения = риск потери

MCP-доступ

Hermes подключён к vault через MCP (Model Context Protocol). Это не монтирование файловой системы — это структурированный доступ с гранулярными правами:

bronevik_knowledge_fs — полный доступ к vault: чтение, запись, редактирование, создание
bronevik_workspace_fs — read-only доступ к остальному workspace
bronevik_knowledge_git — git-операции: status, diff, log, add, commit

Это значит, что агент не может случайно записать секреты за пределы vault и не может выполнить git push --force или git reset --hard.

Результаты: что изменилось

После 2 недель с playbook’ом:

Ноль дубликатов заметок. Агенты ищут перед созданием.
Ноль битых wikilinks. Правило переименования работает.
Чистый git. Каждая сессия коммитится — git status показывает clean.
Прозрачность handoff’ов. Видно, кто передал работу кому и с каким статусом.
Backup без пропусков. Shared backup-политика в одном месте.

Самое ценное — я перестал быть диспетчером. Раньше я тратил 15-20 минут в день на синхронизацию агентов: «Codex, Hermes сделал то-то, имей в виду. Claude, Codex поменял пути, учти.» Теперь это делается через vault автоматически.

Как внедрить у себя

Если у вас два или больше AI-агентов, начните с трёх вещей:

Создайте Shared Context. Один файл с актуальной информацией о среде: сервер, пути, ключевые настройки, состояние. Обновляйте его при любом изменении.
Введите Knowledge Flow. Где лежат сырые данные, где — проверенные факты, где — процедуры. Агент должен знать, куда писать.
Научите агентов читать перед работой. Самый простой шаг: перед выполнением задачи агент читает Shared Context и активные проекты. 30 секунд чтения — вместо часа дебага устаревших предположений.

Не нужен сложный RAG, не нужна отдельная база данных, не нужен LangChain. Файловая система + Markdown + wikilinks + дисциплина процесса — этого достаточно, чтобы три AI-агента работали в унисон.

Мой Agent Sync Playbook живёт в открытом vault. Если собираете свою мультиагентную систему — берите за основу, адаптируйте под себя.

Стек, на котором всё работает:

Hermes Agent (оркестрация, контент)
Claude Code + Codex (инженерные агенты)
Obsidian vault (shared memory)
Git (целостность знаний)
Docker + Proxmox (инфраструктура)
Cloudflare Tunnel + Access (безопасный доступ)
Restic + rclone + Google Drive (шифрованные бэкапы)