AI Handoff: как агенты передают задачи друг другу через общий Obsidian vault

Когда у вас один AI-агент — всё просто: дал задачу, получил результат. Но как только агентов становится три (Hermes, Claude Code, Codex), появляется вопрос: кто что делает и как они передают друг другу незаконченную работу?

В этой статье — реальные handoff-паттерны, которые я использую на своём сервере Bronevik. Без теоретических фреймворков. Только то, что работает на практике.

Почему handoff — это не «просто записка»

Наивный подход: написал задачу в md-файл, другой агент прочитал и сделал. На деле так не работает.

Какие проблемы возникают без структурированного handoff:

Потеря контекста. Claude Code проанализировал архитектуру и нашёл уязвимость — но Hermes об этом не знает и продолжает работать по старому плану.
Дублирование работы. Оба агента независимо фиксят одну и ту же проблему, потому что не видели результатов друг друга.
Несогласованные решения. Один агент принимает решение (например, отключить сервис), второй его же перезапускает, не зная о решении первого.
Битые ссылки и мёртвые заметки. Через месяц в vault лежит 15 handoff-записей, половина из которых ссылается на удалённые файлы.

Реальные последствия:

На моём сервере Codex и Claude Code однажды одновременно пытались обновить один и тот же docker-compose. Результат: конфликт, потерянные изменения, 40 минут ручного слияния. После этого я ввёл handoff-дисциплину.

Три уровня handoff: от простого к продвинутому

Уровень 1: Shared Context (общий контекст)

Минимально необходимый уровень. Каждый агент перед началом работы читает единый файл контекста.

У меня это 50-agents/SHARED_CONTEXT.md в Obsidian vault. В нём зафиксированы:

Серверная топология — IP-адреса, URL, порты, где что работает
Текущие пути — хост-пути и контейнерные пути
Состояние VM — что запущено, что остановлено, снапшоты
Состояние бэкапов — активные таймеры, снапшоты, пройден ли restore drill
Состояние MCP-моста — доступные инструменты, ограничения
Состояние веб-шеллов — какие активны, URL, tmux-сессии

Пример записи из SHARED_CONTEXT:

VM 102 hermes (.124): production, running.
VM 101 cosmos (.123): stopped, onboot=0.
host_exec_shell/host_read_file: removed 2026-06-11.

Агент, который прочитает этот файл, сразу поймёт: cosmos-сервер остановлен (не пытаться туда стучаться), опасные MCP-инструменты удалены (не пытаться их вызвать), production-среда на .124 (работать осторожно).

Правило: SHARED_CONTEXT обновляется ПОСЛЕ любого изменения архитектуры или конфигурации, а не «когда-нибудь потом». Если Claude Code изменил настройки MCP-моста — он обязан обновить SHARED_CONTEXT до того, как передаст эстафету.

Уровень 2: Structured Handoff (структурированная передача)

Когда один агент заканчивает этап работы и передаёт его другому — нужен шаблон. У меня это 50-agents/AGENT_HANDOFF.md.

Шаблон handoff-записи:

## YYYY-MM-DD HH:MM — От Agent1 → Agent2

Task:         что конкретно нужно сделать
Current state: что уже сделано, в каком состоянии система
Files/paths:   какие файлы затронуты, где искать
Verification:  как проверить, что работа сделана правильно
Open risks:    что может пойти не так, что неизвестно
Next action:   конкретный первый шаг для принимающего агента

Живой пример из моего vault — handoff от Claude (архитектор) к исполнителю Фазы 0.0:

## 2026-06-10 — От Claude → исполнителю Фазы 0.0

Task: Исполнять BRONEVIK_STACK_V2_ROADMAP. Начать с Фазы 0.0
(закрыть живые дыры на v1 ДО постройки v2).

Current state: v1 работает; host-аудит = 6/10;
vault сведён, устаревшие заметки обновлены.
YubiKey отложены владельцем — шаги с ключами пропускаем.

Next action: по чеклисту Фазы 0.0 — убрать host_exec_shell,
починить apt-репы, restore-drill, off-disk vzdump,
выключить cosmos, firewall. Снапшот перед каждым, отчёт на гейте.

Что даёт такая структура:

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

Правило: handoff-запись пишется передающим агентом ДО того как он завершил свою сессию. Принимающий агент читает её ПЕРВЫМ делом при старте.

Уровень 3: Vault Health (здоровье базы знаний)

