LyncoreLyncore
Lyncore

五层记忆 vs 查询式召回：
Agent 到底该不该有长期记忆 ​

一句话结论：该有，但不能是一个大筐。 给 Agent 加记忆最常见的失败，是把所有聊天记录塞进一个向量库、下次检索出来拼进提示词——前两周很香，第三周就开始"串台"。DeepSeek 的 dsh-superagent 走的是"查询式召回"路线（没有分层长期记忆）；Lyncore 走的是"显式分层"路线，做了五层记忆 L1–L5。两条路线没有绝对优劣，差别在你要不要为不同生命周期的信息切边界。

查询式召回 vs 分层记忆：L1–L5 五层与源码依据

一个大筐为什么迟早串台 ​

很多人对"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 需要，是因为它的工作边界就是"用户的一生"。

本系列 ​

本文以 DeepSeek 开源的 dsh-superagent（MIT）为对照例子。Lyncore 的五层记忆设计见 《五层记忆》 与官网 lyncore.top。