OpenLore

📜 OpenLore

При поддержке

Предоставляйте вашу документацию ИИ-агентам через SSH.

OpenLore — это минимальная, расширяемая, агент-ориентированная база знаний, которая поддерживает общий контекст актуальным и проверяемым.

---

О проекте

ИИ-агенты для написания кода уже умеют исследовать файлы с помощью ls, cat, grep, find, конвейеров и циклов оболочки. OpenLore предоставляет им тот же интерфейс через SSH, но на основе вашей документации, а не реальной машины.

Agent ──SSH or MCP──▶ OpenLore ──▶ docs, knowledge, and artifacts

Всё начинается с однобинарного, не требующего настройки, сервера документации в режиме только для чтения. Когда вам понадобится живая база знаний, вы можете добавить доступ с привязкой к личности, контролируемую публикацию, атомарные записи, валидацию и одобрение человеком — без изменения того, как агенты читают или перемещаются по содержимому.

Хранение и получение Markdown

Помещайте документацию, руководства, контекст проекта или заметки, созданные агентами, в обычные Markdown-файлы. Никакого конвейера импорта нет: укажите OpenLore на каталог, и он будет обслуживать существующую иерархию напрямую. Организуйте документы с помощью папок, связывайте их стандартными Markdown-ссылками и группируйте в наборы документов, когда разным людям или агентам нужен разный доступ. OpenLore по умолчанию работает только на чтение; включите запись, когда хотите, чтобы агенты также создавали и обновляли Markdown.

Быстрый старт

Самый быстрый путь — позволить вашему агенту настроить OpenLore:

# Teach your agent how to install, configure, and bundle OpenLore
ssh openlore.sh teach | your-agent-cli

# Add documentation access instructions to AGENTS.md
ssh openlore.sh agents >> AGENTS.md

Или установите и запустите его напрямую:

go install github.com/aakarim/go-openlore/cmd/openlore@latest

openlore ./docs

ssh -p 2222 localhost
ssh -p 2222 localhost "grep -r 'authentication' /docs"

По умолчанию запускается:

• SSH на localhost:2222
• веб-интерфейс для людей на http://localhost:8080
• MCP через HTTP на http://localhost:8080/mcp

См. Установка для других способов установки и упаковки OpenLore.

Возможности

• Агент-ориентированный поиск — Агенты используют инструменты оболочки и паттерны композиции, которые они уже понимают, вместо изучения специализированного API поиска.
• Единая поверхность знаний, несколько транспортов — Предоставляйте одну и ту же виртуальную файловую систему через SSH, SFTP/SSHFS, MCP и удобный для людей веб-интерфейс.
• Живые, управляемые знания — Держите контент в режиме только для чтения, разрешайте ограниченную публикацию или включайте полную запись для каждого набора документов. Записи атомарны, учитывают конфликты и могут требовать одобрения человека.
• Представления с привязкой к личности — Давайте каждому человеку или агенту только те наборы документов, которые ему нужны, с ролевыми ro, publish и rw разрешениями, псевдонимами путей и личными домашними каталогами.
• Безопасность по построению — Оболочка — это интерпретатор Go в памяти, а не реальная системная оболочка. Нет побега из оболочки, произвольного выполнения процессов или фонового сетевого доступа в обычном сеансе.
• Портативные пакеты знаний — Встраивайте документацию в автономный бинарный файл, создавайте кроссплатформенные пакеты с помощью GitHub Action или упаковывайте их как настольное MCP-расширение.
• Структурированные знания без нового языка запросов — Просматривайте frontmatter как NDJSON с помощью lore meta, запрашивайте его через jq и проверяйте пакеты Open Knowledge Format (OKF) Google и навыки агентов непосредственно у пути записи.
• Расширяемая политика и обработка — Плагины могут добавлять валидацию, разрешения, промежуточное ПО чтения/записи, метаданные и пост-коммитную обработку, сохраняя тот же файловый интерфейс.

Варианты использования