Handoff работает только если vault живой. Битые ссылки, отсутствующий frontmatter, потерянные файлы — всё это ломает навигацию для агентов.

У меня vault проверяется командой:

bronevik-vault-status

Что проверяется:

Проверка	Почему важно
`git_dirty_count=0`	Все изменения закоммичены, нет «потерянных» правок
`obsidian_config=present`	`.obsidian` на месте — wikilinks работают
`missing_required_count=0`	Все обязательные заметки (SHARED_CONTEXT, AGENT_HANDOFF, HOME) существуют
`broken_wikilinks_count=0`	Ни одной битой ссылки — агент не попадёт в тупик
`missing_frontmatter_count=0`	У всех .md-файлов есть frontmatter — парсеры не ломаются
`secret_like_paths_count=0`	Секреты не просочились в vault

Эта проверка встроена в общий bronevik-status и запускается при каждом аудите.

Что было на практике:

После аварии с PCIe-райзером 11 июня 2026 (внезапное отключение питания) vault-статус показал git_dirty_count=1 — незакоммиченное изменение в SHARED_CONTEXT. Если бы я этого не заметил, следующий агент прочитал бы устаревшую версию контекста из git — без информации о том, что host_exec_shell уже удалён. Результат: агент попытался бы вызвать несуществующий инструмент и получил бы ошибку, которую не смог бы объяснить.

Синхронизация агентов: playbook

Рабочий цикл выглядит так. Это 40-playbooks/AGENT_SYNC_PLAYBOOK.md:

Перед работой

Прочитать 50-agents/SHARED_CONTEXT — понять текущее состояние сервера
Прочитать заметку своего агента в 50-agents/ — вспомнить свои правила и ограничения
Проверить активные проекты в 20-projects/ — не делает ли кто-то параллельно ту же работу
Просканировать vault через rg — не создавать дубликаты существующих заметок

Во время работы

Сырые материалы → 00-inbox/
Устойчивые факты → 30-wiki/
Повторяемые процедуры → 40-playbooks/
Handoff-записи → 50-agents/AGENT_HANDOFF.md
Ссылаться на существующие заметки вместо копирования текста

После работы

Обновить проектную заметку или создать decision note
Обновить SHARED_CONTEXT, если изменилась архитектура или конфигурация
Проверить доступность файлов из контейнера, если менялись пути
Запустить бэкап vault после существенных изменений

Почему один vault, а не отдельные базы для каждого агента

Было искушение сделать три отдельных Obsidian-хранилища: Hermes-vault, Codex-vault, Claude-vault. Но это создало бы больше проблем, чем решило:

Три источника правды. Какой vault правильный? Где актуальная версия SHARED_CONTEXT?
Wikilinks не работают между vault’ами. [[50-agents/AGENT_HANDOFF]] — это ссылка внутри одного vault. Между разными vault такой связи нет.
Дублирование. Одна и та же информация (архитектура, пути, решения) множится в трёх местах и расходится.
Ручная синхронизация. Без общей базы каждый handoff требовал бы ручного копирования контекста.

Решение: один vault, разделение по файлам и ответственности.

Агент-специфичные правила всё равно изолированы — в 50-agents/CLAUDE_CODE.md, 50-agents/CODEX.md, 50-agents/HERMES_AGENT.md. Но общий контекст — один на всех.

Что не надо хранить в vault

Важное правило безопасности, которое легко нарушить по невнимательности:

Никаких секретов в vault. Только пути, имена сервисов, описания архитектуры. Пароли, токены, API-ключи — никогда.

Почему: vault живёт в git, vault читается всеми агентами, vault может быть скопирован. Один restic-password в md-файле — и весь смысл шифрованных бэкапов теряется.

Проверка secret_like_paths_count в bronevik-vault-status ловит это автоматически. Если агент случайно записал что-то похожее на секрет — аудит покажет не ноль и это будет исправлено до того, как vault уйдёт в git.

Итог: три правила, которые спасают от хаоса

SHARED_CONTEXT — всегда актуальный. Обновил конфигурацию → обнови SHARED_CONTEXT. Не через час. Сейчас.
Handoff по шаблону. Task → Current state → Files → Risks → Next action. Без «разберись сам».
Vault health перед handoff. bronevik-vault-status должен быть зелёным. Битые ссылки и потерянный frontmatter — это сломанная навигация для следующего агента.

Типичные ошибки handoff (из реального опыта)

Теория — это хорошо, но вот конкретные грабли, на которые я наступил за две недели.

