做Agent 工作流这段时间我一直有个挥不去的感觉——我们好像一直在解决一个错误的问题。每次 Agent 开新会话就失忆大多数人的第一反应是往prompt 里塞更多东西把上次的决策记录塞进去把项目背景塞进去把之前 踩过的坑也塞进去。上下文窗口越来越大大家也就越塞越多好像只要窗口足够大问题就能解决。但这个逻辑本身就是错的。窗口大小解决的是单次会话能处理多少信息而不是信息能不能跨会话保留。这是两个性质不同的问题。把历史记录手动塞进 pro mpt本质上是用人力去弥补系统缺失的持久化能力——会话一关那些记忆照样清零。下次打开重新塞。这不是记忆这是搬运。我自己做嵌入式出身后来做储能系统现在碰 AI 工程化。这几个方向有一点是共通的如果你一直在用应急手段解决一个结构性问题迟早要还债。意识到这一点之后我开始认真找专门解决 Agent 持久记忆的工具最后选了 EverOS。一、为什么不自己搭一个最直觉的方案是自己搭选个向量数据库写一套存取逻辑把 Agent 需要记住的东西序列化进去。我之前也考虑过这个方向但做过几个 RAG 项目之后对自建向量库这件事有了一些不太美好的经验。核心问题不是搭不起来而是出问题之后你搞不清楚发生了什么。向量数据库是典型的黑箱你喂进去一段文本它在里面做嵌入、建索引检索时给你返回一批相似度分数。理想情况下这个流程很流畅但一旦出了问题——检索结果不对、记忆里存了脏数据、Agent 的行为开始漂移——你几乎没有直接的手段去看清楚里面到底存了什么。调试靠猜修复靠蒙。这对我来说是不可接受的。工程系统的一个基本要求是可观测性你能知道里面在发生什么能介入能修。一个你看不进去的记忆系统出了问题等于在排查一个黑盒——这种感觉做过硬件调试的人大概都懂。EverOS 吸引我的原因正是它在这个问题上的设计取向记忆的最终载体是 Markdown 文件你能cat能 grep能用 Git做版本管理能用编辑器直接改。二、它怎么工作的EverOS 的存储是三层Markdown 作为唯一可信来源SQLite 管理状态和处理队列LanceDB 负责向量检索、BM25全文索引和标量过滤。三层里最重要的是第一层。所有记忆最终都会落成 .md 文件结构化、可读、可编辑。SQLite 和 LanceDB是查询加速层让检索速度不至于太慢但记忆里有什么这个问题直接去看 Markdown 就能回答。检索策略是混合的BM25 处理关键词向量 ANN 处理语义相似度LanceDB 统一承载并支持按 user_id等维度做精确过滤。这意味着同一条记忆就算你换了问法也能被召回。官方在LoCoMo 上跑出了93.05%LongMemEval-S 是83.00%HaluMem大概 90% 出头数据说得过去但我真正在意的不是这几个数字而是记忆我能直接打开看这件事。记忆的组织方式上EverOS 做了一个我觉得比较合理的分离users/ 目录存用户相关的情景记录和画像agents/ 目录存 Agent 自身积累的案例和技能。两条线分开抽取相互不污染。用户的偏好变了改用户画像Agent 学到了新的处理模式更新Agent 的案例库。这个结构比把所有东西混在一起要清晰得多。三、实际怎么装环境要求不高Python 3.10以上推荐 3.12uv 包管理器两个 API key——OpenRouter 管LLM 和多模态DeepInfra管向量化和重排。手头有 OpenAI key或者本地跑着 Ollama 的不用换账号EverOS 兼容所有 OpenAI 协议端点改一下配置里的 base URL 就行。uv 没装过的话curl -LsSf https://astral.sh/uv/install.sh | sh装EverOS 有两种方式按需选一个。想读代码或者做改造git clone https://github.com/EverMind-AI/EverOS.git cd EverOS uv sync source .venv/bin/activate只是接进项目用uv pip install everos然后初始化everos init会生成一个 .env 文件填进两个 key。顺手把 .env 加进 .gitignore这是基本操作但忘掉的概率很高提前说一次。验证环境everos --help能看到命令列表就装好了。四、跑通核心流程启动服务everos server start这个终端保持运行新开一个做健康检查curl http://127.0.0.1:8000/health返回 {“status”:“ok”} 说明服务起来了。接下来写入一条记忆。注意带上 user_id这个参数决定这条记忆归属于谁也是多用户场景下记忆不串台的关键# 确切命令以仓库根目录 QUICKSTART.md 为准 everos memory add --user-id alice Alice 写代码偏好 TypeScript不用 any 类型这条命令触发后EverOS 在后台做了三件事对内容做结构化抽取落盘成 Markdown同步进SQLite 和 LanceDB的索引。现在关掉这个会话模拟第二天打开用自然语言搜everos memory search --user-id alice Alice 有什么编程偏好如果能搜回刚才那条记录跨会话记忆就跑通了。五、记忆文件实际长什么样完成上面的步骤之后去看一下 ~/.everos~/.everos/ └── default_app/ └── default_project/├── users/alice/ │ ├── user.md # Alice 的用户画像 │ ├── episodes/ # 按天记录的情景日志 │ ├── .atomic_facts/ # 原子事实隐藏目录 │ └── .foresights/ # 预测性记忆隐藏目录 └── agents/agent_id/ ├── agent.md └── .cases/ # Agent 的案例库打开 users/alice/user.md刚才写入的偏好已经被结构化整理进去了格式清晰完全可读。你想修改一条记错的内容用编辑器打开直接改就行不需要任何 API 调用。整个 ~/.everos 目录可以用 git init 纳入版本管理记忆的变更历史就有了。如果你用Obsidian把 ~/.everos 直接作为 vault 打开Agent 的记忆就变成了一座可以浏览的知识库这个体验比较直观。六、几个容易翻车的地方网上能搜到很多 EverOS 的教程大部分讲的是它早期的重型版本需要 docker-compose 拉起 MongoDB、Elasticsearch、Redis 一整套服务。这个版本已经不是现在的 EverOS 了照着操作第一步就会出问题。现在的 1.0.0 轻量版整个设计方向就是去掉这些外部依赖everos init 和 everos server start 这套CLI 就是全部入口。另一个坑Office 文档.docx/.pptx/.xlsx的解析依赖系统安装 LibreOffice没装的话这类文件会失败但PDF、图片、音频不受影响。多模态摄取是一个可以继续探索的方向支持把 PDF、图片、网页 URL 直接吃进记忆一次API调用不需要自己写解析层。路线图上还有两个方向Knowledge Wiki把碎片记忆整理成可版本化的 wiki页和 Reflection系统空闲时连接弱信号、压缩历史记录、主动改进画像。目前这两块还在开发中方向是有价值的但不要指望现在就用。七、说几句实在话我现在把它用在 Claude Code 和 Codex 相关工作流的记忆层上跑了一段时间没遇到大问题。回头看它解决的是一个工程上挺基础的问题让一个原本无状态的系统有了可持久化、可检索、可审查的状态存储。说出来简单但在Agent 这个领域真正把它做成透明的、开发者能直接介入的形态目前见到的方案里EverOS 算是做得比较彻底的一个。对于在搭Agent 工作流、LLM应用、或者编程助手的人来说记忆层是个绕不开的问题。与其等到上下文塞满了再临时补救不如从一开始就把这层设计进去。仓库地址https://github.com/EverMind-AI/EverOS本文基于EverOS 1.0.0轻量版跑分数据为官方口径。仓库迭代较快操作前建议以仓库根目录 QUICKSTART.md 中的最新写入/检索命令为准。