DeepSeek Harness 记忆解读：场域分层、参考架构与实现思路

《DeepSeek Harness 架构解读》把核心约束说得很清楚：凡是模型能看见的内容，都必须写进 Session 日志；无论是 replay、fork 还是 compaction，也都从同一份 Session 事件流里读取。系列第 3 篇《多 Agent 解读》还写到子 agent 边界------child 有独立 JSONL，父级通常只见委派 tool 的 prompt 和 result。

但「记忆」在 2025--2026 年已有多套并行方案：MemGPT/Letta $6$ 的分层虚拟上下文、Mem0 $7$ 的多信号检索、EverMemOS $9$ 、MemoryOS $10$ 、MemOS $11$ 的「记忆操作系统」叙事、OpenViking $12$ 把 memory/skill/resource 收进统一目录、Zep $8$ 的会话图、LangGraph $13$ 的检查点状态机，以及 AgentMemory 综述 $1$ 将 agent memory 归纳成 write--manage--read 闭环。Harness 官方目前仍没有单一 Memory 模块。

本文想要分享的是三件事：学界与工程界现在怎么拆「多层次记忆」；一套从业界多家公开方案里抽象出来的参考架构，用来对照各层职责与治理环节，而不绑定某一个具体产品；若 DeepSeek Harness 要支撑完备的记忆能力，在现有 Cordis seam 上应如何挂接------Session 事件、ctx.memory、Write/Read 治理环、后台整合（consolidate，把情节记忆压成可长期保存的事实）等。下文是架构分享与设计思路。

场域共识：记忆不是存储，是 write--manage--read

2026 年多篇综述 $1$ 与基准测试（LoCoMo $2$ 、MemBench $3$ 、MemoryAgentBench $4$ 、MemoryArena $5$ ）有一个共同结论：长上下文不等于记忆。MemoryArena $5$ 上，在 LoCoMo $2$ 接近饱和的模型，放到多 session、前后任务依赖的场景，完成率常降到 40%--60%------说明难的不是「能不能塞进窗口」，而是写哪条、何时召回、谁批准注入、何时遗忘。

把 agent memory 抽象成 Write、Manage、Read 三个动作，再对照具体产品，比直接罗列产品名更清楚：

动作	问什么	典型失败
Write	从交互里抽出什么、以什么 schema 落盘	噪声固化、重复条目、无出处幻觉
Manage	合并、去重、矛盾处理、衰减、归档	摘要漂移、旧偏好覆盖新目标
Read	用什么 query、召回几条、怎么进 context	检索像但不贴任务、自动注入污染窗口

再叠三个正交维度（AgentMemory 综述 $1$ 的分类）：

时间尺度：工作记忆（当前窗口）→ 情节记忆（episodic，一次 session 里具体的 turn/tool 记录）→ 语义记忆（semantic，去掉情境后的事实）→ 程序记忆（可复用 skill/脚本）。难点在迁移策略：哪条情节该 consolidate（整合沉淀）成语义条目，哪条语义事实该在任务开始时 load 回 working memory。

存储基质：上下文内文本、向量索引、SQL/FTS、知识图谱、可执行 skill 库、混合栈。生产里几乎都是 hybrid（多种存储混用）；纯向量检索回答不了「过去 7 天 service X 的失败次数」这类结构化问法。

控制策略：启发式（top-k、每 n 轮摘要）、模型自管（MemGPT $6$ 式 memory tool）、学习策略（RL 优化 store/retrieve/discard）、治理策略（人工确认、注入门控、权限过滤）。工程实践里，检索命中和写进 context 已经常分开处理。

评测也分四层：任务效果、记忆质量（矛盾率/陈旧度）、效率（token/延迟/存储增长）、治理（删除合规/租户隔离）。记忆系统成不成熟，在生产里往往比 benchmark 分数更看「忘掉了多少不该记的、召回了多少该记的」。

工程界几条主路线（2025--2026）

下文按路线分项对照长处与局限。

MemGPT / Letta $6$ ：分层虚拟上下文。把 context window 当 RAM，recall DB 与 archival vector 当磁盘；模型通过 core_memory_*、archival_memory_search 等 tool 在外部存储与窗口之间读写。Letta 后续加了 Filesystem 与 sleep-time agent：记忆整理可异步执行，不阻塞主对话。分层语义清楚；编排（orchestration）失败往往静默------表现为回答略差，没有异常栈。

