Context7
Up-to-date docs for AI agents
作者提供的说明(英文原文)
Hierarchical memory for AI agents. Three-layer (buffer/working/core) with decay and promotion.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
ENGRAM_URL, ENGRAM_API_KEY标为机密的值是你账户的钥匙。千万不要分享给别人,也不要粘贴到聊天里。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"engram": {
"command": "npx",
"args": [
"-y",
"engram-rs-mcp"
],
"env": {
"ENGRAM_URL": "your-value",
"ENGRAM_API_KEY": "your-value"
}
}
}
}在终端中运行这条命令
claude mcp add engram --env ENGRAM_URL=your-value --env ENGRAM_API_KEY=your-value -- npx -y engram-rs-mcp运行前请先填写空着的值。
粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"engram": {
"command": "npx",
"args": [
"-y",
"engram-rs-mcp"
],
"env": {
"ENGRAM_URL": "your-value",
"ENGRAM_API_KEY": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"engram": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"engram-rs-mcp"
],
"env": {
"ENGRAM_URL": "your-value",
"ENGRAM_API_KEY": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
ENGRAM_URL env这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 kael-bit 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
你需要填写:ENGRAM_API_KEY
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.10.0)于8个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。
同一分类中有:Context7, Codebase Memory, Exa
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Up-to-date docs for AI agents
Codebase knowledge graph for AI agents — 162 languages, sub-ms queries, 99% fewer tokens.
Connect AI agents to Exa for web search, content fetching, and multi-step research.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Memory engine for AI agents. Two axes: time (three-layer decay & promotion) and space (self-organizing topic tree). Important memories get promoted, noise fades, related knowledge clusters automatically.
Most agent memory is a flat store — dump everything in, keyword search to get it back. No forgetting, no organization, no lifecycle. engram-rs adds the part that makes memory actually useful: the ability to forget what doesn't matter and surface what does.
Single Rust binary, one SQLite file, zero external dependencies. No Python, no Redis, no vector DB — curl | bash and it runs. ~10 MB binary, ~100 MB RSS, single-digit ms search latency.
# Install (interactive — will prompt for embedding provider config)
curl -fsSL https://raw.githubusercontent.com/kael-bit/engram-rs/main/install.sh | bash
curl -X POST http://localhost:3917/memories \ -d '{"content": "Always run tests before deploying", "tags": ["deploy"]}'
curl -X POST http://localhost:3917/recall \ -d '{"query": "deployment checklist"}'
curl http://localhost:3917/resume
Inspired by the Atkinson–Shiffrin memory model, memories are managed across three layers by importance:
Buffer (short-term) → Working (active knowledge) → Core (long-term identity)
↓ ↓ ↑ eviction importance decay LLM quality gate
Promotion isn't rule-based guesswork — an LLM evaluates each memory in context and decides whether it genuinely warrants long-term retention.
Buffer → [LLM gate: "Is this a decision, lesson, or preference?"] → Working
Working → [sustained access + LLM gate] → Core
Decay is activity-driven — it only fires during active consolidation cycles, not wall-clock time. If the system is idle, memories stay intact.
Exponential decay follows the Ebbinghaus forgetting curve — fast at first, then long-tail. Memories never fully vanish (floor = 0.01), remaining retrievable under precise queries. When a memory is recalled, it gets an activation boost, strengthening frequently-used knowledge.
| Kind | Decay rate | Half-life | Use case |
|---|---|---|---|
episodic | Fastest | ~35 epochs | Events, experiences, time-bound context |
semantic | Medium | ~58 epochs | Knowledge, preferences, lessons (default) |
procedural | Slowest | ~173 epochs | Workflows, instructions, how-to |
| Chart | What it shows |
|---|---|
| Sigmoid score compression. Raw scores are mapped through a sigmoid function, approaching 1.0 asymptotically. High-relevance results remain distinguishable instead of being crushed into the same value. | |
| Ebbinghaus forgetting curve. Exponential decay with kind-differentiated rates — episodic memories fade fastest, procedural slowest. Floor at 0.01 means memories never fully vanish; they remain retrievable under precise queries. | |
| Kind × layer weight bias. Additive biases adjust memory weight by type and layer. Procedural+core memories rank highest, episodic+buffer lowest — but the spread stays bounded so no single combination dominates. | |
| Reinforcement signals. Repetition and access bonuses follow logarithmic saturation. Early interactions matter most; later ones contribute diminishing returns, discriminating between "used occasionally" and "used daily". | |
| Use it or lose it. Left: a memory that's never recalled decays into the buffer layer. Right: periodic recall triggers activation boosts that keep the memory in the working layer. Dashed line shows the unrecalled trajectory for comparison. |
Two memories saying the same thing in different words? Detected and merged automatically:
"use PostgreSQL for auth" + "auth service runs on Postgres"
→ Merged into one, preserving context from both
Vector clustering groups related memories together, LLM names the clusters. No manual tagging required:
Memory Architecture
├── Three-layer lifecycle [4] ├── Embedding pipeline [3] └── Consolidation logic [5] Deploy & Ops ├── CI/CD procedures [3] └── Production incidents [2] User Preferences [6]
The problem this solves: vector search requires asking the right question. Topic trees let agents browse by subject — scan the directory, drill into the right branch.
Tag a memory with trigger:deploy, and the agent can recall all deployment lessons before executing:
curl -X POST http://localhost:3917/memories \
-d '{"content": "LESSON: always backup DB before migration", "tags": ["trigger:deploy", "lesson"]}'
curl http://localhost:3917/triggers/deploy
Agent wakes up, calls GET /resume, gets full context back. No file scanning needed:
=== Core (24) ===
deploy: test → build → stop → start (procedural) LESSON: never force-push to main ...
=== Recent === switched auth to OAuth2 published API docs
=== Topics (Core: 24, Working: 57, Buffer: 7) === kb1: "Deploy Procedures" [5] kb2: "Auth Architecture" [3] kb3: "Memory Design" [8] ...
Triggers: deploy, git-push, database-migration
| Section | Content | Purpose |
|---|---|---|
| Core | Full text of permanent rules and identity | The unforgettable stuff |
| Recent | Recently changed memories | Short-term continuity |
| Topics | Topic index (table of contents) | Drill in on demand, no full load |
| Triggers | Pre-action tags | Auto-recall lessons before risky ops |
Agent reads the directory, finds relevant topics, calls POST /topic to expand on demand.
Semantic embeddings + BM25 keyword search with CJK tokenization (jieba). IDF-weighted scoring — rare terms get boosted, common terms auto-downweighted. No stopword lists to maintain.
# Semantic search
curl -X POST http://localhost:3917/recall \ -d '{"query": "how do we handle auth", "budget_tokens": 2000}'
curl -X POST http://localhost:3917/topic \ -d '{"ids": ["kb3"]}'
Fully automatic, activity-driven — no writes means the cycle is skipped:
Consolidation (every 30 minutes)
Topic Distillation — when a topic grows too large (10+ memories), overlapping content is condensed into fewer, richer entries.
Single instance, multiple projects. Use X-Namespace to isolate:
curl -X POST http://localhost:3917/memories \
-H "X-Namespace: my-project" \ -d '{"content": "API uses OAuth2 bearer tokens"}'
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/kael-bit/engram-rs/main/install.sh | bash
irm https://raw.githubusercontent.com/kael-bit/engram-rs/main/install.ps1 | iex
docker run -d --name engram-rs \
-p 3917:3917 \ -v engram-data:/data \ -e ENGRAM_LLM_URL=https://api.openai.com/v1 \ -e ENGRAM_LLM_KEY=sk-... \ ghcr.io/kael-bit/engram-rs:latest
engram-rs works without an LLM — keyword search and rule-based lifecycle still function. Adding an LLM unlocks intelligent features (triage, gate, merge, topic naming):
export ENGRAM_LLM_URL=https://api.openai.com/v1
export ENGRAM_LLM_KEY=sk-...
export ENGRAM_LLM_URL=http://localhost:11434/v1
export ENGRAM_LLM_PROVIDER=anthropic export ENGRAM_LLM_KEY=sk-ant-...
Two-tier model config — strong model for judgment, lightweight for text processing:
ENGRAM_GATE_MODEL=gpt-4o # quality decisions
ENGRAM_LLM_MODEL=gpt-4o-mini # text processing
Add to your agent's system prompt:
Set up engram-rs (persistent memory) by following the guide at:
https://raw.githubusercontent.com/kael-bit/engram-rs/main/docs/SETUP.md
Works with Claude Code, Cursor, Windsurf, OpenClaw, and any MCP-compatible tool.
17 MCP tools (MCP docs) | Full HTTP API (Setup guide)
# MCP (Claude Code)
npx engram-rs-mcp
{"mcpServers": {"engram": {"command": "npx", "args": ["-y", "engram-rs-mcp"]}}}
Built-in web UI at http://localhost:3917/ui for browsing memories, viewing the topic tree, and monitoring LLM usage.
| Binary | ~10 MB |
| Memory | ~100 MB RSS in production |
| Storage | SQLite, no external database |
| Language | Rust |
| Platforms | Linux, macOS, Windows (x86_64 + aarch64) |
| License | MIT |
MIT