Урок 13.6. EverOS: local-first memory runtime с Markdown как source of truth

План лекции

Сначала мы разберем, почему EverOS называет себя portable memory layer and local-first memory runtime, а не просто библиотекой для retrieval. Затем рассмотрим его главный architectural choice: Markdown files как canonical source of truth, а SQLite and LanceDB как локальные индексы для поиска.

После этого разберем user tracks, agent tracks, knowledge wiki, orthogonal retrieval, reflection and API loop. В конце сравним EverOS с memU, Supermemory and Cognee, обсудим self-hosting implications and составим checklist для оценки local-first memory runtime.

Цель лекции

Понять EverOS как open-source memory runtime, который делает память агента readable, editable, local-first and portable across apps, agents, devices and workflows.

Ожидаемый результат

После лекции читатель понимает:

почему Markdown source of truth меняет свойства memory layer;
как SQLite and LanceDB дополняют Markdown;
чем user tracks отличаются от agent tracks;
зачем нужны user_id, agent_id, app_id, project_id, session_id;
где EverOS подходит лучше, чем hosted memory API;
какие production risks есть у local-first memory.

Короткая карточка инструмента

Поле	Значение
Repository	https://github.com/EverMind-AI/EverOS
Website	https://evermind.ai/everos
Docs entry	https://github.com/EverMind-AI/EverOS/tree/main/docs
Stars snapshot	около 11.9k на 2026-08-08 по GitHub page
Primary language	Python
License	Apache-2.0
Category	Local-first memory runtime
Storage model	Markdown + SQLite + LanceDB
API	`/api/v2/memory/add`, `/flush`, `/search` style loop

EverOS описывает себя как Python library and local-first memory runtime for agents and makers. Его основное обещание: one portable memory layer across coding assistants, apps, devices and workflows.

Для курса EverOS важен как пример memory architecture, где source of truth остается человеком-читаемым. Это не только инженерная деталь, но и философия ownership.

Главная идея: Markdown как canonical memory

Большинство memory tools хранит truth в базе:

database rows
vector index
graph nodes
dashboard state
API records

EverOS выбирает другой центр:

Markdown files are source of truth.
Indexes are derived.

Это означает, что память можно:

открыть обычным editor;
прочитать без server;
diff через Git;
редактировать напрямую;
переносить между машинами;
backup как обычные файлы;
review через pull request.

Такой подход особенно ценен для personal memory, research memory and coding workflows, где прозрачность важнее абсолютной скрытой автоматизации.

Базовая архитектура

EverOS можно описать как трехчастный локальный stack:

flowchart TD MD[Markdown source files] --> W[Watcher and sync] W --> SQL[(SQLite metadata)] W --> VEC[(LanceDB vector index)] API[Memory API] --> ADD[Add conversation or files] ADD --> MD API --> FLUSH[Flush and extract] FLUSH --> W Q[Search query] --> RET[Recall flow] RET --> SQL RET --> VEC RET --> MD RET --> CTX[Source-backed context]

Markdown хранит смысл. SQLite хранит metadata, ownership, identifiers, sync state and structured lookup. LanceDB хранит vector index for fast semantic retrieval.

Такое разделение полезно: database acceleration не становится lock-in для знания. Если индекс сломался, source files остаются.

Почему local-first

Local-first не означает "без сервера вообще". Это означает, что пользователь может иметь полноценный memory runtime на своей машине, а локальные файлы and indexes не являются временным cache hosted service.

Преимущества:

больше контроля над данными;
проще inspect and backup;
ниже latency for local workflows;
можно работать с coding agents без обязательного cloud;
легче встроить Git-versioned memory.

Ограничения:

нужно управлять локальными зависимостями;
нужны provider keys для реального LLM/embedding flow;
синхронизация между devices становится отдельной задачей;
локальные файлы надо защищать;
index consistency нужно мониторить.

EverOS удобно обсуждать как компромисс: меньше black box, больше responsibility у владельца среды.

User tracks and agent tracks

README EverOS выделяет user + agent tracks as first-class surfaces:

Track	Что хранит
User `episodes/profile`	User memories, preferences, life/project facts, personal context.
Agent `cases/skills`	Agent trajectories, solved cases, reusable skills and workflow improvements.

Это важное разделение. User memory and agent memory часто смешивают, но они отвечают на разные вопросы.

User memory:

Кто пользователь? Что для него важно? Какой у него контекст?

Agent memory:

Что агент уже научился делать? Какие cases and skills стоит повторять?

Если их не разделять, агент может воспринимать свой internal workaround как preference пользователя or наоборот.

Orthogonal retrieval

EverOS заявляет search by user_id, agent_id, app_id, project_id, and session_id. Это называется orthogonal retrieval: память можно срезать по нескольким независимым измерениям.