Mem0 $7$ ：抽取 + 多信号检索。ECAI 2025 论文与 2026 算法更新强调 single-pass 结构化抽取、语义+关键词+实体三路打分融合，对 temporal / multi-hop 查询在公开报告里有提升。抽取与检索链路较完整；抽取质量仍依赖任务域，金融/合规场景常要加 schema 与审计。

Zep / Graphiti $8$ ：会话图 + 时序边。把 message 建成图，支持「某事实何时被推翻」类查询。时序与关系查询方便；架构与运维更重。

EverMemOS $9$ ：记忆操作系统。ACL 2026 把 episodic trace（情节轨迹）→ semantic consolidation（语义整合）做成生命周期；与 Mem0 $7$ 、Zep $8$ 等同台比的是组织原则，不是单一向量库。

MemoryOS $10$ ：分层 persona 记忆（短/中/长期）与 Storage--Updating--Retrieval--Generation 四模块；EMNLP 2025 Oral。

MemOS $11$ ：MemCube 统一封装 + MemScheduler 调度，把 plaintext、activation、parameter 几类记忆当系统资源管。长程推理叙事在各方案里都比较完整；集成面仍在快速迭代。

OpenViking $12$ 思路：统一对象模型 + L0/L1/L2。memory、resource、skill 映射到虚拟目录；检索先 L0 摘要、L1 概览、L2 原文按需下钻，并做目录递归检索。token 预算可控、路径可解释；目录治理做不好时，递归检索容易在深层目录里绕圈。

LangGraph $13$ / 检查点式：记忆与工作流状态机绑定，适合多步任务 resume。编排内聚；跨产品长期语义记忆常要外接 store。

Harness 社区 $14$ $15$ $16$ ：文件轨 + 注入门控 + 状态版本化。memory-evolve $14$ 五轨文件 + 确认队列；memory-gate $15$ SQLite/FTS + CBDC 注入门控；continual-evolve $16$ 版本化 harness 资产。贴合 Session 不变量、可审计；尚未收敛为官方单一 API。

参考架构：七层记忆栈 + 治理环

下面这套参考架构综合了：AgentMemory 综述 $1$ 的 write--manage--read 与四型时间记忆；「轮内 / 会话 / 长期 / 外部 provider」四层分层；OpenViking $12$ 的 L0/L1/L2 按需加载；后台 consolidate（主会话与整理隔离）；memory-gate $15$ 的 Claim → Belief → Decision → Consumption 注入链；memory-evolve $14$ 的多轨 + 人审；以及 Harness 已有的 Session / compaction / Skill / Goal seam。

七层（从短到长）

L0 工作记忆（Working）：当前 provider 窗口里的 messages + system prompt 片段。Harness 对应 deriveMessages() 投影结果、agent/pre-step 可改 prompt。容量最小、延迟为零，但会被 compaction 替换表层。

L1 会话情节（Session Episodic）：append-only JSONL，含 user/assistant/tool/compaction/skill-catalog 等事件。Harness 已是事务源；resume、fork、replay 都读这层。审计以原始事件为准，不能只用 compaction 摘要。

L2 窗口管理（Compaction / Prune）：同 Session 内把旧表层摘要替换，原始事件仍在 L1。Harness 用 ctx.compaction、dsh-compaction-tool-result-pruner。解决窗口太长，不解决跨周用户画像。

L3 任务态（Goal / Todo）：同 Session 内持续推进的目标与检查点。Harness 用 ctx.goals、goal-round-driver；工作区 todo 文件经 tool 进入 L1。

L4 程序与规范（Skill / Workspace）：可复用指令与外部事实文件。Harness 用 ctx.skills + skill 工具（目录经 skill-catalog inject）；Ralph 式跨 Round 状态在工作区文件。程序记忆强调可执行、可版本；Skill 更新应像发版，不要静默改 prompt。

L5 语义长期（Semantic Store）：跨 Session 的结构化 semantic 事实------用户偏好、项目约定、API 坑点。存储可以是 SQLite+FTS、向量库、KG 或 MCP 后端（Memorix / Engram 等）。写入必须经过 Write 路径（tool → Session 记录 → 异步 index），不能只写索引不写日志。

L6 情节归档（Episodic Archive）：完整 Session 日志、compaction 前的 shadow 区间、子 agent JSONL。用途是合规回放、蒸馏 L5、训练反思。

