13.5k 星 EverOS：Agent 记忆为什么要独立

关键词：EverOS、EverMind、Agent 记忆层、Markdown、SQLite、LanceDB、DeepSeek Harness 插件、Reflection、LoCoMo

2026年10月26日，一个叫 EverOS 的开源记忆运行时因 13.5k 星的仓库读数被集中讨论：它给 DeepSeek Harness 等工具提供长期记忆插件，把对话、文件和执行轨迹落成可读可改的 Markdown，再配 SQLite 与 LanceDB 做检索。先厘清一件事——这 13.5k 星属于 EverMind 的 EverOS 主仓库，不是 DeepSeek 出的插件，也不是那个插件自己的星数。对做 Agent 平台的开发者，值得拆的是记忆归谁；对每天在几个编程助手之间来回切换的人，值得拆的是这份记忆能不能带走；对选型者，更该先看清基准数字是在哪套口径下跑出来的。

---

目录

• 一、先把三个名字分开：项目、星数、还有记忆的所有权
• 二、把记忆从应用里搬出来，要拆成三层
• 三、用户记忆与 Agent 经验，为什么不能混着存
• 四、存得越多越难用：离线反思与准入闸门
• 五、13.5k 星和 93.05%，分别该怎么读
• 六、同一条赛道上还有谁：按记忆归谁切
• 七、现在就试：零密钥 demo 到接进 DSH
• 八、把「装上就有长期记忆」打个折
• 收束：记忆是资产，不是功能

---

一、先把三个名字分开：项目、星数、还有记忆的所有权

第一个要分开的是出品方。DeepSeek Harness（dsh）是 DeepSeek 在 2026 年 8 月开源的 Agent 运行时，MIT 许可、TypeScript、底层是 Cordis 的可组合插件架构，口号是「一切皆插件」。EverOS 是另一家 EverMind 的独立项目，Apache-2.0、Python、2025 年 10 月建仓，官方给自己的定位是「给每个 AI Agent 用的可移植记忆层：本地优先、Markdown 原生、用户持有、可自我演化」。两者通过一个插件 @everos-ai/dsh-plugin 接上，主仓库里还能看到 deepseek-harness、hermes、openclaw、mcp、clawdbot-skill 这些集成目录。把插件当成 dsh 的官方能力，后面判断它的依赖、许可和迭代节奏都会错位。

第二个要分开的是星数。13.5k 是 2026年10月26日 前后的公开读数；另一份 2026年10月25日 的仓库快照是 13,600 星、947 fork，45 天增加 741 星。更早的第三方记录里还有 7.7k、8.7k、10.5k 等读数。星数是快照，不同时间点本来就不一样，它说明关注度，不说明召回质量，更不说明适不适合你的场景。

记忆到底该归谁？这才是全篇的主轴。讨论 Agent 记忆通常有两种问法：一种是「怎么让下一次会话别把昨天的事忘了」，落点是捕获、压缩、注入这条上下文链路；另一种是「这份记忆能不能不属于任何一个工具、任何一家厂商」，落点是存储形态、所有权与迁移成本。两种问法都成立，但导出的架构完全不同——前者会把记忆做进某个助手的钩子里，后者必须把它做成一个能独立启动、独立读写、独立版本化的东西。EverOS 走的是第二条路，这也是它值得单独拆一遍的原因。

把事实、推断、未知摆在一处，后面才好判断边界：

• 能确认的：Apache-2.0 许可、Python 3.12+、Markdown + SQLite + LanceDB 的三层栈、按 user_id / agent_id / app_id / project_id / session_id 五维检索、Reflection 默认关闭且建议每周最多一次、1.6.0 加入的 Agent 经验准入闸门、以及统一 harness 下的公开基准快照分数。
• 我的推断：它真正的差异不在「记得久」，而在把记忆做成用户手里的文件资产。这个选择直接决定了它更适合单机、单人、多工具切换，而不是多租户共享。
• 目前没有公开信息的：中文语料上的抽取质量与召回表现、连续跑一整年之后的记忆膨胀与反思质量、多用户并发下的稳定性与单任务成本。

二、把记忆从应用里搬出来，要拆成三层

