EverOS 架构全解以 Markdown 为唯一事实源的本地优先 AI Agent 记忆层【免费下载链接】EverOSOne portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.项目地址: https://gitcode.com/gh_mirrors/ev/EverOS本文以仓库 docs/overview.md 为骨架结合 docs/architecture.md、docs/how-memory-works.md、pyproject.toml 及src/everos/下的核心实现系统讲解 EverOS 的项目愿景、设计哲学、三层存储分工、算法与编排分离边界、DDD 分层架构以及从写入、级联索引到检索的完整数据流。读完本文你将掌握 EverOS 的总体架构与关键设计取舍能够在自己的 AI Agent 项目中正确理解并使用这一套本地优先、Markdown 原生、用户所有、可自我演化的记忆层。一、VisionAI Agent 的长期记忆就是磁盘上的纯文本 MarkdownEverOS 是一个开源的 Python 记忆框架其核心愿景在 docs/overview.md 中表述得非常直接AI Agent 的长期记忆应当是用户磁盘上的纯 Markdown 文件plain Markdown files on the users disk而不是托管数据库里不透明的行记录opaque rows in a hosted database。这一定位决定了 EverOS 与主流记忆库通常以 API / 向量数据库 / 图数据库为核心的根本差异记忆的物理形态必须是用户能直接看见、直接编辑、可以直接纳入 Git 版本管理的文本文件。用户可以随时cat/vim/grep自己的记忆这种物理可见性是用户信任的根基。从项目描述看EverOS 的定位是为每个 AI Agent 提供一层可移植的记忆One portable memory layer for every AI agent强调本地优先local-first、Markdown 原生Markdown-native、用户所有user-owned并且能够跨应用、跨工具、跨工作流自我演化self-evolving across apps, tools, and workflows。二、Scopev1 范围与 v2 边界docs/overview.md 明确划定了项目边界v1 范围内In scope面向个人 Agent 或小团队small teams的本地部署对话、工作流、Agent 轨迹、文件知识 → 结构化记忆conversation, workflow, agent-trace, file-knowledge → structured memory混合检索BM25 向量 标量过滤hybrid retrieval级联索引同步Markdown 编辑 → LanceDB 亚秒级同步cascade index sync, md edit → LanceDB sub-second双轨记忆用户轨 / Agent 轨Dual-track memory: user-track / agent-track离线记忆演化Foresight / AtomicFact / Profile / Skill以及 Reflection——OME 内部的一种整合策略将相关 episode 合并并重新抽取merges re-extracts related episodes知识库Knowledge base文档上传、解析、CRUD、语义检索CLI HTTP API。v1 范围外Out of scope, 未来 v2多租户 / 群组 / 社区级部署10K 用户端到端云同步End-to-cloud sync规划在 v2分布式部署 / 分片Distributed deployment / sharding。仓库 pyproject.toml 将版本描述为everos — local-first markdown memory framework for AI agents and user chats; lightweight, dev-friendly, small-team与 v1 的个人 / 小团队定位完全一致。当前项目版本为1.2.3而 docs/overview.md 记录的最新稳定版本为 v1.1.4PyPI 发布v1 API 已稳定。三、四大设计哲学3.1 Markdown 作为唯一事实源Markdown as Source of Truthdocs/overview.md 用两句对比式陈述概括了这一原则delete all LanceDB / SQLite files → can rebuild from md delete any md file → memory is gone删除所有 LanceDB / SQLite 文件 → 可以从 md 完整重建删除任何 md 文件 → 记忆永久丢失。这意味着索引与状态都是派生数据derived而非真相本身。用户信任来自物理可见性——用户随时可以cat/vim/grep自己的记忆文件。3.2 三件套存储职责边界清晰Three-piece storage组件职责Role不做什么Does NOT doMarkdown 文件事实源——条目entries、frontmatter不承担检索grep 仅是降级兜底SQLite队列、级联审计日志cascade audit log、敏感数据隔离不做向量 / 全文检索LanceDB向量 ANN BM25 标量过滤单查询混合检索不当事实源丢失后可从 md 重建在 docs/how-memory-works.md 中这一分工被进一步细化为可重建性表格Markdown YAML frontmatter记忆内容本身唯一可移植、可人工编辑的资产是事实源SQLiteaiosqlite.index/sqlite/*.db存系统状态、审计日志、级联队列、边界缓冲、OME 引擎状态可从 markdown 重建LanceDBArrow.index/lancedb/*.lance存向量 BM25 标量列用于检索可从 markdown 重建。由此得出的唯一规则是删除整个.index/目录不会丢失任何记忆——它可以从.md树重建。Markdown 本身就是导出不存在单独的导出流程。3.3 算法与编排分离Algorithm-orchestration separationEverOS 将抽取算法与存储编排严格分离。算法封装在一组独立的 PyPI 包everalgo中everalgo-user-memory/everalgo-agent-memory/everalgo-rank/everalgo-knowledge必装外加可选的everalgo-parserextra承载记忆单元抽取memory-cell extraction、episode 生成、画像演化profile evolution等算法EverOS 直接调用 everalgo 的抽取函数——传入无存储依赖的数据得到结构化结果对少数抽取器episode 和边界检测 boundary detectionEverOS 可以通过PromptSlot 机制覆盖内置 prompteveralgo对存储一无所知knows nothing about storage。在 pyproject.toml 中可以看到这一边界的落地everalgo-user-memory0.4.0、everalgo-agent-memory0.4.0、everalgo-rank0.4.1、everalgo-knowledge0.1.1被锁定为精确版本依赖可选依赖multimodal [everalgo-parser[svg]0.2.1]则负责多模态解析。这一边界的价值在于同一套算法既能驱动本开源轻量版也能驱动其他产品形态EverOS Cloud、OpenClaw 插件等。3.4 DDD 分层架构DDD layered architectureentrypoints → service → memory → infra ↓ component / core / config严格单向依赖由 CI 中的import-linter强制约束。在 pyproject.toml 的[tool.importlinter]中可以看到具体契约[[tool.importlinter.contracts]] name Layered architecture type layers layers [ everos.entrypoints, everos.service, everos.memory, everos.infra, ]docs/architecture.md 给出了各层的具体职责entrypoints/表现层CLI APIservice/应用层用例编排——memorize / search / get / knowledgememory/领域层业务核心——models extract search cascade prompt_slots reflection strategies get eventsinfra/persistence/基础设施层markdown sqlite lancedb 存储适配器横切层被所有层使用、不依赖任何层component/可注入的 LLM / Embedding / parser / config / utils 提供商、core/运行时基座可观测性 / lifespan / context / errors / persistence / middleware、config/配置数据Settings schema default.toml。依赖方向矩阵明确禁止了以下违规路径entrypoints → memory/infra必须经过 service、memory → service、infra → memory以及 infra 内部跨子包如 lancedb → markdown的依赖。另有第二个契约Subpackage internals are private禁止外层直接导入存储子包的内部模块以及OME does not depend on memory/service/entrypoints or sibling infra subpackages契约保证 OME 引擎的独立性。四、为什么采用 src 布局src/everos/pyproject.toml 中[tool.hatch.build.targets.wheel] packages [src/everos]docs/overview.md 给出了采用src/everos/布局的三点理由标准 PyPA 项目结构——用于发布到 PyPI 时的规范做法避免与系统包命名空间冲突——如memory、infra这类常见名字避免开发时意外导入工作区代码——PyPA 推荐防止导入的是源码树而非已安装包的隐患。everos命令入口在 pyproject.toml 的[project.scripts]中注册everos everos.entrypoints.cli.main:app。五、记忆是怎么诞生的写入链路与数据流结合 docs/how-memory-works.md 与 src/everos/memory/extract/pipeline/user_memory.py一条消息变成可检索记忆经历以下阶段POST /add ──▶ unprocessed_buffer (SQLite) ← 消息按 (session, app, project) 累积 │ ├─ boundary detector 触发 ─┐ POST /flush ─────────┤ (或手动强制) │ 一次 LLM 调用 │ ▼ │ extract MemCell ──▶ memcell row (SQLite) │ │ │ ┌──────────────┴───────────────┐ │ ▼ ▼ │ UserMemoryPipeline (同步) AgentMemoryPipeline (异步) │ 立即写 episode .md 发出 AgentPipelineStarted ▼ │ │ (响应在 md 落盘后返回) ▼ ▼ ┌─────────────────── Offline Memory Engine (OME) ───────────────────┐ │ 异步策略写入派生 .md │ │ atomic_facts · foresight · user profile · agent cases · agent skills │ └───────────────────────────────┬──────────────────────────────────────┘ ▼ cascade daemon 监视 .md 树 ▼ md_change_state 队列 (SQLite, 持久化) ▼ 重建 LanceDB 行 ──▶ 可检索/add将消息追加到按(session_id, app_id, project_id)划分的缓冲若边界在本调用中触发则返回extracted否则返回accumulated/flush立即强制边界检测一次抽取 LLM 调用用于聊天 / Agent 运行结束时Episode Markdown 同步写入——/flush返回extracted时episode 文件已经落盘其余一切atomic facts、foresight、profile、agent cases/skills由OME 异步产出cascade daemon将每一次.md写入转成 LanceDB 行使内容可检索。在 src/everos/memory/extract/pipeline/user_memory.py 中可以读到用户轨管道的实现细节UserMemoryPipeline.run对每个预切割的 MemCell 先发出UserPipelineStarted事件让 atomic_fact / foresight / 聚类策略与 episode 工作并行再调用everalgo.user_memory.EpisodeExtractor完成一次整 cell 的 LLM 抽取随后按_unique_user_senders得到的去重用户 sender 做md-only 的 fan-out——每个用户视角在自己的owner_id路径下持有一份相同叙事的副本。抽取失败时_extract_with_retry会以 1s/2s 退避重试最多 2 次针对 everalgo 在 LLM 返回畸形 JSON 时抛出的ValueError。六、八种记忆类型与三种落盘策略docs/how-memory-works.md 列出了当前八种业务记忆类型分别归属用户 / Agent / 全局采用三种落盘模式之一Kind所有者目录 / 文件策略产出方episodeuserepisodes/episode-date.mddaily-log抽取同步atomic_factuser.atomic_facts/atomic_fact-date.md隐藏daily-logOMEforesightuser.foresights/foresight-date.md隐藏daily-logOMEprofileuseruser.md单文件重写OMEagent_caseagent.cases/agent_case-date.md隐藏daily-logOMEagent_skillagentskills/skill_name/SKILL.md技能命名目录OME聚类knowledge_documentglobalknowledge/category_id/title_dirname/index.md知识树knowledge serviceknowledge_topicglobalknowledge/category_id/title_dirname/N_topic_slug.md知识树knowledge service三种落盘策略的取舍每日日志追加Daily-log appendprefix-YYYY-MM-DD.md每条记忆追加一个条目把成千上万的小文件收敛为每天一个文件单文件重写Single-file rewrite固定文件名原地覆盖适合单一持续演进的文档如用户 / Agent 画像技能命名目录Skill-named dir每个技能一个目录因为技能是更丰富的单元主体 可选的references/、scripts/。在磁盘布局上docs/how-memory-works.md 有完整树默认记忆根目录是~/.everos/可用EVEROS_ROOT环境变量或 CLI--root覆盖配置everos.toml由everos init生成。记忆按app_id/project_id预先分区default会落盘为default_app/default_project不同(app, project)空间永不共享目录、检索互不交叉。系统管理目录.index/sqlite lancedb、.tmp/与ome.toml直接位于记忆根下。七、cascadeMarkdown 编辑 → LanceDB 亚秒级同步cascade 子系统保证 LanceDB 与 Markdown 树保持一致随服务进程内运行由应用 lifespan 启动的协程而非独立 OS 守护进程原生文件系统监视器watchdogmacOS 用 FSEvents、Linux 用 inotify感知.md创建 / 修改变更写入 SQLite 的md_change_state表——持久化崩溃后可重放worker 以条目级entry-level粒度排空队列diff 文件、仅对变更条目按content_sha256重新嵌入、upsert LanceDB 行。由于 Markdown 是事实源直接编辑文件完全被支持——在 VSCode / Obsidian / Vim 中打开 episode 修改某个条目后保存daemon 只对那一条目重新索引。系统管理命令见下文 CLI 小节。cascade 的 kind 注册表 是kind 名称 →md schema, LanceDB 绑定, handler 工厂的唯一事实源KIND_REGISTRY元组以声明顺序覆盖全部八种业务 kindepisode、atomic_fact、foresight、agent_case、agent_skill、user_profile、knowledge_document、knowledge_topic。路径匹配使用pathlib.PurePosixPath.match*只匹配单个路径组件、不跨/。其中knowledge_document是纯 SQLite 类型lance_schemaNoneknowledge_topic在嵌入能力不可用时通过embed_or_none写入vectorNone该列自嵌入软依赖迁移起即可空。从 src/everos/memory/cascade/orchestrator.py 可以读到级联的健康模型CascadeHealth.healthy只反映运维健康drain 循环存活、optimize 未卡死、版本清理未停滞而failed_permanent等待cascade fix的 md 文件数被刻意排除在健康判定之外——少量 md 索引失败是真实部署中的正常数据质量积压计入健康信号会导致告警永远为红。八、OME离线记忆演化引擎与 Reflection大多数记忆类型不在请求路径上抽取而是由 OMEOffline Memory Engine稍后派生。当抽取切出一个 MemCell 时发出事件OME 策略拾取后写入各自的 Markdownextract_atomic_facts— 从 episode 抽取单句事实extract_foresight— 前瞻性笔记anticipatory notesextract_user_profile— 聚合user.mdextract_agent_case— 可复用的 Agent 轨迹仅当 cell 内容足够实质过薄的轨迹被有意跳过extract_agent_skill— 将相关 case 聚类为命名技能trigger_profile_clustering/trigger_skill_clustering— 聚类触发器reflect_episodescron默认关闭— 离线记忆整合将聚类内的碎片化 episode 合并为单一连贯叙事、重新抽取 atomic facts、通过deprecated_by废弃原始条目。策略可通过记忆根下的ome.toml免改代码配置约 2 秒内热加载。例如关闭两个策略[strategies.extract_foresight] enabled false [strategies.extract_user_profile] enabled falseOME 自身状态存于.index/sqlite/ome.db运行记录、计数器调度器任务库在.index/sqlite/ome.aps.db拆分以避免同步 APScheduler 写入与异步 OME 写入争用同一文件锁。Reflection即reflect_episodes策略默认 cron 表达式0 2 * * 1每周一 02:00默认关闭。它选择多成员的聚类调用 LLM 将其中 episode 合并为单一叙事写入合并后的 episode 到 markdown重新抽取 atomic facts并用deprecated_by废弃原件。合并后的 episode 使用parent_typecluster、session_idNone。启用方式[strategies.reflect_episodes] enabled true对客户端的一个重要提示/flush返回extracted后episode 很快可查询一旦 cascade 完成索引但 atomic facts / profile / agent cases 要等对应 OME 策略运行——通常是数秒后。需要即时取用时应轮询 / 重试。九、一致性模型写强一致、读最终一致路径保证细节写/add,/flush强一致episode.md在调用返回extracted之前已落盘绝不阻塞在 LanceDB 上读/search,/get最终一致读 LanceDB落后于 md 的时间为 cascade 处理时间——通常亚秒负载下最多约 10–15 秒因此紧跟在产生记录的/flush之后的/search可能查不到该记录。Markdown 无论如何都是持久的索引延迟永不丢数据。若需要读己之写read-your-write请带退避重试或执行everos cascade sync强制排空队列。完整性由几个不变量锚定frontmatterid/entry_id是不可变连接键content_sha256决定条目是否需要重新嵌入system.db中的 LSN 水位线为重建排序持久化的md_change_state队列是可重放的审计轨迹。十、零外部服务与检索无需运行任何数据库服务器、消息代理或向量服务向量 ANN、全文 BM25、标量过滤全部在嵌入式 LanceDB引擎内一次查询完成SQLite 是本地文件。整个栈就是一个目录可整体复制、备份或把用户可见部分纳入 Git。pyproject.toml 对 LanceDB 版本有明确约束lancedb0.34.0,0.35.0注释中解释了原因——0.35.0 内嵌 lance-rust v9存储 / 编码大跳变尚未稳定发布而 0.32–0.34 存在 compaction offset-overflow 回归0.34.0 通过with_positionFalse的 FTS 方案安全运行同时不能放宽到 0.34 以下旧版 lance 读不了 v8 数据。这也是阅读 docs/cascade_runbook.md 时应特别注意的版本前提。需要说明的是当前没有自动的grep 兜底搜索——如果 LanceDB 索引不可用正确的做法是从 markdown 重建索引是派生、可丢弃的而非依赖降级检索路径。十一、记忆根目录布局默认记忆根~/.everos/EVEROS_ROOT或 CLI--root覆盖的完整布局docs/how-memory-works.md~/.everos/ ← 记忆根 (EVEROS_ROOT) ├── default_app/ ← app_id (default → default_app) │ └── default_project/ ← project_id (default → default_project) │ ├── users/ ← 用户可见事实源 │ │ └── user_id/ │ │ ├── user.md 单文件 (profile) │ │ ├── episodes/ │ │ │ └── episode-YYYY-MM-DD.md 每日日志追加 │ │ ├── .atomic_facts/ 每日日志隐藏 │ │ │ └── atomic_fact-YYYY-MM-DD.md │ │ └── .foresights/ 每日日志隐藏 │ │ └── foresight-YYYY-MM-DD.md │ ├── agents/ │ │ └── agent_id/ │ │ ├── .cases/ 每日日志隐藏 │ │ │ └── agent_case-YYYY-MM-DD.md │ │ └── skills/ 技能命名目录 │ │ └── skill_name/SKILL.md ( references/ scripts/) │ └── knowledge/ ← 共享 / 全局 │ ├── .index/ ← 系统管理可重建gitignore │ ├── sqlite/ │ │ ├── system.db 状态 / 审计 / cascade 队列 (md_change_state) / 缓冲 / LSN │ │ ├── ome.db OME 状态 │ │ ├── ome.aps.db APScheduler 任务库拆分以避免锁竞争 │ │ └── ome.db.lock OME 单引擎守护portalocker │ └── lancedb/ │ └── kind.lance/ 每种 kind 一张 Arrow 表 │ ├── ome.toml ← 用户可编辑的 OME 策略覆盖热加载 └── .tmp/ 原子写入暂存路径管理器是 src/everos/core/persistence/memory_root.py上述每个路径都是其上的属性MemoryRoot.ensure()创建运行期目录.index/{sqlite,lancedb}/、.tmp/用户可见目录在首次写入时出现everos.toml/ome.toml由everos init创建。值得注意的历史差异索引目录是.index/点前缀不是旧文档中的_index/cascade 队列与 LSN / 审计状态位于 SQLitesystem.db的md_change_state表不存在.cascade.log/.manifest.json文件app/project嵌套始终存在没有名为reindex的命令everos cascade rebuild承担从 markdown 重建索引的职责。十二、配置体系速览配置查找顺序src/everos/config/default.toml 头部注释shipped defaults最低优先级→root/everos.toml用户配置→ 环境变量EVEROS_SECTION__KEY如EVEROS_SQLITE__BUSY_TIMEOUT_MS10000→ 编程式 init 参数最高优先级。核心配置节均可在everos.toml或环境变量中覆盖配置节关键项与默认值说明[memory]timezone UTC日期分桶与时间戳的唯一时区来源不读系统TZ[api]host 127.0.0.1,port 8000默认仅回环监听EverOS 不内置认证暴露0.0.0.0前必须自行放置网关 / 认证层[sqlite]journal_mode WAL,synchronous NORMAL,busy_timeout_ms 5000等连接级 PRAGMA 配置[lancedb]read_consistency_seconds默认不检查0为严格每次读都检查更新0为最终一致间隔秒[llm]model openai/gpt-4.1-mini,base_url https://openrouter.ai/api/v1OpenAI 协议客户端api_key必填[multimodal]model google/gemini-3-flash-preview,max_concurrency 4多模态解析独立 LLMoffice 文档需宿主安装 LibreOfficesoffice无头转换[embedding]model Qwen/Qwen3-Embedding-4B,base_url https://api.deepinfra.com/v1/openai加配后启用向量 / 用户混合检索、reflection、技能抽取[rerank]provider deepinfra,model Qwen/Qwen3-Reranker-4Bprovider可选deepinfra/vllm加配后启用 agentic 检索与 Knowledge Wiki[boundary_detection]hard_token_limit 65536,hard_msg_limit 500透传给everalgo.BoundaryDetector.adetect[memorize]mode agent,session_lock_timeout_seconds 360.0chat仅用户轨agent双轨模式切换需重启[knowledge]max_upload_bytes 52_428_80050 MiB超限上传在解析前以 HTTP 422 拒绝[clustering]threshold 0.65,time_window_days 7.0几何聚类余弦阈值与时间窗[cascade]optimize_rebuild_interval_seconds 43200.0等维护节奏约束挂起调用的 deadline 刻意不可配置置于代码旁并按实测标定[observability]enabled false,exporter otlp_http,capture_content falseOpenTelemetry OTLP/HTTP 导出厂商中立capture_contenttrue才输出查询 / 抽取记忆 / md 路径能力分层README 中What works with one key?仅有[llm]即达 Tier 1核心记忆流 关键词搜索加[embedding]获得向量 / 用户混合检索、reflection 与技能抽取再加[rerank]获得 agentic 检索、默认 agent 混合检索与 Knowledge Wiki再加[multimodal]与 parser extra 则支持图片、PDF、音频、office 文件摄取。缺失的可选能力由/health报告请求依赖缺失能力的特性时返回清晰的 HTTP 422。十三、CLI 与 HTTP API最小操作面CLI 命令集很小docs/cli.md命令作用everos init生成起始配置文件everos.tomlome.toml--root path指定记忆根everos server start运行 HTTP APIcascade 与 OME 随其启动everos cascade status队列 / LSN 摘要everos cascade sync立即排空 cascade 队列强制 md → LanceDBeveros cascade fix列出失败行 / 重新入队可重试行everos cascade rebuild从 markdown 重建整个索引漂移 / 损坏恢复两个易混淆点docs/how-memory-works.md 有专门警示没有everos reindex或everos flush命令。重建整个索引请用everos cascade rebuild——它会删除 LanceDB 表并从 md 重建包括队列已标done的条目且保留未抽取的缓冲消息。裸rm -rf memory-root/.index/lancedb是不够的cascade 队列仍显示这些文件为done扫描器会跳过它们索引会以空结果回来。Flush 是 HTTP 端点POST /api/v2/memory/flush不是 CLI 命令——它强制的是会话缓冲的抽取与cascade sync强制索引同步是两回事。HTTP 业务端点位于/api/v2前缀下/api/v1仍可解析到同一批 handler属遗留别名未来大版本可能移除新代码请写/api/v2。核心端点POST /api/v2/memory/add # 追加消息到会话缓冲 POST /api/v2/memory/flush # 强制抽取 POST /api/v2/memory/search # 混合 / 关键词检索 GET /api/v2/memory/get # 按 id / 过滤条件取记忆从 README 的快速开始流程可以看到最小 Tier 1 场景安装everos→everos init填入一个 OpenRouterapi_key→everos server start→curl http://127.0.0.1:8000/health看到status:ok→ 依次调用/add、/flush、/search此场景下capabilities.llm为 trueembedding 与 rerank 为 false检索请保持method: keyword因为 API 默认 hybrid 搜索需要 embedding provider。写入的 Yosemite 记忆可以在~/.everos下直接打开生成的 Markdown 文件检查。不配置任何 provider 也能体验完整记忆生命周期everos demo启动全屏 TUI走 ingest → extract → index → recall 真实流程everos demo --plain为非交互预览everos demo --live则连接运行中的服务器走真实 add/flush/search因使用混合检索需先配置 embedding。十四、与同类项目的定位差异docs/overview.md 明确列出了可比较项目及差异下表为原文整理链接已省略以避免外部跳转项目定位差异mem0API-first 记忆服务mem0 存储在向量数据库EverOS 存储在 md 文件LettaAgent OS含 Core/Recall/ArchivalLetta 用 PostgresEverOS 用 Markdown 文件系统MemOS多分类记忆MemOS 面向企业EverOS 面向轻量单用户 / 小团队memsearchmd-first 搜索引擎与 EverOS 最接近EverOS 额外提供记忆抽取不止搜索需要强调这些差异描述仅代表 docs/overview.md 自身的定位陈述不构成对同类项目的优劣评价。十五、路线图与当前状态版本里程碑v0.1 (MVP)Phase 1 核心循环markdown lancedb cascade episode 抽取v0.2完整抽取管道workspace / agent / knowledge演化框架v0.3生产加固完整 CLI、HTTP API、Obsidian 演示v1.0稳定 API、PyPI 发布、完整文档v1.1知识库 Reflection离线记忆整合v2未来经 EverMe独立项目实现 edge-to-cloud 同步状态最新稳定版为v1.1.4PyPIv1 API 已稳定docs/overview.md仓库内当前开发版本为 1.2.3pyproject.toml。十六、进一步阅读docs/architecture.md — DDD 分层、依赖规则、错误处理架构与异常层次AppError四分支DomainError / InfrastructureError / CapabilityError / ConfigurationError由entrypoints/api/exception_handlers.py统一转为规范错误信封docs/how-memory-works.md — 存储栈、路径布局、写读管道与一致性保证docs/storage_layout.md — 文件编码、frontmatter 底盘、entry-id 格式、原子写语义docs/api.md — HTTP 契约docs/cascade_runbook.md — 同步队列运维手册docs/engineering.md — 构建、测试、CI、约定docs/migration-to-1.0.0.md — 1.0.0 之前的旧版 API 迁移说明README.md — 快速开始与完整使用案例【免费下载链接】EverOSOne portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.项目地址: https://gitcode.com/gh_mirrors/ev/EverOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考