L7 整合层（Consolidation / Sleep-time）：Idle 或 session 结束后，后台 job 从 L1/L6 提炼 candidate facts，写入 L5 或更新 Skill/Goal。执行须与主 transcript（对话记录）隔离：不污染主会话、失败可回滚、权限只写记忆目录。Harness 可用 subagent + ctx.jobs 或独立 bundle 实现，事件仍应可观测。

治理环（套在七层外）

Write 环：置信阈值、去重、矛盾检测、人工确认队列（memory-evolve $14$ ）或 claim 可撤销（memory-gate $15$ ）。

Read 环：检索不等于注入。Recall 得到 candidate；Decision 在 agent/pre-step 做预算（条数/字符/token）；Consumption 经 agent.inject() 写 user 消息进 Session，模型才「看见」。

Forget 环：TTL、访问衰减（MemoryBank/Ebbinghaus 思路）、显式 delete tool、版本覆盖。

Observe 环：每条注入绑 memory/inject 类 Session 事件（或 tool/result），记录 recall id、score、decision=use|ignore。

多 Agent：父/子不共享隐式池；共享只经 L4 工作区文件、L5 命名空间（project/user scope）、或父级读 child tool result。

与 OpenViking L0/L1/L2 的对应

OpenViking $12$	参考架构	Harness 今日
L0 摘要	L5 条目的 abstract	需插件生成
L1 概览	L5 条目 + 元数据	需插件生成
L2 全文	L1 原始事件 / 工作区文件	Session JSONL、fs tool
目录递归	L5 按 project/user/skill 命名空间	memory-evolve $14$ 五轨近似

Harness 现有能力与七层对照

Harness 与参考架构对齐：L1/L2/L3/L4 在 core 里，L5/L7 留给 MCP 与 bundle。

不变量：模型可见 ⟺ 已记录。Session 是 append-only JSONL；deriveMessages() 投影 model history。插件若在内存藏 state 不写 Session，fork、compaction、replay 会对不上------L5 写入也应经 tool/result 或扩展 Session 事件留痕。

Compaction 走读：一次压缩走 compaction/start → compaction/summary → 表层 user 消息带 <compacted-summary> 替换 → compaction/end。L1 保留全量；L0 变短。subagent/descriptor 仅日志、不进 surface，跨 compaction 保留折叠语义。

Skill 与 compaction：skill-catalog 经 agent.inject() 整目录替换；compaction 遮蔽后，skills 子系统会在下次完整观察重建目录，不会静默沿用旧视图。

MCP 记忆（默认关闭）：mcp-memory 示例三份 overlay 只做桥；须 --patch 启用。验证跨 session：会话 A 写入 → 新建会话 B 检索；成功说明 L5 在上游进程，DSH 只传 tool。

参考层	Harness 机制	跨 Session？
L0	deriveMessages 投影	否
L1	Session JSONL + 持久化	同 id 可 resume
L2	ctx.compaction	否
L3	ctx.goals	否
L4	ctx.skills、工作区 fs/bash	文件可跨 session
L5	无内置；MCP / 社区 bundle	取决于实现
L6	L1 即归档	可
L7	无官方；可 subagent/job	需自建

Harness 如何实现完备记忆：架构思路

前提不变：不改 agent-loop 的核心语义，L1 Session 仍是事务源；扩展靠 seam、Session 事件类型与 bundle。下面按 Write → Manage → Read → Observe → Consolidate 五条链路，说明「完备记忆系统」在 Harness 里应如何挂接。

Session 事件：审计与投影

跨 Session 的长期记忆先要处理索引与 Session 日志不一致：向量库或文件里有一份，Session 里又一份，fork 后对不上。Harness 的解法是凡进入模型的，必须在 L1 留痕；L5 的写入、召回、注入、遗忘也都应落成 Session 事件，例如 memory/write-proposed、memory/write-accepted、memory/recall、memory/inject、memory/forget。

session-projection 规定哪些事件进 model history（通常只有 inject 后的 user 消息），哪些仅审计。L5 索引因此与 L1 对话记录指向同一套 Session 事件，fork 后仍可对账。

`ctx.memory` seam：存储可插、逻辑统一

Harness 社区讨论里常见的缺口，是缺少一层官方 seam。概念上可定义 MemoryService，后端可换、接口稳定：

typescript 复制代码

// 概念接口，非官方 API
interface MemoryService {
  proposeWrite(sessionId, claim, evidenceSeqs): Promise<WriteProposal>
  acceptWrite(proposalId): Promise<MemoryRecord>
  recall(scope, query, budget): Promise<RecallResult>
  forget(recordId, reason): Promise<void>
}