不少记忆方案把状态藏在 API、向量库、图库或者一个管理面板后面，用户只能通过 SDK 或界面间接读写。EverOS 把这件事反过来做：Markdown 文件是唯一的事实源，SQLite 管运行状态，LanceDB 管检索索引，三者由一个叫 cascade watcher 的后台进程串起来。

（图一：事实源、运行状态、检索索引三层分开。改记忆不必碰数据库，代价是要养两份索引与一个同步进程。）

这么拆的收益很直接。发现模型把项目约定记错了，用编辑器打开那个 .md 文件改掉就行，watcher 会把改动同步进索引；整个 ~/.everos 目录可以 git init 纳入版本管理，记忆的每次改动都有历史，也可以直接当 Obsidian 的 vault 打开翻看。索引丢了能重建，源文件还在——这一点对需要审计、需要交接、或者单纯不信任黑盒的团队，比多几个百分点的召回率更有说服力。

代价同样清楚：两份索引加一个后台进程；Markdown 与索引之间是最终一致性，异步同步通常 1 到 3 秒，需要严格顺序就得在应用层自己加同步屏障；watcher 挂掉或者漏掉一次文件编辑，索引可能变旧，而公开文档里没写这类情况的恢复机制。做架构的人该记住的是这个因果：可编辑性不是白来的，它是用「事实源与索引分离」换的，而分离必然带来同步问题。

还有个容易被忽略的默认值。LanceDB 支持向量、BM25 全文与条件过滤，但只配一把 LLM 密钥的最小档里，capabilities.embed 和 capabilities.rerank 都是 false，开箱能用的只有关键词检索。想要语义检索、想要跨措辞命中，得另外补嵌入模型与重排模型。把「混合检索开箱即用」当成默认能力，第一次上手就会对不上。

五维正交检索是另一处设计上的差异。它不按 thread 或 namespace 一刀切，而是允许按用户、Agent、应用、项目、会话五个维度任意组合——既可以把某个 Agent 攒下的 cases 与另一个彻底隔离，也可以把某位用户在所有会话里的痕迹一次拉出来。多工具共用一份记忆时，这个粒度才是「谁的记忆」能说清楚的前提。

三、用户记忆与 Agent 经验，为什么不能混着存

为什么非要把两条轨分开？因为两类信息回答的根本不是同一个问题。用户轨放在 episodes 和 profile 里，回答「这个人是谁、他希望活怎么干」；Agent 轨放在 cases 和 skills 里，回答「之前做过什么、哪条路走得通、下次能借鉴什么」。前者是约束，后者是经验。举个具体的：要求所有服务统一某套接口规范，这是项目背景，属于用户侧；调试时发现某个依赖版本有兼容性问题，这是执行经验，属于 Agent 侧。全塞进一坨聊天历史，检索时两类证据会互相稀释。

（图二：三条容易混的边界。记忆不等于备份，用户轨不等于 Agent 轨，存下不等于学到了。）

有个公开的社区实测把这条链路演示得很具体：开发者用一段中文口语把几条配图踩坑规则写进去，约 6 秒后可被检索到，系统还顺手生成了一份用户画像；换一种问法「图片太大怎么办」能捞回对应条目，用英文问 why did my image generation request fail 也能捞回中文记录；同一份记录里混合检索不到 100 毫秒，换成更聪明的智能检索约 5 秒一次。这些是个人实测口径，不是基准数据，但它说明了一件事：抽取之后的记忆是结构化的条目，不是把上一轮对话整段塞回提示词。

更值得琢磨的是经验怎么变成技能。同一位实测者录了两次生图过程，约一分半后后台多了两个 Case，并自动提炼出一份带步骤和判断分支的 SOP，里头写着「主动排除文字、数字、品牌标识」以及「图片过大就转 JPEG」。但他也记下了两处不完美：第一次录制格式没写对，一个 Case 都没生成，照官方文档重录才成功；自动提炼出的 Skill 只覆盖了「出过错又被修好」的步骤，过程里没报错的两条命令压根没进去。经验沉淀依赖输入格式与失败信号，不是把轨迹丢进去就自动长成手册。

