📌 原文由 Lyncore 团队撰写并发布于官网：https://lyncore.top/tech/agent-memory-five-layers/
本文为 Lyncore 团队授权转载，仅作分发用途。

一个真实事故：你的 AI 助手在跟 B 客户聊天时，突然冒出了 A 客户的报价和项目细节。追根究底，是它把所有对话塞进了一个向量库，检索时串了。

这不是模型的问题，是记忆没分层。本文讲五层记忆怎么把「该记的」和「该忘的」切开。

一个大筐为什么迟早串台

很多人对"AI 记忆"的直觉是：把对话历史向量化，存起来，下次相似问题检索出来拼回提示词。问题立刻来了：

• 一周的临时草稿和用户的长期偏好，被放进同一个检索空间，检索时必然搅在一起；
• 哪段话是临时的、哪段是永久的、哪段只属于某个项目——全混了；
• 于是 Agent 开始把上一家客户的事，说给下一家听。

根因：不同信息的生命周期和可见范围根本不一样。把临时上下文和永久偏好放一个筐，检索必然串台。记忆要分层，是因为"该忘的"和"该记的"根本不是一类东西。

dsh-superagent：查询式召回，没有分层长期记忆

dsh-superagent 的"记忆"不是分层长期记忆，而是更克制的查询式召回：

• 它的领域状态（Trigger、Thread、Ticket、Assignment、Input）落在一个 SQLite（orchestrator.sqlite）里，需要上下文时去查；
• 会话上下文窗口是受限的——文档里 Thread 窗口只取首 5 条 + 前后各 5 条，而不是无限铺开；
• 它刻意不把"人"做成实体、不维护跨 Source 的身份映射，所谓"某人在多个 Source 的账号"只是 prompt 文本。

这对一个"单仓库编码代理"是够的：它的上下文边界天然清晰（一个 Ticket 一个目录、一个 Session），不需要一套面向终端用户的长期人格记忆。

Lyncore：把记忆显式切成五层

Lyncore 面对的是通用桌面 Agent——它要长期服务于同一个人/团队，记住偏好、历史、行为模式，还不能串台。所以它把记忆显式分层（常量见 memory.go，长任务层 LayerLongTask MemoryLayer = "L5"）：

层	作用域	生命周期	典型内容
L1 上下文	当前会话	短	这轮对话在聊什么
L2 偏好	用户级	中长	喜欢简洁还是详细、用什么语言
L3 历史	用户级	长	过去做过的事、检索走向量 RAG
L4 行为模式	用户级	长	反复出现的做事方式
L5 长任务	任务级	任务周期	跨天/跨周长任务的结论（薄层，只写任务名+终态+摘要，不向量化）

几个刻意的设计点：

• 向量检索不是一层记忆，是 L3 历史层的机制。 它不是"记忆层"本身，只是历史层存取的一种手段。把"向量库"当成独立记忆层，是很多方案的误判。
• L5 是薄层、已落地。 长任务层只记任务名、终态、摘要（≤500 字符），不入向量、不膨胀。代码里常量 LayerLongTask = "L5" 已随设计蓝图任务包落地。它解决的是"一个跨好几天的任务，Agent 下次回来还认得自己干到哪了"，而不是塞更多上下文。
• 分层是为了切边界。 上下文只活一轮、偏好跟人走、历史可检索、行为模式跨会话稳定、长任务结论只绑定任务——每层只管自己的生命周期和可见范围。

更细的拆解见 《五层记忆：分身记得住，又不把 A 客户的事说给 B》。

两条路线怎么选

• **查询式召回（dsh 路线）**适合边界天然清晰的场景：单仓库、单任务、上下文随 Ticket/Session 隔离。轻、好维护，不引入"长期人格"的复杂度。
• **显式分层（Lyncore 路线）**适合长期服务同一用户的通用 Agent：你必须为"该忘的"和"该记的"切边界，否则串台只是时间问题。代价是要维护多层存储与跨层隔离。

没有"更先进"，只有"更适配"。dsh 不需要五层记忆，是因为它的工作边界由 Ticket 和目录替它划好了；Lyncore 需要，是因为它的工作边界就是"用户的一生"。

---

本文由 Lyncore 撰写，源自官网：https://lyncore.top/tech/agent-memory-five-layers/