From 06fc195325302215fe3e0c0202f1cc75601b6974 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 09:02:09 +0800 Subject: [PATCH 01/10] docs: explain upcoming knowledge wiki and reflection --- README.md | 44 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index f22d960f3..e63f2ac11 100644 --- a/README.md +++ b/README.md @@ -22,6 +22,7 @@
- [EverOS 1.0.0 Highlights](#everos-100-highlights) +- [Coming Next: Knowledge Wiki And Reflection](#coming-next-knowledge-wiki-and-reflection) - [Why EverOS](#why-everos) - [Quick Start](#quick-start) - [Architecture At A Glance](#architecture-at-a-glance) @@ -49,7 +50,7 @@ > through [EverAlgo](https://github.com/EverMind-AI/EverAlgo). > > **Watch this repository** for the next wave of memory-system work, including -> Wiki-style knowledge layers and Dreaming for deeper offline evolution. +> Knowledge Wiki and Dreaming / Reflection for deeper offline evolution. @@ -94,6 +95,41 @@ Search independently by user_id, agent_id,
+## Coming Next: Knowledge Wiki And Reflection + +Knowledge Wiki and Dreaming / Reflection are the next big EverOS features. +They extend EverOS from long-term retrieval into an inspectable memory workspace +that agents and humans can both improve. + + + + + + +
+Knowledge Wiki
+
+Knowledge Wiki turns scattered episodes, files, facts, and agent traces into +source-backed Markdown pages for people, projects, topics, decisions, and +workflows. Instead of hiding memory behind vectors, EverOS will expose a +wiki-like knowledge layer that users can read, correct, link, version, and open +directly in their existing Markdown tools. +		 +Dreaming / Reflection
+
+Dreaming, exposed as Reflection, is the offline evolution loop. It revisits +stored memory between active sessions, connects weak signals, compresses noisy +history into durable patterns, updates profiles and skills, and prepares better +future context. The goal is an agent that improves while you are away, not only +while you are prompting it. +
+ +Most memory systems stop at chat history, opaque profiles, or vector recall. +EverOS differentiates itself by keeping memory local, Markdown-native, +auditable, and self-evolving: raw memory stays readable, derived knowledge +becomes a wiki, and offline Reflection turns repeated experience into more +useful long-term behavior. +
@@ -665,9 +701,9 @@ Explore stored entities and relationships in a graph interface. Frontend demo; b ## Watch EverOS EverOS 1.0.0 is the first release of a larger memory-system roadmap. -Watch this repository for upcoming work on Wiki-style memory, Dreaming, -deeper offline evolution, benchmark releases, and more real-world agent -integrations. +Watch this repository for upcoming work on Knowledge Wiki, Dreaming / +Reflection, deeper offline evolution, benchmark releases, and more real-world +agent integrations. If EverOS is useful to your agent stack, starring the repo helps more builders discover it. From 0b7fd0e966672df4b9cf08f48c2f3c9b280ed14f Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 09:17:46 +0800 Subject: [PATCH 02/10] docs: tighten roadmap summary in readmes --- README.md | 72 +++++++++++++++++++++---------------------------- README.zh-CN.md | 33 +++++++++++++++++++---- 2 files changed, 59 insertions(+), 46 deletions(-) diff --git a/README.md b/README.md index e63f2ac11..d616c5520 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,6 @@
- [EverOS 1.0.0 Highlights](#everos-100-highlights) -- [Coming Next: Knowledge Wiki And Reflection](#coming-next-knowledge-wiki-and-reflection) - [Why EverOS](#why-everos) - [Quick Start](#quick-start) - [Architecture At A Glance](#architecture-at-a-glance) @@ -49,8 +48,10 @@ > multimodal ingestion, user and agent memory scopes, and modular algorithms > through [EverAlgo](https://github.com/EverMind-AI/EverAlgo). > -> **Watch this repository** for the next wave of memory-system work, including -> Knowledge Wiki and Dreaming / Reflection for deeper offline evolution. +> **Coming next:** Knowledge Wiki will turn memory into editable, +> source-backed Markdown knowledge pages. Reflection, also called Dreaming, +> will run offline to connect signals, compress history, and improve profiles +> and skills between sessions. @@ -95,41 +96,6 @@ Search independently by user_id, agent_id,
-## Coming Next: Knowledge Wiki And Reflection - -Knowledge Wiki and Dreaming / Reflection are the next big EverOS features. -They extend EverOS from long-term retrieval into an inspectable memory workspace -that agents and humans can both improve. - - - - - - -
-Knowledge Wiki
-
-Knowledge Wiki turns scattered episodes, files, facts, and agent traces into -source-backed Markdown pages for people, projects, topics, decisions, and -workflows. Instead of hiding memory behind vectors, EverOS will expose a -wiki-like knowledge layer that users can read, correct, link, version, and open -directly in their existing Markdown tools. -		 -Dreaming / Reflection
-
-Dreaming, exposed as Reflection, is the offline evolution loop. It revisits -stored memory between active sessions, connects weak signals, compresses noisy -history into durable patterns, updates profiles and skills, and prepares better -future context. The goal is an agent that improves while you are away, not only -while you are prompting it. -
- -Most memory systems stop at chat history, opaque profiles, or vector recall. -EverOS differentiates itself by keeping memory local, Markdown-native, -auditable, and self-evolving: raw memory stays readable, derived knowledge -becomes a wiki, and offline Reflection turns repeated experience into more -useful long-term behavior. -
@@ -701,9 +667,33 @@ Explore stored entities and relationships in a graph interface. Frontend demo; b ## Watch EverOS EverOS 1.0.0 is the first release of a larger memory-system roadmap. -Watch this repository for upcoming work on Knowledge Wiki, Dreaming / -Reflection, deeper offline evolution, benchmark releases, and more real-world -agent integrations. +Watch this repository for upcoming work on deeper offline evolution, benchmark +releases, and more real-world agent integrations. + + + + + + +
+Knowledge Wiki
+
+Turns scattered episodes, files, facts, and agent traces into source-backed +Markdown pages for people, projects, topics, decisions, and workflows. Memory +becomes something users can read, correct, link, version, and open in their +existing Markdown tools. +		 +Dreaming / Reflection
+
+Runs offline between active sessions to revisit stored memory, connect weak +signals, compress noisy history into durable patterns, and improve profiles and +skills. The agent gets better while you are away, not only while you prompt it. +
+ +Most memory systems stop at chat history, opaque profiles, or vector recall. +EverOS keeps memory local, Markdown-native, auditable, and self-evolving: raw +memory stays readable, derived knowledge becomes a wiki, and Reflection turns +repeated experience into more useful long-term behavior. If EverOS is useful to your agent stack, starring the repo helps more builders discover it. diff --git a/README.zh-CN.md b/README.zh-CN.md index 1a382d599..107342752 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -1,6 +1,6 @@
-![EverOS banner](https://github.com/EverMind-AI/EverOS/releases/download/v1.0.0/everos-readme-banner-optimized.jpg) +![EverOS banner](https://github.com/user-attachments/assets/8e217d39-5d15-4c6c-9b54-3e83add4e0f2)

X @@ -48,8 +48,9 @@ > 多模态摄取、用户记忆与 Agent 记忆作用域，以及由 > [EverAlgo](https://github.com/EverMind-AI/EverAlgo) 支撑的模块化算法。 > -> **欢迎 Watch 这个仓库。** 下一阶段我们会继续推进记忆系统方法， -> 包括 Wiki 式知识层和用于更深层离线进化的 Dreaming。 +> **即将推出：** Knowledge Wiki 会把记忆整理成可编辑、可溯源的 +> Markdown 知识页。Reflection（也称 Dreaming）会在离线时连接信号、 +> 压缩历史，并持续改进 profile 和 skills。 @@ -651,8 +652,30 @@ Claude Code 的持久记忆插件。自动保存并回忆过去 coding sessions ## 关注 EverOS EverOS 1.0.0 是更大规模记忆系统路线图的第一个发布版本。Watch 这个仓库， -即可持续关注 Wiki 式记忆、Dreaming、更深入的离线进化、benchmark releases， -以及更多真实 Agent 集成。 +即可持续关注更深入的离线进化、benchmark releases，以及更多真实 Agent 集成。 + +
+ + + + +
+Knowledge Wiki
+
+把分散的 episodes、files、facts 和 Agent traces 整理成有来源的 Markdown +知识页，覆盖 people、projects、topics、decisions 和 workflows。记忆不再只是 +向量召回结果，而是用户可以阅读、修正、链接、版本化，并用现有 Markdown 工具打开的知识层。 +		 +Dreaming / Reflection
+
+在活跃会话之间离线运行，重新审视已存储记忆，连接弱信号，把嘈杂历史压缩成稳定模式， +并持续改进 profile 和 skills。目标是让 Agent 在你离开时也能变得更好， +而不是只在你 prompt 它时才进步。 +
+ +许多记忆系统停留在聊天历史、黑盒 profile 或向量召回。EverOS 的差异在于： +记忆保持本地、Markdown-native、可审计、可自进化；原始记忆仍然可读， +衍生知识沉淀为 wiki，Reflection 则把重复经验转化为更有用的长期行为。 如果 EverOS 对你的 Agent stack 有帮助，Star 这个仓库也会帮助更多 builders 发现它。 From 3ceb528a9c3964016e643012455694c93c1d84e1 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 10:06:55 +0800 Subject: [PATCH 03/10] docs: add memory library comparison table --- README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ README.zh-CN.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 110 insertions(+) diff --git a/README.md b/README.md index d616c5520..bcf285893 100644 --- a/README.md +++ b/README.md @@ -23,6 +23,7 @@ - [EverOS 1.0.0 Highlights](#everos-100-highlights) - [Why EverOS](#why-everos) +- [How EverOS Is Different](#how-everos-is-different) - [Quick Start](#quick-start) - [Architecture At A Glance](#architecture-at-a-glance) - [Storage Layout](#storage-layout) @@ -131,6 +132,60 @@ The system is built around three boundaries:

+## How EverOS Is Different + +Most memory libraries are useful, but many optimize for managed APIs, vector or +graph recall, or one narrow memory surface. EverOS is built as a local, +inspectable memory workspace for both agents and people. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Developer needEverOSCommon memory-library default
Readable source of truth✅ Markdown files are the canonical memory surface. Open them in Obsidian, review diffs, or version them with Git.❌ Memory usually lives behind APIs, dashboards, vector stores, graphs, or backend payloads.
Simple local runtime✅ Markdown + SQLite + LanceDB keep content, state, BM25, vectors, and scalar filters local.❌ Many systems center on managed services, vector DBs, graph DBs, or pluggable backend services.
Human-editable memory✅ Edit a .md file directly; the cascade watcher diffs entries and syncs derived indexes.❌ Memory updates usually go through an SDK, API, dashboard, or storage backend.
User and agent tracks✅ User memory (episodes / profile) and agent memory (cases / skills) are first-class.❌ Most systems focus on chat history, profiles, graph facts, or retrieval records rather than both tracks.
Portable scopes✅ Search orthogonally by user_id, agent_id, app_id, project_id, and session_id.❌ Scope is often centered on one app, thread, tenant, or custom schema.
Auditable evolution✅ Repeated experience becomes reusable skills while raw memory remains editable Markdown; Knowledge Wiki and Reflection keep evolution inspectable.❌ Evolution, when available, usually happens inside service state, graphs, or dashboards rather than editable source files.
+ +Comparison is about default product posture across public memory-library repos, not every optional backend or deployment mode. + +
+
+ +[![](https://img.shields.io/badge/-Back_to_top-gray?style=flat-square)](#readme-top) + +
+ + ## Quick Start ### 1. Install EverOS diff --git a/README.zh-CN.md b/README.zh-CN.md index 107342752..21dda7502 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -23,6 +23,7 @@ - [EverOS 1.0.0 亮点](#everos-100-亮点) - [为什么选择 EverOS](#为什么选择-everos) +- [EverOS 的差异](#everos-的差异) - [快速开始](#快速开始) - [架构概览](#架构概览) - [存储布局](#存储布局) @@ -122,6 +123,60 @@ EverOS 会把对话、Agent 轨迹和文件保存为可读 Markdown，并同步
+## EverOS 的差异 + +许多 memory libraries 都有价值，但它们通常围绕 managed API、向量 / 图召回， +或某一种单一记忆形态来设计。EverOS 的定位是一个面向 Agent 和人的本地、 +可检查记忆工作区。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
开发者关心什么EverOS常见 memory-library 默认形态
可读的 source of truth✅ Markdown 文件就是标准记忆表面。可以用 Obsidian 打开、review diff，也可以用 Git 版本化。❌ 记忆通常藏在 API、dashboard、vector store、graph 或后端 payload 里。
简单本地运行时✅ Markdown + SQLite + LanceDB 在本地保存内容、状态、BM25、向量和标量过滤。❌ 很多系统以 managed service、vector DB、graph DB 或可插拔后端服务为中心。
人可直接编辑✅ 直接编辑 .md 文件；cascade watcher 会做 entry-level diff 并同步衍生索引。❌ 记忆更新通常需要经过 SDK、API、dashboard 或 storage backend。
用户与 Agent 双轨✅ 用户记忆（episodes / profile）和 Agent 记忆（cases / skills）都是一等公民。❌ 多数系统更偏向 chat history、profile、graph facts 或 retrieval records，而不是同时覆盖两条轨道。
可携带的作用域✅ 可按 user_id、agent_id、app_id、project_id 和 session_id 正交检索。❌ 作用域常常围绕单一 app、thread、tenant 或自定义 schema 展开。
可审计的进化✅ 重复经验可以沉淀为 reusable skills，同时原始记忆仍是可编辑 Markdown；Knowledge Wiki 和 Reflection 会让进化过程保持可检查。❌ 即使支持 evolution，通常也发生在 service state、graph 或 dashboard 内，而不是可编辑源文件上。
+ +这里比较的是公开 memory-library repos 的默认产品取向，不代表每一种可选后端或部署模式。 + +
+
+ +[![](https://img.shields.io/badge/-Back_to_top-gray?style=flat-square)](#readme-top) + +
+ + ## 快速开始 ### 1. 安装 EverOS From 020aa3d4c7129a13180c9441572327354d2755a0 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 11:06:56 +0800 Subject: [PATCH 04/10] docs: make memory comparison a named matrix --- README.md | 102 ++++++++++++++++++++++++++++++------------------ README.zh-CN.md | 101 +++++++++++++++++++++++++++++------------------ 2 files changed, 129 insertions(+), 74 deletions(-) diff --git a/README.md b/README.md index bcf285893..07a64e108 100644 --- a/README.md +++ b/README.md @@ -134,49 +134,77 @@ The system is built around three boundaries: ## How EverOS Is Different -Most memory libraries are useful, but many optimize for managed APIs, vector or -graph recall, or one narrow memory surface. EverOS is built as a local, -inspectable memory workspace for both agents and people. +The table below compares first-class, developer-visible capabilities from +public memory-library repos and docs. It focuses on default product posture, +not every optional backend or enterprise deployment. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Developer needEverOSCommon memory-library default
Readable source of truth✅ Markdown files are the canonical memory surface. Open them in Obsidian, review diffs, or version them with Git.❌ Memory usually lives behind APIs, dashboards, vector stores, graphs, or backend payloads.
Simple local runtime✅ Markdown + SQLite + LanceDB keep content, state, BM25, vectors, and scalar filters local.❌ Many systems center on managed services, vector DBs, graph DBs, or pluggable backend services.
Human-editable memory✅ Edit a .md file directly; the cascade watcher diffs entries and syncs derived indexes.❌ Memory updates usually go through an SDK, API, dashboard, or storage backend.
User and agent tracks✅ User memory (episodes / profile) and agent memory (cases / skills) are first-class.❌ Most systems focus on chat history, profiles, graph facts, or retrieval records rather than both tracks.
Portable scopes✅ Search orthogonally by user_id, agent_id, app_id, project_id, and session_id.❌ Scope is often centered on one app, thread, tenant, or custom schema.
Auditable evolution✅ Repeated experience becomes reusable skills while raw memory remains editable Markdown; Knowledge Wiki and Reflection keep evolution inspectable.❌ Evolution, when available, usually happens inside service state, graphs, or dashboards rather than editable source files.CapabilityEverOSMem0MemOSMemPalaceMemoryLakeLangMem / Cognee / Graphiti
Markdown source of truth
Memory is readable, editable, diffable, and Git-versioned as files.		✅ Canonical .md memory❌ API / backend memory❌ Memory cubes / service state❌ Verbatim store + backend index❌ Hosted memory passport❌ Store / graph / platform state
Direct file editing
Edit memory with normal developer tools, then sync indexes.		✅ Edit .md files; cascade watcher syncs❌ SDK / API path❌ API / dashboard path❌ CLI / backend path❌ App / API path❌ Store / graph API path
Local three-part stack
Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required.		✅ Built in❌ Vector / service stack❌ Cloud or self-hosted service stack❌ Chroma / pluggable backend stack❌ Hosted product stack❌ Graph / database / platform stack
User + agent memory tracks
User episodes/profile and agent cases/skills are separate first-class surfaces.		✅ Built in❌ User/session/agent state, not this dual track❌ Multi-layer memory, not this dual track❌ Conversation/project recall focus❌ Personal memory passport focus❌ App memory or graph focus
Orthogonal retrieval scopes
Search by user_id, agent_id, app_id, project_id, and session_id.		✅ Built in❌ Different scoping model❌ Different scoping model❌ Wing / room style scoping❌ Product account / connector scoping❌ Namespace / graph / app scoping
Markdown-native evolution
Skills, upcoming Knowledge Wiki, and Reflection evolve from inspectable source files.		✅ Built around files❌ Evolution is not Markdown-native❌ Evolution is not Markdown-native❌ Retrieval-first, no Markdown-native evolution❌ Reflection is product state, not Markdown-native❌ Evolution lives in stores or graphs
-Comparison is about default product posture across public memory-library repos, not every optional backend or deployment mode. +✅ = first-class/default in public docs. ❌ = not presented as a first-class/default capability in public docs. Mem0 is sometimes referred to as MemZero; MemoryLake covers the MemLake shorthand.
diff --git a/README.zh-CN.md b/README.zh-CN.md index 21dda7502..d3b5336ce 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -125,49 +125,76 @@ EverOS 会把对话、Agent 轨迹和文件保存为可读 Markdown，并同步 ## EverOS 的差异 -许多 memory libraries 都有价值，但它们通常围绕 managed API、向量 / 图召回， -或某一种单一记忆形态来设计。EverOS 的定位是一个面向 Agent 和人的本地、 -可检查记忆工作区。 +下面这张表对比的是公开 memory-library repos 和 docs 中的一等、默认、 +开发者可见能力。它比较的是产品默认取向，不覆盖每一种可选后端或企业部署模式。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
开发者关心什么EverOS常见 memory-library 默认形态
可读的 source of truth✅ Markdown 文件就是标准记忆表面。可以用 Obsidian 打开、review diff，也可以用 Git 版本化。❌ 记忆通常藏在 API、dashboard、vector store、graph 或后端 payload 里。
简单本地运行时✅ Markdown + SQLite + LanceDB 在本地保存内容、状态、BM25、向量和标量过滤。❌ 很多系统以 managed service、vector DB、graph DB 或可插拔后端服务为中心。
人可直接编辑✅ 直接编辑 .md 文件；cascade watcher 会做 entry-level diff 并同步衍生索引。❌ 记忆更新通常需要经过 SDK、API、dashboard 或 storage backend。
用户与 Agent 双轨✅ 用户记忆（episodes / profile）和 Agent 记忆（cases / skills）都是一等公民。❌ 多数系统更偏向 chat history、profile、graph facts 或 retrieval records，而不是同时覆盖两条轨道。
可携带的作用域✅ 可按 user_id、agent_id、app_id、project_id 和 session_id 正交检索。❌ 作用域常常围绕单一 app、thread、tenant 或自定义 schema 展开。
可审计的进化✅ 重复经验可以沉淀为 reusable skills，同时原始记忆仍是可编辑 Markdown；Knowledge Wiki 和 Reflection 会让进化过程保持可检查。❌ 即使支持 evolution，通常也发生在 service state、graph 或 dashboard 内，而不是可编辑源文件上。能力EverOSMem0MemOSMemPalaceMemoryLakeLangMem / Cognee / Graphiti
Markdown source of truth
记忆以文件形式可读、可编辑、可 diff、可 Git 版本化。		✅ 标准 .md 记忆❌ API / backend memory❌ Memory cubes / service state❌ Verbatim store + backend index❌ Hosted memory passport❌ Store / graph / platform state
直接文件编辑
用普通开发者工具编辑记忆，然后同步索引。		✅ 编辑 .md；cascade watcher 同步❌ SDK / API 路径❌ API / dashboard 路径❌ CLI / backend 路径❌ App / API 路径❌ Store / graph API 路径
本地三件套
Markdown + SQLite + LanceDB；不需要 MongoDB、Elasticsearch 或 Redis。		✅ 内置❌ Vector / service stack❌ Cloud 或 self-hosted service stack❌ Chroma / pluggable backend stack❌ Hosted product stack❌ Graph / database / platform stack
用户 + Agent 双轨
用户 episodes/profile 与 Agent cases/skills 是分离的一等记忆表面。		✅ 内置❌ User/session/agent state，不是这套双轨❌ Multi-layer memory，不是这套双轨❌ 偏 conversation/project recall❌ 偏 personal memory passport❌ 偏 app memory 或 graph
正交检索作用域
按 user_id、agent_id、app_id、project_id 和 session_id 检索。		✅ 内置❌ 作用域模型不同❌ 作用域模型不同❌ Wing / room 式作用域❌ Product account / connector 作用域❌ Namespace / graph / app 作用域
Markdown-native evolution
Skills、即将推出的 Knowledge Wiki 和 Reflection 都从可检查源文件中进化。		✅ 围绕文件构建❌ Evolution 不是 Markdown-native❌ Evolution 不是 Markdown-native❌ Retrieval-first，没有 Markdown-native evolution❌ Reflection 是产品状态，不是 Markdown-native❌ Evolution 存在于 stores 或 graphs 中
-这里比较的是公开 memory-library repos 的默认产品取向，不代表每一种可选后端或部署模式。 +✅ = 公开 docs 中的一等 / 默认能力。❌ = 公开 docs 中未作为一等 / 默认能力呈现。Mem0 有时也被写作 MemZero；MemoryLake 对应 MemLake 这个简称。
From 215abe2545b1d82032220ba62ac801883eb73ca4 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 15:04:40 +0800 Subject: [PATCH 05/10] docs: use category comparison for memory positioning --- README.md | 62 +++++++++++++++++-------------------------------- README.zh-CN.md | 60 ++++++++++++++++------------------------------- 2 files changed, 41 insertions(+), 81 deletions(-) diff --git a/README.md b/README.md index 07a64e108..f114fa1d6 100644 --- a/README.md +++ b/README.md @@ -134,77 +134,57 @@ The system is built around three boundaries: ## How EverOS Is Different -The table below compares first-class, developer-visible capabilities from -public memory-library repos and docs. It focuses on default product posture, -not every optional backend or enterprise deployment. +The table below compares common memory-library architectures rather than naming +specific repos. Some projects overlap categories, and some do expose +file-oriented or Markdown-like surfaces. EverOS is different because Markdown is +the canonical memory layer, not just an export, log, or integration target. - - - - - - - + + + + - - - - - + + - - - - - + + - - - - - + + - - - - - + + - - - - - + + - - - - - + +
CapabilityEverOSMem0MemOSMemPalaceMemoryLakeLangMem / Cognee / GraphitiDeveloper needEverOS defaultTypical memory librariesFile / Markdown-adjacent tools
Markdown source of truth
Memory is readable, editable, diffable, and Git-versioned as files.		 ✅ Canonical .md memory❌ API / backend memory❌ Memory cubes / service state❌ Verbatim store + backend index❌ Hosted memory passport❌ Store / graph / platform state❌ Usually API, vector, graph, dashboard, or database state✅ Often readable, but not always the full runtime source of truth
Direct file editing
Edit memory with normal developer tools, then sync indexes.		 ✅ Edit .md files; cascade watcher syncs❌ SDK / API path❌ API / dashboard path❌ CLI / backend path❌ App / API path❌ Store / graph API path❌ Usually SDK, API, dashboard, or backend update paths✅ Sometimes possible, but often without entry-level index sync
Local three-part stack
Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required.		 ✅ Built in❌ Vector / service stack❌ Cloud or self-hosted service stack❌ Chroma / pluggable backend stack❌ Hosted product stack❌ Graph / database / platform stack❌ Often depends on managed services, vector DBs, graph DBs, or server stacks❌ Often local, but commonly tied to a different index/backend model
User + agent memory tracks
User episodes/profile and agent cases/skills are separate first-class surfaces.		 ✅ Built in❌ User/session/agent state, not this dual track❌ Multi-layer memory, not this dual track❌ Conversation/project recall focus❌ Personal memory passport focus❌ App memory or graph focus❌ Usually centered on chat history, profiles, entities, facts, or retrieval records❌ Usually centered on logs, notes, projects, or conversations
Orthogonal retrieval scopes
Search by user_id, agent_id, app_id, project_id, and session_id.		 ✅ Built in❌ Different scoping model❌ Different scoping model❌ Wing / room style scoping❌ Product account / connector scoping❌ Namespace / graph / app scoping❌ Usually app, namespace, tenant, thread, or graph scoped❌ Usually folder, project, or conversation scoped
Markdown-native evolution
Skills, upcoming Knowledge Wiki, and Reflection evolve from inspectable source files.		 ✅ Built around files❌ Evolution is not Markdown-native❌ Evolution is not Markdown-native❌ Retrieval-first, no Markdown-native evolution❌ Reflection is product state, not Markdown-native❌ Evolution lives in stores or graphs❌ If evolution exists, it usually lives in service, graph, or database state❌ Usually recall-oriented rather than file-native self-evolution
-✅ = first-class/default in public docs. ❌ = not presented as a first-class/default capability in public docs. Mem0 is sometimes referred to as MemZero; MemoryLake covers the MemLake shorthand. +✅ means first-class in the default posture. ❌ means it is usually absent or not the primary design center for that category. This is a product-shape comparison, not a claim that no individual project has an adjacent feature.
diff --git a/README.zh-CN.md b/README.zh-CN.md index d3b5336ce..a0cf43202 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -125,76 +125,56 @@ EverOS 会把对话、Agent 轨迹和文件保存为可读 Markdown，并同步 ## EverOS 的差异 -下面这张表对比的是公开 memory-library repos 和 docs 中的一等、默认、 -开发者可见能力。它比较的是产品默认取向，不覆盖每一种可选后端或企业部署模式。 +下面这张表比较的是常见 memory-library 架构类型，而不是点名具体仓库。 +有些项目会跨多个类型，也确实有项目提供 file-oriented 或 Markdown-like 能力。 +EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 - - - - - - - + + + + - - - - - + + - - - - - + + - - - - - + + - - - - - + + - - - - - + + - - - - - + +
能力EverOSMem0MemOSMemPalaceMemoryLakeLangMem / Cognee / Graphiti开发者关心什么EverOS default常见 memory librariesFile / Markdown-adjacent tools
Markdown source of truth
记忆以文件形式可读、可编辑、可 diff、可 Git 版本化。		 ✅ 标准 .md 记忆❌ API / backend memory❌ Memory cubes / service state❌ Verbatim store + backend index❌ Hosted memory passport❌ Store / graph / platform state❌ 通常是 API、vector、graph、dashboard 或 database state✅ 往往可读，但不一定是完整 runtime source of truth
直接文件编辑
用普通开发者工具编辑记忆，然后同步索引。		 ✅ 编辑 .md；cascade watcher 同步❌ SDK / API 路径❌ API / dashboard 路径❌ CLI / backend 路径❌ App / API 路径❌ Store / graph API 路径❌ 通常需要 SDK、API、dashboard 或 backend update path✅ 有些可以做到，但常常缺少 entry-level index sync
本地三件套
Markdown + SQLite + LanceDB；不需要 MongoDB、Elasticsearch 或 Redis。		 ✅ 内置❌ Vector / service stack❌ Cloud 或 self-hosted service stack❌ Chroma / pluggable backend stack❌ Hosted product stack❌ Graph / database / platform stack❌ 常依赖 managed service、vector DB、graph DB 或 server stack❌ 往往本地，但通常绑定另一套 index/backend model
用户 + Agent 双轨
用户 episodes/profile 与 Agent cases/skills 是分离的一等记忆表面。		 ✅ 内置❌ User/session/agent state，不是这套双轨❌ Multi-layer memory，不是这套双轨❌ 偏 conversation/project recall❌ 偏 personal memory passport❌ 偏 app memory 或 graph❌ 通常围绕 chat history、profiles、entities、facts 或 retrieval records❌ 通常围绕 logs、notes、projects 或 conversations
正交检索作用域
按 user_id、agent_id、app_id、project_id 和 session_id 检索。		 ✅ 内置❌ 作用域模型不同❌ 作用域模型不同❌ Wing / room 式作用域❌ Product account / connector 作用域❌ Namespace / graph / app 作用域❌ 通常按 app、namespace、tenant、thread 或 graph 来组织❌ 通常按 folder、project 或 conversation 来组织
Markdown-native evolution
Skills、即将推出的 Knowledge Wiki 和 Reflection 都从可检查源文件中进化。		 ✅ 围绕文件构建❌ Evolution 不是 Markdown-native❌ Evolution 不是 Markdown-native❌ Retrieval-first，没有 Markdown-native evolution❌ Reflection 是产品状态，不是 Markdown-native❌ Evolution 存在于 stores 或 graphs 中❌ 如果支持 evolution，通常存在于 service、graph 或 database state❌ 通常偏 recall，而不是 file-native self-evolution
-✅ = 公开 docs 中的一等 / 默认能力。❌ = 公开 docs 中未作为一等 / 默认能力呈现。Mem0 有时也被写作 MemZero；MemoryLake 对应 MemLake 这个简称。 +✅ 表示默认取向中的一等能力。❌ 表示该类型通常没有，或并不是核心设计中心。这是 product-shape comparison，不表示没有任何单个项目具备相邻能力。
From c1e13cafea04e663c5f0f2de3c1258f98e2acb79 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 15:31:57 +0800 Subject: [PATCH 06/10] docs: sharpen readme comparison table --- README.md | 63 ++++++++++--------------------------------------- README.zh-CN.md | 57 ++++++++++---------------------------------- 2 files changed, 26 insertions(+), 94 deletions(-) diff --git a/README.md b/README.md index f114fa1d6..ad0a174c2 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,7 @@
-- [EverOS 1.0.0 Highlights](#everos-100-highlights) +- [EverOS 1.0.0](#everos-100) - [Why EverOS](#why-everos) - [How EverOS Is Different](#how-everos-is-different) - [Quick Start](#quick-start) @@ -40,7 +40,7 @@ -## EverOS 1.0.0 Highlights +## EverOS 1.0.0 > [!IMPORTANT] > @@ -54,49 +54,6 @@ > will run offline to connect signals, compress history, and improve profiles > and skills between sessions. - - - - - - - - - - - -
-Markdown As Source Of Truth
-
-All memory is persisted as .md files: readable, editable, -grep-able, Git-versioned, and openable directly in Obsidian. -		 -Local Three-Part Stack
-
-Markdown + SQLite + LanceDB keep vectors, BM25, and scalar filters -local. No MongoDB, Elasticsearch, or Redis required. -		 -Dual-Track Memory
-
-Agent memory (cases / skills) and user memory -(episodes / profile) are extracted independently. -
-Multimodal Ingestion
-
-Text, images, audio, documents, PDFs, HTML, and email are unified into -searchable memory. -		 -Self-Evolution
-
-Common skills are extracted from real usage; repeated patterns become -reusable workflows, no retraining required. -		 -Orthogonal Retrieval
-
-Search independently by user_id, agent_id, -app_id, project_id, and session_id. -
-
@@ -177,14 +134,20 @@ the canonical memory layer, not just an export, log, or integration target. ❌ Usually folder, project, or conversation scoped -Markdown-native evolution
Skills, upcoming Knowledge Wiki, and Reflection evolve from inspectable source files. -✅ Built around files -❌ If evolution exists, it usually lives in service, graph, or database state -❌ Usually recall-oriented rather than file-native self-evolution +Knowledge Wiki
Memory should become editable, source-backed knowledge pages. +✅ Coming next: Markdown wiki pages derived from memory +❌ Usually retrieval, graph, dashboard, or generated summary state +✅ Often wiki-like, but usually manual or separate from runtime memory + + +Dreaming / Reflection
Offline consolidation should connect signals and improve long-term behavior. +✅ Coming next: offline Reflection across profiles, skills, and wiki +❌ Usually online read/write APIs rather than file-native self-improvement +❌ Usually note recall or summaries, not runtime memory evolution -✅ means first-class in the default posture. ❌ means it is usually absent or not the primary design center for that category. This is a product-shape comparison, not a claim that no individual project has an adjacent feature. +✅ means first-class in the current or announced default posture. ❌ means it is usually absent or not the primary design center for that category. This is a product-shape comparison, not a claim that no individual project has an adjacent feature.
diff --git a/README.zh-CN.md b/README.zh-CN.md index a0cf43202..e0de2b334 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -21,7 +21,7 @@
-- [EverOS 1.0.0 亮点](#everos-100-亮点) +- [EverOS 1.0.0](#everos-100) - [为什么选择 EverOS](#为什么选择-everos) - [EverOS 的差异](#everos-的差异) - [快速开始](#快速开始) @@ -40,7 +40,7 @@ -## EverOS 1.0.0 亮点 +## EverOS 1.0.0 > [!IMPORTANT] > @@ -53,43 +53,6 @@ > Markdown 知识页。Reflection（也称 Dreaming）会在离线时连接信号、 > 压缩历史，并持续改进 profile 和 skills。 - - - - - - - - - - - -
-Markdown As Source Of Truth
-
-所有记忆持久化为 .md 文件：可读、可改、可 grep、可 Git 版本化，也可直接用 Obsidian 打开。 -		 -Local Three-Part Stack
-
-Markdown + SQLite + LanceDB 在本地完成向量、BM25 和标量过滤检索，无需 MongoDB、Elasticsearch 或 Redis。 -		 -Dual-Track Memory
-
-Agent 记忆（cases / skills）与用户记忆（episodes / profile）独立提取，互不污染。 -
-Multimodal Ingestion
-
-文本、图像、音频、文档、PDF、HTML 和邮件统一抽取为可检索的记忆形态。 -		 -Self-Evolution
-
-从真实使用经验中自动抽取共性 skills，重复模式沉淀为可复用流程，无需重训。 -		 -Orthogonal Retrieval
-
-按 user_id、agent_id、app_id、project_id 和 session_id 五维独立检索。 -
-
@@ -167,14 +130,20 @@ EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log ❌ 通常按 folder、project 或 conversation 来组织 -Markdown-native evolution
Skills、即将推出的 Knowledge Wiki 和 Reflection 都从可检查源文件中进化。 -✅ 围绕文件构建 -❌ 如果支持 evolution，通常存在于 service、graph 或 database state -❌ 通常偏 recall，而不是 file-native self-evolution +Knowledge Wiki
记忆应该沉淀为可编辑、可溯源的知识页。 +✅ 即将推出：由记忆生成 Markdown wiki 知识页 +❌ 通常是 retrieval、graph、dashboard 或 generated summary state +✅ 往往像 wiki，但通常是手写内容，或与 runtime memory 分离 + + +Dreaming / Reflection
离线整理应该连接信号，并改善长期行为。 +✅ 即将推出：围绕 profiles、skills 和 wiki 做离线 Reflection +❌ 通常是在线读写 API，而不是基于文件的自我改进 +❌ 通常偏笔记召回或摘要，不是运行时记忆进化 -✅ 表示默认取向中的一等能力。❌ 表示该类型通常没有，或并不是核心设计中心。这是 product-shape comparison，不表示没有任何单个项目具备相邻能力。 +✅ 表示当前或已宣布默认取向中的一等能力。❌ 表示该类型通常没有，或并不是核心设计中心。这是 product-shape comparison，不表示没有任何单个项目具备相邻能力。
From 2eaac5a95558edc666746fe69538bea7892e7043 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 19:22:31 +0800 Subject: [PATCH 07/10] docs: refine everme readme positioning --- README.md | 108 +++++++++++++++++++++++++++++------------------- README.zh-CN.md | 99 ++++++++++++++++++++++++++------------------ 2 files changed, 125 insertions(+), 82 deletions(-) diff --git a/README.md b/README.md index ad0a174c2..cc73b26d6 100644 --- a/README.md +++ b/README.md @@ -22,8 +22,8 @@
- [EverOS 1.0.0](#everos-100) -- [Why EverOS](#why-everos) -- [How EverOS Is Different](#how-everos-is-different) +- [EverMe: One Memory For All](#everme-one-memory-for-all) +- [How EverMe Is Different](#how-everme-is-different) - [Quick Start](#quick-start) - [Architecture At A Glance](#architecture-at-a-glance) - [Storage Layout](#storage-layout) @@ -62,24 +62,56 @@
-## Why EverOS +## EverMe: One Memory For All -EverOS is an open-source Python framework for self-evolving long-term -memory across agents and platforms. It gives makers one portable memory -layer for every agent they use - Claude Code, Codex, OpenClaw, Hermes, -and more - so context, decisions, files, and trajectories can follow the -work instead of staying trapped in one tool. - -EverOS stores conversations, agent trajectories, and files as readable -Markdown, then syncs local SQLite and LanceDB indexes for fast retrieval. -Agents can reuse past cases and skills, improve from repeated workflows, -and become more proactive over time. - -The system is built around three boundaries: + + + + + + + + + + + +
+Markdown As Source Of Truth
+
+All memory is persisted as .md files: readable, editable, +grep-able, Git-versioned, and openable directly in Obsidian. +		 +Local Three-Part Stack
+
+Markdown + SQLite + LanceDB keep vectors, BM25, and scalar filters +local. No MongoDB, Elasticsearch, or Redis required. +		 +Dual-Track Memory
+
+Agent memory (cases / skills) and user memory +(episodes / profile) are extracted independently. +
+Multimodal Ingestion
+
+Text, images, audio, documents, PDFs, HTML, and email are unified into +searchable memory. +		 +Self-Evolution
+
+Common skills are extracted from real usage; repeated patterns become +reusable workflows, no retraining required. +		 +Orthogonal Retrieval
+
+Search independently by user_id, agent_id, +app_id, project_id, and session_id. +
-1. **Memory content stays readable** - Markdown is the durable source of truth. -2. **Runtime state stays local** - SQLite tracks state and LanceDB handles vector, BM25, and scalar-filter search. -3. **Algorithms stay modular** - [EverAlgo](https://github.com/EverMind-AI/EverAlgo) owns memory algorithms; EverOS owns runtime, persistence, online flows, and offline evolution. +EverMe is the personal-memory experience built on EverOS: a CLI and agent +plugin layer that lets one memory follow a maker across coding assistants, +apps, devices, and workflows. Today it stores conversations, files, and agent +trajectories as readable Markdown, then syncs local SQLite and LanceDB indexes +for fast retrieval and self-evolving reuse.
@@ -89,61 +121,53 @@ The system is built around three boundaries:
-## How EverOS Is Different +## How EverMe Is Different The table below compares common memory-library architectures rather than naming specific repos. Some projects overlap categories, and some do expose -file-oriented or Markdown-like surfaces. EverOS is different because Markdown is +file-oriented or Markdown-like surfaces. EverMe is different because Markdown is the canonical memory layer, not just an export, log, or integration target. - - - - + + + - - + + - - + - - - + + - - - + + - - - + + - - + - - + -
Developer needEverOS defaultTypical memory librariesFile / Markdown-adjacent toolsTitleEverMeAgent Memory libraries
Markdown source of truth
Memory is readable, editable, diffable, and Git-versioned as files.		✅ Canonical .md memoryMarkdown source of truth✅ Canonical .md files that are readable, editable, diffable, and Git-versioned ❌ Usually API, vector, graph, dashboard, or database state✅ Often readable, but not always the full runtime source of truth
Direct file editing
Edit memory with normal developer tools, then sync indexes.		Direct file editing ✅ Edit .md files; cascade watcher syncs ❌ Usually SDK, API, dashboard, or backend update paths✅ Sometimes possible, but often without entry-level index sync
Local three-part stack
Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required.		✅ Built inLocal three-part stack✅ Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required ❌ Often depends on managed services, vector DBs, graph DBs, or server stacks❌ Often local, but commonly tied to a different index/backend model
User + agent memory tracks
User episodes/profile and agent cases/skills are separate first-class surfaces.		✅ Built inUser + agent tracks✅ User episodes/profile and agent cases/skills are separate first-class surfaces ❌ Usually centered on chat history, profiles, entities, facts, or retrieval records❌ Usually centered on logs, notes, projects, or conversations
Orthogonal retrieval scopes
Search by user_id, agent_id, app_id, project_id, and session_id.		✅ Built inOrthogonal retrieval✅ Search by user_id, agent_id, app_id, project_id, and session_id ❌ Usually app, namespace, tenant, thread, or graph scoped❌ Usually folder, project, or conversation scoped
Knowledge Wiki
Memory should become editable, source-backed knowledge pages.		Knowledge Wiki ✅ Coming next: Markdown wiki pages derived from memory ❌ Usually retrieval, graph, dashboard, or generated summary state✅ Often wiki-like, but usually manual or separate from runtime memory
Dreaming / Reflection
Offline consolidation should connect signals and improve long-term behavior.		Dreaming / Reflection ✅ Coming next: offline Reflection across profiles, skills, and wiki ❌ Usually online read/write APIs rather than file-native self-improvement❌ Usually note recall or summaries, not runtime memory evolution
diff --git a/README.zh-CN.md b/README.zh-CN.md index e0de2b334..7915bc523 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -22,8 +22,8 @@
- [EverOS 1.0.0](#everos-100) -- [为什么选择 EverOS](#为什么选择-everos) -- [EverOS 的差异](#everos-的差异) +- [EverMe: One Memory For All](#everme-one-memory-for-all) +- [EverMe 的差异](#everme-的差异) - [快速开始](#快速开始) - [架构概览](#架构概览) - [存储布局](#存储布局) @@ -61,22 +61,49 @@
-## 为什么选择 EverOS +## EverMe: One Memory For All -EverOS 是一个开源 Python 框架，用来构建**跨 Agent、跨平台的自进化长期记忆**。 -它为 maker 提供一层可携带的统一记忆层，适用于他们使用的每一个 Agent： -Claude Code、Codex、OpenClaw、Hermes 等等。这样，上下文、决策、文件和 -Agent 轨迹可以跟着工作流走，而不是被锁在某一个工具里。 - -EverOS 会把对话、Agent 轨迹和文件保存为可读 Markdown，并同步本地 SQLite -和 LanceDB 索引，以便快速检索。Agent 可以复用过去的 cases 和 skills，从重复 -工作流中自我改进，并逐渐变得更加主动。 - -系统围绕三个边界设计： + + + + + + + + + + + +
+Markdown As Source Of Truth
+
+所有记忆持久化为 .md 文件：可读、可改、可 grep、可 Git 版本化，也可直接用 Obsidian 打开。 +		 +Local Three-Part Stack
+
+Markdown + SQLite + LanceDB 在本地完成向量、BM25 和标量过滤检索，无需 MongoDB、Elasticsearch 或 Redis。 +		 +Dual-Track Memory
+
+Agent 记忆（cases / skills）与用户记忆（episodes / profile）独立提取，互不污染。 +
+Multimodal Ingestion
+
+文本、图像、音频、文档、PDF、HTML 和邮件统一抽取为可检索的记忆形态。 +		 +Self-Evolution
+
+从真实使用经验中自动抽取共性 skills，重复模式沉淀为可复用流程，无需重训。 +		 +Orthogonal Retrieval
+
+按 user_id、agent_id、app_id、project_id 和 session_id 五维独立检索。 +
-1. **记忆内容保持可读** - Markdown 是长期、耐用的 source of truth。 -2. **运行时状态保持本地** - SQLite 跟踪状态；LanceDB 处理向量、BM25 和结构化过滤搜索。 -3. **算法保持模块化** - [EverAlgo](https://github.com/EverMind-AI/EverAlgo) 负责记忆算法；EverOS 负责运行时、持久化、在线流程和离线进化。 +EverMe 是构建在 EverOS 之上的个人记忆体验：通过 CLI 和 Agent plugin layer， +让同一份记忆跟随 maker 穿过 coding assistants、apps、devices 和 workflows。 +目前它会把对话、文件和 Agent 轨迹保存为可读 Markdown，并同步本地 SQLite +和 LanceDB 索引，用于快速检索和自进化复用。
@@ -86,60 +113,52 @@ EverOS 会把对话、Agent 轨迹和文件保存为可读 Markdown，并同步
-## EverOS 的差异 +## EverMe 的差异 下面这张表比较的是常见 memory-library 架构类型，而不是点名具体仓库。 有些项目会跨多个类型，也确实有项目提供 file-oriented 或 Markdown-like 能力。 -EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 +EverMe 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 - - - - + + + - - + + - - + - - - + + - - - + + - - - + + - - + - - + -
开发者关心什么EverOS default常见 memory librariesFile / Markdown-adjacent toolsTitleEverMeAgent Memory libraries
Markdown source of truth
记忆以文件形式可读、可编辑、可 diff、可 Git 版本化。		✅ 标准 .md 记忆Markdown source of truth✅ 标准 .md 文件：可读、可编辑、可 diff、可 Git 版本化 ❌ 通常是 API、vector、graph、dashboard 或 database state✅ 往往可读，但不一定是完整 runtime source of truth
直接文件编辑
用普通开发者工具编辑记忆，然后同步索引。		直接文件编辑 ✅ 编辑 .md；cascade watcher 同步 ❌ 通常需要 SDK、API、dashboard 或 backend update path✅ 有些可以做到，但常常缺少 entry-level index sync
本地三件套
Markdown + SQLite + LanceDB；不需要 MongoDB、Elasticsearch 或 Redis。		✅ 内置本地三件套✅ Markdown + SQLite + LanceDB；不需要 MongoDB、Elasticsearch 或 Redis ❌ 常依赖 managed service、vector DB、graph DB 或 server stack❌ 往往本地，但通常绑定另一套 index/backend model
用户 + Agent 双轨
用户 episodes/profile 与 Agent cases/skills 是分离的一等记忆表面。		✅ 内置用户 + Agent 双轨✅ 用户 episodes/profile 与 Agent cases/skills 是分离的一等记忆表面 ❌ 通常围绕 chat history、profiles、entities、facts 或 retrieval records❌ 通常围绕 logs、notes、projects 或 conversations
正交检索作用域
按 user_id、agent_id、app_id、project_id 和 session_id 检索。		✅ 内置正交检索作用域✅ 按 user_id、agent_id、app_id、project_id 和 session_id 检索 ❌ 通常按 app、namespace、tenant、thread 或 graph 来组织❌ 通常按 folder、project 或 conversation 来组织
Knowledge Wiki
记忆应该沉淀为可编辑、可溯源的知识页。		Knowledge Wiki ✅ 即将推出：由记忆生成 Markdown wiki 知识页 ❌ 通常是 retrieval、graph、dashboard 或 generated summary state✅ 往往像 wiki，但通常是手写内容，或与 runtime memory 分离
Dreaming / Reflection
离线整理应该连接信号，并改善长期行为。		Dreaming / Reflection ✅ 即将推出：围绕 profiles、skills 和 wiki 做离线 Reflection ❌ 通常是在线读写 API，而不是基于文件的自我改进❌ 通常偏笔记召回或摘要，不是运行时记忆进化
From 639b44f573e2bf6d2e6c1e5ee229853a4ba39710 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 19:48:04 +0800 Subject: [PATCH 08/10] docs: correct readme positioning title to everos --- README.md | 22 +++++++++++----------- README.zh-CN.md | 16 ++++++++-------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index cc73b26d6..7727715f9 100644 --- a/README.md +++ b/README.md @@ -22,8 +22,8 @@
- [EverOS 1.0.0](#everos-100) -- [EverMe: One Memory For All](#everme-one-memory-for-all) -- [How EverMe Is Different](#how-everme-is-different) +- [EverOS: One Memory For All](#everos-one-memory-for-all) +- [How EverOS Is Different](#how-everos-is-different) - [Quick Start](#quick-start) - [Architecture At A Glance](#architecture-at-a-glance) - [Storage Layout](#storage-layout) @@ -62,7 +62,7 @@
-## EverMe: One Memory For All +## EverOS: One Memory For All @@ -107,11 +107,11 @@ Search independently by user_id, agent_id,
-EverMe is the personal-memory experience built on EverOS: a CLI and agent -plugin layer that lets one memory follow a maker across coding assistants, -apps, devices, and workflows. Today it stores conversations, files, and agent -trajectories as readable Markdown, then syncs local SQLite and LanceDB indexes -for fast retrieval and self-evolving reuse. +EverOS is the local memory operating system for agents and makers. It gives +one portable memory layer across coding assistants, apps, devices, and +workflows. Today it stores conversations, files, and agent trajectories as +readable Markdown, then syncs local SQLite and LanceDB indexes for fast +retrieval and self-evolving reuse.
@@ -121,17 +121,17 @@ for fast retrieval and self-evolving reuse.
-## How EverMe Is Different +## How EverOS Is Different The table below compares common memory-library architectures rather than naming specific repos. Some projects overlap categories, and some do expose -file-oriented or Markdown-like surfaces. EverMe is different because Markdown is +file-oriented or Markdown-like surfaces. EverOS is different because Markdown is the canonical memory layer, not just an export, log, or integration target. - + diff --git a/README.zh-CN.md b/README.zh-CN.md index 7915bc523..2bc1aef49 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -22,8 +22,8 @@
- [EverOS 1.0.0](#everos-100) -- [EverMe: One Memory For All](#everme-one-memory-for-all) -- [EverMe 的差异](#everme-的差异) +- [EverOS: One Memory For All](#everos-one-memory-for-all) +- [EverOS 的差异](#everos-的差异) - [快速开始](#快速开始) - [架构概览](#架构概览) - [存储布局](#存储布局) @@ -61,7 +61,7 @@ -## EverMe: One Memory For All +## EverOS: One Memory For All
TitleEverMeEverOS Agent Memory libraries
@@ -100,8 +100,8 @@ Agent 记忆（cases / skills）与用户记忆（
-EverMe 是构建在 EverOS 之上的个人记忆体验：通过 CLI 和 Agent plugin layer， -让同一份记忆跟随 maker 穿过 coding assistants、apps、devices 和 workflows。 +EverOS 是面向 agents 和 makers 的本地记忆操作系统。它提供一层可携带的 +统一记忆层，让记忆穿过 coding assistants、apps、devices 和 workflows。 目前它会把对话、文件和 Agent 轨迹保存为可读 Markdown，并同步本地 SQLite 和 LanceDB 索引，用于快速检索和自进化复用。 @@ -113,16 +113,16 @@ EverMe 是构建在 EverOS 之上的个人记忆体验：通过 CLI 和 Agent pl
-## EverMe 的差异 +## EverOS 的差异 下面这张表比较的是常见 memory-library 架构类型，而不是点名具体仓库。 有些项目会跨多个类型，也确实有项目提供 file-oriented 或 Markdown-like 能力。 -EverMe 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 +EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 - + From 629b69a33d39dbd430403ce30cc80941efac158b Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 20:46:56 +0800 Subject: [PATCH 09/10] docs: simplify readme comparison table --- README.md | 17 +++++------------ README.zh-CN.md | 16 +++++----------- 2 files changed, 10 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 7727715f9..199d3e75c 100644 --- a/README.md +++ b/README.md @@ -123,16 +123,11 @@ retrieval and self-evolving reuse. ## How EverOS Is Different -The table below compares common memory-library architectures rather than naming -specific repos. Some projects overlap categories, and some do expose -file-oriented or Markdown-like surfaces. EverOS is different because Markdown is -the canonical memory layer, not just an export, log, or integration target. -
TitleEverMeEverOS Agent Memory libraries
- + @@ -161,18 +156,16 @@ the canonical memory layer, not just an export, log, or integration target. - - + + - - + +
Title EverOSAgent Memory librariesOther Agent Memory Libraries
Markdown source of truth
Knowledge Wiki✅ Coming next: Markdown wiki pages derived from memory❌ Usually retrieval, graph, dashboard, or generated summary state✅ Coming next: editable, source-backed Markdown knowledge pages built from memory❌ Usually retrieval, graph, dashboards, or generated summaries instead of editable source-backed pages
Dreaming / Reflection✅ Coming next: offline Reflection across profiles, skills, and wiki❌ Usually online read/write APIs rather than file-native self-improvement✅ Coming next: offline Reflection that connects signals, compresses history, and improves profiles and skills between sessions❌ Usually online read/write APIs, retrieval records, or summaries rather than offline memory consolidation
-✅ means first-class in the current or announced default posture. ❌ means it is usually absent or not the primary design center for that category. This is a product-shape comparison, not a claim that no individual project has an adjacent feature. -
diff --git a/README.zh-CN.md b/README.zh-CN.md index 2bc1aef49..d63b93558 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -115,15 +115,11 @@ EverOS 是面向 agents 和 makers 的本地记忆操作系统。它提供一层 ## EverOS 的差异 -下面这张表比较的是常见 memory-library 架构类型，而不是点名具体仓库。 -有些项目会跨多个类型，也确实有项目提供 file-oriented 或 Markdown-like 能力。 -EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log 或 integration target。 - - + @@ -152,18 +148,16 @@ EverOS 的差异在于：Markdown 是标准记忆层，而不是 export、log - - + + - - + +
Title EverOSAgent Memory librariesOther Agent Memory Libraries
Markdown source of truth
Knowledge Wiki✅ 即将推出：由记忆生成 Markdown wiki 知识页❌ 通常是 retrieval、graph、dashboard 或 generated summary state✅ 即将推出：由记忆形成可编辑、可溯源的 Markdown 知识页❌ 通常是 retrieval、graph、dashboard 或 generated summaries，而不是可编辑、可溯源的知识页
Dreaming / Reflection✅ 即将推出：围绕 profiles、skills 和 wiki 做离线 Reflection❌ 通常是在线读写 API，而不是基于文件的自我改进✅ 即将推出：离线连接信号、压缩历史，并在 session 之间改进 profiles 和 skills❌ 通常是在线读写 API、retrieval records 或 summaries，而不是离线记忆整理
-✅ 表示当前或已宣布默认取向中的一等能力。❌ 表示该类型通常没有，或并不是核心设计中心。这是 product-shape comparison，不表示没有任何单个项目具备相邻能力。 -
From c4d5e3e952dd2fe6d88bde995a1132c3dfdd4578 Mon Sep 17 00:00:00 2001 From: Elliot Chen Date: Tue, 16 Jun 2026 20:57:39 +0800 Subject: [PATCH 10/10] docs: clarify reflection idle behavior --- README.md | 29 +++++++++++++++-------------- README.zh-CN.md | 24 ++++++++++++------------ 2 files changed, 27 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index 199d3e75c..2996aae1a 100644 --- a/README.md +++ b/README.md @@ -51,8 +51,8 @@ > > **Coming next:** Knowledge Wiki will turn memory into editable, > source-backed Markdown knowledge pages. Reflection, also called Dreaming, -> will run offline to connect signals, compress history, and improve profiles -> and skills between sessions. +> will run when the system is idle or offline to connect signals, compress +> history, and improve profiles and skills between sessions.
@@ -64,6 +64,12 @@ ## EverOS: One Memory For All +EverOS is the local memory operating system for agents and makers. It gives +one portable memory layer across coding assistants, apps, devices, and +workflows. Today it stores conversations, files, and agent trajectories as +readable Markdown, then syncs local SQLite and LanceDB indexes for fast +retrieval and self-evolving reuse. +
@@ -107,12 +113,6 @@ Search independently by user_id, agent_id,
-EverOS is the local memory operating system for agents and makers. It gives -one portable memory layer across coding assistants, apps, devices, and -workflows. Today it stores conversations, files, and agent trajectories as -readable Markdown, then syncs local SQLite and LanceDB indexes for fast -retrieval and self-evolving reuse. -
@@ -161,8 +161,8 @@ retrieval and self-evolving reuse. Dreaming / Reflection -✅ Coming next: offline Reflection that connects signals, compresses history, and improves profiles and skills between sessions -❌ Usually online read/write APIs, retrieval records, or summaries rather than offline memory consolidation +✅ Coming next: Reflection that runs when the system is idle or offline to connect signals, compress history, and improve profiles and skills between sessions +❌ Usually online read/write APIs, retrieval records, or summaries rather than idle-time memory consolidation @@ -710,8 +710,8 @@ Explore stored entities and relationships in a graph interface. Frontend demo; b ## Watch EverOS EverOS 1.0.0 is the first release of a larger memory-system roadmap. -Watch this repository for upcoming work on deeper offline evolution, benchmark -releases, and more real-world agent integrations. +Watch this repository for upcoming work on deeper idle-time and offline evolution, +benchmark releases, and more real-world agent integrations. @@ -726,9 +726,10 @@ existing Markdown tools.
Dreaming / Reflection

-Runs offline between active sessions to revisit stored memory, connect weak +Runs when the system is idle or offline to revisit stored memory, connect weak signals, compress noisy history into durable patterns, and improve profiles and -skills. The agent gets better while you are away, not only while you prompt it. +skills. The agent gets better between active sessions, not only while you prompt +it.
diff --git a/README.zh-CN.md b/README.zh-CN.md index d63b93558..c2b3cc75c 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -50,8 +50,8 @@ > [EverAlgo](https://github.com/EverMind-AI/EverAlgo) 支撑的模块化算法。 > > **即将推出：** Knowledge Wiki 会把记忆整理成可编辑、可溯源的 -> Markdown 知识页。Reflection（也称 Dreaming）会在离线时连接信号、 -> 压缩历史，并持续改进 profile 和 skills。 +> Markdown 知识页。Reflection（也称 Dreaming）会在系统空闲或离线时 +> 连接信号、压缩历史，并持续改进 profile 和 skills。
@@ -63,6 +63,11 @@ ## EverOS: One Memory For All +EverOS 是面向 agents 和 makers 的本地记忆操作系统。它提供一层可携带的 +统一记忆层，让记忆穿过 coding assistants、apps、devices 和 workflows。 +目前它会把对话、文件和 Agent 轨迹保存为可读 Markdown，并同步本地 SQLite +和 LanceDB 索引，用于快速检索和自进化复用。 +
@@ -100,11 +105,6 @@ Agent 记忆（cases / skills）与用户记忆（
-EverOS 是面向 agents 和 makers 的本地记忆操作系统。它提供一层可携带的 -统一记忆层，让记忆穿过 coding assistants、apps、devices 和 workflows。 -目前它会把对话、文件和 Agent 轨迹保存为可读 Markdown，并同步本地 SQLite -和 LanceDB 索引，用于快速检索和自进化复用。 -
@@ -153,8 +153,8 @@ EverOS 是面向 agents 和 makers 的本地记忆操作系统。它提供一层 Dreaming / Reflection -✅ 即将推出：离线连接信号、压缩历史，并在 session 之间改进 profiles 和 skills -❌ 通常是在线读写 API、retrieval records 或 summaries，而不是离线记忆整理 +✅ 即将推出：在系统空闲或离线时运行，用来连接信号、压缩历史，并在 session 之间改进 profiles 和 skills +❌ 通常是在线读写 API、retrieval records 或 summaries，而不是空闲态记忆整理 @@ -696,7 +696,7 @@ Claude Code 的持久记忆插件。自动保存并回忆过去 coding sessions ## 关注 EverOS EverOS 1.0.0 是更大规模记忆系统路线图的第一个发布版本。Watch 这个仓库， -即可持续关注更深入的离线进化、benchmark releases，以及更多真实 Agent 集成。 +即可持续关注更深入的空闲态和离线进化、benchmark releases，以及更多真实 Agent 集成。 @@ -710,8 +710,8 @@ EverOS 1.0.0 是更大规模记忆系统路线图的第一个发布版本。Watc
Dreaming / Reflection

-在活跃会话之间离线运行，重新审视已存储记忆，连接弱信号，把嘈杂历史压缩成稳定模式， -并持续改进 profile 和 skills。目标是让 Agent 在你离开时也能变得更好， +在系统空闲或离线时运行，重新审视已存储记忆，连接弱信号，把嘈杂历史压缩成稳定模式， +并持续改进 profile 和 skills。目标是让 Agent 在活跃 session 之间也能变得更好， 而不是只在你 prompt 它时才进步。