2026年10月28日的 1.6.0 更新正好对着这个问题加了一道闸门：[agent_memory] case_gate_enabled（默认关闭）让抽取模型判断这次 Agent 会话是否真的把任务做成了，只有被准入的才变成 case 并驱动技能抽取；没通过的不再沉默，system.db 会记下 case_skip_reason 与 case_extracted_at，跳过原因包括 too_few_tool_rounds、filter_rejected。同一版本还规定「一个记忆单元只定一种语言」，按 Unicode 字符脚本检测后冻结成 user.md 里的 primary_language。我的判断是，这一步比「存得久」重要得多：记忆系统最危险的地方从来不是遗忘，而是把一次失败的做法固化成下次默认执行的流程。

四、存得越多越难用：离线反思与准入闸门

记忆系统有个反直觉的规律：全量原样保存，时间长了反而更难用。重复内容、已经过时的结论、互相矛盾的记录会一起堆起来；每次检索把这些都塞进上下文，既费 token 又干扰判断。EverOS 的应对是离线反思（Reflection），而官方文档里那句提醒我认为比功能本身更值钱——默认每周最多跑一次，因为每轮都是一次有损的模型合并，反复重新巩固同一批记忆会让叙事变差，不会变好。

（图三：离线反思五步。默认关闭、每周一次、有损合并，每一步都留了可回查的凭据。）

具体流程是这样的：在 ome.toml 里把 [strategies.reflect_episodes] enabled 设为 true 才启用，默认每周一 02:00 跑一次，也可以写 cron 改时间，配置热加载无需重启。运行时把同一相似簇里的多个 Episode 合并成一条按时间组织的新叙事，一个簇至少要有 2 名成员；遇到过期信息按最新状态收敛；被替换的旧碎片软归档、移出默认检索。产物仍然是一个可以直接打开的 .md 文件，条目标着 parent_type: cluster，普通会话产生的则是 memcell。每轮还会往 SQLite 写一条 reflection_report 审计记录，记下簇 ID、合并模式、来源条数、产物 ID 与被归档的事实数。

健壮性上也留了余地：合并要调语言模型、重聚类要调嵌入模型，某个供应方不可用时跳过受影响的簇并记日志，不让整轮任务失败；索引异步跟上，通常 1 到 3 秒。把「整理」这件事也交给模型，等于新引入一层不容易核对的改动，所以那些审计字段和 Markdown 产物不是装饰，是让有损合并能被回查的唯一凭据。真要上自动周任务，我建议先手动触发一次 /api/v1/ome/trigger、把 reflection_report 翻一遍，看看它合并出来的叙事是不是你认的那个意思，再决定要不要让它自己跑。

五、13.5k 星和 93.05%，分别该怎么读

13.5k 星说明什么？说明这个项目被看见了，别的不说明。同一项目在不同时间点的公开读数从 7.7k、8.7k、10.5k 一路到 13.5k、13.6k，本来就是不同快照；把它当成能力刻度，或者拿它和另一款工具的星数直接比高低，得到的结论没有工程含义。

真正要小心的是跑分口径。EverMind 官方博客给出的自报数字相当亮眼：LoCoMo 93.05%、LongMemEval-S 83.00%、HaluMem 召回 90.04%，检索 p95 低于 500 毫秒，成本约为替代方案的十分之一。但 OmniMemEval 在 2026年10月12日 核对的那份快照里，所有后端统一用 GPT-4.1-mini 作答、GPT-4o-mini 评判，EverOS 的 LoCoMo 是 82.75%、LongMemEval-S 是 80.40%，排在 MemOS 的 88.83% / 89.20% 之后。

（图四：统一答案模型与裁判下的 LoCoMo 分数。换一套 harness，厂商自报的高分会明显回落。）

项目 / 基准	厂商自报	统一 harness 快照	该注意什么
EverOS / LoCoMo	93.05%	82.75%	答案模型、裁判与上下文预算都变了
EverOS / LongMemEval-S	83.00%	80.40%	这一项两者差距反而最小
Mem0 云版 / LongMemEval	94.4%	56.00%	同一份快照里落差最大的一行
Zep / Graphiti / LoCoMo	94.7%	63.83%	时间推理强项在统一口径下也没保住高分