flowchart LR Q[Query] --> F[Filters] F --> U[user_id] F --> A[agent_id] F --> APP[app_id] F --> P[project_id] F --> S[session_id] U --> R[Recall] A --> R APP --> R P --> R S --> R

Для production systems это полезно потому, что scope редко одномерен. Например, один пользователь работает в нескольких apps, один agent обслуживает несколько projects, один project имеет много sessions.

Orthogonal retrieval снижает риск смешивания context and делает память гибче.

Knowledge Wiki

EverOS включает Knowledge Wiki: editable, source-backed Markdown knowledge pages with taxonomy, CRUD APIs and topic search.

Это близко к идее world memory, но с local-first формой. Knowledge base не прячется только в векторном индексе; ее можно редактировать как wiki.

Пример:

~/.everos/
  users/
    alice/
      profile.md
      episodes/
  agents/
    code-agent/
      skills/
      cases/
  wiki/
    projects/
    products/
    policies/

Даже если конкретная структура в проекте меняется, mental model остается полезной: source-backed wiki makes memory inspectable.

Reflection and self-evolving memory

EverOS README подчеркивает offline memory evolution: merge episode clusters and refine profiles and skills between sessions.

Это reflection memory. Агент или runtime не просто вспоминает past events, а перерабатывает их:

группирует похожие episodes;
обновляет profile;
уточняет skills;
удаляет noise;
связывает cases;
повышает качество будущего recall.

flowchart TD E1[Episode 1] --> CL[Cluster similar episodes] E2[Episode 2] --> CL E3[Episode 3] --> CL CL --> RF[Reflect] RF --> PR[Refined profile] RF --> SK[Updated skills] RF --> WK[Wiki updates]

Важно, что reflection between sessions снижает latency во время ответа. Тяжелая переработка памяти может происходить offline.

API loop

Quickstart EverOS показывает core loop:

Start server.
Add conversation через /api/v2/memory/add.
Force extraction через /api/v2/memory/flush.
Search через /api/v2/memory/search.
Inspect generated Markdown files.

Для архитектора это полезная последовательность:

ingest -> durable source -> extraction/index sync -> search -> source proof

В production важно сохранять этот proof loop. Если search возвращает result, команда должна иметь возможность открыть source Markdown and понять, почему этот context появился.

Multimodal ingestion

EverOS поддерживает optional multimodal ingestion for image, PDF, audio and office documents через extra dependencies. README упоминает parser pipeline and LibreOffice requirement for office conversion.

Для курса это хороший reminder: memory layer часто начинается с text conversations, но быстро доходит до файлов.

Multimodal memory усложняет:

parsing;
provenance;
storage size;
privacy;
source attribution;
re-indexing;
evaluation.

Если вы добавляете PDFs or office docs в memory, обязательно храните source references and extraction metadata. Иначе retrieval станет трудно проверять.

Мини-кейс: local memory для coding assistant

Допустим, разработчик использует разные coding assistants на одном проекте. Ему нужна память:

project conventions;
решения прошлых bugs;
команды проверки;
стиль общения;
failed attempts;
reusable coding skills.

EverOS может хранить это в Markdown and index locally.

sequenceDiagram participant Agent participant EverOS participant Files as Markdown files participant Index as SQLite and LanceDB Agent->>EverOS: add session messages EverOS->>Files: write source memory EverOS->>Index: sync metadata and vectors Agent->>EverOS: search before next task EverOS->>Files: read source proof EverOS-->>Agent: relevant context

Пользователь может открыть generated Markdown and поправить skill manually. Это сильное свойство для engineering teams.

Мини-кейс: research assistant

Research memory часто требует source-backed notes. Исследователь хочет не просто получить "похожий chunk", а понять:

где был источник;
как заметка связана с темой;
когда была сделана;
какой вывод был промежуточным;
какие гипотезы устарели.

EverOS-like Markdown wiki хорошо подходит для такого workflow. Векторный поиск помогает найти relevant notes, а Markdown дает readable context and provenance.

Сравнение с memU

Критерий	memU	EverOS
Главный объект	Reusable Markdown skills from agent history	Portable memory runtime with Markdown source
Integration style	Host adapters for desktop/coding agents	Server/API, CLI, local runtime, apps
Source of truth	Skill Markdown in shared store	Broader Markdown memory/wiki/cases/profiles
Indexes	SQLite/Postgres plus embeddings depending setup	SQLite + LanceDB local stack
Scope	Across agents/devices via backend	user/agent/app/project/session dimensions
Reflection	Agent-driven skill extraction	Offline memory evolution and profile/skill refinement

memU уже и более focused: он решает задачу learned skills across agents. EverOS шире: он пытается быть local memory OS для разных apps and workflows.

Сравнение с Supermemory and Cognee

