尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！

Harness 架构已经是 架构面试的核心题目， 前两天就有个小伙伴面 字节， 问到 Agent的 记忆底座 架构

• “你们怎么实现 Agent的 记忆架构 ？

• “ 记忆系统的成本太高，怎么优化？

• 记忆检索准确率低，怎么系统性优化？

• 线上出现 Agent"记忆混乱"，怎么排查与定位？

• 如何设计记忆系统的监控指标体系？

• Multi-Agent 多智能体场景下，全局共享记忆怎么设计？

尼恩透露一下，答案都在后面。

尼恩 发现一个共性面试问题，也是目前大厂AI架构岗必考高频重难点：Harness基础设施架构，其中涵盖 Agent的 记忆底座 架构相关知识点。

尼恩 有很多 面架构、或者面大厂 的学员，在架构终面直接折戟在这类场景题上。

通过这个 系列的 文章， 这里 尼恩给大家做一下 系统化、体系化的梳理，写一个系列的文章组成 尼恩编著 《Harness 架构与源码 学习圣经》 深入剖析 Harness AI 平台级 架构的 架构思维与 核心源码，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

同时，也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

尼恩编著 《 DeepAgents /Deerflow / 手写 Harness基建 圣经》

第一章： 什么是 Harness架构？2026年AI核心范式解析 ： Harness架构与Agent工程化

具体文章： 54k+Star 爆火！AI 框架 新王者 Harness Agent 来了！尼恩 来一次Harness穿透式解读

第二章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑

具体文章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑

第十四章： 架构哲学和思维： Harness /ReAct /PlanExec /Reflect /混合范式 的 区别

架构哲学和思维： Harness /ReAct /PlanExec /Reflect /混合范式 的 区别

第十五章： Harness 底层知识： MCP与FC的10大差别？Harness 怎么 用MCP与FC？

Harness 底层知识： MCP与FC的10大差别？Harness 怎么 用MCP与FC？

第17章： Harness SDK 架构 ：DeepAgent 基于LangGraph的生产级Super Agent驾驭层实现

本文

第17章： Harness SDK 架构 ：DeepAgent 基于LangGraph的生产级Super Agent驾驭层实现

第18章：DeepAgent ： 基于LangGraph的 Harness 执行层 生产级 子智能体 Sub-Agent 深度拆解

第18章：DeepAgent ： 基于LangGraph的 Harness 执行层 生产级 子智能体 Sub-Agent 深度拆解

第19章： 深入解析DeepAgents的Middleware管道：设计一个Harness 护栏完成Agent全生命周期的治理

第19章： 深入解析DeepAgents的Middleware管道：设计一个Harness 护栏完成Agent全生命周期的治理

第20章： DeepAgents 经验注入+记忆注入：基于Memory与Skills双中间件 实现 渐进式披露 + 运行时 经验注入

第20章： DeepAgents 经验注入+记忆注入：基于Memory与Skills双中间件 实现 渐进式披露 + 运行时 经验注入

第21章：【顶级架构思维】Harness 架构如何 上下文压缩： 深入 剖析 DeepAgents 四级上下文 压缩流水线 底层原理和核心源码

【顶级架构思维】Harness 架构如何 上下文压缩： 深入 剖析 DeepAgents 四级上下文 压缩流水线 底层原理和核心源码

第22章：Hermes +Claude 实现 AI 编程 Agent Team 硅基团队 ，一人 开启 10个Agent的 个人boss 之路

第22章：Hermes +Claude 实现 AI 编程 Agent Team 硅基团队 ，一人 开启 10个Agent的 个人boss 之路

第24章：【顶级架构】穿透Hermes 塔尖工具系统：自注册设计+ 组合式按需推送+四层纵深防御+零配置插件 +常驻事件循环

第24章：【顶级架构】穿透Hermes 塔尖工具系统：自注册设计+ 组合式按需推送+四层纵深防御+零配置插件 +常驻事件循环

第25章：【Harness顶级架构】Hermes skills 自进化 秘诀：三层引擎 + 影子Agent + 边车文件 + 伞状合并

第25章：【Harness顶级架构】Hermes skills 自进化 秘诀：三层引擎 + 影子Agent + 边车文件 + 伞状合并

第26章：Harness 底层架构： 基于 Deep Agents 深入底层 Sandbox沙盒Infa 基础设施架构

第26章：Harness 底层架构： 基于 Deep Agents 深入底层 Sandbox沙盒Infa 基础设施架构

第27章：【手写 Harness 基建实操】阿里面试官： 如何设计一个 Agent 工具？工业级实战：本地工具 + MCP 混合工具底座设计

第27章：【Harness 基建实操 之 工具底座】阿里面试官： 如何设计一个 Agent 工具？工业级实战：本地工具 + MCP 混合工具底座设计

第28章：【手写 Harness 基建 之 记忆底座】 字节面试官： 如何设计一个 Agent 记忆系统？工业级实战： 四层记忆 infra 底座架构

第28章：【Harness 基建实操 之 记忆底座】 字节面试官： 如何设计一个 Agent 记忆系统？工业级实战： 四层记忆 infra 底座架构

第29章：【手写 Harness 基建 之 Agent 编排底座】 字节面试官： Agent 和 Workflow 到底有什么区别？90%的人都理解错了！ 手写 一个工业级实战： 四层Agent协同编排引擎 Infra 底座 ， 新一代的Agent 协同编排引擎 Infra 底座

第29章：【手写 Harness 基建 之 Agent 编排底座】 字节面试官： Agent 和 Workflow 到底有什么区别？90%的人都理解错了！ 手写 一个工业级实战： 四层Agent协同编排引擎 Infra 底座 ， 新一代的Agent 协同编排引擎 Infra 底座

其他的高质量 文章， 估计有 10章以上，具体请关注技术自由圈。

尼恩还在写，后续发布

字节面试官：Agent记忆系统如何设计？从传统两层 “短期 + 长期” → 工业级四层 记忆架构的完整技术演进

做 AI Agent 这几年，不管是面试候选人还是线上故障复盘，我发现一个共性问题：90% 的人对记忆系统的认知还停留在两三年前的 “短期 + 长期” 两层架构。但真实线上环境里，纯两层架构早就不够用了。

先讲清楚最基础的定义：Agent 记忆系统，就是让智能体 “记住” 历史信息、避免重复提问、保持交互连贯性、实现 “越用越懂你” 的核心基础设施。没有记忆的 Agent，每轮对话都是全新的，永远做不了长任务、永远记不住用户偏好。

早期大家对记忆的理解很朴素，就是简单两层划分：

• 短期记忆：当前会话内的对话历史，塞上下文窗口里
• 长期记忆：跨会话的历史信息，存向量库按需召回

这套两层架构放在简单问答、闲聊场景勉强够用.

但两层架构 不适合 复杂 长任务、企业级场景 ， 本质问题就是粒度太粗、边界模糊、缺少治理。

在 2025 到 2026 年的主流 Agent 实践里，记忆系统开始从粗粒度的 “短期 + 长期” 两层，演进为更细的分层架构。

常见做法是从热到冷清晰划分：

(1) 上下文窗口记忆：直接放 LLM 提示词，速度最快

(2) 工作记忆：当前任务的结构化状态，专门解决长任务失忆

(3) 会话记忆：当前完整会话历史，摘要压缩控长度

(4) 长期记忆：跨会话持久化沉淀，混合检索精准召回

不同开源项目会以不同方式落地这套分层思想：

