从"记忆即外挂层"到"Agent 自主管理记忆即操作系统"——给 Agent 持久记忆的方案，正沿着几条互不相容的哲学路线分裂。这是一张面向工程实践者的全景地图。
独立记忆层（外挂） vs 内嵌 Runtime（接管 Agent 循环）
向量 / 知识图谱 / KV / 混合，决定能回答什么样的查询
系统被动累积+自动编辑 vs Agent 用函数调用自主策展
是否把"事实随时间变化"作为一等公民来追踪
注意：自托管 ≠ 开源，部分方案自托管需企业协议
能否在不同 LLM / 框架间迁移，关系到锁定风险
"记忆"在不同流派里意味着完全不同的东西：对话缓冲、向量库、知识图谱，还是一整套抽取引擎。
核心哲学是框架无关的可插拔层——不接管你的 Agent 循环，import SDK 指向它即可，编排、工具、Agent 逻辑全部留在原处。无论 Agent 跑在 LangChain、CrewAI、AutoGen 还是自定义循环里都通用。
架构上提供 user / session / agent 三层作用域，底层是向量 + 图关系 + KV 的混合存储；事实冲突时自我编辑而非追加重复项，保持记忆精简。生态最大，约 4.8 万 GitHub stars，是采用最广的独立记忆层。
最具架构辨识度的一派，把 Agent 记忆建模成操作系统。但内部分两个子类型：一类强调"Agent 自主用函数调用管理记忆"（Letta），一类强调"自演化生命周期 + 文件即真相源"（EverOS）。
主上下文是 RAM（快、有限），外部存储是磁盘（慢、无限），Agent 自己决定何时换入换出。三层 Core / Recall / Archival memory。
关键 · 它不是记忆层，是 Agent Runtime——Agent 运行在 Letta 里面，框架接管 Agent 循环、工具执行与状态持久化。
Markdown 即真相源——所有记忆存为纯 .md 文件，可 grep、用 Git 版本化、在 Obsidian 里查看，无黑盒数据库锁定。三件套：Markdown + SQLite + LanceDB，不需要 Mongo/ES/Milvus/Redis/Kafka。
程序性记忆 · 完成的任务被捕获为 Case，重复成功的自我提升为可复用 Skill，在 agent 团队间共享。兼容 Claude Code / Codex / OpenClaw / Hermes / MCP。
把时间作为一等维度，这是平面向量库做不到的事。每个事实带 valid_from、valid_to、invalid_at 标记，可以查询"一月份时什么是真的"或"它何时改变的"。底层 Graphiti 约 2.48 万 stars，支持 Neo4j、FalkorDB、Kuzu、Neptune 多种图后端。
典型价值场景：当用户公司被收购、角色变化、或既有偏好被更新时，图谱保留历史关系同时正确呈现当前状态。性能上报告 200ms 检索延迟，在 LongMemEval 上比竞品高 15 分。
把记忆当流水线而非即插即用：摄入原始数据 → 抽取结构 → 构建知识图谱 → 精确检索，模糊了 RAG 与 Agent 记忆的边界。强项是自动从非结构化数据（文档、对话、外部源）构建知识图谱，检索时结合图遍历与向量搜索，理解概念间关系而非仅文本相似度。
差异化定位：完全本地部署，对有严格数据驻留要求或气隙环境的团队是真正的差异化优势；代价是没有托管基础设施、合规认证或企业支持。开源（Apache 2.0），有托管云。
与 harness-agent 最直接相关的一派——记忆方案直接以编码 Agent 为目标，通过 MCP 挂进 Claude Code、Codex、Cursor 等。内部分闭源商业与开源两条路线。
单一记忆 API，涵盖事实抽取、用户画像、矛盾消解与选择性遗忘；MCP server + Claude Code / OpenCode 插件。
注意 · 闭源，自托管需企业协议（自托管 ≠ 开源）。称在 LongMemEval / LoCoMo / ConvoMem 领先，但为自报、未独立验证。
开源对位方案，为 Claude Code、Copilot CLI、Cursor、Gemini CLI、Codex CLI、Hermes、OpenClaw、pi、OpenCode 及任意 MCP 客户端提供持久记忆。
架构亲和 · 建在 iii-engine 的 Worker/Function/Trigger 三原语 + 文件型 SQLite 之上；一个本地 server 可被多 Agent 共享，pi 集成直接挂 agent 生命周期（非 MCP）。
记忆作为大框架的一个模块，强在生态整合、弱在可移植性。最大风险是锁定：LangMem 主要为 LangGraph 设计，在其之外价值有限；LlamaIndex Memory 绑定 LlamaIndex。若将来可能换框架，应选独立记忆系统。
Semantic Kernel 偏企业存量系统：假设你已有 CRM、数据库、内部 API，需要不重建一切就把 LLM 接上去；插件模型是包装现有代码而非替换。对已在跑 .NET 或 Java 栈的企业是阻力最小的路径。
这一层是上面各派的底座，单独不构成完整记忆策略。Redis Agent Memory Server 适合已在用 Redis、需要低延迟存储后端的团队。各类向量库 / 图库同属此层。
| 流派 | 代表 | 形态 | 存储架构 | 记忆控制权 | 时间建模 | 开源 |
|---|---|---|---|---|---|---|
| 独立记忆层Memory Layer | Mem0 | 外挂层 | 向量+图+KV 混合 | 系统自我编辑 | 弱 | ✓ |
| OS 隐喻 / 自主Agent-Managed | Letta (MemGPT) | Runtime | 三层 RAM/磁盘 | Agent 自主 | 弱 | ✓ |
| OS 隐喻 / 自演化Self-Evolving | EverOS | 框架 | Markdown+SQLite+LanceDB | 系统（生命周期） | 中 | ✓ |
| 时序知识图谱Temporal KG | Zep / Graphiti | 层（引擎） | 时序知识图谱 | 系统 | 一等公民 | ✓ 引擎 |
| KG / RAG 融合Pipeline | Cognee | 流水线 | 知识图谱+向量 | 系统 | 中 | ✓ |
| 编码 Agent 原生Coding-Native | Supermemory | API + MCP | 混合 | 系统 | 中 | ✗ |
| 编码 Agent 原生Coding-Native | agentmemory | Server + MCP | iii-engine + SQLite | 系统 | 中 | ✓ |
| 框架内嵌Framework-Coupled | LangMem / LlamaIndex / SK | 模块 | 各异 | 系统 | 弱 | ✓ |
| 存储后端Backend | Redis Memory Server | 底座 | KV / 向量 | — | — | ✓ |
如果约束是"开源 + 自托管 + 模型无关 + 直接挂进 Claude Code / Codex / pi"——agentmemory 是当前唯一同时满足全部条件的编码 Agent 原生记忆层。EverOS 是强力第二，若你更看重"记忆可被 Git/Obsidian 直接审阅"与 Skill 自演化，可对调顺序。
编码 Agent 原生派的开源代表。一个本地 server 即可被 Claude Code、Codex CLI、Cursor、Gemini CLI、pi、OpenClaw 共享，记忆跨工具复用。iii-engine 的 Worker/Function/Trigger 三原语 + 文件型 SQLite，与 harness-agent "最小核 + Trigger 组合"哲学同源。对你而言迁移成本最低、锁定风险最小。
记忆存为纯 .md，可 grep、Git 版本化、Obsidian 查看，无数据库锁定；完成的任务沉淀为 Case，重复成功自我提升为可复用 Skill。最契合 spec-first 与 SIA 自改进思路。代价是它偏框架形态、需自己接入，且 benchmark 为自报。
不是编码原生，但框架无关、生态成熟，作为"跨 session 偏好与决策"的通用记忆层很稳。注意开源版只有基础向量+KV，Graph Memory 等需云端付费——纯自托管前要确认够用。
编码 Agent 集成度高，但闭源 + 自报 benchmark 与你的评估轴直接冲突。仅建议作竞品研究，不宜作依赖。
Qoder（阿里）的「知识引擎」不属于任何单一流派，而是把三种记忆源合并成一个团队级知识引擎，再用一套混合检索把它喂给 Agent。它最像第 4 派（KG/RAG 融合，Cognee 那类），但叠加了第 2 派的自演化生命周期——这正是它被你列为"持久记忆即护城河"的原因。
沟通模式、技术偏好、团队约定、历史决策。对应"跨 session 偏好/决策"那类记忆。
架构知识与模块关系，从代码库自动构建。对应"codebase / 工程知识"那类记忆——这是编码场景的核心。
编码规范与技术栈知识。结构化、可由团队成员共同贡献和精炼。
三源被统一管理、在 Agent 运行时被持续调用；每个团队成员都能贡献和精炼，知识存于云端并带企业级治理与审计——把个人 know-how 沉淀为组织能力。
不同于"只看代码"的传统工具，Qoder 把向量搜索、代码图谱、预索引知识库三路并联再融合排序。代码图谱让它理解结构、依赖与设计意图，从而支持跨文件搜索、重构与架构级决策——这是平面向量库做不到的。
Repo Wiki 自动从代码库构建并保持更新；团队成员持续贡献精炼，Agent 越跑越准。知识不是静态库，而是持续演化的生命周期——这点与第 2 派 EverOS 的 Case→Skill 思路同源。
开发者写 Spec，Agent 自主规划交付（Quest Mode）。Spec 不只是任务描述，还会沉淀进团队知识库——把"人定义 spec，Agent 实现"做成了记忆闭环。
Qoder 的知识引擎 = KG/RAG 融合派的工程化落地（Repo Wiki + 代码图谱 + 混合检索）＋ 自演化生命周期（云端治理、团队共建、随运行增长）。它没有走 Letta 式"Agent 自主管理记忆"的路，而是走"系统主动构建并治理知识、Agent 消费"的路。
对你最有借鉴价值的两点：(1) 把 codebase 知识做成可自动构建、可被多 Agent 复用的 Repo Wiki，正是 harness-agent "codebase context management" 那一层该有的形态；(2) 三源分治——把"工程知识"和"用户偏好/决策"显式拆开管理，印证了前面推荐里"两类记忆不该用同一方案"的判断。注意 Qoder 本体闭源、知识存云端，与你的自托管诉求冲突，宜借鉴架构而非直接依赖。
Mem0 / Cognee 不侵入 Claude Code runtime，符合"小核 + 环境扩展"。Letta 是路线竞争者——它要接管整个 runtime，与以 Claude Code 为底座冲突。
harness-agent 跑长流水线、跨多次 acceptance review，"某个 spec 决策何时被推翻"是真实需求——正是 Zep/Graphiti 解决而向量库做不到的。state persistence 层值得借鉴此思路。
EverOS 的 Markdown 真相源 + Case→Skill 自演化，呼应你的输出偏好与 SIA 思路；agentmemory 开源 + MCP 原生 + pi 集成 + iii-engine 三原语，架构哲学与 harness-agent 同源。两者都不锁定存储后端。
"codebase / institutional context"（适合 Cognee 式 KG 流水线）与"跨 session 的 spec 决策与偏好"（适合 Mem0 式自我编辑层）——很可能不该用同一个方案。