Когда ты запускаешь в работу команду автономных ИИ-агентов — например, терминального кодера Claude Code, системного оркестратора Hermes и несколько вспомогательных скриптов для сбора данных, — ты неизбежно сталкиваешься с явлением, которое исследователи называют «амнезией сессий» (Session Amnesia).
Каждый агент заперт в собственном контекстном окне. Ты можешь потратить два часа на то, чтобы объяснить Claude Code специфику сборки проекта под архитектуру ARM64. Агент найдет правильный флаг компилятора, исправит ошибку и закроет сессию. Но на следующий день агент Hermes столкнется с тем же самым багом — и будет заново набивать те же самые шишки, потому что между ними нет общей памяти.
Классический ответ корпораций — «прикрутите векторную базу данных и RAG». Но на практике векторный поиск часто превращается в непрозрачный черный ящик: эмбеддинги не понимают строгих хронологических связей, поиск по косинусному сходству часто выдает устаревшие обрывки, а человек-разработчик не может заглянуть внутрь и понять, почему агент принял то или иное решение.
Инженерное сообщество выработало альтернативный, поразительно элегантный архитектурный паттерн: использование локального хранилища Obsidian Vault в качестве общего «второго мозга» (Shared Cognitive Substrate) для разнородных агентов. Давай разберем, как устроена эта база знаний на тысячу связанных заметок.
Почему именно Markdown: прозрачность против черного ящика
Фундамент решения — отказ от проприетарных форматов в пользу плоских текстовых файлов Markdown (.md) с метаданными YAML frontmatter и двусторонними вики-ссылками [[Название заметки]].
В чем сила такого подхода?
- Единый источник истины (Single Source of Truth). Человек-оператор и любой ИИ-агент читают и пишут в одну и ту же файловую систему. Ты можешь открыть Obsidian, включить интерактивный граф связей и своими глазами увидеть паутину знаний: как решения по архитектуре связаны с профилями микросервисов и логами багов.
- Контроль человека (Human-in-the-loop). Если агент начал галлюцинировать и занес в память неверную команду, тебе не нужно переиндексировать векторную базу. Ты просто открываешь нужный файл в блокноте и правишь строчку руками.
- Кросс-платформенность без привязки к вендорам. Любой инструмент — будь то утилита
ripgrep, плагин Obsidian Local REST API или протокол Model Context Protocol (MCP) — может взаимодействовать с этой памятью без закрытых SDK.
Борьба с гонками: папка _inbox/ и регламент ночной уборки
Самый опасный сценарий в распределенной памяти — состояние гонки (Race Condition). Представь: два агента параллельно решают задачи и одновременно пытаются дописать новые факты в один и тот же файл Architecture.md. В результате один агент неизбежно затрет правки другого.
Чтобы исключить повреждение графа, в системе применяется двухуровневая архитектура записи:
- Изолированный буфер
_inbox/. Агентам категорически запрещено напрямую редактировать канонические узлы графа знаний. Когда агент узнает новый факт (например, фиксирует команду обхода бага в библиотеке), он создает отдельный атомарный файл во входящей директории с временной меткой:_inbox/2026-10-31-arm64-fix.md. Внутри заметки прописываются теги и ссылки на родительские сущности. - Ночной агент-консолидатор (Nightly Brain Sweep). Раз в сутки по расписанию (cron) запускается специализированный агент-уборщик. Он сканирует накопившиеся заметки во входящих, анализирует их контекст, обновляет канонические карточки компонентов, проставляет взаимные wikilinks и переносит обработанные черновики в архивную директорию.
Взгляни на минимальный скрипт консолидации на Python, автоматизирующий этот перенос:
import os
import glob
import datetime
VAULT_PATH = "./agent_vault"
INBOX_PATH = os.path.join(VAULT_PATH, "_inbox")
LOG_PATH = os.path.join(VAULT_PATH, "Daily_Logs")
def consolidate_inbox():
today_str = datetime.date.today().isoformat()
daily_file = os.path.join(LOG_PATH, f"{today_str}.md")
inbox_files = glob.glob(os.path.join(INBOX_PATH, "*.md"))
if not inbox_files:
return
with open(daily_file, "a", encoding="utf-8") as out_f:
out_f.write(f"\n\n## Ночная консолидация: {datetime.datetime.now().isoformat()}\n")
for fpath in inbox_files:
with open(fpath, "r", encoding="utf-8") as in_f:
content = in_f.read()
title = os.path.basename(fpath).replace(".md", "")
out_f.write(f"\n### Извлечено из [[{title}]]\n{content}\n")
os.rename(fpath, fpath.replace("_inbox", "_archive"))
Каноническая карточка: как агенты ориентируются в графе
Чтобы агенты мгновенно извлекали нужные сведения без чтения всего файла, во главе каждой заметки размещается строгий YAML-блок:
---
id: ent-agent-hermes
type: architecture-component
status: active
tags:
- AI
- ИИ-агенты
- Архитектура
updated_by: claude-code-worker-01
last_verified: 2026-10-30T22:15:00Z
related_nodes:
- "[[Hermes-Advanced-Delegation]]"
- "[[Model-Routing-Schema]]"
---
# Архитектура агента Hermes
Агент отвечает за терминальные операции и координацию подзадач.
Спецификация делегирования описана в [[Hermes-Advanced-Delegation]].
Благодаря такой структуре любой агент перед началом работы делает быстрый поиск по тегам или заголовкам YAML, подтягивая только актуальный срез данных.
Границы масштабирования: когда файлов становится слишком много
Пока база знаний насчитывает от одной до пяти тысяч заметок, текстовый поиск через grep или встроенный индекс Obsidian летает за миллисекунды.
Но если твоя агентная ферма генерирует сотни заметок в час и база переваливает за сто тысяч файлов, обычная файловая система начинает подтормаживать при сканировании каталогов. В этом случае поверх хранилища надстраивают легковесный индекс метаданных на SQLite или подключают полнотекстовый движок поиска вроде Tantivy.
Второй нюанс — дисциплина ссылок. Если человек вручную переименует файл через стандартный проводник Windows или macOS, а не внутри интерфейса Obsidian, старые wikilinks могут стать битыми. Чтобы избежать поломки связей, в ночной регламент агента обязательно включают регулярную проверку битых ссылок (linter).
Но как практичный, визуально прозрачный и полностью подконтрольный человеку фундамент памяти, граф Obsidian сегодня дает сто очков вперед любым сложным облачным векторным базам.