• Репозиторий непрерывного обучения — храните сеансы и наработки на одном общем сервере. Добавляйте метрики для оптимизации. Позволяйте агентам обмениваться наработками друг с другом, сохраняя изоляцию пользователей.
• Репозиторий артефактов команды — делитесь созданными документами Markdown, HTML, JSON, Excel и т. д., сохраняя контроль доступа. Гораздо естественнее, чем git, и более агент-ориентированно, чем Confluence/Notion.
• Документация для ИИ-агентов кода — размещайте внутреннюю документацию API, руководства, контекст продукта и заметки по архитектуре за знакомым, доступным для поиска интерфейсом.
• Общая живая память для команд агентов — давайте агентам отдельные или общие наборы документов, чтобы они могли публиковать результаты, передавать работу и накапливать устойчивый контекст между сеансами.
• Публичный сайт документации — добавляйте любые файлы в ваш публичный набор документов, включайте публичный доступ, и они будут показаны любому агенту, который наткнётся на ваш сайт. Улучшает AEO/GEO без необходимости редактировать существующую документацию.
• Обмен навыками — публикуйте навыки агентов в общих коллекциях, чтобы каждый авторизованный агент мог обнаруживать и использовать одни и те же управляемые процедуры.
• Репозиторий плагинов агентов — закрепляйте версии репозиториев Agent Plugins с GitHub и предоставляйте их агентам вашей команды. Навыки, упакованные в открытом стандарте, остаются актуальными автоматически.
• Управляемый вклад знаний — позволяйте участникам публиковать во входящие, reserving чувствительные пути для утверждающих и предотвращая случайные перезаписи.
• Удалённый просмотр артефактов агентов — предоставляйте отчёты, журналы, скриншоты и сгенерированные файлы через браузер или SSH без создания собственного просмотрщика артефактов или предоставления доступа к машине агента.
• Рабочие пространства с привязкой к личности — монтируйте личный домашний каталог для каждого агента плюс общие знания команды — всё через один сервер и одну модель авторизации.
• Портативные знания клиента или проекта — поставляйте версионируемый исполняемый файл с встроенной соответствующей документацией или распространяйте те же знания как настольное расширение MCPB.
• Проверенные каталоги знаний — применяйте соглашения о frontmatter и пакетах, экономно проверяйте метаданные и останавливайте некорректные знания на этапе приёма.

Как это работает

OpenLore построен на Wish для SSH-транспорта. Соединение обрабатывается полностью на виртуальной файловой системе:

1. Аутентификация — подключайтесь без ключа или сопоставьте SSH-ключ, сертификат, passkey или вход через OAuth с личностью.
2. Составление представления — монтируйте только те наборы документов и пути, которые разрешены этой личности.
3. Исследование — выполняйте команды оболочки, реализованные как чистые функции Go, в этом представлении или используйте эквивалентный MCP-инструмент shell.
4. Безопасный вклад — если запись включена, авторизуйте и проверяйте изменение всего файла перед атомарным коммитом или направлением на утверждение.

OAuth-клиенты используют делегированные личности, поэтому устойчивое происхождение записей различает прямую работу от имени adil и работу, выполненную как adil/claude@claude.ai. Делегаты не могут наследовать больше полномочий, чем их принципал, и могут быть ограничены списками запретов по наборам документов и возможностям. CIMD-клиенты могут дополнительно аутентифицироваться с помощью метаданных, размещённых у вендора, и private_key_jwt; см. Аутентифицированные OAuth-клиенты.

Обычная оболочка не может вызывать bash, exec, curl или произвольные процессы хоста. Встроенная документация всегда доступна только для чтения. Явно доверенным личностям может быть предоставлена узко ограниченная асинхронная обработка через возможность spawn.

Управляемая запись

OpenLore по умолчанию работает только на чтение. Развёртывания с записью сохраняют единый путь записи, управляемый политикой, для перенаправлений, добавления, tee, patch, sed -i, перемещения файлов, публикации и одобренных внешних заданий.

echo "# Research" | publish backend findings.md
cat change.diff | patch /backend/api.md
sed -i 's/old/new/g' /backend/runbook.md

Записи — это атомарные замены целых объектов. Защита сравнения-и-замены отклоняет устаревшие правки по умолчанию, разрешения набора документов ограничивают цель, а выбранные пути могут создавать проверяемые наборы изменений под /requests вместо прямого коммита.

См. Запись и публикация для настройки на уровне пользователя и Внутреннее устройство системы записи для модели реализации.

Установка

Установка с помощью Go

Требуется Go 1.26 или новее:

go install github.com/aakarim/go-openlore/cmd/openlore@latest

Сборка из исходного кода

git clone https://github.com/aakarim/go-openlore.git
cd go-openlore
go build -o openlore ./cmd/openlore

Встраивание документации в бинарный файл

Поместите документацию в assets/lore/ и выполните сборку. Полученный бинарный файл содержит документацию и предоставляет её в режиме только для чтения на /docs при запуске без аргумента каталога:

go build -o my-docs ./cmd/openlore

Сборка с помощью GitHub Action

Создавайте кроссплатформенные бинарные файлы со встроенной документацией:

- uses: aakarim/openlore@v1
  with:
    docs-dir: ./docs
    config: ./openlore.yml

См. Способы использования OpenLore для MCP stdio, настольной упаковки MCPB, SSHFS и использования Go-библиотеки.

Создание настраиваемого развёртывания

Используйте встроенный навык setup для создания <team>-lore — небольшого репозитория, принадлежащего клиенту, содержащего openlore.yml, тонкий Containerfile, закреплённый за официальным релизом OpenLore, и артефакты развёртывания. Он собирает работающий локальный сервер и проверяет HTTP, MCP, аутентифицированный SSH, запись и сохранность перед развёртыванием:

ssh openlore.sh setup | amp