Ошибка 1: Handoff без verification

Claude Code передал задачу «починить apt-репы» агенту-исполнителю с пометкой Verification: проверить, что apt update работает. Агент выполнил apt update, получил 0 upgraded, отрапортовал «готово». Проблема: репы были починены только для amd64, а i386 — нет. Агент не проверил ВСЕ архитектуры.

Урок: в Verification пиши конкретные условия, а не общие фразы. Не «проверить что работает», а «проверить apt update для amd64 И i386 — оба должны вернуть 0 пакетов с ошибками».

Ошибка 2: Устаревший SHARED_CONTEXT

Codex обновил docker-compose, перезапустил контейнеры, но забыл обновить SHARED_CONTEXT. В нём осталась старая запись:

host_exec_shell/host_read_file: active (to be removed in Phase 0.0).

Следующий агент прочитал контекст, увидел «active» и попытался вызвать host_exec_shell — которого уже физически не было в MCP-мосте. Ошибка, потеря времени, ручная диагностика.

Урок: SHARED_CONTEXT должен обновляться в той же транзакции, что и само изменение. Никаких «обновлю потом».

Ошибка 3: Параллельная работа без координации

Два агента одновременно получили задачи, затрагивающие один и тот же docker-compose файл. Один правил волюмы для бэкапов, второй — переменные окружения для Telegram. Каждый сделал свою правку, но второй перезаписал файл поверх первого. Результат: правки одного агента потеряны.

Урок: перед началом работы с файлом — проверь 20-projects/, не ведётся ли там активная работа. Если да — либо дождись, либо согласуй через handoff.

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

Кроме bronevik-vault-status, в экосистеме есть ещё несколько проверок:

bronevik-status — полный аудит сервера, включает vault health как подсекцию == knowledge-vault ==
Git-хуки — vault живёт в git; каждый коммит триггерит проверку на secret-like строки
Backup timer — локальные и офсайт (Google Drive) бэкапы vault через restic + rclone. После каждого значимого изменения vault — snapshot
Agent bridge health — проверка, что все три агента (Hermes, Codex, Claude) видят vault и могут читать/писать

Все эти проверки работают автоматически. Если vault не в порядке — я узнаю об этом ДО того, как агент запнётся о битую ссылку.

Когда handoff не нужен

Важно понимать границы. Не каждая задача требует формального handoff:

Атомарные задачи — «проверь статус бэкапа», «обнови одну строку в конфиге». Делаются одним агентом за один заход.
Повторяющиеся cron-задачи — генерация статей, ежедневный дайджест. У них свой цикл, handoff не участвует.
Чисто информационные запросы — «какой IP у VM 102?». Прочитал SHARED_CONTEXT, ответил — всё.

Handoff нужен когда:

Один агент сделал анализ/аудит, а второй будет исполнять по результатам
Задача пересекает границы компетенций (Claude анализирует → Codex фиксит → Hermes деплоит)
Решение повлияет на общую архитектуру

Как это выглядит на сервере: один день из жизни

Чтобы не быть абстрактным — вот реальный сценарий за 11 июня 2026, день аварии с PCIe-райзером:

08:00 — Hermes запускает ежедневный bronevik-status. Vault health: overall=ok.
14:00 — Аварийное отключение питания. Сервер перезагружается. Docker-контейнеры поднимаются, но часть файлов могла повредиться.
14:15 — Hermes запускает аудит. Vault health показывает git_dirty_count=1 — незакоммиченные изменения в SHARED_CONTEXT.
14:20 — Hermes фиксит vault (коммит), обновляет SHARED_CONTEXT (VM cosmos всё ещё stopped), создаёт handoff-запись в AGENT_HANDOFF: «Требуется проверка целостности контейнеров после аварийного reboot».
14:30 — Codex читает handoff, аудитирует Docker-контейнеры, логи, волюмы.
15:00 — Codex завершает проверку, обновляет AGENT_HANDOFF: «Контейнеры целы, данные не повреждены. Рекомендация: усилить мониторинг питания».

Без handoff-дисциплины каждый агент действовал бы вслепую, а я бы узнал о проблеме только когда что-то сломалось.

Эти три правила превращают трёх независимых агентов в одну распределённую систему. Без них — это три изолированных бота, которые иногда пересекаются и ломают друг другу работу.

У меня на это ушло две недели проб и ошибок. Надеюсь, вам хватит этой статьи.