这不是 EverOS 一家的问题，而是整个记忆层赛道的普遍现象：换到别人搭的 harness，自报分数普遍掉一大截。裁判模型、答案模型、允许注入多少上下文 token、是否允许挑选重试，每一项都能改写结果；行业追踪站自己也提醒过，某些对比论文是厂商自己跑的、不同裁判之间不能算严格对齐。所以 93.05% 和 82.75% 不是「谁在撒谎」，而是两把不同的尺子，直接相减没有意义。选型时该做的是拿自己的语料和查询，在同一套答案模型下把两三个候选各跑一遍。

六、同一条赛道上还有谁：按记忆归谁切

把这几家按「分数谁高」排队，选出来的往往不是能用的那个。换个维度看更清楚：这份记忆放在哪、归谁、换工具时还在不在、记错了能不能一行改掉。

方案	记忆放在哪	归谁所有	换工具能带走吗	记错了怎么改	更贴合的场景
claude-mem	SQLite + FTS5，可选 Chroma	贴某个编程助手的钩子生态	较弱	走工具接口	单一编程 Agent 的跨会话连续性
mem0	向量 + 图，图记忆在云付费档	以平台托管为主	中	走 API	应用内用户画像与个性化
Zep / Graphiti	双时态知识图	托管 Context Lake	中	走 API	事实有效期、时间推理
Letta	内嵌在 Agent 状态模型里	与运行时绑定	较弱	Agent 自己编辑记忆块	要完整 Agent 运行时
ReMe / memU / MemOS	文件式或分层蒸馏	多为自托管	中到强	部分可直接改	长程基准与渐进压缩
EverOS	Markdown + SQLite + LanceDB	用户文件，Apache-2.0	强	直接编辑 .md	多工具切换、需要审计与迁移

这张表里最该盯的是后三列。平台自带的长期记忆（各家桌面端与网页端陆续都加了）用起来最省事，换来的是记忆跟着账号走、不跟着你走；贴钩子的方案能把一个助手的会话接得很顺，但换个客户端就要重来；把记忆做成独立文件的方案，代价是自己得养服务、管同步、盯索引。MCP 这类标准化通路让跨工具交换上下文变容易了，但它解决的是「怎么传」，不解决「传的这份东西归谁、存多久、能不能改」。

我的看法是，这条赛道正在从「功能」分化成「基础设施」，分水岭就是记忆有没有独立于应用的生命周期。判断一个方案属于哪一边，问一句就够了：把那个 Agent 工具整个卸掉，之前攒下的东西还在不在、还能不能打开看。

七、现在就试：零密钥 demo 到接进 DSH

没有 API 密钥能跑吗？能。官方给了一条零依赖的演示路径，不需要密钥、不需要起服务，直接看一条记忆怎么走过写入、抽取、索引、召回。环境只要 Python 3.12+。

uv pip install everos
everos demo

第二条路是完整的最小配置。everos init 会生成 ~/.everos/everos.toml 与 ~/.everos/ome.toml，模型名和端点已经填好，只补一个 api_key：

[llm]
model = "openai/gpt-4.1-mini"
api_key = ""
base_url = "https://openrouter.ai/api/v1"

everos init --root ./my-memory
everos server start
curl http://127.0.0.1:8000/health

端点写 /api/v2，/api/v1 是兼容旧集成的别名，官方已注明未来可能移除。下面这段把「加一条记忆 → 会话结束冲刷 → 换个说法搜回来」跑通，timestamp 用毫秒时间戳动态生成：

import time
import httpx

BASE = "http://127.0.0.1:8000/api/v2"
scope = {"session_id": "demo-001", "app_id": "default", "project_id": "default"}

httpx.post(f"{BASE}/memory/add", json={**scope, "messages": [
    {"sender_id": "alice", "role": "user",
     "timestamp": int(time.time() * 1000),
     "content": "项目统一用 REST 风格接口，异常一律返回 200 加错误码"}]})
httpx.post(f"{BASE}/memory/flush", json=scope)
res = httpx.post(f"{BASE}/memory/search",
                 json={"user_id": "alice", "query": "接口风格怎么定", **scope})
print(res.json())

跑完去 ./my-memory 目录下翻那个 .md 文件，比看任何架构图都直观。任何 OpenAI 兼容端点都能替换 base_url，官方模板里点名了 OpenAI、vLLM、Ollama 桥接与 DeepInfra；1.6.0 起 [llm] 变成必填，缺 api_key 或 base_url 会直接抛 LLMNotConfiguredError 并以退出码 3 停下，属于刻意的快速失败。

