Agent Memory
概览
作者提供的说明（英文原文）
Persistent agent memory with a decision layer: replay, restore, verify, or none — explainable.
PopNx MCP 的三大支柱
这三项永远不会合并成一个分数：意见、测量和人气是不同的东西。
- 用户评价i暂无评价评价功能将在后续阶段与账户功能一起开放
- 我们的基础检查i1 项中通过 1 项依据公开信息检查；尚未扫描代码
- 使用情况i非常新↓ 34/周 · ★ –
它能帮你做什么
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
- 连接方式: 在你的电脑上运行
- 传输方式: stdio
- 分类: 搜索与 AI 记忆
安装
选择你使用的 AI 应用，然后复制设置。
安装之前
- 基础检查：1 项中通过 1 项
- 在你的电脑上运行，拥有你的用户账户的权限（文件、网络、应用）。
- 需要你自己填写：
AGENT_MEMORY_DIR,AGENT_MEMORY_COLLECTION
你需要
- PyPI已安装 Python 的 uv（用于 uvx 命令）
你用的是哪个应用？
在上方选择你的应用。我们会记住它，下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config，把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"agent-memory": {
"command": "uvx",
"args": [
"agent-memory-sdk"
],
"env": {
"AGENT_MEMORY_DIR": "your-value",
"AGENT_MEMORY_COLLECTION": "your-value"
}
}
}
}在终端中运行这条命令
claude mcp add agent-memory --env AGENT_MEMORY_DIR=your-value --env AGENT_MEMORY_COLLECTION=your-value -- uvx agent-memory-sdk运行前请先填写空着的值。
或者自己复制设置
粘贴到项目中的 .cursor/mcp.json，或 ~/.cursor/mcp.json
{
"mcpServers": {
"agent-memory": {
"command": "uvx",
"args": [
"agent-memory-sdk"
],
"env": {
"AGENT_MEMORY_DIR": "your-value",
"AGENT_MEMORY_COLLECTION": "your-value"
}
}
}
}浏览器会先询问是否打开应用，然后应用会显示设置并请你确认。密钥的值会留空，由你自己填写。
或者自己复制设置
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"agent-memory": {
"type": "stdio",
"command": "uvx",
"args": [
"agent-memory-sdk"
],
"env": {
"AGENT_MEMORY_DIR": "your-value",
"AGENT_MEMORY_COLLECTION": "your-value"
}
}
}
}浏览器会先询问是否打开应用，然后应用会显示设置并请你确认。密钥的值会留空，由你自己填写。
这个服务器在你的电脑上运行，而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上，无需账户。
需要你填写的值
AGENT_MEMORY_DIRenvDirectory for the persistent memory store (default: ~/.agent_memory)AGENT_MEMORY_COLLECTIONenvCollection (database) name within the memory directory
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同，请以 README 为准。
它能做什么
它在你的电脑上运行；安装后，工具列表会显示在你的 AI 应用中。
基础检查i
我们检查的是任何人都能看到的信息；我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月8日
- ✓ 通过
作者与仓库一致
注册名称已通过 GitHub 账户 TheProdSDE 验证，该账户拥有此仓库
- … 尚未检查
仍在维护
我们还没有从 GitHub 读取这个仓库
- … 尚未检查
有许可证
我们还没有从 GitHub 读取这个仓库
- – 不适用
端点有响应
它在你的电脑上运行，没有互联网端点
- – 不适用
使用 OAuth 登录
在你的电脑上运行，改用本地设置
- … 尚未检查
工具描述中没有隐藏指令
它在你的电脑上运行；我们只能读取互联网端点的工具列表
与“搜索与 AI 记忆”中的其他服务器比较i
- 星标数多于此分类中其他 5688 个服务器的 0%
- 发布到注册中心的时间比此分类中其他 5688 个服务器的 47% 更新
- 基础检查结果等于或优于此分类中其他 5688 个服务器的 100%
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时，星标数才计入。
常见问题
Agent Memory 安全吗？
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前，请先看看这个服务器要求哪些权限，并使用只具备所需权限的密钥。
它需要哪些密钥或代码？
注册中心没有列出必需的密钥，不过有些服务器会在首次使用时要求你登录。
它在我的电脑上运行还是在云端？
它在你的电脑上运行。你的 AI 应用会在需要时启动它，数据不会经过作者的服务器（除非它自己调用在线服务）。
它还在维护吗？
GitHub 仓库最后更新于–，最新版本（0.1.5）于2个月前进入注册中心。
哪些应用可以使用它？
支持 MCP 的应用，例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
有什么可以替代它？
同一分类中有：Context7, Codebase Memory, Exa
替代选择
同一分类中其他作者的服务器，按星标数排序。
如何看卡片：↓ 每周下载量i★ GitHub 星标i三大支柱：评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Codebase Memory
Codebase knowledge graph for AI agents — 162 languages, sub-ms queries, 99% fewer tokens.
Exa
Connect AI agents to Exa for web search, content fetching, and multi-step research.
作者的 README
打开 README
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Agent Memory
Persistent semantic memory for AI agents with intelligent decision-making.
🚀 Created by: TheProdSDE
The problem
Most AI memory systems retrieve and inject past context into every prompt. This leads to wasted tokens, inconsistent responses, and agents that blindly replay stale or wrong answers.
Agent Memory adds a decision layer:
flowchart TDA[User Query] --> B[Resolve Memory] B --> C[Decision Engine] C -->|High confidence match| D[🔄 Replay — return stored answer] C -->|Moderate match| E[📋 Restore — inject as context] C -->|Needs validation| F[✅ Verify — validate before reuse] C -->|No match| G[❌ None — answer from scratch]
style D fill:#0d47a1,color:#fff style E fill:#e65100,color:#fff style F fill:#1b5e20,color:#fff style G fill:#b71c1c,color:#fff
Every resolve() returns an explicit action with a scored, explainable rationale — not just a retrieved chunk. Adversarial eval: 34/36 (94%) on trap queries — the 2 misses return VERIFY (cautious), never a wrong REPLAY — see benchmarks.
Context rot — what this solves (and what it can't)
Context rot is the measured degradation of LLM accuracy as the context window fills — long before the token limit. Stale chunks, irrelevant retrievals, and unbounded conversation history don't just waste tokens; they actively degrade answers ("lost in the middle", instruction drift, distractor sensitivity).
Context rot has two causes. Agent Memory addresses the first; nothing outside the model itself can address the second.
1. What goes into the context — controllable, and this SDK's job:
| Rot source | Mechanism in Agent Memory |
|---|---|
| Irrelevant memory injected into every prompt | Decision layer — NONE refuses to inject when nothing truly matches (34/36 on adversarial trap queries; the 2 misses fail safe to VERIFY) |
| Unbounded in-session history | `PagedMemory` — fixed in-context buffer; old turns page out to recall storage and return per-query (MemGPT-style tiers) |
| Instruction drift in long coding sessions | RESTORE re-injects the relevant convention fresh, near the end of context, exactly when a query needs it |
| Stale facts silently reused | VERIFY + custom verifier callbacks + TTL expiry + half-life temporal decay |
| Reminders that never adapt | mark_correct() / mark_wrong() — confidence learning promotes memories that keep helping, demotes corrected ones |
| Knowledge lost when the session ends | from_conversation() distills durable facts from conversation turns into the store |
2. How the model attends over tokens already in its context — not controllable from outside. Attention degradation over long context is a property of the model. No memory layer changes that. What Agent Memory does is keep the context small and relevant enough that the model rarely enters the degraded regime in the first place.
The honest claim: Agent Memory prevents context pollution — the dominant controllable cause of context rot in agentic systems. It doesn't change model attention behavior, and it only helps if your agent routes context through resolve() / PagedMemory instead of concatenating history by hand.
How it compares
Today you need three tools wired together to get what resolve() does in one call: a semantic cache (GPTCache) for replay, a memory layer (Mem0 / Zep) for context, and custom staleness logic for verification. No existing tool decides — at read time — *whether and how* a memory should be used.
Cells about other projects are capability checks against their own source or docs (mem0 checked on 2026-09-27), not measured behaviour; ❔ means we have not tested it rather than that it is absent. Corrections welcome — see docs/comparison.md for sourcing and the benchmark RFC for the review process.
| Capability | Mem0 | Zep / Graphiti | Letta (MemGPT) | GPTCache | Agent Memory |
|---|---|---|---|---|---|
| Read-time decision (replay / inject / verify / skip) | ❌ always injects | ❌ always injects | ⚠️ LLM self-manages | ⚠️ replay only | ✅ REPLAY / RESTORE / VERIFY / NONE |
| Explainable per-decision scores | ❌ | ❌ | ❌ | ❌ | ✅ decision.explain() |
| Semantic answer cache (skip the LLM call) | ❌ | ❌ | ❌ | ✅ | ✅ |
| Staleness protection at read time | ⚠️ write-side updates + expiration_date | ✅ temporal graph | ❌ | ⚠️ eviction only | ✅ VERIFY + TTL + confidence decay |
| Adversarial trap-query eval published | ❔ none found | ❔ none found | ❔ none found | ❔ none found | ✅ 34/36 (94%) |
| LLM / API calls per memory op | 1+ | 1+ | 1+ | 0 | 0 |
| Local after model assets are installed/cached, zero API keys | ⚠️ self-hostable; needs an LLM for extraction | ⚠️ needs server + LLM | ⚠️ LLM per op | ✅ | ✅ SQLite + local ONNX |
| Paged context tiers (MemGPT-style) | ❌ | ❌ | ✅ | ❌ | ✅ memory.paged() |
Because hosted or model-backed configurations can add an LLM or embedding API round-trip per memory operation, their latency includes provider, model, and network costs. Exact latency depends on each project's configuration; this repository does not publish a universal 100ms–2s floor. Agent Memory resolves in-process in SQLite-only mode; measured latency depends on corpus shape and cache state (see performance and stress-testing details).
On *retrieval*, we publish a cleaned-release retrieval-proxy measurement below. On *end-to-end accuracy* (LLM answering + judge, where Mem0 and Zep publish), we don't quote numbers we haven't measured yet — that stage is next on the roadmap. → Full feature matrix and trade-offs (including where they're better): [docs/comparison.md](docs/comparison.md)
Benchmarked on LongMemEval (ICLR 2025)
LongMemEval is a benchmark for conversational-history retrieval. These results measure Agent Memory's RESTORE/retrieval tier, not REPLAY, VERIFY, TTL, or end-to-end answer correctness. Each question runs against a separate SQLite store containing that question's haystack; aggregate ingestion totals are not the size of one queried store. All ingestion uses zero LLM calls and $0 in API charges:
- LongMemEval_S (500 independent ~48-session haystacks; 124K turn-pair entries across all runs): 98.1% session Recall@5 with local ONNX embeddings, 96.0% lexical-only, 10.04ms lexical / 19.56ms semantic p50 retrieval. The report includes p90/p95/p99 and run-resource measurements.
- LongMemEval_M (500 independent ~500-session haystacks; ~2,500 turn-pair entries per queried store): 87.0% session Recall@5 with lexical retrieval, 12.05ms p50. This uses the official cleaned re-release and turn-pair indexing; it is not directly comparable with the paper's original-release session-index baselines.
Full methodology, per-type tables, scope notes (what this benchmark does and doesn't test), and negative results are in the [benchmark report](benchmarks/longmemeval/REPORT.md). Reproduce the semantic _S result with uv run python benchmarks/longmemeval/run_retrieval.py --semantic.
Real software, not a prototype
Every claim below is reproducible from this repo:
- 34/36 (94%) on adversarial decision-quality eval, and the 2 misses fail safe (VERIFY, never wrong REPLAY) —
agent-memory eval(methodology) - LongMemEval retrieval proxy: 98.1% Recall@5 (_S, semantic) · 87.0% (_M, lexical) — 500 independent haystacks; not an end-to-end or paper-baseline head-to-head, full report
- Reproducible stress harness for synthetically seeded workloads up to 1,000,000 entries; archive the JSON output before publishing a performance claim (methodology)
- Stress-test benchmark charts: latency percentiles, seed throughput, resource use, action mix, and cache/decision rates for lexical FTS5 runs at 10K, 100K, and 1M entries, with workload and archived result JSON documented in stress-testing
- 412 collected tests across 25 test modules — decision quality, concurrency, all 4 backends, MCP server, adapters — run in CI on every push
- Published on PyPI and the official MCP Registry
- Ships with a REST API, Streamlit dashboard, CLI, LangChain/LlamaIndex adapters, and async counterparts for memory read/write and decision operations
When to use it — real use cases
| Use case | Without memory | With Agent Memory | Saving |
|---|---|---|---|
| Support bot handling 10k identical FAQ queries/day | Every query costs 1 LLM call | If roughly 75% of requests match reusable memories, those matches can REPLAY without an LLM call | Potentially lower LLM cost; measure your workload |
| Coding agent that re-derives project conventions each session | Wastes 2–5 LLM calls per session to "remember" conventions | Conventions stored once are REPLAYED/RESTORED from the first query of every later session | No re-derivation overhead |
| Research agent building knowledge over multiple sessions | Each session starts cold; re-reads the same sources | Facts and summaries are RESTORED as context | Persistent cross-session knowledge |
| Customer onboarding bot answering the same steps repeatedly | Always generates a response | High-confidence workflows are REPLAYED verbatim | Consistent identical answers |
| Tool-output caching for expensive API calls | Calls the external API every time | Results stored with TTL; REPLAY within TTL, re-call after | Reduced external API cost |
| Policy-compliance agent that must verify facts before replaying | Silent hallucination risk on stale data | requires_verification=True routes relevant matches to VERIFY; low-scoring matches return NONE | Auditability + safety |
Where Agent Memory saves real money
A GPT-4o call costs ~$0.005. A support agent handling 50,000 queries/day with 70% repeat rate:
- Without memory: 50,000 × $0.005 = $250/day
- With Agent Memory: 15,000 LLM calls + cache misses = $75/day
- Saving: ~ $175/day (~$64k/year)
- Savings depend on your repeat rate and how similar incoming queries are to previously stored ones — measure in your own pipeline.
REPLAY avoids an LLM call when policy permits it. The latency and cost difference depends on the local workload, provider, model, and network; measure both paths in your own pipeline.
Is it right for your use case?
Good fit:
- Agent answers the same or similar questions across sessions
- You have fact-sensiti
只显示了开头部分；其余内容请在仓库中阅读