Что это решает
Знания компании обычно размазаны по головам, переписке и десятку документов в облаке, и отдать их ИИ-агенту нечем: он не умеет читать чужой чат и не имеет прав на корпоративный диск. Obsidian хранит заметки как обычные .md-файлы в обычной папке на диске — то, что агент читает напрямую, ищет grep-ом и правит теми же инструментами, что и исходный код. При этом человек продолжает работать в удобном редакторе со ссылками, поиском и обратными связями, а не в наборе текстовых файлов через блокнот.
Как устроено
Хранилище
Хранилище (vault) — папка. Внутри markdown-файлы, вложения и служебный каталог .obsidian с настройками, темой и плагинами. Отдельной базы данных нет: удалили приложение — файлы остались, открылись любым редактором. Из-за этого одна и та же папка доступна человеку, скрипту, системе контроля версий и агенту, и никому не нужен экспорт.
Связи
Запись [[Имя заметки]] создаёт вики-ссылку по имени файла с автодополнением при вводе. В целевой заметке появляется панель обратных ссылок — список того, что на неё ссылается. Переименование файла обновляет ссылки во всём хранилище. Теги через решётку дают второй, поперечный срез поверх папок. Граф связей рисуется автоматически.
Свойства заметки
В начале файла — блок YAML между тройными дефисами: тип заметки, статус, владелец, дата обновления, теги, источник. Машиночитаемая часть базы живёт здесь. По этим полям фильтруют и человек, и плагины, и агент; всё остальное в файле — свободный текст.
Организация
Папки по смыслу, заметка-оглавление на каждую большую тему, соглашение об именовании файлов. Для агента структура папок вторична, а критичны три вещи: один факт — одна заметка; в заголовке те слова, которыми этот факт будут спрашивать; во frontmatter дата обновления, чтобы отличать живое от протухшего.
Как в это входит агент
Три рабочих способа. Первый — прямой файловый доступ: агент читает, ищет и пишет в папке хранилища, как в любом каталоге проекта. Второй — репозиторий: хранилище лежит под контролем версий, агент коммитит правки, человек смотрит diff и откатывает лишнее. Третий — MCP-сервер поверх папки, который отдаёт агенту поиск и чтение как инструменты.
Поверх любого из них полезен слой подготовки контекста: перед ответом собрать в подсказку заметку-канон по теме плюс результаты поиска по ключевым словам вопроса. Качество ответа определяется тем, какие куски базы доехали до модели, а не тем, какая это модель.
Синхронизация
Подходит система контроля версий, встроенная синхронизация Obsidian или облачная папка. Правило одно: человек и агент не должны писать в один файл одновременно. Облачная папка на конфликте молча создаёт второй файл с пометкой о конфликте, и его никто не заметит; репозиторий даёт явный конфликт, который придётся разрешить руками.
Полезные сценарии
- Канон определений: одна заметка на метрику с формулировкой и готовым запросом, которую агент обязан прочитать перед любым расчётом.
- Журнал решений: что выбрали, что отклонили и почему — после этого агент перестаёт предлагать уже отвергнутое.
- Разборы инцидентов: симптом, причина, что починили, как проверить, что не вернулось.
- Онбординг: доступы, соглашения, кто за что отвечает — один источник для человека и для агента.
- Правила самого агента: тон, запреты, формат ответов — отдельным файлом в хранилище, а не в переписке.
- Черновики публикаций и заготовки писем со ссылками на исходные факты.
Ограничения
Прав доступа на отдельную заметку нет. Кто получил папку — получил всё содержимое. Персональные данные клиентов, пароли и токены в хранилище не кладут, и это ограничение не обходится настройками.
Markdown не заменяет базу данных: нет типов, уникальности, транзакций и целостности ссылок. Учёт клиентов, платежей и остатков живёт в таблице или в СУБД, а в заметках остаётся описание того, как этот учёт устроен.
Плагины работают внутри приложения, а не в файле. Запрос Dataview агенту виден как текст в кодовом блоке, а не как посчитанная таблица. Поэтому машиночитаемым должно быть frontmatter, а красивые сводки остаются человеку.
Объём даёт шум. Когда заметок много, поиск возвращает два десятка похожих файлов, и агент тащит в контекст всё подряд. Лечится не наведением порядка в папках, а слиянием близких заметок в одну и явными заголовками.
База гниёт. Агент, которому разрешено писать, за месяц наплодит дубликатов: та же мысль под другим названием. Помогает жёсткое правило в инструкции — сначала искать существующую заметку по ключевым словам, обновлять её, создавать новую только если ничего не нашлось.
Граф связей выглядит эффектно и почти не помогает в работе. Смотреть в него ради принятия решений смысла нет.
Как проверить результат
Слепой вопрос: спросить агента о том, ответ на что есть ровно в одной заметке, не подсказывая путь к файлу. Нашёл — сборка контекста работает; начал сочинять — проблема в поиске, а не в знании.
Поиск по словам пользователя: взять формулировку из реального вопроса и прогнать grep по хранилищу. Если заметка не находится теми словами, которыми её спрашивают, добавить эти слова в заголовок и первый абзац.
Битые ссылки: скрипт или плагин, сверяющий все [[...]] с именами существующих файлов. Ссылка в никуда означает либо переименование мимо приложения, либо заметку, которую собирались написать и забыли.
Валидность свойств: скрипт, разбирающий YAML во всех файлах и печатающий те, где блок сломан или отсутствует дата обновления. Такие заметки — первые кандидаты на разбор.
Свежесть: раз в квартал выгрузить список заметок, не обновлявшихся больше года, и по каждой решить — обновить, слить с соседней или удалить.
История правок: просмотр диффов за неделю показывает, что именно писал агент. Три новые заметки с почти одинаковыми названиями — сигнал чинить инструкцию, пока дубликатов не стало тридцать.