Сгенерированный репозиторий хранит начальную политику lore.json и файлы, видимые через SSH, в gitignored-каталоге .local/. Первое развёртывание инициализирует пустой постоянный том из этого состояния. Корневой openlore.yml остаётся источником истины Git/IaC и развёртывается отдельно на /var/lib/openlore/config/openlore.yml; он не встраивается в образ. Последующие правки lore.json и файловой системы на сервере являются авторитетными и никогда не перезаписываются обновлениями образа.

Дополнительные команды инструкций поддерживают полный жизненный цикл:

• onboarding добавляет начальные личности, роли, домашние каталоги и папки локально;
• deploy выбирает Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean или настраиваемое развёртывание и проверяет общий контракт сохранности/сети;
• upgrade подготавливает только изменение версии закреплённого базового образа, чтобы существующий CD мог его развернуть.

Развёртывания у провайдеров требуют HTTPS/MCP, аутентифицированного OpenLore SSH, административного доступа к оболочке и постоянного тома /var/lib/openlore. Там, где провайдер это поддерживает, развёртывание настраивает публичный порт 22 для пересылки на порт OpenLore 2222. В противном случае оно сообщает назначенный порт и рекомендует внешнюю систему TCP-пересылки.

Опубликованный контейнер содержит только OpenLore. Он намеренно не содержит политики онбординга или конфигурации сервера. До запуска сервиса развёртывание должно поместить openlore.yml и lore.json в постоянный каталог конфигурации и выполнить:

./out --config /var/lib/openlore/config/openlore.yml

Это сохраняет конфигурацию независимо развёртываемой: простое развёртывание может скопировать openlore.yml на том, а Kubernetes может спроецировать тот же файл из ConfigMap. Используйте навык deploy для Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean или настраиваемой инфраструктуры. Файлы Railpack и Fly в репозитории обеспечивают образ, постоянный том и настройку портов; они не заполняют и не изменяют конфигурацию при запуске процесса.

Railway назначает своему SSH TCP-прокси публичное имя хоста и порт. Стандартный SSH-порт 22 требует внешнего raw TCP-балансировщика. Fly.io может сопоставить публичный порт 22 с внутренним портом OpenLore 2222 с выделенным адресом. Raw SSH не имеет маршрутизации по имени хоста или SNI, поэтому один слушатель не может маршрутизировать несколько доменов на порту 22.

Рабочий процесс контейнера публикует latest из main; релизы также публикуют VERSION, vVERSION, major и minor теги образов.

HTTP-загрузка во входящие

Настройте набор документов inbox и роль с её разрешением publish, затем создайте учётные данные для существующей личности (конфигурация сервера должна указывать auth_file, чтобы CLI мог их проверить):

openlore inbox token create --identity alice --label webhook --config openlore.yml
curl -H 'Authorization: Bearer olin_ID_SECRET' -H 'Content-Type: text/markdown' \
  --data-binary @note.md 'https://docs.example.com/inbox/docs?name=note.md'

POST /inbox/{docset} принимает bearer-учётные данные или HMAC точного тела с использованием X-OpenLore-Token-Id и X-OpenLore-Signature. OAuth-токены доступа используются только для POST/GET /inbox/tokens и DELETE /inbox/tokens/{id}; учётные данные входящих отдельные и отзываемые. См. Конфигурация и личность.

Документация

Руководство	Содержание
Способы использования OpenLore	SSH, MCP, веб, SSHFS, встраиваемые бинарные файлы, GitHub Action, MCPB и использование в качестве библиотеки
Справочник команд	Полный справочник по shell, интроспекции, публикации, синтаксису, CLI-командам и флагам
Конфигурация и идентичность	openlore.yml, аутентификация, роли, docsets, алиасы, homes и проверка хоста
Федерация идентичности рабочих нагрузок	Аутентификация CI и агентов с помощью кратковременных внешних токенов идентичности
Написание и публикация	Режимы записи, входящие, обработка конфликтов, одобрения и задания
Плагины и форматы знаний	Установка плагинов, интерфейсы, проверка OKF, lore validate и lore meta
Внутренности системы записи	Слои файловой системы, шов записи, changesets, хуки и асинхронные задания
Оценка безопасности	Модель угроз и свойства безопасности

Безопасность

• Команды выполняются в интерпретаторе на чистом Go, а не через os/exec.
• Виртуальная файловая система очищает пути и обеспечивает соблюдение границ docset.
• Разрешенные шаблоны файлов и игнорируемые каталоги не допускают секреты в поле зрения.
• RBAC управляет чтением, публикацией, записью, одобрениями и доверенными возможностями.
• Веб-конечная точка может публиковать SSH-ключ хоста через TLS, чтобы избежать слепого доверия при первом использовании; также поддерживаются SSH-сертификаты пользователей и хостов.

См. SECURITY.md для полной оценки безопасности.

Лицензия

MIT — Адиль Карим

OpenLore включает сторонние компоненты с открытым исходным кодом. Их лицензии и необходимые уведомления перечислены в assets/legal/THIRD_PARTY_NOTICES.md, с полными текстами лицензий в assets/legal/licenses/. Они встроены в бинарный файл и предоставляются работающим сервисом по адресу /legal.