Возможно, вы уже держите что-то вроде вики внутри своей базы знаний — набор связанных markdown-файлов, по которым ходит ваш агент. Такой подход популяризировал Андрей Карпаты.
У нас около десятка репозиториев такого типа. Каждый раз, когда заводишь новый репозиторий, структуру придумываешь заново. Агенту же не скажешь «веди базу знаний правильно» — он не знает, как её раскладывать. При этом некие логичные правила как лучше, вообще-то существуют.
Недавно такой стандарт сделал Google. Называется OKF (Open Knowledge Format). Идея простая: договориться, как раскладывать markdown-базу знаний, чтобы её понимал любой агент. Как разложены файлы и папки, какие поля в шапке (frontmatter) у каждой страницы.
Frontmatter — это просто несколько строк в самом верху файла, между двумя
---, куда пишешь метаданные о странице: что это такое, теги, дата, связи с другими страницами. Формат — обычный YAML, поле: значение. Человек их читает как заголовок, а агент — как структурированные данные, по которым можно фильтровать и собирать. Выглядит так:---
type: проект
статус: в работе
теги: [клиент, ai-трансформация]
---
Правда формат довольно куцый пока. В текущей версии 0.1 обязательное поле там ровно одно —
type (что это за страница: концепт, человек, проект, требование…), остальное по желанию. Из явных плюсов, которые мы ощутили — единый источник правды через тот самый frontmatter. Смотрите: раньше как — есть, например, карточки проектов, и отдельно ведёшь табличку-реестр со статусами. Сдвинулся проект — нужно править в двух местах - в проекте и реестре, и рано или поздно они разъезжаются. А с OKF статус лежит в шапке самого файла, и отдельный реестр просто не нужен — он поднимается из этих шапок сам за секунду. Одна правда.
Если хотите пощупать — вот спека: github.com/GoogleCloudPlatform/knowledge-catalog. Проще всего так: киньте её своему агенту и попросите сделать аудит вашей базы на соответствие — где вы уже сходитесь со стандартом, а где стоит подправить.
