企业官网建设流程全解析

EverOS 完整解析：把 AI Agent 的长期记忆写成 Markdown 文件，LoCoMo 基准做到 94.42%

【免费下载链接】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 助手关窗即失忆、记忆锁在某个数据库里谁也读不出来、换个应用一切归零——那么"长期记忆"就不只是一个功能，而是一个工程问题。EverOS 给出的答案是：把 Agent 的长期记忆直接写成磁盘上可读、可改、可进 Git 的 Markdown 文件，SQLite 和 LanceDB 只做可随时重建的派生索引。这是一个 local-first 的 Python 记忆运行时，一条 OpenRouter key 就能跑起来，仓库里还带了 4 个基准测试的一键复现脚本。

重启即失忆：Agent 记忆的三个老问题

把"没有记忆层"和"有记忆层"放在一起对比，差异其实很具体：

值得强调的一点：EverOS 区分"用户轨"和"Agent 轨"两条一等公民记忆线——用户的episodes / profile与 Agent 的cases / skills分开存储和检索，而不是把所有东西都塞进一张聊天历史表。8 种记忆类型（episode、atomic_fact、foresight、profile、agent_case、agent_skill、knowledge_document、knowledge_topic）各有独立的落盘策略，详见 docs/how-memory-works.md。

一句话对话是如何变成"可检索文件"的

整条链路可以按"输入 → 处理 → 输出"看，每一步都有明确的责任边界：

输入（缓冲与切分）：POST /api/v2/memory/add把消息追加到按(session_id, app_id, project_id)划分的缓冲区（SQLite），返回accumulated。系统内置边界检测器，话题切换时自动触发提取；会话结束时客户端显式调用/flush强制提取。

处理（一次 LLM 调用 + 异步派生）：一次提取调用产出一个 MemCell，用户的 episode 被同步写成episodes/episode-<日期>.md——/flush返回extracted时文件已在盘上。剩下的原子事实、foresight、用户画像、Agent 案例与技能，全部交给进程内的 Offline Memory Engine（OME）异步派生，策略开关热加载（ome.toml，约 2 秒生效）。

输出（派生索引追平）：cascade 守护进程用文件系统 watcher 盯着 Markdown 树，把每次变更写入 SQLite 的md_change_state队列，按"条目级"做 diff——只有content_sha256变化的条目才重新嵌入并 upsert 到 LanceDB。之后/search读的就是这张索引表。

对应的分层保证是这样的：

三层存储的分工是这套设计的核心约束：

换句话说：删掉全部索引目录不会丢任何记忆，因为没有"导出"这个概念——Markdown 本身就是导出。

实测表现：LoCoMo 94.42、LongMemEval 94.00

仓库自带统一评测器，四个基准各 4 个阶段（ADD → SEARCH → ANSWER → JUDGE），一条命令复现，产出逐对话的 JSONL 和检索 trace，中断可续跑：

DATASET=locomo bash benchmarks/reproduce.sh

当前已发布的数字（micro accuracy，配置见 benchmarks/configs/）：

LoCoMo 上 1,540 题做到 94.42，是目前这套检索与提取管线在长对话多跳问答上的直接体现；LongMemEval 侧重跨会话知识更新，94.00 说明"知识更新"这类难题同样不是短板。需要注意 EverMemBench 一行的对比口径（宏平均 vs 微平均）在 benchmarks/README.md 里有专门说明，引用数字前值得看一眼。

两个值得读的源码细节

cascade：索引永远追得上文件的增量同步。实现位于 src/everos/memory/cascade/，行为细节在 docs/cascade_runbook.md。它跑在服务进程内（不是独立 OS 守护进程），500ms 防抖，变更先进 SQLite 持久队列再消费，所以崩溃重启会重放未完成项；恢复靠 LSN 水位线。运维命令刻意很少：everos cascade status / sync / fix / rebuild四个，其中rebuild从 Markdown 全量重建索引（注意不是删目录了事，队列账本仍会标记done从而跳过文件）。这套机制直接支撑了"手改.md文件"被完全支持——在 VSCode 或 Obsidian 里改一条记忆，保存后只有那一条被重新嵌入。

llm_multiround：让 LLM 当"检索裁判"的多轮检索。默认检索是 BM25 + 向量的 hybrid，而 src/everos/memory/search/llm_multiround.py 走得更远：每一轮由一个可插拔的 decider 看着"问题 + 已召回证据"一次性做三件事——选出承载关键信息的"核心"记忆、判断是否已经够答（停）、或者为仍缺的每个方面各扩一条聚焦子查询。每个子查询独立做 RRF 融合（不用 cross-encoder：实测它把金标答案排到 20 名开外，属于负收益），最终 top-k 组装时"核心优先"是硬保证。decider 目前是开箱 LLM，接口预留了换成小策略模型的 Phase 2——整个检索底座不变，只换裁判，这个循环本身就成了强化学习环境。

顺带一提，记忆侧的"自进化"落在 src/everos/memory/reflection/orchestrator.py：Reflection 策略按 cron 执行 Select → Merge → Re-extract → Deprecate，把同一簇里碎片化的 episode 合并成一段连贯叙事、重提原子事实并把原件标记废弃，默认关闭，ome.toml里一行enabled = true开启。

谁会在什么场景用它

配置梯度也很清晰：只配[llm]就有 add/flush、Markdown 持久化、级联索引和关键词检索；加[embedding]解锁向量混合检索、Reflection 与技能提取；再加[rerank]才有 agentic 检索和 Knowledge Wiki；/health会如实报告缺哪个能力，请求缺失能力时直接返回带说明的 HTTP 422 而不是静默降级。

快速上手：三步从零到第一次检索

第 1 步，安装并先跑离线 demo（无需任何 key）：

pip install everos # 需 Python 3.12+ everos demo # 体验 写入 -> 提取 -> 索引 -> 召回 全流程

第 2 步，从源码跑的话：

git clone https://gitcode.com/gh_mirrors/ev/EverMemOS cd EverMemOS && uv sync uv run everos demo

第 3 步，初始化并启动服务，写入第一条记忆：

everos init # 生成 ~/.everos/everos.toml 与 ome.toml，填入 OpenRouter key everos server start # 前台服务，含 cascade 与 OME

然后在第二个终端对/api/v2/memory/add发一段对话、/flush落盘、/search带"method": "keyword"查回来——单 key 配置下务必用 keyword 方法（hybrid 需要 embedding）。检索成功后直接去~/.everos目录看生成的 Markdown，那就是"记忆的源码"。完整流程与带注释的响应见 QUICKSTART.md。

一句话总结

EverOS 把"记忆必须可读、可改、可迁移"设为硬约束：Markdown 是唯一事实，索引是随时可重建的衍生物，检索由 LLM 裁判多轮把关，LoCoMo 94.42 的分数来自这套管线而非某个调参技巧。如果你正在给 Agent 做长期记忆、又不想把用户数据交给一个黑盒托管服务，它目前是最接近"本地优先 + Markdown 原生"这个组合的开源选择；如果你是研究者，benchmarks/的四阶段复现器和可插拔 decider 接口也留足了实验空间。

【免费下载链接】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