EverOS：用 Markdown 文件当 AI 记忆底座，本地优先的取舍与边界
One portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.
秒懂
- 它是什么？
- EverOS 是一个 Python 库和本地优先的记忆运行时，把对话、文件和智能体轨迹存成可读的 Markdown，再用 SQLite 和 LanceDB 建索引。它适合想要摆脱托管向量库、愿意直接编辑文件来管理记忆的开发者，但它的检索能力和生态成熟度需要你先验证。
- 适合谁用？
- EverOS 适合那些已经习惯用文件管理状态、希望记忆可读可 diff、并愿意自己维护本地索引的智能体开发者，尤其是个人项目和中小型工作流。不适合需要生产级高并发检索、依赖托管向量数据库或不想接触命令行配置的团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 7 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
EverOS 解决的是智能体记忆的哪个痛点
大多数智能体框架把记忆存在 API、向量库或图数据库里，用户看不到也改不了。EverOS 反其道而行，把 Markdown 文件当作唯一的事实来源。对话、文件、智能体的执行轨迹都落成可读的 .md 文件，之后再用 SQLite 和 LanceDB 建索引供快速检索。这个设计直接回应了一个具体问题：当智能体跨应用、跨工具运行时，记忆散落在各自的后端里，无法统一回溯。EverOS 想让你拥有这些记忆文件，而不是被锁在某个平台的数据库里。目标用户是会用命令行、愿意编辑文件的开发者，不是只想点界面的业务人员。
本地三件套：Markdown、SQLite、LanceDB 的分工
README 里的架构图很清晰：Markdown 是规范存储，SQLite 和 LanceDB 是派生的索引。写入时，先落 Markdown 文件，然后一个级联监视器会同步更新索引。这个顺序很关键，它意味着即使索引损坏，原始记忆仍在文件里，可以重建。EverOS 刻意不依赖 MongoDB、Elasticsearch 或 Redis，整套栈跑在本地。检索时支持按 user_id、agent_id、app_id、project_id 和 session_id 正交过滤，而不是像多数库那样只按会话或命名空间隔离。这种设计适合多智能体共用一个记忆库的场景，但代价是索引同步的逻辑更复杂，级联监视器一旦出错，可能造成文件与索引不一致。
用户轨道与智能体轨道分开，Wiki 是第三类存储
EverOS 把记忆分成两个第一类表面：用户的 episodes/profile 和智能体的 cases/skills。前者记录用户的历史交互和画像，后者沉淀智能体解决问题的案例和技能。两者分开，意味着你可以让智能体学习自己的经验，而不污染用户的个人数据。此外还有一个 Knowledge Wiki，是可编辑、带来源的 Markdown 知识页面，有分类、CRUD API 和主题搜索。这个 Wiki 不是简单的笔记，它要求每个页面绑定到源文件，这样知识更新时能追溯到原始材料。对需要长期维护领域知识的智能体来说，这种结构比把知识塞进对话历史里更可靠。但要注意，Wiki 的编辑接口需要额外学习，不是零成本。
快速上手：从安装到跑通关键词搜索
官方给了一条最短路径。先用 uv pip install everos 或 pip install everos 安装。然后运行 everos demo，这个命令不需要 API key，也不需要启动服务器，就能体验记忆从 ingest 到 extract、index、recall 的完整流程。接着 everos init 会生成 ~/.everos/everos.toml 和 ~/.everos/ome.toml 两个配置文件。打开 everos.toml，里面的模型和 OpenRouter URL 已经填好，你只需要替换空的 api_key 字段。文档给出的最小配置是 model = "openai/gpt-4.1-mini"，base_url 指向 https://openrouter.ai/api/v1。最后 everos server start 启动服务，用 curl http://127.0.0.1:8000/health 检查状态。这个流程对熟悉 Python 的开发者很顺，但注意它假设你已经有一个 OpenRouter key，而且 Python 版本要 3.12 以上。
一个真实的局限：默认只有关键词搜索，embedding 和 rerank 未开启
README 在快速开始部分说得很直白：一个 OpenRouter key 就够用，但 capabilities.llm 为 true，而 embedding 和 rerank 保持 false，直到你额外配置。这意味着开箱即用的情况下，EverOS 的检索是关键词级别的，不是语义搜索。对需要理解同义词、处理模糊查询的场景，这可能是硬伤。文档没有说明如何开启 embedding 和 rerank，也没有给出配置示例，这让人怀疑该功能是否成熟。如果你的智能体依赖对长文档的语义理解，纯关键词索引可能召回率不足。另一个限制是 EverOS 目前主要面向 Python 3.12+，如果你的项目还在用 3.10 或 3.11，需要先升级环境。
替代方案：对比直接使用 LanceDB 或向量数据库
如果你不需要 Markdown 文件作为事实来源，EverOS 的替代方案是直接使用 LanceDB 或 Qdrant 这类向量数据库，自己管理记忆的写入和检索。差别在于，LanceDB 只提供存储和检索原语，你需要自己设计记忆的 schema、处理会话隔离、写合并逻辑。EverOS 则把这些封装成一套带反射机制的记忆层，还提供了用户和智能体两个轨道。另一个替代是使用 MemGPT 或 Letta 这类记忆管理框架，它们通常把记忆抽象成虚拟上下文，自动管理分页和遗忘，但记忆内容往往不是用户可读的 Markdown。选择的关键在于你更看重可控性还是自动化。EverOS 偏向可控，因为它把记忆文件暴露给你。
维护成本与许可证影响
EverOS 采用 Apache-2.0 许可证，这对商业使用友好，你可以在自己的产品里集成它，只要保留版权声明。维护成本主要来自版本更新。仓库的最近发布记录显示 v1.3.1 在 2026 年 9 月 8 日发布，距离 v1.3.0 只隔一天，说明迭代速度很快，但也意味着 API 可能不稳定。你在升级时需要注意配置文件格式是否变化，因为 everos.toml 和 ome.toml 的结构可能随版本调整。另外，EverOS 依赖 OpenRouter 作为默认 LLM 后端，这意味着你的记忆提取和反射功能会消耗 API 费用，并且依赖外部服务的可用性。如果 OpenRouter 出现故障或变更定价，你的记忆处理流程会受影响，除非你手动改成其他兼容 OpenAI 协议的端点。
编辑结论
EverOS 适合那些已经习惯用文件管理状态、希望记忆可读可 diff、并愿意自己维护本地索引的智能体开发者，尤其是个人项目和中小型工作流。不适合需要生产级高并发检索、依赖托管向量数据库或不想接触命令行配置的团队。在决定采用前，先确认三件事：你的 Python 版本是否在 3.12 以上，OpenRouter API key 是否可用，以及 EverOS 对中文内容的索引和检索效果是否满足你的场景。官方文档中 embedding 和 rerank 功能默认关闭，这意味着纯关键词搜索可能是你前期的全部能力，不要对此抱有超出文档的预期。
社区笔记