Mem0 $7$ 、Zep $8$ 、SQLite、MCP 可各做插件实现；不变量不变：recall 结果要 inject 才进 L0，inject 必须写 Session。

Write 与 Manage 链路

模型通过 memory_remember 一类 tool 提议写入 → Session 留 memory/write-proposed 与 tool/result → 策略或 UI accept → memory/write-accepted → 后端 index。L5 可按用途分命名空间（memory-evolve $14$ 五轨是现成映射：user/、global/、project/ 等）。人审是治理选项，不是架构必选，但 accept 前后都应有 Session 事件。Manage（去重、矛盾、衰减）在 index 之后执行，状态变更同样应可审计。

Read 链路：检索、门控、注入

检索不等于注入，应拆成三步：recall 得 candidate → pre-step 门控（CBDC：use/verify/ignore，预算如 ≤3 条）→ 仅 use 的条目经 agent.inject() 写入并记 memory/inject。统一挂在 agent/pre-step，比多个 bundle 各自改 system prompt 更容易收敛行为。

L7 整合与分层检索

后台 consolidate 用 ctx.jobs 或隔离 subagent，从 L1 或 compaction 摘要提炼 semantic 事实写 L5，不污染主 transcript。L5 条目可存 abstract / overview / bodyRef，recall 先粗后细，路径写入 memory/recall 便于排障（OpenViking $12$ 式思路）。

多 Agent

child 不 inherit 父 L5；共享靠 project scope、L4 文件或 tool result。Fork 只 seed L1/L0，不复制 L5 索引。

能力挂载一览

记忆能力	Harness 上应落在哪里	常见误配
同 Session 窗口	已有 `ctx.compaction`	把 compaction 当跨 session 语义记忆
L5 持久化	`ctx.memory` 插件 + 可选 MCP	只写向量库、不写 Session
Read 治理	`agent/pre-step` 门控 + inject	检索结果直接写入 system prompt
Write 治理	memory tool → Session 事件 → index	内存里藏 state
后台整合	`ctx.jobs` / 隔离 subagent	整理过程写入主 transcript
可观测	`memory/*` 事件 + UI	黑盒 recall

社区插件在参考架构里的位置

memory-evolve $14$ 接近 L5 文件轨 + Write 人审 + Web 面板；memory-gate $15$ 接近 Read 环 CBDC；continual-evolve $16$ 偏 L4/L7 版本化资产；Jesse-njx/dsh-memory、mneme 类偏 L6→L5 蒸馏；mcp-memory 示例可验证 L5 后端桥接。叠加插件之前先对齐：存哪、谁批准注入、能否回滚。

多 Agent 时的记忆边界

child 有独立 L1。父级只见委派 tool 的 prompt/result 时，中间推理在 child JSONL。父要知道 child 结论：读 tool 结果、读 child 写的 L4 文件、或对 project scope 做 recall。Fork seed 父级已完成轮次前缀；spawn 全新 L0/L1。共享要显式选 L4/L5 scope。

范围与代价

官方目前：L0--L4 + L6 已在 core；L5/L7 靠社区/MCP。完备记忆的代价包括：治理多一层就多一道 latency；人审成瓶颈；多插件重复 inject 占 token；L5 写错需 forget 与 audit 兜底，不宜假设「越记越聪明」。

收尾

2026 年的 agent memory 是 write--manage--read 与七层栈、治理环组合在一起的系统工程。Harness 这边 L1 已是事务源，seam 也可组合------长期记忆不必重写 agent-loop，把 L5/L7 与治理环接到现有 Session 主干即可。对照七层表可以看今天缺哪几层；对照 Write/Read 两条链路，可以检查插件是否遵守「可见即已记录」。实验上可跟一条 L1 事件链到 compaction/summary，再用 mcp-memory 做跨 session 召回。记忆类能力通常通过 Bundle + Profile 叠加。

参考资料

$1$ Agent Memory Survey（arXiv:2603.07670，2026）。

$2$ LoCoMo：Long Context Memory benchmark（github.com/snap-research/locomo）。

$3$ MemBench（github.com/import-myself/Membench）。

$4$ MemoryAgentBench（github.com/HUST-AI-HYZ/MemoryAgentBench）。

$5$ MemoryArena（memoryarena.github.io）。