Supermemory дает productized memory/context API with user profiles, connectors and hybrid search. Он удобен, когда команда хочет быстро встроить memory в AI product.

Cognee строит graph-first memory platform with relational, vector and graph stores. Он силен там, где важны entities and relationships.

EverOS занимает другую позицию:

readable Markdown first;
local ownership;
direct file editing;
user and agent tracks;
source-backed wiki;
portable runtime.

Если ваша главная ценность - inspectability and user-owned memory, EverOS заслуживает отдельного внимания.

Риски и ограничения

Первый риск - локальная операционка памяти требует обслуживания. Индексы нужно пересоздавать, backups настраивать, provider keys защищать.

Второй риск - Markdown editing can break structure. Если пользователь руками меняет файлы, watcher and parser должны корректно реагировать.

Третий риск - sync conflicts. Как только появляются несколько devices, Git or cloud sync, конфликтующие edits становятся реальной проблемой.

Четвертый риск - false sense of privacy. Storage может быть локальным, но LLM, embedding or rerank providers могут быть external.

Пятый риск - API stability. README указывает, что /api/v1 legacy alias может быть removed in future major release, поэтому новые integrations should use /api/v2.

Как тестировать EverOS

Тест	Что проверяет
Source write	Создается ли читаемый Markdown after add/flush.
Index sync	Попадает ли memory в SQLite/LanceDB search.
Source proof	Можно ли открыть источник returned result.
Direct edit	Подхватывает ли watcher ручные изменения Markdown.
Scope filters	Работают ли user/app/project/session filters.
Reflection	Улучшаются ли profiles/skills after offline evolution.
Provider boundary	Понятно ли, какие данные уходят в external APIs.
Rebuild index	Можно ли восстановить индекс из Markdown source.

Самый важный тест для Markdown-first systems: удалить derived indexes and восстановить их from source. Если это невозможно, Markdown не является настоящим source of truth.

Практический rollout

Начните с локальной demo without API keys, чтобы понять lifecycle visually. Затем поднимите server-backed flow and сохраните одну простую memory. Проверьте generated Markdown manually.

После этого добавьте scope: user, app, project. Только затем подключайте real agent. Если сразу пустить EverOS на все conversations and files, вы получите много memory noise before understanding structure.

Для команды полезно вести memory repo separately and version it. Тогда changes in memory become reviewable artifacts.

Антипаттерны

Первый антипаттерн - считать Markdown только export format. В EverOS смысл в том, что Markdown является primary source, а не отчетом из базы.

Второй антипаттерн - не проектировать taxonomy. Если user/project/session identifiers хаотичны, retrieval станет непредсказуемым.

Третий антипаттерн - включить multimodal ingestion без provenance. Для файлов source proof критичен.

Четвертый антипаттерн - забыть про index rebuild. Local-first architecture должна переживать corrupted derived storage.

Чек-лист выбора EverOS

EverOS стоит рассмотреть, если:

нужна user-owned memory;
важно читать and редактировать memory вручную;
команда хочет Git-versioned memory artifacts;
агент работает across apps and projects;
нужны separate user and agent tracks;
важна local-first философия;
source proof важнее dashboard convenience.

Если нужен hosted API with connectors, Supermemory может быть проще. Если нужен knowledge graph over enterprise documents, Cognee может быть ближе. Если нужен focused skill extraction for coding agents, memU может быть легче.

Источники

GitHub repository: https://github.com/EverMind-AI/EverOS
README: https://github.com/EverMind-AI/EverOS/blob/main/README.md
EverMind site: https://evermind.ai/
Documentation directory: https://github.com/EverMind-AI/EverOS/tree/main/docs
Quickstart: https://github.com/EverMind-AI/EverOS/blob/main/QUICKSTART.md

Краткое резюме

EverOS показывает local-first, Markdown-native approach to agent memory. Его ключевой урок: память может быть не закрытой базой, а набором readable, editable and versionable source files, поверх которых строятся быстрые индексы.

В архитектурном смысле EverOS соединяет user memory, agent memory, knowledge wiki, reflection and retrieval. Это хороший вариант для задач, где ownership, portability and source proof важны не меньше, чем recall quality.

Вопросы для самопроверки

Почему Markdown source of truth отличается от database-first memory?
Зачем EverOS использует SQLite and LanceDB рядом с Markdown?
Чем user tracks отличаются от agent tracks?
Что означает orthogonal retrieval?
Почему local-first не всегда означает fully private?
Какие проблемы возникают при direct file editing?
Когда EverOS лучше memU?
Как проверить, что индекс можно восстановить из source files?

Что дальше

В следующей лекции мы разберем Honcho - инструмент с другим акцентом: память как representation of user and relationships, подходящая для social, companion and collaborative agents.