• Hermes Agent 更强调有界核心记忆和会话搜索，
• OpenClaw 更强调本地工作区、Markdown 记忆文件和混合检索，
• DeerFlow 2.0 更强调长任务编排、上下文压缩和文件产物沉淀。

接下来我们就逐层拆解，结合可验证的开源实现讲透原理、考点、踩坑经验。

一、 四层记忆架构数据流向图

记忆系统的本质是解决 “LLM 上下文窗口有限” 和 “长任务 / 跨会话需要历史信息” 这对核心矛盾。

传统两层架构粒度太粗，工程上通常会进一步拆成上下文、任务状态、会话历史、长期沉淀这几类能力：

记忆系统的本质是解决 “LLM 上下文窗口有限” 和 “长任务 / 跨会话需要历史信息” 这对核心矛盾。传统两层架构粒度太粗，工程上通常会进一步拆成上下文、任务状态、会话历史、长期沉淀这几类能力：

四层记忆核心参数对照表

记忆层级	定位	存储介质	典型容量	访问延迟	三大开源项目实现
第 0 层上下文窗口记忆	热记忆 / 当前交互	LLM 原生上下文	4k~128k tokens	最低(直接推理)	Hermes 核心记忆注入 OpenClaw 核心记忆 / 近期笔记按需进入上下文 DeerFlow 上下文压缩
第 1 层工作记忆	任务认知黑板 / 长任务必备	内存 / 文件 / 任务状态	无硬限制	低	DeerFlow sub-agent 上下文隔离 OpenClaw 工作区每日笔记 Hermes 核心偏好约束
第 2 层会话记忆	单会话完整历史	SQLite / 本地文件	单会话无限	中	Hermes SQLite 会话搜索 OpenClaw 每日笔记 + memory_search DeerFlow 中间结果 offload
第 3 层长期记忆	跨会话知识沉淀	文件 / DB / 向量索引	理论无限	较高	Hermes 有界 Markdown 记忆 OpenClaw MEMORY.md + memory/*.md 索引 DeerFlow 本地长期记忆

四层记忆架构 核心优势有三个：

第一，冷热分离：高频访问的热记忆放上下文，低频的冷记忆存向量库，兼顾速度和容量；

第二，升降级机制：会话结束后自动提炼精华写入长期记忆，检索命中的冷记忆重新注入上下文；

第三，治理边界清晰：每一层都有独立的清理、去重、过期机制，从根源避免 “记忆熵增”。

Hermes、OpenClaw、DeerFlow 这类项目都体现了分层记忆思想，但实现方式并不完全相同：有的偏核心记忆注入，有的偏本地工作区和记忆检索，有的偏长任务上下文工程。

面试官大概率 问的两个问题，提前准备好：

问 1：为什么不直接把所有记忆都塞上下文？反正现在大模型窗口都很大了？

答：三个现实问题绕不开：

(1) 成本问题：上下文是 O (n²) 的 Token 开销，1M 窗口跑起来成本是几十倍的上涨；

(2) 注意力问题：长上下文存在 “中间遗忘效应”，模型注意力集中在开头和结尾，中间信息大概率被忽略；

(3) 延迟问题：窗口越大推理速度越慢，线上 C 端产品根本扛不住。

所以窗口再大，分层记忆依旧是工程最优解。

问 2：工作记忆这一层和传统短期记忆到底区别在哪？

答：本质完全不同：

传统短期记忆是 “对话流水账”，按时间顺序存原始对话；

工作记忆是 “结构化任务认知”，存的是任务目标、实体关系、中间产出，和对话顺序无关。

举个例子：写一篇万字调研报告，短期记忆存的是你和 Agent 的每一句对话，工作记忆存的是 “当前写到第几章、已确认的核心论点、引用的数据源”。这就是为什么加了工作记忆层，长任务就不会 “跑着跑着忘了最初目标”。

二、四层记忆架构深度拆解

这部分是面试的核心，也是区分 “背题党” 和 “真做过项目” 的关键。

我把每一层拆开来讲，不光讲原理，重点讲三大开源项目怎么实现的、线上踩过什么坑、面试官最爱问什么，看完直接能答题。

第 0 层：上下文窗口记忆（In-Context Memory）

1. 核心定位与原理

这是最基础、也是所有人都接触过的一层。

简单说就是把对话历史直接塞 LLM 的提示词里，依托大模型自身的注意力机制来 “记住”。

这一层的特点非常鲜明：

• 优点：速度最快、无额外开销、实现最简单
• 缺点：容量最受限、成本随长度指数级上涨、长上下文注意力稀释

面试官灵魂拷问：既然上下文窗口这么好用，为什么还要其他记忆层？

你答：三个硬伤绕不开 ：

• ① 窗口再大也有上限；
• ② Token 成本是 O (n²) 上涨，128k 上下文比 8k 贵几十倍；
• ③ 长上下文存在 “中间遗忘效应”，模型只记得开头结尾，中间内容基本被忽略。

2. 三大核心实现方案（面试必考点）

（1）固定窗口截断方案

原理：只保留最近 N 轮对话或者最近 N 个 token，超出的部分直接丢弃。

• 适用场景：闲聊机器人、简单客服问答、信息价值快速衰减的场景
• 优点：实现零成本、长度绝对可控
• 踩坑点：用户开头说的 “输出要严谨”" 不要改格式 “这类全局指令，很容易被截断丢掉，导致后面 Agent 突然” 失忆变傻 "

（2）滑动窗口 + 置顶保护方案

原理：系统指令、全局规则这类重要信息永久置顶不参与截断，只截断尾部的普通对话历史。

• 这是目前工业界标配方案，比纯固定窗口靠谱太多
• 优化点：支持给重要消息打标记 “免截断”

（3）实时令牌压缩方案

原理：工具返回的大体积内容、长文本先做摘要压缩再进上下文。

• 适用场景：大量工具调用、文档检索的 Agent

3. 三大开源项目实现对比

项目	实现方案	核心细节
Hermes Agent	核心记忆注入 + 会话搜索	MEMORY.md / USER.md 保存短而稳定的长期信息，历史会话走 SQLite/FTS5 搜索
OpenClaw	工作区记忆文件 + memory_search	核心记忆和近期笔记按需进入上下文，更早历史通过检索召回
DeerFlow 2.0	Sub-Agent 隔离 + 上下文压缩	通过子任务上下文隔离、中间产物落地和摘要压缩减少上下文压力

很多团队上线前只测短对话，一到真实用户连续聊几十轮，Agent 就可能忘掉最开始的要求，输出格式也开始漂移。

根源通常不是模型突然变差，而是没有做重要信息置顶保护。

4. 本层高频率面试题

Q：上下文窗口的 “中间遗忘效应” 是什么？怎么缓解？

A：大模型处理长上下文时，注意力主要集中在开头和结尾，中间内容的召回率大幅下降。缓解手段：① 重要信息放开头或结尾；② 关键内容定期重复出现；③ 不要过度依赖长上下文，该分层就分层。

第 1 层：工作记忆（Working Memory）

1. 为什么必须加这一层？

之前团队做调研报告 Agent，用户要求 “写一份 10 个章节的行业报告”，结果跑了 3 个小时，最后 Agent 忘了要写 10 章，只输出了 3 章就结束了。

这就是传统两层架构的致命死穴：长任务跑着跑着就忘了最初的目标。

工作记忆就是专门解决这个问题的，它不是 “对话流水账”，而是当前任务的 “认知黑板”： 存的不是对话内容，是结构化的任务状态。

2. 核心能力

工作记忆（Working Memory） 记录的是 任务状态+任务目标+任务中间成果物

(1) 任务目标锚定：永久记住最终目标，防止跑偏

(2) 实体关系图谱：记录任务涉及的人、事、物及其关联

(3) 中间结果持久化：已完成的子任务产出落地，不用反复重算

(4) 断点续传支持：任务中断了，从上一个状态继续，不用从头再来

3. 三大开源项目深度对比

项目	实现方式	核心创新	适用场景
DeerFlow 2.0	Sub-Agent 上下文隔离 + 文件产物沉淀	通过子任务隔离、sandbox 文件系统和上下文压缩降低长任务失忆风险	长报告、自动化调研、代码项目生成
OpenClaw	工作区每日笔记 + 检索索引	当前和近期工作上下文可直接检查，更早历史通过 memory_search 召回	个人助理、代码开发、文档写作
Hermes	有界核心记忆 + 会话搜索	用小而稳定的核心偏好约束当前任务，历史会话走 SQLite 搜索	个人助理、日常办公助手

4. 本层高频率面试题

Q：工作记忆和传统短期记忆的本质区别是什么？

A：三个维度完全不同：

(1) 内容不同：短期记忆是对话流水账，按时间排序；工作记忆是结构化任务状态+任务目标+任务中间成果物，和对话顺序无关

(2) 目的不同：短期记忆是 “记住说了什么”；工作记忆是 “记住要做什么、做到哪了”

(3) 价值不同：没有工作记忆，Agent 做不了超过 10 轮的长任务

Q：工作记忆会增加系统复杂度，简单任务要不要加？

A：简单对话类任务确实不需要，但只要是任务型 Agent，哪怕不复杂，建议都加上。成本不高，但能避免大量 “目标漂移” 的线上故障。

第 2 层：会话记忆（Episodic Memory）

1. 核心定位

会话记忆就是当前这一轮完整对话的 “外存”： 上下文窗口装不下的内容，先存在这一层。

边界很清晰：当前会话内有效，会话结束默认不跨会话加载。

作用就是承接上下文窗口溢出的内容，避免重要信息被直接丢掉。

2. 两大核心实现方案

（1）滚动摘要方案

原理：对话历史快塞满窗口时，不直接删除最早的内容，而是把前面一段对话总结成一条短摘要，用摘要替换原始记录。

• 优点：压缩长度的同时，尽量保住任务目标、风格要求、已确认结论
• 缺点：多一次模型调用，摘要质量直接影响后续效果
• 适用场景：项目规划、长篇创作、长任务类 Agent

（2）会话内检索方案

原理：整个会话历史向量化，当前问题只召回最相关的 N 条历史，不把所有历史都塞上下文。

• 适用场景：单会话超长篇任务（写一本书、做大型调研）

3. 三大开源项目实现对比

项目	实现方案	触发时机
Hermes	SQLite 会话搜索	历史会话进入本地数据库，通过全文检索找回相关内容
OpenClaw	每日笔记 + 检索索引	近期笔记按需进入上下文，远期历史通过 memory_search 召回
DeerFlow 2.0	上下文压缩 + 中间结果落地	通过摘要、裁剪和文件产物 offload 控制长任务上下文

滚动摘要这个方案，最容易踩的坑就是摘要质量差。摘要一旦总结错了，相当于给 Agent 植入了错误记忆。

更稳的做法是：

• ① 摘要模型和主任务模型解耦；
• ② 关键信息（比如用户要求、核心结论）标记为 “不参与摘要”；
• ③ 摘要结果进入上下文前做一次校验。

4. 本层高频率面试题

Q：滚动摘要多了一次模型调用，成本怎么控制？

A：三个优化手段：

• ① 降低摘要触发频率，比如超过 20 轮才摘一次；
• ② 用便宜的小模型做摘要，成本是主模型的 1/10；
• ③ 摘要结果做缓存，同一段不用反复摘。

Q：会话记忆和工作记忆有重叠吗？

A：定位完全不同。会话记忆是 “这轮对话都说了什么”，工作记忆是 “这个任务做到哪了”。前者是情景记录，后者是任务状态。

第 3 层：长期记忆（Long-term Memory）

1. 核心定位

跨会话的持久化记忆，是 Agent"越用越聪明" 的核心。

简单说就是：上次对话你说过 “我讨厌写注释”，这次找 Agent 写代码，它自动就记住了，不用你再说一遍。

特点：容量大、访问频率低、必须检索才能使用。

2. 核心技术链路：存储 → 索引 → 检索 → 注入

（1）存储层：三大开源方案对比

项目	存储介质	设计哲学	优势
Hermes	Markdown 核心记忆 + SQLite/FTS5	轻量化、本地优先	部署简单，会话搜索方便
OpenClaw	MEMORY.md + memory/*.md + SQLite 混合索引	人类可读、可直接编辑	调试方便，可人工修正记忆
DeerFlow	本地长期记忆 + 文件系统产物	长任务上下文工程	适合多步骤任务和中间结果沉淀

选型建议：

• 个人偏好和本地会话搜索选 Hermes；需要长期运行在本地、记忆可检查可修改，选 OpenClaw；
• 多步骤长任务和文件产物型 Agent 选 DeerFlow。

（2）索引层：2026 年主流是混合检索

纯向量检索已经不够用了，现在都是三驾马车混合检索：

(1) 向量相似度：语义匹配

(2) BM25 关键词：精确匹配

(3) 实体标签：结构化过滤

（3）检索层：不是什么都值得存

该存进长期记忆的内容：

• 用户稳定偏好（“我喜欢简洁输出”）
• 任务核心目标
• 已经确认的重要事实
• 后续会复用的结论

不该存的：临时对话、中间过程、错误信息

（4）注入层：召回结果排序去重后，按优先级注入上下文

3. 本层高频率面试题

Q：长期记忆为什么不用纯文件存储，一定要上向量库？

A：向量库支持语义相似度检索。

比如用户说 “我上次说的那个方案”，向量库能从几千条历史里，找到语义相关的那条；纯文件存储只能按时间查找，做不到语义理解层面的召回。

Q：向量检索不准怎么办？

A：更稳的工程解法是混合检索 ： 向量 + 关键词 + 实体标签多维度打分。

相比纯向量检索，它更适合同时处理语义相似、精确术语和实体过滤问题。

老架构师总结

这四层记忆，面试的时候别光说名字，记住一句话：

第 0 层拼速度，第 1 层拼长任务稳定性，第 2 层拼会话连贯性，第 3 层拼个性化体验。

少了第 1 层，做不了长任务；少了第 3 层，做不到 “越用越懂你”。这就是为什么行业要从两层升级到四层。

三、工业级 Harness 实操之 memory infra 记忆底座架构

很多 Agent 线上故障，不是模型不行，而是记忆系统没治理好。

很多团队做记忆系统，只做 “存” 和 “取”，完全忽略 “治”。

上线前三个月好好的，越用越乱：重复记忆一大堆、过时信息还在影响决策、新旧事实冲突了 Agent 自己也分不清，最后整个记忆系统彻底熵增，变成一团浆糊。

就是记忆系统没治理好

尼恩团队结合 Hermes 、 DeerFlow 等Harness 马具架构的 灵魂，给大家 打造一个 工业级 Harness 实操之 memory infra 记忆底座.

[ 请参考尼恩团队 《 全球顶级 全栈 AI 架构视频 第十一章 ： 手写 工业级harness 基础设施架构实操 》](尼恩团队 AI全栈架构 ：0数学 一步登天 精通 深度学习 + 机器学习+ 大模型微调 + Harness 架构 +Agent架构)

这一节全是踩坑踩出来的经验，也是现在大厂面试深挖的重点。

1. 为什么必须做治理？记忆熵增定律

什么是 记忆熵增定律 ？

先讲个真实线上事故： 某团队做的智能客服，上线半年，用户明明说 “我要退款”，Agent 还在给人发优惠券。

查了三天才发现：

• 三个月前这个用户咨询过优惠券，这条过时记忆一直没清理
• 检索的时候权重还很高，把最新的退款请求给盖过去了。

这就是记忆熵增定律：只要不加治理，记忆系统一定会自发地从有序走向混乱。

面试官提问：记忆系统只做存储和检索不行吗？为什么还要治理？

你可以答：只存不治，三个问题必然出现：

(1) 重复记忆：同一个事实存 N 遍，检索结果全是冗余

(2) 过时记忆：信息过期了还在用，导致决策错误

(3) 冲突记忆：新旧事实矛盾，Agent 自己不知道该信哪个

治理的本质就是对抗熵增，让记忆系统长期可用。

2. memory infra 记忆底座 的 五大核心治理机制

机制一：设计 记忆准入机制

注意 ， 不是什么都配进长期记忆

核心原则：写入前先做 “资格审查”，别什么垃圾都往里塞。

具体怎么做：

(1) 重要性打分：模型给每轮对话打分，低于阈值直接不存

• 用户偏好、核心目标、已确认事实 → 高分必存
• 闲聊、中间过程、临时信息 → 低分过滤

(2) 语义去重校验：写入前和已有记忆做相似度比对，重复的不存

(3) 事实校验：明显错误的信息直接拦截

三大开源项目实现对比

项目	准入机制	具体实现
Hermes	字符上限 + 写入校验	对核心记忆做敏感信息扫描、重复检测和长度约束
OpenClaw	文件可编辑 + 检索增强	稳定事实写入 MEMORY.md，日常笔记通过索引召回
DeerFlow	长任务上下文治理	通过 sub-agent、文件产物和长期本地记忆降低上下文污染

不能 图省事，直接 “对话全量存”，运行一段时间后，记忆库里会堆积大量无效内容，检索噪声明显变大。

加上准入机制后，写入量会下降，但召回质量通常会更稳定。

宁可少存，也别乱存。

机制二：记忆合并与归一化

记忆合并与归一化 ，目标 解决冗余与实体混乱

两个最常见的问题：

(1) 同一件事存了七八遍，检索出来全是重复

(2) “张三”" 张总 ““张工”” 张三老师 "，Agent 不知道是同一个人

具体怎么做：

(1) 语义去重合并：相似度超过阈值的记忆自动合并，只保留最新版本

(2) 实体归一化：实体链接 + 消歧，同一个人的不同称呼统一成一个实体 ID

(3) 冲突解决：新旧事实冲突时，默认新记忆覆盖旧记忆，高优先级保留

机制三：记忆过期与主动遗忘

记忆过期与主动遗忘 ，目标 该忘的就得忘

• 人类会遗忘，这是优点；
• Agent 不会遗忘，就是缺陷。

主流遗忘策略：

(1) 时间衰减曲线：90 天自动过期，越老的记忆检索权重越低

(2) 访问频率衰减：越久没被召回的记忆，权重持续降低

(3) 定期清理：每日凌晨跑定时任务清理无效记忆

开源项目中的相关能力

• OpenClaw Dreaming / Memory Wiki 类能力：Dreaming 是可选后台整理，Memory Wiki 是伴随插件，可以辅助整理知识，但不要把这些增强能力当成基础记忆主线来背
• Amazon Bedrock：Intelligent Consolidation 智能合并，四种策略：语义合并、用户偏好提取、摘要压缩、情景记忆固化

面试官高频追问：

主动遗忘会不会把重要信息删掉了？

你可以回答：不会，我们会做记忆分级：

• 核心记忆（用户偏好、重要事实）：永久保存，不参与自动过期
• 普通记忆（单次对话结论）：90 天过期
• 临时记忆（中间过程）：会话结束就删

分级处理，该永久存的不会丢，该忘的果断忘。

机制四：记忆升降级 ： 四层架构的核心联动

这是四层记忆架构最精妙的设计：记忆不是一成不变的，会在四层之间流动。

完整升降级链路：

(1) 降级（热→冷）：

• 对话溢出 → 从第 0 层写入第 2 层会话记忆
• 会话结束 → 精华提炼后写入第 3 层长期记忆
• 任务完成 → 工作记忆的核心结论沉淀到长期记忆

(2) 升级（冷→热）：

• 检索命中 → 从第 3 层长期记忆注入第 0 层上下文

DeerFlow 相关实现：

DeerFlow 2.0 更强调 sub-agent 上下文隔离、sandbox 文件系统、中间结果 offload 和本地长期记忆。更准确的说法是：它适合承载长任务记忆与上下文治理，但具体存储分层要看落地方案。

机制五：记忆安全与可解释性

记忆安全与可解释性 ， 目标 用户要有控制权

记忆系统处理的都是用户数据，安全和可控是底线。

三大必备能力：

(1) 用户可控：提供界面让用户可以查看、编辑、删除任意一条记忆

(2) 审计日志：谁、什么时候、修改了哪条记忆，全链路可追溯

(3) 防注入防护：记忆写入前做恶意指令检测，防止提示注入通过记忆传播

进一步做多 Agent 系统时，可以借鉴操作系统的隔离思想，把主 Agent 的全局记忆和工作 Agent 的局部记忆分开，降低记忆污染扩散的风险。

3. 三大开源项目治理方案全景对比

治理机制	Hermes	OpenClaw	DeerFlow 2.0
记忆准入	字符上限 + 写入校验	MEMORY.md 精简长期事实，每日笔记走索引召回	上下文压缩 + 长期记忆写入约束
去重合并	重复检测	依赖索引和人工整理	写入时尽量跳过重复事实
过期遗忘	手工修订核心记忆	Dreaming / Memory Wiki 可辅助整理，基础能力仍以文件和索引为主	以具体版本实现为准
升降级	核心记忆注入 + 会话搜索	核心记忆 / 近期笔记按需进入上下文，远期历史检索	中间结果 offload，必要信息回注上下文
安全可控	Markdown 可审查	Markdown 直接修改	通过 memory / filesystem 机制沉淀

4. 本层高频面试题

Q：小项目、简单场景，能不能不做记忆治理？

A：短期跑 demo 可以，长期上线就不建议省掉。哪怕最简单的系统，也至少要做两个基础治理：

• ① 写入前去重；
• ② 过期或降权机制。它们实现成本不高，却能显著降低记忆噪声。

Q：记忆治理会不会增加很多成本？

A：恰恰相反，治理通常能降本。

无效记忆少了，检索范围会缩小，召回质量会提高，大模型反复纠错的次数也会减少。

短期看增加了一点复杂度，长期看是省钱又省心。

Q：你在项目中遇到过哪些记忆治理的坑？怎么解决的？

A：可以按一个企业知识库 Agent 的典型故障来讲：上线一段时间后，检索准确率持续下降。

排查发现是大量过时的旧文档记忆还在被召回，而且同一个知识点更新了三四版，旧版本还在。

解决方案：

(1) 加了版本号机制，新文档写入后自动标记旧版本过期

(2) 加了时间衰减，超过三个月的记忆权重自动减半

(3) 做了记忆分级，核心知识永久保存，临时文档 90 天自动清理

优化后，过时内容的召回比例会明显下降，检索结果也更稳定。

5、参考实现

请参考尼恩团队 《 全球顶级 全栈 AI 架构视频 第十一章 ： 手写 工业级harness 基础设施架构实操 》

尼恩团队结合 Hermes 、 DeerFlow 等Harness 马具架构的 灵魂，给大家 打造一个 工业级 Harness 实操之 memory infra 记忆底座.

[ 请参考尼恩团队 《 全球顶级 全栈 AI 架构视频 第十一章 ： 手写 工业级harness 基础设施架构实操 》](尼恩团队 AI全栈架构 ：0数学 一步登天 精通 深度学习 + 机器学习+ 大模型微调 + Harness 架构 +Agent架构)

四、三大开源项目记忆架构全景对比

从定位上看

• Hermes 更偏有界持久记忆 + 会话搜索
• OpenClaw 更偏个人助理运行时 + 工作区文件记忆 + 混合检索
• DeerFlow 2.0 更偏长任务 SuperAgent Harness + 上下文工程 + 本地长期记忆。

1. Hermes Agent：有界持久记忆 + SQLite 会话搜索

核心定位

轻量化个人智能体，记忆系统的核心特点是：

• 把少量高价值长期记忆显式写入 Markdown 文件，
• 把历史会话存入本地 SQLite 数据库，便于后续搜索和恢复上下文。

设计哲学

有界、可检查、避免记忆膨胀。

Hermes 不是把所有历史都塞进长期记忆，而是给核心记忆设置明确字符上限，逼迫 Agent 或用户只保留高价值内容。

记忆结构

Hermes 的记忆结构主要有两类：

~/.hermes/
├── memories/
│   ├── MEMORY.md    # 环境 / 项目 / 工具相关长期记忆，约 2,200 字符上限
│   └── USER.md      # 用户偏好、沟通方式、工作习惯，约 1,375 字符上限
└── state.db         # SQLite + FTS5，用于会话历史与 session_search

很多人刚接触会觉得上限太小，但这恰恰是 Hermes 的工程取舍：长期置顶记忆必须短、准、稳定。

超过限制时，系统会要求 Agent 合并、删除或重写后再尝试写入，而不是无限压缩。

可以确定的记忆能力：

(1) 长期核心记忆：MEMORY.md 和 USER.md 会在会话开始时注入系统提示，适合保存稳定偏好、项目约定、环境信息。

(2) 本地会话历史：历史会话存入 state.db，通过 SQLite FTS5 支持全文检索。

(3) 记忆写入治理：写入时会做敏感信息扫描、重复检测和字符上限校验，避免记忆污染。

(4) 人类可编辑：用户可以直接编辑 Markdown 记忆文件，适合个人长期使用和手工校准。

核心创新：有界置顶记忆

Hermes 最值得借鉴的不是复杂架构，而是把长期记忆做小、做硬、做可控。

比如用户长期偏好 “输出要简洁”" 不要改我的格式 "，这类稳定信息适合写入 USER.md。

但临时对话、一次性任务中间过程，不应该进入这两个核心文件。

工程取舍

优点：

• 记忆文件小而清晰，适合保存长期偏好和项目约定
• SQLite + FTS5 能覆盖个人会话搜索，不需要额外向量库
• Markdown 文件可人工审查和修改，调试成本低

缺点：

• 核心记忆容量有限，不适合承载大规模知识库
• 更适合单用户、本地化使用，不是多租户企业记忆平台
• 记忆能力更偏偏好管理和会话搜索，不适合作为完整四层记忆治理系统来使用

最适合的场景

• 个人日常办公助理，长期用、希望它越来越懂你
• 对隐私要求高，所有数据必须本地
• 讨厌复杂配置，开箱即用
• 不适合：多用户权限隔离、大规模知识库、强状态长任务恢复

2. OpenClaw：个人助理运行时里的工作区记忆

核心定位

OpenClaw 不是单独的记忆框架，而是一个跑在用户自己设备上的个人 AI 助手运行时。

它的记忆系统服务于一个更大的目标：让 Agent 有自己的本地工作区，长期使用时能保存偏好、事实、日常笔记和历史线索。

如果只看记忆这一块，OpenClaw 的特点很清楚：记忆能落到文件里，人能看、能改；历史内容还能通过检索找回来。

设计哲学

工作区优先、文件可见、检索补充。

OpenClaw 把核心记忆和日常笔记放在本地 agent 工作区里：

• MEMORY.md 放稳定偏好、长期事实和重要约定；
• memory/*.md 放每天的上下文、观察和会话摘要；
• 默认 memory-core 会把这些文件建成索引，搜索时再用关键词和向量一起召回。

所以它适合长期运行的个人助理，也适合开发、写作、调试这类需要“看得见记忆”的场景。

出了问题可以直接打开文件检查，不必猜 Agent 到底记了什么。

记忆结构

OpenClaw 的主线记忆结构，更接近下面这种本地 Agent 工作区：

本地 Agent 工作区
├── MEMORY.md              # 精简长期记忆，保存稳定偏好、事实和约定
├── memory/
│   └── YYYY-MM-DD.md      # 每日笔记，保存当天上下文、观察和会话摘要
└── DREAMS.md              # 可选，Dreaming 后台整理结果，给人审查

这里有三个边界一定要讲清楚：

(1) MEMORY.md 是精简长期记忆：只放稳定、重要、后面还会用的信息，不适合当原始聊天记录仓库。

(2) memory/*.md 是日常笔记层：保存更细的上下文和观察，今天、昨天这类近期笔记可以进入会话上下文，更早内容主要靠 memory_search / memory_get 找回来。

(3) 检索索引不是人工记忆文件：默认后端会把 MEMORY.md 和 memory/*.md 切块后写入每个 Agent 独立的 SQLite 索引，用 FTS5/BM25 和向量检索提高召回质量。

核心创新：人能改的文件 + 机器能搜的索引

OpenClaw 最值得借鉴的地方，不是发明了一套玄乎的“仿生记忆”，而是把两件朴素但很实用的事接起来：

(1) 重要记忆放在 Markdown 文件里，人能读、能改、能备份；

(2) 历史笔记交给索引和 memory_search，需要时再召回。

这个设计很适合代码、文档、文件名、错误码这类场景。

因为纯向量检索 ，会出现 语义漂移，而关键词检索能抓住精确名词； 两者结合起来，比只靠一种检索方式更稳。

这里也要把边界讲清楚：

• OpenClaw 的基础主线是工作区记忆文件、默认 SQLite 索引和 memory_search / memory_get。
• Dreaming、Memory Wiki、LanceDB、QMD、Honcho 这类能力属于可选增强层，面试时不要把它们说成 OpenClaw 的唯一默认记忆架构。

工程取舍

优点：

• 核心记忆和每日笔记都是人类可读的 Markdown，出问题可以直接检查和修改
• 默认 memory-core 支持关键词检索、向量检索和混合检索，适合代码、文档、文件名、错误码这类精确召回场景
• 本地工作区模式适合个人助理长期使用，也方便用私有 Git 仓库备份
• Dreaming / Memory Wiki 等可选能力可以辅助整理，但不影响基础记忆模型

缺点：

• 更偏个人 / 本地工作区，不应直接等同于企业多租户记忆平台
• 每日笔记不是严格的任务状态快照，强断点续传要额外设计
• 记忆规模变大后，检索质量依赖索引、embedding 服务和文件组织
• 部分高级能力依赖插件或配置，不能默认说成所有安装都具备

最适合的场景

• 个人 AI 助理长期运行在自己的设备上
• 程序员写代码、debug、整理项目上下文
• 写文档、做创作、需要长期保留项目设定
• 喜欢掌控感，希望记忆能看见、能修改、能备份
• 不适合：企业级多租户、超高并发、强状态长任务恢复

3. DeerFlow 2.0：长任务 SuperAgent Harness + 上下文工程

核心定位

面向长任务的 SuperAgent Harness，字节跳动开源，重点不只是 “记忆存储”，而是把 sub-agents、sandbox、files、skills、memory、context engineering 组合起来，让 Agent 能完成分钟到小时级的复杂任务。

设计哲学

长任务优先、上下文优先、产物优先。

DeerFlow 2.0 的核心思路是：复杂任务不能只靠单个长上下文模型硬扛，而要把任务拆给多个 sub-agent，在隔离上下文中执行，再通过文件系统、记忆和压缩机制沉淀结果。

个人简单问答用它会显得偏重，但如果任务需要多步骤调研、代码生成、文件产物和长时间执行，它的设计会更合适。

记忆与上下文结构

DeerFlow 的记忆与上下文能力，可以概括为三类：

能力层	主要作用	适合保存的内容
上下文压缩与隔离	通过 sub-agent 隔离上下文，压缩无关历史	子任务输入、局部推理过程、阶段性摘要
文件系统记忆	用 sandbox / filesystem 保存中间产物	调研资料、代码文件、报告草稿、工具输出
长期本地记忆	跨会话保存用户画像、偏好、积累知识	用户偏好、常用项目背景、可复用结论，并在写入时尽量跳过重复事实

关键能力：Sub-Agent + Sandbox + Memory

DeerFlow 2.0 的优势不在于一个单独的 “记忆数据库”，而在于把任务执行拆成多个隔离单元：

(1) Sub-Agent 隔离：不同子任务可以在独立上下文中执行，减少主上下文污染。

(2) Sandbox 文件系统：中间产物落到文件，不必都塞回模型上下文。

(3) Memory 能力：跨会话保留用户偏好、长期知识和积累事实。

(4) Context Engineering：通过摘要、裁剪、offload intermediate results 控制上下文长度。

这些机制组合起来，才是它适合长任务的原因。

工程边界

DeerFlow 2.0 的重点是 SuperAgent 编排、上下文工程、本地长期记忆和文件系统产物，而不是一个已经固定为 “Redis 短期记忆 + 向量库中期记忆 + PostgreSQL/知识图谱长期记忆” 的三级数据库系统。

如果项目中要做强断点续传，可以在 DeerFlow 这类长任务框架之上继续设计任务状态快照和恢复机制，但这属于具体落地方案，不应和框架的基础记忆能力混为一谈。

工程取舍

优点：

• 适合多步骤长任务，尤其是调研、代码生成、文档产物类任务
• sub-agent 隔离能减少单一上下文过载
• sandbox / filesystem 让中间产物可以落地，不必全部塞进上下文
• 本地长期记忆可以保存偏好和积累知识

缺点：

• 对简单问答和轻量个人助理来说偏重
• 企业级多租户、权限管控、数据库选型需要结合具体业务额外设计
• 是否具备强断点续传、跨进程恢复，要以具体版本和源码实现为准

最适合的场景

• 多步骤调研、长报告生成、代码项目生成
• 需要 sub-agent 分工和文件产物沉淀的任务
• 需要跨会话保留用户偏好和长期知识的复杂 Agent 应用
• 不适合：简单问答、轻量聊天、只需要一两个工具调用的任务

4. 三大项目全景对比总表

对比维度	Hermes Agent	OpenClaw	DeerFlow 2.0
出品方	NousResearch / 社区开源	社区开源	字节跳动开源
核心定位	轻量个人 Agent 记忆	个人助理运行时 + 本地工作区记忆	长任务 SuperAgent Harness
记忆分层	有界核心记忆 + 会话搜索	MEMORY.md 长期记忆 + 每日笔记 + memory tools	上下文隔离 + 文件产物 + 本地长期记忆
存储介质	Markdown 文件 + SQLite/FTS5	Markdown 工作区 + 每个 Agent 独立的 SQLite 索引	Sandbox 文件系统 + 本地记忆
索引方式	FTS5 会话搜索	BM25/FTS5 + 向量混合检索	重点是上下文压缩与产物 offload
核心创新	有界置顶记忆，防止长期记忆膨胀	人能改的文件 + 机器能搜的索引	Sub-Agent 编排 + Sandbox + Memory
长任务支持	不作为核心卖点	不作为核心卖点	较强，适合多步骤长任务
部署依赖	轻量，本地文件和 SQLite	本地工作区 + 索引	相对更重，依赖具体运行配置
多用户支持	更偏单用户	更偏单用户	可作为复杂应用底座，但多租户能力需看具体实现
记忆可编辑	直接编辑 Markdown	原生 Markdown 可编辑	主要通过文件 / 记忆接口沉淀
检索特点	会话全文搜索	默认 memory-core 支持关键词、向量和混合检索	强调上下文压缩和产物 offload
企业级能力	不作为主要定位	不作为主要定位	更接近复杂任务框架，但不能夸大成完整企业记忆平台
推荐用户	个人长期使用	个人助理 / 开发者 / 创作者	长任务 / 多步骤产物型 Agent

5. 2026 年选型决策树

别再问 “哪个最好” 了，三个项目的定位并不相同：

选型时可以简单按任务类型切分：

• 日常问答、个人偏好沉淀：优先 Hermes
• 个人助理长期运行、代码开发、文档写作、需要人工检查记忆：优先 OpenClaw
• 多步骤调研、代码项目生成、报告产物：优先 DeerFlow

三个工具解决三类问题，重点是按场景选择。

老架构师总结

这三个项目其实代表了 Agent 记忆架构的三个发展方向：

• Hermes 走的是轻量个人化、有界核心记忆路线
• OpenClaw 走的是本地工作区、文件可控、混合检索路线
• DeerFlow 走的是长任务编排、上下文工程、产物沉淀路线

面试的时候，能把这三个项目的差异、取舍、适用场景讲到这个深度，面试官就知道你是真研究过，不是只会跑 demo 的新手。

五、面试高频原题精准解答

尼恩一直在给vip陪跑， 在辅导大家进 字节、阿里、腾讯 的过程中， 碰到大量 真实面试题 。

原题1：Agent 的记忆系统分哪几层？每层怎么实现？

出现频率：95% 以上的 Agent 岗位必考题

记忆系统的本质是解决 “LLM 上下文窗口有限” 和 “长任务 / 跨会话需要历史信息” 这对核心矛盾。传统两层架构粒度太粗，现在行业已经收敛到四层设计：

现代工业级 Agent 采用四层分层记忆架构：

(1) 上下文窗口记忆：当前对话直接放入 LLM 提示词，速度最快但容量最小

(2) 工作记忆：存储当前任务的 任务状态+ 任务目标+ 任务中间成果物 （中间结果 、实体关系），解决长任务失忆问题。

(3) 会话记忆：当前完整会话历史，通过滚动摘要控制长度

(4) 长期记忆：跨会话持久化存储，通过向量检索按需召回

核心原则是分层存储、按需加载、动态治理。

层级	定位	存储介质	开源实现参考
上下文窗口记忆	热记忆，当前交互	LLM 原生上下文	Hermes 双文件置顶保护
工作记忆	任务认知黑板	任务状态+ 任务目标+ 任务中间成果物	DeerFlow sub-agent 上下文隔离
会话记忆	单会话完整历史	SQLite / 本地文件	OpenClaw 每日笔记 + memory_search
长期记忆	跨会话知识沉淀	向量库 / 知识图谱	三大项目均有实现

这套设计的核心优势是冷热分离：高频访问的热记忆放上下文，低频的冷记忆放文件、数据库或索引里；

同时有清晰的升降级机制，会话结束自动提炼精华写入长期记忆，检索命中再注入上下文。

Hermes、OpenClaw、DeerFlow 这类项目都体现了这套思想，但具体实现不能混着讲。

高频原题 TOP 2：短期记忆的滚动摘要和固定截断怎么选？

出现频率：85%

基础版答案

• 固定窗口截断：只保留最近 N 轮对话，实现简单、成本低，适合闲聊、简单问答这类信息快速衰减的场景；缺点是重要信息容易被截断
• 滚动摘要：历史快满时把前面内容压缩成摘要，能保住高价值信息，适合长任务、项目规划；缺点是多一次模型调用，摘要质量影响效果

但是， 这两个方案不是二选一，现在行业都是组合使用：

(1) 简单短对话场景用固定截断，零成本、够稳定

(2) 长任务场景用滑动窗口 + 置顶保护 + 滚动摘要：重要指令永久置顶不参与截断，普通对话历史超过阈值才触发摘要

(3) 摘要环节用便宜的小模型做，不要用主模型，成本降 90%

我们团队踩过的坑：纯滚动摘要最容易出问题的就是摘要质量，一旦摘要错了，相当于植入错误记忆，后面全错。所以我们现在的做法是：关键信息标记 “不参与摘要”，摘要结果做二次校验。

面试官连环追问 & 标准答案

追问：滚动摘要多了一次模型调用，成本怎么控制？

答：三个优化手段：

① 降低触发频率，超过 20 轮才摘一次；

② 用专门的小模型做摘要，成本是主模型的 1/10；

③ 同一段摘要做缓存，不用反复摘。

高频原题 TOP 3：长期记忆为什么不能全量存储？记忆治理怎么做？

出现频率：80%

基础版答案

全量存储会导致三个问题：重复记忆多、过时信息干扰、检索噪声大。

记忆治理主要做五件事：准入校验、去重合并、过期遗忘、升降级流转、安全可控。

进阶版答案（架构师视角）

这是区分 “做过 demo” 和 “做过生产” 的核心题。

首先说为什么不能全存：记忆系统存在熵增定律，只存不治，一定会从有序走向混乱。

比如，某 实际场景中，出个 线上真实故障：用户明明说要退款，Agent 还在发优惠券，就是三个月前的优惠券记忆没清理，检索权重太高盖过了新请求。

五大治理机制，按优先级排序：

(1) 记忆准入：写入前做重要性打分，低价值直接过滤，宁可少存也不乱存。我们加了准入后，写入量降了 70%，准确率反而升了

(2) 去重归一：语义去重、实体消歧，“张三”" 张总 " 识别为同一个人

(3) 主动遗忘：90 天时间衰减曲线，越老的记忆权重越低。OpenClaw 的 Dreaming / Memory Wiki 类整理能力、Amazon 的智能合并，都可以作为记忆整理思路参考

(4) 升降级机制：热记忆溢出到会话记忆，会话结束提炼精华到长期记忆，检索命中再升回上下文

(5) 用户可控：让用户能看、能改、能删记忆，这是合规底线

高频原题 TOP 4：长任务 Agent 如何解决 “跑久了失忆” 的问题？

出现频率：75%，长任务方向必考题

基础版答案

主要靠工作记忆层锚定任务目标，加上中间结果落地、上下文压缩和必要的状态恢复机制。

进阶版答案

这是 DeerFlow 这类长任务 Agent 框架要解决的核心痛点。

四个层面系统解决：

(1) 工作记忆层锚定目标：持续保存任务目标、关键约束、中间结果，不依赖纯上下文。每执行一步都和目标做校验，防止跑偏

(2) Sub-Agent 上下文隔离：把复杂任务拆成多个子任务，让每个子 Agent 只处理相关上下文，减少主上下文污染

(3) 分层记忆 + 中间结果落地：重要中间结果直接落到文件或存储，不放在上下文里，不会因为窗口满了就丢

(4) 定期目标复盘：每执行 N 步，强制让模型回顾一次原始目标，拉回正轨

高频原题 TOP 5：向量检索不准怎么办？

出现频率：65%

标准答案

纯向量检索的问题是语义漂移，现在行业标准解法是混合检索：

(1) 向量相似度：做语义匹配

(2) BM25 关键词：做精确匹配

(3) 实体标签：做结构化过滤

三个维度加权打分，OpenClaw 默认 memory-core 就是这个思路：关键词检索抓精确名词，向量检索抓语义相关，组合起来比只靠纯向量更稳。

另外还有两个优化手段：① 召回后做重排序；② 记忆写入前做质量治理，减少噪声。

高频原题 TOP 7：大模型上下文窗口越来越大（1M+ tokens），记忆系统还有存在的必要吗？

考点：考察对技术本质的理解，不盲目追热点

标准答案：

非常有必要，三个核心问题窗口再大也解决不了：

(1) 成本问题：上下文是 O (n²) 的 Token 开销，1M 窗口推理一次的成本是 8k 窗口的上百倍，线上根本跑不起

(2) 注意力问题：长上下文存在 “中间遗忘效应”，模型注意力集中在开头结尾，中间内容基本被忽略

(3) 跨会话问题：窗口再大也只能存当前会话，跨会话的长期记忆、用户偏好沉淀，还是要靠专门的记忆系统

窗口变大只是缓解了问题，没有解决本质问题，分层记忆依旧是工程最优解。

高频原题 TOP 8： 工作记忆和会话记忆的本质区别是什么？

考点：考察对四层架构核心边界的理解

标准答案：

三个维度完全不同：

(1) 内容不同：会话记忆是对话流水账，按时间顺序存原始对话；工作记忆是结构化任务状态，存任务目标、实体关系、中间结果，和对话顺序无关

(2) 目的不同：会话记忆是 “记住说了什么”；工作记忆是 “记住要做什么、做到哪了”

(3) 价值不同：没有会话记忆，只是连贯性差一点；没有工作记忆，Agent 根本做不了超过 10 轮的长任务，一定会跑偏

高频原题 TOP 9： 多用户场景下，记忆系统的隔离与共享如何设计？

考点：企业级多租户架构设计能力

标准答案：

采用三层隔离 + 两级共享的设计：

三层严格隔离：

(1) 用户级隔离：每个用户的记忆数据完全隔离，数据库层面按 user_id 分库分表

(2) 会话级隔离：同一个用户的不同会话记忆互相隔离，不会串扰

(3) 权限级隔离：敏感记忆设置访问权限，不是所有 Agent 都能读

两级合理共享：

(1) 公共知识库共享：通用领域知识、公司内部知识库，所有用户共享

(2) 组织级共享：同一个团队、同一个部门的工作记忆，可以在组织内授权共享

DeerFlow 2.0 就是这套设计，也是目前企业级多租户的标准方案。

高频原题 TOP 10： Multi-Agent 多智能体场景下，全局共享记忆怎么设计？

考点：多 Agent 协作架构能力

标准答案：

多 Agent 记忆采用全局共享 + 局部私有的双层架构：

(1) 全局共享记忆层：所有 Agent 都能读，存公共知识、任务全局目标、整体进度、已确认的共识。只能由 Orchestrator 调度 Agent 写入，普通 Agent 只读

(2) Agent 私有记忆层：每个 Agent 自己的工作记忆、中间结果、思考过程，其他 Agent 不可见

(3) A2A 协议同步：Agent 之间通过 A2A 协议同步必要信息，不直接读写对方记忆

核心原则：共享只读，私有隔离，同步走协议。避免多个 Agent 同时写记忆造成数据冲突。

[ 请参考尼恩团队 《 全球顶级 全栈 AI 架构视频 第十一章 ： 手写 工业级harness 基础设施架构实操 》](尼恩团队 AI全栈架构 ：0数学 一步登天 精通 深度学习 + 机器学习+ 大模型微调 + Harness 架构 +Agent架构)

高频原题 TOP 11：记忆系统的容灾备份与数据迁移方案怎么设计？

考点：生产级系统设计能力

标准答案：

企业级记忆系统的容灾方案分三层：

(1) 实时备份：记忆写入时双写主备库，RPO=0

(2) 定时快照：每天凌晨做全量快照，保留 7 天，支持回滚到任意时间点

(3) 异地容灾：跨机房同步，极端情况可以切站

数据迁移方案：

• 记忆数据导出成标准格式（JSON + 向量），可以在不同向量库、不同框架之间迁移
• 迁移时做完整性校验，避免迁移过程中丢数据

高频原题 TOP 12：如何设计记忆系统的监控指标体系？

考点：可观测性能力

标准答案：

四大类核心监控指标：

(1) 检索质量指标：召回率、准确率、Top-K 命中率

(2) 性能指标：检索耗时、写入耗时、摘要耗时

(3) 成本指标：记忆存储量、Token 消耗量、摘要调用次数

(4) 业务指标：记忆命中率、用户修正记忆的次数、记忆导致的故障数

其中用户修正记忆的次数是最核心的业务指标 ： 这个指标高，说明记忆系统质量差，用户一直在纠正 Agent 记错的内容。

高频原题 TOP 12： 线上出现 Agent"记忆混乱"，怎么排查与定位？

考点：线上故障排查能力

标准答案：

按这个排查路径一步步来：

(1) 先看检索结果：把当前问题的召回记忆打出来，看是不是召回了错误的、过时的、冲突的记忆。80% 的问题出在这一步

(2) 再看记忆治理：看是不是没做去重，同一个事实存了 N 个版本；是不是过时记忆没过期，旧信息干扰了新请求

(3) 再看注入顺序：看召回的记忆是不是放在了上下文中间，被 “中间遗忘效应” 给忽略了

(4) 最后看摘要质量：看滚动摘要是不是把关键信息总结错了，植入了错误记忆

定位到问题后对应解决：检索不准优化混合检索权重，记忆混乱加强治理，位置问题把重要记忆放开头结尾。

高频原题 TOP 13： 记忆检索准确率低，怎么系统性优化？

考点：准确率 优化能力

标准答案：

从四个层面系统性优化，按投入产出比排序：

(1) 治理层面（ROI 最高）：先做记忆清洗，删掉无效、重复、过时的记忆。源数据干净了，准确率自然提升。这一步能解决 50% 的问题

(2) 检索层面：从纯向量改成混合检索（向量 + BM25 + 实体标签），多维度加权打分。这一步再提升 30%

(3) 召回后层面：增加重排序环节，用小模型对召回结果二次打分排序

(4) Embedding 层面：换更好的 Embedding 模型，针对领域做微调

按这个路径优化，检索准确率 可以 从 62% 提升到 91%。

高频原题 TOP 14： 记忆系统的成本太高，怎么优化？

考点：成本优化意识

标准答案：

四个优化手段，实测能降 60% 以上成本：

(1) 治理降本：严格的记忆准入，不要什么都存。存储量降 70%，检索成本自然降

(2) 摘要降本：滚动摘要用最便宜的小模型做，不要用主模型。摘要成本能降 90%

(3) 缓存降本：热点记忆、高频检索结果做缓存。重复请求不用反复查向量库、反复算 Embedding

(4) 分层降本：冷记忆存在便宜的存储介质，热记忆放高性能存储。存储成本再降一半

不要上来就堆硬件，先从架构和治理层面优化，成本降下来的同时，质量还能提升。

高频原题 TOP 15： 如何防止记忆系统被提示注入攻击？

考点：安全意识

标准答案：

三层防护体系：

(1) 写入前过滤：所有要写入记忆的内容，先过一遍恶意指令检测，发现注入直接拦截

(2) 存储隔离：用户输入的记忆和系统记忆分开存储，注入的内容不会影响系统指令

(3) 读取前校验：从记忆库读出来注入上下文之前，再做一次二次校验

参考 AgentSys 的层级化内存管理思想，主 Agent 和工作 Agent 记忆完全隔离，从物理层面阻断污染扩散。

老架构师总结

这些新考点，本质考察的就一件事：你是不是真的在生产环境用过记忆系统，而不是只跑过 demo。

面试的时候，遇到这些题别慌：

• 概念题讲清楚本质，别盲目追热点
• 架构题讲清楚设计原则和取舍，别只说方案不说为什么这么设计
• 实战题讲排查路径和真实数据，越具体越好

能答到这个深度，大厂 offer 基本就稳了。

七、总结：记忆架构设计的三大黄金原则

整个 Agent 记忆系统讲完了，最后我用三句话总结整个文档的核心，也是我们团队踩了无数坑总结出来的三大黄金原则。不管是面试答题，还是实际做项目，守住这三条，基本就不会出大问题。

黄金原则一：分层原则 ： 冷热分层，按需加载

永远不要把所有记忆都塞到上下文窗口里。

• 热记忆（第0层 上下文、第一层 工作记忆 ）放缓存，追求速度；

• 温记忆（第二层 会话历史）放本地数据库，追求连贯；

• 冷记忆（第三层 长期沉淀）放向量库，追求容量。

记忆在四层之间自动升降级，该升的升，该降的降。

这是所有优秀记忆架构的共性 ：

• Hermes 的硬上限、
• OpenClaw 的工作区记忆文件 + 检索索引、
• DeerFlow 的文件产物和上下文压缩，本质都是在践行这条原则。

反例就是那些 “把所有历史都塞上下文” 的朴素实现，窗口再大也救不了成本爆炸和注意力稀释。

黄金原则二：治理原则 ： 对抗熵增，动态治理

记忆系统不是 “存进去就完事” 的仓库，它是一个动态的、需要持续治理的数据资产。

只存不治，必然熵增。三个月后一定是记忆混乱、检索噪声、决策错误。

五大治理机制一个都不能少：准入要严、去重要勤、过期要忘、升降要顺、用户要可控。宁可少存，也别乱存。

这是 90% 团队踩过的最大的坑 ： 上线前只做存取，不做治理，半年后只能全量清库重来。

黄金原则三：务实原则 ： 场景驱动，拒绝炫技

没有最好的架构，只有最适合场景的架构。

• 个人日常用，选 Hermes，有界核心记忆 + 会话搜索，简单就是美
• 个人助理长期运行、开发者写代码搞创作，选 OpenClaw，本地工作区 + Markdown 记忆 + 混合检索，透明就是生产力
• 多步骤长任务和文件产物型 Agent，选 DeerFlow，sub-agent + sandbox + 上下文压缩更合适

别上来就上最复杂的长任务框架，个人轻量使用 DeerFlow 可能是过度设计；也别拿个人记忆工具去硬扛复杂长任务，那是对业务不负责。

面试的时候最加分的一句话就是：“技术没有高低，只有适合不适合场景”。这句话一出口，面试官就知道你是懂工程的，不是只会追新技术的新手。