要接进 DeepSeek Harness，再走插件这一步：

uv tool install everos
everos init
everos server start
dsh plugin --profile web add @everos-ai/dsh-plugin

这里有个容易被低估的细节：EverOS 是 Python 侧的本地 HTTP 服务，dsh 是 Node.js / TypeScript 侧的 Agent 运行时，两边跨语言、跨进程靠插件和 HTTP 连起来。「把记忆独立出来」落到工程上就是这个意思——它不再是被编译进某个助手里的一段代码，而是一个可以随时换掉、也可以同时服务好几个客户端的进程。

动手前有几处坑值得先记下来。网上不少教程讲的是早期重型版，要 docker-compose 拉起 MongoDB、Elasticsearch、Redis 一整套，现在的 1.0.0 轻量版已经去掉这些外部依赖，照老教程操作第一步就会卡住。Office 文档（.docx / .pptx / .xlsx）解析依赖系统装 LibreOffice，PDF、图片、音频不受影响。配置从环境变量迁到了 TOML 的 [cascade] / [ome] 段，没迁走的旧 EVEROS_DISABLE_CASCADE 会静默地把 cascade 重新打开。版本节奏也快，v1.2.3 在 2026 年 8 月、v1.3.1 在 9 月、v1.5.0 与 v1.5.1 在 10 月 21、22 日、1.6.0 在 10 月 28 日，minor 版本之间可能有破坏性改动，写脚本前先看仓库根目录的 QUICKSTART.md。

八、把「装上就有长期记忆」打个折

第一，开箱只有关键词检索。 最小档里嵌入与重排能力都是关的，跨措辞、跨语言的召回要另外配模型与密钥。社区评测提到完整能力会用到多把钥匙：语言模型与多模态走一个端点，嵌入、重排走另一个。这不算缺陷，但「装上就语义检索」的预期需要校准。

第二，同步是有代价的。 文件与索引之间最终一致，通常 1 到 3 秒；watcher 漏掉一次编辑，索引可能悄悄变旧，公开文档没给出这类故障的恢复办法。要严格顺序、要强一致、要多机共享，都得自己补。本地优先这套设计本来就没打算服务高并发多租户或亚毫秒 SLA。

第三，记忆不会自动越攒越准。 抽取、合并、技能提炼都依赖模型，而 Reflection 官方自己定性为有损合并，还明确建议每周最多一次；社区实测里技能只总结了出过错又被修好的步骤，输入格式不对时连一个 Case 都生成不了。记忆会攒出偏的、过时的、自相矛盾的东西，准入闸门与审计记录是缓解，不是免疫。

第四，跑分不能当采购依据。 厂商自报与统一 harness 的落差是行业性的，中文语料上的抽取质量、连续运行一年后的膨胀幅度、每千次记忆写入的实际成本，都没有公开独立数据。真要上生产，得自己拿真实任务量一遍。

第五，项目还年轻。 2025 年 10 月建仓，一年不到，版本密集迭代，配置段与 API 前缀都在迁。Apache-2.0 解决的是能不能商用、能不能改，不解决接口稳不稳。把记忆层放进关键链路之前，先想清楚升级时怎么回滚、索引怎么重建、旧数据怎么验。

收束：记忆是资产，不是功能

把 13.5k 星记成「DeepSeek 又出了个插件」会漏掉整件事：真正的变化是记忆开始拥有独立于应用的生命周期——可读、可改、可版本化、能跨工具带走。对天天在几个编程助手之间切换的人，值得先跑一次零密钥 demo，翻翻 Markdown 里到底写了什么，再决定要不要接进日常链路；对做平台的人，更该抄的是用户轨与 Agent 轨分离、以及经验准入闸门这两条设计，而不是三层存储的具体选型。还没被回答的是中文语料上的召回质量、长期运行后的膨胀与成本，这些得自己拿真实任务量一遍，榜单给不了。

标签：EverOS、Agent 记忆、Markdown、LanceDB、DeepSeek Harness、Reflection、LoCoMo、记忆层选型