EverOS

EverMind-AIApache-2.0活跃维护

给 AI Agent 提供可移植的长期记忆层,本地优先、Markdown 原生、用户自持,跨应用和工具持续演化。

One portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.

v1.5.1发布于 2026-10-22 13:22 UTC13,862star +16 / 7 天970fork同步于 2026-11-10 05:27 UTC

怎么上手

由 README 提炼,执行前请确认
uv pip install everos
everos init
everos server start
硬件要求按 README 说明

README 未说明显存或 GPU 要求;本地运行依赖 Python 3.12+,核心流程用 OpenRouter 云端模型,未提及本地推理。

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

给 AI Agent 用的本地优先记忆层,把对话和轨迹存成可读 Markdown 并建索引

给 AI Agent 提供可移植的长期记忆层,本地优先、Markdown 原生、用户自持,跨应用和工具持续演化。

核心能力

  • 以 Markdown 为唯一事实来源,可读可改可 Git 版本化
  • 本地用 SQLite 加 LanceDB 建索引,无需 MongoDB 或 Redis
  • 按 user_id、agent_id、app_id 等维度做正交检索
  • 离线反思合并记忆簇,持续精炼用户画像与技能
  • 提供可编辑、有来源的 Markdown 知识 Wiki 页面

容易踩的坑

