На Hacker News показали Kiso — open-source движок для публикации баз знаний в формате Open Knowledge Format (OKF). Идея проекта: держать один источник правды в Markdown-файлах, а затем собирать из него статический сайт, который удобен и людям, и AI-агентам.
Что именно делает Kiso
Согласно документации проекта, Kiso работает вокруг OKF bundle — набора Markdown-файлов, который остается основным источником данных. Инструмент не добавляет отдельную базу данных и не требует переносить знания в проприетарное хранилище.
CLI умеет как минимум две ключевые операции:
- check — проверяет Markdown-файлы в OKF-бандле, сообщает о структурных и форматных ошибках, а также предупреждает о битых ссылках;
- build — генерирует статический сайт в указанную директорию.
На выходе Kiso создает HTML-страницы, сохраняет исходные Markdown-файлы, добавляет llms.txt и sitemap.xml. Такой набор важен: HTML нужен для пользователей, Markdown и llms.txt — для более предсказуемого чтения агентами и LLM-инструментами, sitemap.xml — для индексации.
Как это предполагается использовать
Типовой сценарий выглядит просто: команда хранит документацию в репозитории, валидирует ее через kiso-cli check, затем собирает сайт командой kiso-cli build. Полученный каталог можно опубликовать как обычный статический сайт, например через GitHub Pages.
В документации также приведен пример GitHub Action: при push в репозиторий можно автоматически собирать OKF-бандл в готовый сайт. Это делает Kiso ближе к генераторам статических сайтов вроде Hugo, но с акцентом на формат базы знаний, пригодной для машинного чтения.
Конфигурация задается через .kiso/configuration.yaml. Там можно указать baseUrl, название сайта, язык, заголовок, описание, тему и правила игнорирования файлов, например drafts/ или private/.
Почему это интересно для AI-практики
Главная практическая ценность Kiso — попытка убрать разрыв между “документацией для людей” и “контекстом для агентов”. Сейчас компании часто держат знания в Notion, Confluence, GitHub Wiki, README, внутренних сайтах и отдельных RAG-пайплайнах. В результате агентам приходится читать не всегда структурированные или устаревшие источники.
Подход Kiso более прямолинеен: Markdown остается редактируемым источником, а публикация делает его доступным в нескольких формах. Это может быть полезно для внутренних handbook, документации продукта, onboarding-материалов, API-описаний и баз знаний, которые должны одновременно открываться в браузере и использоваться агентными workflow.
Ограничения и что пока не стоит додумывать
В HN-анонсе автор упоминает добавление MCP-сервера в последнем релизе. Однако в доступном фрагменте документации нет подробного описания возможностей MCP, схемы инструментов или примеров интеграции с клиентами. Поэтому пока корректнее говорить не о зрелой MCP-платформе, а о проекте, который движется в сторону агентного доступа к базе знаний.
Также Kiso не решает сам по себе вопросы качества контента, прав доступа, ревью изменений и актуальности документации. Если Markdown-файлы плохо поддерживаются, статическая сборка лишь аккуратно опубликует устаревшие данные. Для генерации превью-изображений в нативной сборке отдельно требуются rsvg-convert, inkscape или resvg.
Проект выглядит полезным как легковесный слой публикации поверх Git-репозитория. Но признаков широкой адаптации или производственных бенчмарков в источнике нет: HN-пост на момент сигнала был почти без обсуждения.
Источники