摘要:本周 Agent 记忆赛道密集上新——本地轻量的 MCP Memory(OKF 格式 SQLite FTS5 全文索引)、单日 550 星迅速破 2 万的腾讯云 TencentDB Agent Memory、以及发布 v0.2.0 的 Zep ingest 记忆接入管道。三者分别代表个人工具级 / 团队协作级 / 生产数据级三种记忆实现路径,本文逐一拆解并给出选型建议。为什么 Agent 记忆是工程难题大模型会话天然无状态:每次对话从零开始,而真实的 Agent 任务是长时程的。做一个多会话的编码助手、一个连续跟踪项目的智能体,最先撞上的就是它什么都不记得。把记忆全部塞进上下文窗口显然不可行——窗口有上限,而且成本随 token 线性上涨;于是记忆必须落到外部存储,再按需召回。记忆工程要解决的其实是三类问题:写入:什么值得记?偏好、决策、工作流、代码结构,还是全部聊天记录?记少了没价值,记多了全是噪音。检索:需要时怎么找回来?全文、向量、还是图谱?检索不到的记忆等于不存在。更新:记忆会过期、会冲突、会被覆盖,谁来管理生命周期?昨天的结论和今天的新事实打架时听谁的?过去一年,主流方案基本围绕向量数据库做嵌入 相似度检索,但本周出现的三个项目给出了完全不同的答案——分别用结构化文档、团队资产库和数据接入管道来重新定义记忆。它们恰好覆盖了记忆工程的不同层次,放在一起看就是一份现成的选型地图。三种方案拆解一、MCP Memory:本地优先的 OKF SQLite FTS5fellowgeek/mcp-memory 是 8 月 13 日以 Show HN(53 分)发布的 MCP 服务器,截至 8 月 15 日 152 星,MIT 许可,纯 Python 实现。它的思路很朴素:既然是给 Agent 用,不如直接走 MCP 标准协议,让 Claude Desktop、Cursor、Windsurf、Codex 等客户端开箱即用。它的两个技术底座:OKF v0.2(Open Knowledge Format):Google 知识目录项目提出的开放知识格式。每条记忆都是一份带 YAML frontmatter 的 Markdown 文档,包含 type、key、namespace、tags、generated、sources、verified、status、stale_after 等字段——人类可读,也方便溯源、审计和版本管理。一条典型记忆长这样:--- type: Agent Memory title: Coding Style key: user/preferences/coding_style namespace: default tags: [preferences, style] status: stable generated: { by: mcp-memory/0.2.0, at: 2026-08-12T19:23:35Z } created_at: 2026-08-12T19:23:35Z updated_at: 2026-08-12T19:23:35Z --- User prefers functional programming style with explicit type annotations.SQLite FTS5 全文索引:仓库采用双写架构——记忆同时落盘为 memory/ 目录下人类可读的 .md 文件(带 index.md 渐进式索引和 log.md 更新历史),并在 .mcp_memory/memories.db 里建 FTS5 全文索引,项目宣称 key 查询低于 20ms。它暴露 5 个 MCP 工具:memory_store(写入/更新)、memory_retrieve(按 key 取)、memory_search(关键词/标签/命名空间搜索)、memory_get_last 与 memory_update_last(会话断点续传,Agent 开局就知道上次干到哪)。namespace 机制支持按 user/preferences、project/architecture 等隔离上下文,stale_after 字段为记忆过期留了口子;存储默认按项目隔离,也支持用 MCP_MEMORY_PROJECT_ROOT、MCP_MEMORY_DB_PATH 环境变量自定义位置。安装方式同样轻:克隆后跑 python3 setup.py 自动注册到已安装的 MCP 客户端,或者手动在 mcp_config.json 里加一行配置:// mcp_config.json(Claude Desktop / Cursor 等){mcpServers:{memory:{command:/ABSOLUTE/PATH/TO/run.sh}}}二、TencentDB Agent Memory:团队级记忆中心TencentCloud/TencentDB-Agent-Memory 是腾讯云官方仓库,4 月 7 日创建,8 月 12 日单日 550 星,截至 8 月 15 日已达 21,796 星,MIT 许可,TypeScript 实现,要求 Node ≥ 22.16,并提供 npm 包 tencentdb-agent-memory/memory-tencentdb。它的定位不是给一个 Agent 加记忆,而是给一队 Agent 建一个共享的记忆中枢:部署后同时起 memory-core memory-hub proxy 三个服务,通过 localhost:8125 面板管理,proxy 层对接 Claude Code、CodeBuddy 等客户端,README 里还挂着 OpenClaw、Hermes 等生态的兼容徽章。核心是四类可复用资产:Chat Memory:保留偏好、事实、决策与交互历史,并做分层蒸馏——原始对话从 L0 Conversation 逐层提炼为 L1 Atom、L2 Scenario、L3 Persona,越上层越接近稳定的用户画像,常规上下文引导用高层,精确事实再下钻到原始层。Skill:从对话和工具调用中提炼可复用技能,它不只是一段 prompt 提示,而是带版本、资源文件、触发边界、执行步骤和校验规则的完整资产;个人技能默认私有,评审后可共享给团队并指派给指定 Agent。LLM-Wiki:把产品文档、设计稿、运维手册转成带链接图的结构化页面(README 明说灵感来自 Karpathy 的 LLM 知识库),Agent 不用每次开工前把文档从头读一遍。CodeGraph:索引代码符号、文件、调用关系和影响路径,Agent 改代码前能做影响分析——“改这里会影响哪些地方”,而不是只知道代码在这。检索上它走混合路线:BM25 向量检索 RRF(倒数排名融合)混合召回,平时用 L2/L3 快速引导上下文,需要精确事实时回退 L1/L0,并按条数、字符预算、超时三重限制防止记忆撑爆上下文窗口。权限模型是 Fixed Binding ACL:资产分 private / team / restricted 三档,配合 System Admin / Team Admin / Member 两级角色,先按团队、用户、Agent、可见性圈定范围再检索。冷启动支持直接导入代码库、文档和历史会话,把已经付过的学习成本变成存档,新成员第一天就能加载团队的存档文件。三、Zep ingest:记忆接入管道前两个方案解决记忆怎么存、怎么查,Zep 则从另一个角度切入:数据怎么进得来。Zep 是托管式 Agent 记忆平台(Zep Cloud),底层图引擎是开源的 Graphiti;getzep/zep 仓库(4,838 星,Apache-2.0)现在主要承载示例、集成与基准(仓库内置 LoCoMo、LongMemEval 记忆基准的评测)。8 月 12 日发布的 zep-ingest v0.2.0(PyPI 同步,Python ≥ 3.11,Apache-2.0)是它的批量数据接入管道,负责 Zep API 上游的一切:分块、语境化、别名规范化、校验、提交。管道结构是 Loader → Transforms(分块 / 语境化 / 规范化)→ LimitGuard → Submitter,每个环节都是可替换的小类,数据全程惰性流式处理,50 万条消息也不会整体进内存。现成 Loader 覆盖了常见生产数据:Slack 导出、文档、转写稿、邮件、聊天记录、JSON/CSV 记录、事实三元组;默认走 Batch API(5 万条/批),部署没有批量端点时自动降级为限速顺序提交。它对时间戳特别较真:缺失 created_at 的片段会被 Zep 静默按摄入时间归档,而冲突裁决是最新的 valid_at 胜出,所以无时间戳的批量回填会永久污染事实时间线——管道会在提交前逐条警告。图本体(ontology)必须在首次摄入前设置且不可追溯,命名图默认不带任何实体类型,这些坑都被管道以客户端校验的形式提前拦下。v0.2.0 的主要更新:为 Strands Agents 框架新增 Zep MemoryStore 集成(官方支持的 Python 框架列表里已有 Google ADK、AutoGen、CrewAI、LangGraph、Pydantic AI 等);新增带 Zep 记忆的 TypeScript Eve 示例;zep-ingest 与服务端分配的 UUID 对齐;eval-harness 默认检索改为自动搜索。典型用法:# Python:zep-ingest 批量导入fromzep_cloud.clientimportZepfromzep_ingestimportingest_slack_export,ingest_documents clientZep(api_key...)ingest_slack_export(client,slack-export.zip,graph_idteam_knowledge)ingest_documents(client,handbook/**/*.md,graph_idcompany_kb)横向对比维度MCP MemoryTencentDB Agent MemoryZep ingest部署形态本地 SQLite OKF 文件,MCP stdio三服务 管理面板,可自托管Python 管道,写入 Zep Cloud记忆粒度单条 OKF 文档(key-value 标签)四类资产 分层蒸馏(L0→L3)知识图谱(实体 / 边 / 事实三元组)检索方式SQLite FTS5 全文 标签过滤BM25 向量 RRF 混合图检索 语义(由 Zep 提供)共享能力单机单项目,namespace 隔离团队共享,ACL 固定绑定多图 / 用户图,按 graph 隔离适用场景个人工具、项目内轻量记忆团队协作、多 Agent 共享资产生产数据批量接入、图谱构建选型建议与落地三个方案不是互斥的,而是记忆工程不同阶段的答案:个人原型、最小成本起步:选 MCP Memory。零服务、本地存储、MCP 标准协议,Claude Code / Cursor 里加一行配置就能用,适合先验证结构化记忆到底有没有用——注意它面向单机单项目,不要指望多机同步。团队协作、多 Agent 共享:演进到 TencentDB Agent Memory。当多个 Agent 反复解释同一项目、重复造同样的轮子时,四类资产 ACL 治理的价值就出来了;它的冷启动导入也适合已有代码库和文档的团队,部署成本是三者里最高的,要能接受起三个服务。生产数据接入、要知识图谱:上 Zep ingest。Slack 导出、文档库、邮件、CRM 记录这类现成数据需要的是可靠管道,而不是手工搬运——时间戳校验、别名规范化、批量提交正是它解决的问题;代价是数据最终落在 Zep Cloud,自托管场景需要评估数据出境与成本。三个常见坑提前说:一是记忆污染,写错一条覆盖掉对的,OKF 的 verified 字段和 TencentDB 的评审分享流程都是对冲手段;二是检索召回,全文索引对语义相近但字面不同的记忆无能为力,混排(如 BM25向量RRF)是更稳的做法;三是多 Agent 写冲突,团队场景下一定要有所有权和 ACL(TencentDB 的 Fixed Binding、Zep 的 “latest valid_at wins” 都是为此设计的)。另外建议定期做记忆审计:过期资产该清理就清理,stale_after、状态字段不是摆设。总结Agent 记忆正在从向量数据库的单一叙事走向分层:本地结构化文档(MCP Memory)、团队资产库(TencentDB Agent Memory)、生产数据管道(Zep ingest)各司其职。对大多数团队,建议路径是MCP Memory 做原型 → 需要共享时上 TencentDB → 需要批量喂数据时接 Zep,按记忆的规模与协作半径逐步升级,而不是一上来就上最重的方案。参考链接MCP Memory 仓库:https://github.com/fellowgeek/mcp-memoryOKF v0.2 规范:https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.mdTencentDB Agent Memory 仓库:https://github.com/TencentCloud/TencentDB-Agent-Memoryzep-ingest v0.2.0 Release:https://github.com/getzep/zep/releases/tag/zep-ingest-v0.2.0zep-ingest PyPI:https://pypi.org/project/zep-ingest/Zep 仓库(示例与集成):https://github.com/getzep/zep