默认只配 LLM 时仅支持关键词检索,混合检索需另配 embedding 提供方;多模态入库需装 everos[multimodal] 额外依赖;Office 文档解析还需系统装 LibreOffice,否则返回 HTTP 415。

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v1.5.1
  1. v1.5.1EverOS 1.5.1最新正式版2026-10-22 · 2026-10-22 13:22 UTC

    Hybrid and vector search keep up with 10 requests a second out of the box. Each of those searches embeds its query first, and the slots reserved for those calls were the limit: with 4 of them and a remote embedding endpoint answering in about 0.45 s, search topped out near 9 requests a second and a steady 10 queued without bound. The default is now 16, which held the same load at a p50 of 0.42 s and a p95 of 1.45 s.

    Changed

    • [embedding].query_max_concurrent defaults to 16 instead of 4. Every hybrid or vector search makes one query embedding call, and the budget reserved for those calls bounded search throughput: with a remote endpoint answering in about 0.45 s, 4 slots capped hybrid search near 9 requests/s, so a steady 10 requests/s queued without bound (10,020 indexed entries, 5 minutes: p50 64 s, p95 101 s). At 16 the same load held p50 0.42 s, p95 1.45 s, p99 2.11 s, all 3,000 requests served at 9.99/s. In-flight requests to the endpoint can now reach max_concurrent + 16; set it lower if the endpoint is rate-limited.

    Upgrade

    pip install --upgrade everos   # or: uv sync
    

    Nothing to migrate. One thing to check: requests in flight to the embedding endpoint can now reach max_concurrent + 16 (26 with the shipped values) instead of 14. If your endpoint is rate-limited or a small self-hosted model, set [embedding] query_max_concurrent (or EVEROS_EMBEDDING__QUERY_MAX_CONCURRENT) back to what it can take. Roughly, the searches per second it can serve is this value divided by the endpoint's per-call latency.

    Full changelog: v1.5.0...v1.5.1

  2. v1.5.0EverOS 1.5.02026-10-21 · 2026-10-21 13:38 UTC
    查看更新说明

    /add no longer has to wait for extraction, and an index can no longer be wrong without saying so. A client can hand a batch to /add with async_mode and get a 202 back in milliseconds, while a durable in-process queue runs extraction in session order; the field, the response body and the task-status paths match EverOS Cloud, so one client works against both. Vector columns now follow [embedding] dim instead of a hardcoded 1024, startup refuses an index the configured model cannot have produced instead of accepting writes that are truncated or searches that quietly return nothing, and an emptied index is reported instead of looking healthy. The rest is reliability: OME writes no longer starve one another on Windows, a session lock timeout no longer strands a memcell without its episode, a message the model can never segment no longer blocks its session, resolving a cluster's members no longer reads two embedding vectors per member, and a dozen smaller faults found by property-based tests are fixed.

    Added

    • async_mode on /add: accept now, extract in the background. A request with async_mode: true is written to a durable SQLite queue (memorize_inbox) and answered with 202 Accepted; an in-process worker then runs the unchanged memorize pipeline for each batch, per session in arrival order and several sessions at a time (max_concurrency, default 4), so a session's batches and its flush never overtake each other and one slow session does not hold up the others. A synchronous call on a session that still has queued batches is queued too, for the same reason; /flush has no async_mode of its own and queues only behind such a backlog. The queue is bounded (413 PAYLOAD_TOO_LARGE, 429 QUEUE_SATURATED), a batch whose delivery fails is marked failed and skipped (no automatic retry by default: the pipeline is not atomic, so a re-run is not a clean retry), and every row is deleted seven days after it was accepted. GET /api/v2/tasks/{task_id} reports one request's outcome and GET /api/v2/tasks lists them (filter by session_id / status, paged). The field name, the 202 body, the task paths and the status vocabulary match the EverOS Cloud gateway. Replays after a crash are bounded (max_replays, default 3), the delivery loop relaunches itself if it ever dies, and GET /health reports the queue (memorize_queue block: loop alive, backlog, failed, restarts). Configured under [memorize.async_queue]; enabled = false stops accepting new async work while rows accepted earlier are still delivered. Synchronous calls without a backlog are unchanged.

    • [embedding] dim sets the width of every vector column. It used to be hardcoded at 1024, so a model of any other width could not be used: a narrower one failed every write, a wider one was truncated without saying so. dim now drives the schema, and startup checks the configured model against it. (#434)

    • cascade status and /health tell an emptied index apart from a healthy one. Deleting .index/lancedb used to leave a store that reported perfect health: the ledger lives in .index/sqlite and survives the delete, so every file stayed done, the scanner enqueued nothing, cascade status showed done: 106 with lag: 0, and /health reported zero failures — while search returned nothing. Startup now counts rows per business table and compares them against the ledger. cascade status prints a live count per table and warns when every one of them is empty; /health carries the startup snapshot in cascade.index_rows and cascade.index_emptied. Reported, not enforced: healthy does not flip, because these are startup counts and a signal that cannot clear until the next restart is worse than a number an operator can read. A fresh root, a queue still draining, and a root whose markdown was all delet

  3. v1.5.0rc1EverOS 1.5.0rc1pre-release2026-10-21 · 2026-10-21 10:06 UTC
    查看更新说明

    Pre-release build of 1.5.0rc1. See CHANGELOG.md on the tag.

    Upgrade

    pip install --upgrade --pre everos==1.5.0rc1   # pip skips pre-releases without --pre
    

    Full changelog: v1.4.2...v1.5.0rc1

  4. v1.4.2EverOS 1.4.22026-10-14 · 2026-10-14 13:49 UTC
    查看更新说明

    A server that stays healthy for days, not hours. Three faults in this release compounded on exactly the deployments that ran longest: a long-lived index leaked file descriptors until searches took seconds, interactive searches queued behind the cascade's background embedding, and a memory root holding more than one project had each project's index rows overwrite the other's. All three are fixed, and a LanceDB root that the last fault already damaged repairs itself on the first start after upgrading.

    Changed

    • [embedding].max_concurrent defaults to 10 instead of 5. The EmbeddingSettings class default (50) is aligned to the same value; the shipped default.toml always overrode it, so the effective default moves from 5 to 10. (#486)

    • Milvus collections must be rebuilt once after upgrading. They gain the __pk primary-key column; the server refuses to start on an old collection and names everos cascade rebuild, which recreates them from markdown.

    • Response ids are unique within (app_id, project_id), not globally; the shape of id is unchanged.

    • The cascade optimizes a LanceDB table at most once a minute, not once every ten seconds. Each optimize pass leaves an _indices/<uuid>/ directory behind until cleanup reclaims it, so the old 10 s floor set the ceiling on how many could pile up: about 126k directories a day and ~1.8M at the retention horizon. The 60 s default costs a sixth of that (~21k a day, ~300k at the horizon, roughly 1.2 GB) and keeps a full index sweep inside its 60 s deadline. The interval is a built-in floor on how often a table may be optimized, not a setting; a write-heavy deployment sees an index that trails its markdown by up to a minute longer than before.

    Fixed

    • A long-running server no longer leaks file descriptors on LanceDB index readers. Every optimize() mints a new index version whose reader is kept in a session cache, and that reader holds the descriptors of its _indices/<uuid>/ files. Lance keys those cache entries by dataset version and never evicts them when cleanup deletes the files underneath (lance-format/lance#7718), so the count grew for the life of the process: a 65-minute soak went from 74 to 558 index descriptors with no plateau, and a deployment on a 1024-descriptor limit exhausts it in hours. EverOS capped only one of the session's two caches and left the metadata cache unbounded, which is the one that decides whether the count converges. Both are now capped ([lancedb].metadata_cache_size_bytes, default 1 MB): the same soak holds between 6 and 82 descriptors, falling as often as it rises. Reported upstream as lance-format/lance#9934.

    • An interactive search no longer queues behind the cascade's embedding work. Query embeddings and background write embeddings shared one process-wide semaphore, so a burst of writes put the query a user was waiting on at the back of the queue. Under three concurrent writers, vector search p50 measured 46 s and p95 112 s, while the keyword leg — which needs no embedding — answered in 0.35 s. Queries now draw on their own budget ([embedding].query_max_concurrent, default 4): vector p50 drops to 0.60 s and p95 to 3.70 s under the identical load. Total in-flight requests to the endpoint become max_concurrent + query_max_concurrent rather than a silently shared bound. (#473)

    • The same owner's memories in two projects no longer overwrite each other in the derived index. Index rows were merged on id alone, and id is unique only within one (app_id, project_id): a user's episodes, atomic facts, agent cases, foresights, skills and profile written under a second project replaced the first project's rows (markdown was never affected). Every table now declares PRIMARY_KEY = ("app_id", "project_id", "id"); LanceDB merges on it and Milvus keys it

  5. v1.4.2rc1EverOS 1.4.2rc1pre-release2026-10-14 · 2026-10-14 09:26 UTC
    查看更新说明

    Pre-release build of 1.4.2rc1. See CHANGELOG.md on the tag.

    Upgrade

    pip install --upgrade everos   # or: uv sync
    

    Full changelog: v1.4.1...v1.4.2rc1

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    EverOS banner

    Website · Documentation · Blog · 中文

    Why EverOS

    EverOS is a Python library and local-first memory runtime for agents and makers. It gives one portable memory layer across coding assistants, apps, devices, and workflows from day one. It stores conversations, files, and agent trajectories as readable Markdown, then syncs local SQLite and LanceDB indexes for fast retrieval and self-evolving reuse.

    Ecosystem Integrations

    EverOS adds durable memory to the agent and workflow platforms below—and comes built into Raven. Choose an integration to open its setup guide.

    Quick Start

    One OpenRouter API key is enough to start EverOS, write durable memories, and retrieve them with keyword search.

    Prerequisites

    1. Install

    uv pip install everos
    # or: pip install everos
    

    2. Try the standalone demo — no key required

    No API key or server setup required—run one command to quickly experience how EverOS stores and recalls memory:

    # If you installed EverOS as a package:
    everos demo
    
    # If you cloned or forked this repository and have not activated .venv:
    uv run everos demo
    

    Enter something EverOS should remember, then ask a related question to watch the memory move through ingest -> extract -> index -> recall.

    https://github.com/user-attachments/assets/98cb8e1e-2ca8-4504-b0a6-0b9a040a0a5c

    3. Initialize and add your OpenRouter key

    everos init
    

    This creates ~/.everos/everos.toml and ~/.everos/ome.toml. Open ~/.everos/everos.toml; the generated model and OpenRouter URL are already correct, so replace only the empty api_key:

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

    This is the smallest Tier 1 setup: memory add, flush, Markdown persistence, cascade indexing, and keyword search.

    Use everos init --root <path> if you want a different memory root. Pass the same --root <path> to subsequent commands.

    4. Start EverOS

    everos server start
    

    Keep the server running, then open a second terminal and check it:

    curl http://127.0.0.1:8000/health
    

    Look for "status":"ok". With this one-key setup, capabilities.embed and capabilities.rerank remain false until you configure them.

    5. Add and retrieve your first memory

    [!NOTE] Business endpoints live under /api/v2. The older /api/v1 prefix still resolves to the same handlers so existing integrations keep working, but it is a legacy alias that may be removed in a future major release — write new code against /api/v2.

    Add a tiny conversation:

    TS=$(($(date +%s)*1000))
    
    curl -X POST http://127.0.0.1:8000/api/v2/memory/add \
      -H 'Content-Type: application/json' \
      -d "{
        \"session_id\": \"demo-001\",
        \"app_id\": \"default\",
        \"project_id\": \"default\",
        \"messages\": [
          {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $TS, \"content\": \"I love climbing in Yosemite every spring.\"},
          {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $((TS+10000)), \"content\": \"My favorite coffee shop is Blue Bottle in SOMA.\"}
        ]
      }"
    

    Flush the memory at the end of the session:

    curl -X POST http://127.0.0.1:8000/api/v2/memory/flush \
      -H 'Content-Type: application/json' \
      -d '{"session_id":"demo-001","app_id":"default","project_id":"default"}'
    

    Search it back:

    curl -X POST http://127.0.0.1:8000/api/v2/memory/search \
      -H 'Content-Type: application/json' \
      -d '{
        "user_id": "alice",
        "app_id": "default",
        "project_id": "default",
        "query": "Where do I like to climb?",
        "method": "keyword",
        "top_k": 5
      }'
    

    You should see the Yosemite memory in the response. Keep "method": "keyword" in this one-key setup because the API defaults to hybrid search, which requires an embedding provider.

    [!TIP] First memory unlocked. You just gave EverOS a fact, flushed it into durable Markdown-backed memory, and searched it back through the local index. That is the core loop. Want to see the source of truth? Open ~/.everos and inspect the generated Markdown files.

    For annotated responses and the Markdown files EverOS creates, see QUICKSTART.md.

    What works with one key?

    The OpenRouter one-key setup is EverOS Tier 1. It supports server startup, memory add and flush, durable Markdown storage, cascade indexing, and keyword search. Add optional providers only when you need the features below:

    ConfigurationAdds
    [llm] onlyCore memory flow and keyword search
    Add [embedding]Vector/user hybrid search, reflection, and skill extraction
    Add [rerank] tooAgentic search, default agent hybrid search, and Knowledge Wiki
    Add [multimodal] and parser extraImage, PDF, audio, and office-file ingestion

    Missing optional capabilities are reported by /health and return a clear HTTP 422 if you request a feature that needs them.

    [!NOTE] everos demo --live is different from the standalone demo in step 2: it connects to a running server and uses the real add/flush/search flow. It uses hybrid search, so add an embedding provider before you run it.

    Optional: Ingest Multimodal Files

    To ingest non-text content (image / pdf / audio / office documents) through /api/v2/memory/add content items, install the optional extra:

    uv pip install 'everos[multimodal]'   # or: pip install 'everos[multimodal]'
    

    This pulls in everalgo-parser (with the [svg] bundle for SVG support via cairosvg). Configure the [multimodal] section in everos.toml; its default model is google/gemini-3.8-flash via OpenRouter.

    Office document support requires LibreOffice as a system dependency. The parser shells out to soffice (LibreOffice's headless renderer) to convert .doc / .docx / .ppt / .pptx / .xls / .xlsx to PDF before feeding the result into the multimodal LLM. Without LibreOffice, office uploads return HTTP 415 with a clear error message; PDF / image / audio / HTML / email parsing is unaffected.

    Install on the host before serving office documents:

    brew install --cask libreoffice              # macOS
    sudo apt-get install -y libreoffice          # Debian / Ubuntu
    

    For Contributors

    git clone https://github.com/EverMind-AI/EverOS.git
    cd EverOS
    uv sync                              # creates ./.venv and installs deps
    uv run everos demo --plain           # try the local educational demo; no API keys needed
    uv run everos init                   # add one OpenRouter key to ~/.everos/everos.toml
    
    uv run everos --help
    make test
    

    Use Cases

    Now that you have had your first successful EverOS moment, explore what people are building with persistent memory across agents, apps, and community integrations.

    Use cases show what persistent memory makes possible in real products and workflows. Some examples are packaged in this repository; others point to external demos or integrations you can study and adapt.

    AIUI Sports Agents for Smart Glasses

    AIUI Sports Agents

    Sports agents for smart glasses, covering running, cycling, and indoor rowing. AISmartRun includes an optional memory-backend contract for post-run summaries; connecting it to EverOS requires a separately configured backend.

    Code

    banner-gif

    Reunite - Find With EverOS

    Parents describe what they remember. Children describe what they recall. Reunite uses semantic memory to surface the connections.

    Learn more

    banner-gif

    Hive Orchestrator

    Browser-native hive-mind for CLI coding agents - Claude Code, Codex, Gemini, and OpenCode collaborate as real PTY processes via a team protocol.

    Code

    banner-gif

    MCP Server for AI Coding Assistants

    Plug EverOS memory into Claude Code, Codex, Claude Desktop or Cursor with uvx everos-mcp. Works with EverOS Cloud and with this self-hosted server.

    Code · Setup guide

    banner-gif

    AI Data Technician

    An agentic AI system that learns from scientist interaction to inspect, analyze, and classify high-dimensional time series data - with persistent memory that improves across sessions.

    Code

    banner-gif

    Rokid AI Assistant With EverOS

    Connect to EverOS within Rokid Glasses enabling long-term memory for all of your smart activities.

    Coming soon

    banner-gif

    Creative Assistant With Memory

    Creative assistant with long-term memory, so your creative context stays available across sessions.

    Coming soon

    banner-gif

    Earth Online Memory Game

    Earth Online is a memory-aware productivity game that turns everyday planning into a living quest log.

    Code

    banner-gif

    Multi-Agent Orchestration Platform

    Golutra presents a multi-agent workforce for engineering teams, extending the IDE model from a single assistant to coordinated agents.

    Code

    banner-gif

    Your Personal Tasting Universe

    Record, visualize, and explore your tasting journey through an immersive 3D star map.

    Code

    banner-gif

    EverOS Open Her

    Build AI that feels. Open-source persona engine - personality emerges from neural drives, not prompts. Inspired by Her.

    Code

    banner-gif

    Browser Agent For Personal Memory

    Ruminer brings persistent memory to a browser agent so it can carry personal context across web tasks.

    Plugin

    banner-gif

    EverMem Sync With EverOS

    One command to connect any AI coding CLI to EverOS (formerly called EverMemOS) for long-term memory.

    Code

    banner-gif

    MCO - Orchestrate AI Coding Agents

    MCO equips your primary agent with an agent team that can work together to solve complex tasks.

    Code

    banner-gif

    Study Buddy With Self-Evolving Memory

    Study proactively with an agent that has self-evolving memory.

    Code

    banner-gif

    Alzheimer's Memory Assistant

    Empowering individuals with advanced memory support and daily assistance.

    Code

    banner-gif

    Memory-Driven Multi-Agent NPC Experience

    An iOS sci-fi mystery game where players explore and uncover the truth.

    Code

    banner-gif

    Mobi Companion

    An iOS app where users create, nurture, and live with a personalized AI companion called Mobi.

    Code

    banner-gif

    AI Wearable With Memory

    A context-native AI wearable that listens to everyday life and converts conversations into memory.

    Code

    banner-gif

    Legacy OpenClaw Agent Memory

    Archived pre-1.0.0 plugin reference. New integrations should use the current EverOS API.

    Learn more

    banner-gif

    Live2D Character With Memory

    Add long-term memory to a real-time Live2D character, powered by TEN Framework.

    Code

    banner-gif

    Computer-Use With Memory

    Run screenshot-based analysis with computer-use and store the results in memory.

    Live Demo

    banner-gif

    Game Of Thrones Memories

    A demonstration of AI memory infrastructure through an interactive Q&A experience with A Game of Thrones.

    Code

    banner-gif

    Claude Code Plugin

    Persistent memory for Claude Code. Automatically saves and recalls context from past coding sessions.

    Code

    banner-gif

    Memory Graph Visualization

    Explore stored entities and relationships in a graph interface. Frontend demo; backend integration is in progress.

    Live Demo

    Documentation

    EverMind Ecosystem

    EverMind connects memory research, production-ready products, and practical integrations into one open-source ecosystem.

    Together, these projects form EverMind's research-to-runtime stack: methods and benchmarks become reusable memory infrastructure, products, and agent integrations.

    Contributing

    Contributions are welcome across the whole repository: memory methods, benchmark coverage, use-case examples, documentation, and bug fixes. Browse Issues to find a good entry point, then open a PR when you are ready.

    [!TIP]

    Welcome all kinds of contributions 🎉

    Help make EverOS better. Code, documentation, benchmark reports, use-case write-ups, and integration examples are all valuable. Share your projects on social media to inspire others.

    Connect with one of the EverOS maintainers @ElliotChen on 𝕏 or @cyfyifanchen on GitHub for project updates, discussions, and collaboration opportunities.

    divider divider

    Code Contributors

    EverOS Contributors

    divider divider

    License

    Apache License 2.0 — see NOTICE for third-party attributions.

    Citation

    If you use EverOS in research, see CITATION.md.