AI搜索 = Agent Memory:记忆实践有感
「Always push your boundary further」
碎碎念：上周末翻到肖涵(Jina AI 创始人)4 月的演讲,主题是『2026 年做搜索就是做 Agent Memory』，他是从「搜索人」的视角往下看记忆，落点在表征和三大流派；我想从「做Agent的产品」视角出发，挑了三个我自己最有体感的地方,结合最近在业务上实践的情况，聊一聊我的体感。
-
01 肖涵分享内容里）让我感同身受的 911 case
记忆系统的失败，80% 发生在它运行之前。数据库（信息来源）问题、向量模型不够好、Reranker 不够细，这些都是影响因素；但实操绝大多数翻车，都发生在 Query 这第一个字写错的瞬间
肖涵在演讲里讲了一个真实的 debug 故事，我先复述一下。
他对 Agent 说:「把我之前做的 911 图表发给我」911 是保时捷一款跑车的代号。但 Agent 反手回了一句:「您说的是恐怖袭击,还是别的?」
第一反应：是不是模型降智了?查了一下,跑的是当时最强的模型,不是模型问题。那继续往下查,问 Agent 你刚才用了什么 Query:
第一次:`911 chart graph visualization`(直接把中文翻译成英文)
第二次:`September 11th chart visualization Twin Towers attack`(直接搜成恐袭了)
后来肖涵换了一个说法——「把 992.2 的图表发给我」。992.2 是 911 这一代车型的内部代号；一搜就命中，3 月 29 号做的。
肖涵的总结道：整条记忆链路再完美,只要 Query 构造错了,整个检索就是废的
同一个对象,可能同时拥有它的官方型号、口语别名、子型号代号、还有用户基于使用场景给它起的外号。这四个名字指向同一个东西,但任何一个都不能简单地翻译成另一个。
-
用户在第一轮对话里用了口语别名讨论了对象 X，记忆系统按口语别名建了索引;
-
用户在第二天的新会话里用了官方型号问同一个对象的后续问题;
-
Agent 用「官方型号」去检索记忆 → 一无所获 → 装作什么都不知道
用户的「指称习惯」会随场景流动,但记忆系统不会自己流动
而 911 这种“翻译翻车”,只是 Query 出错的一种形态。。。
演讲里，肖涵把市面上做记忆的方案分成三大流派,分类标准是「Source of Truth 在哪」—> i.e.「真相到底存在哪里」:
|
|
|
|
|
|
|
|
|
|
|
龙虾(Claude Code 的记忆机制)、MemSearch
|
|
|
|
|
聊天记录/信息 --> 大模型抽取事实 --> 存入向量/图/时序--> 检索时用 Query 召回 --> 注入上下文
每一派都在 highlight 自己存的那一段——数据库派 highlight 怎么存得快、文件派 highlight 怎么存得透明、模型派 highlight 自己根本不用存；
真正决定召回质量的,不是「存」那一步,而是「用 Query 召回」那一步
我的判断：记忆这件事，必须把「写入策略、Query 改写、检索召回」三件事当整体来设计
假设你的写入策略很work，记忆里同时存了「保时捷 911」「992.2」「德国大牛」三个名字，但 Query 改写环节直接把「911」翻译成`September 11th attack` —> 写得再齐全也没用，钥匙跟锁不在一个屋里
Query 改写做得再fancy，如果写入时只记了一个「保时捷 911」,那用户用「992.2」来问的时候照样翻车 —> 因为锁里压根没有这把钥匙能开的孔
它们共享一个隐藏前提:「同一个对象在两端用同一种表征」
我把踩过的坑总结成四类：每一类都对应着 Query 改写中的一种典型错误
这就是 911 case 的本质。当用户的 Query 含有专有名词、内部代号、缩写时,模型会用「最常见的语义」去解读它,而不是「这个用户最可能说的语义」
`911`在大语言模型的预训练分布里,绝大概率指向恐袭事件,而不是保时捷；
maybe这是个统计先验问题——模型不知道你是谁、不知道你最近在聊什么，所以它会按全互联网的平均分布来猜；
解法是:在 Query 改写之前,先做一次「场景锁定」；
模型会先判断当前对话发生在哪个垂直语境,再根据这个语境去理解专有名词。同样是「911」,在汽车场景锁定的前提下绝对不会跑出恐袭这种解释
但场景锁定也不是万能的,因为下面这个坑会让场景锁定本身翻车 →
多轮对话里，上一轮的对象会以一种你想不到的方式渗透到下一轮的 Query 里
举个抽象的例子；假设用户连续聊了三轮关于对象 A 的事，第四轮突然说「换一个吧」。这时候 Agent 的 Query 改写模块会怎么做?
最容易出 bug 的 case 是：把「换一个」改写成「另一个 A 的替代品」——因为前三轮的上下文里都是 A，模型自然会以为「换一个」是在 A 的池子里换。
但用户其实可能想换的是整个品类。他不是想要 A 的替代品,他是想看完全不同的另一类东西。
这种「上下文污染」的根源在于：Query 改写需要参考上下文，但参考多少、参考哪些字段、什么时候应该清空上下文，每一个判断都是独立的命题
处理的方案可能是：拆成两步，先识别用户的「意图是否切换」(这是一个独立的分类问题)，如果切换了就重置上下文池；如果没切换才把上下文带进 Query 改写
在多语言场景里，信息来源的内容是 A 语言,用户的 Query 是 B 语言。一个看起来很合理的做法是：先把 Query 翻译到 A 语言,再去检索
上面讲的`911 chart graph visualization`就是这种「早翻译」导致的翻车—>把中文 Query 翻成英文之后，专有名词的语义已经丢了一半
这里有个反直觉的结论：翻译应该尽量晚发生,而不是越早越好
WHY？因为翻译这一步会丢失上下文（Won’t come back）
更好的方式可能是：先用原语言做完字段提取(用户在问什么对象、什么时间、什么属性)，把这些字段独立保存下来。最后召回阶段再决定要不要翻译
learning是，信息处理的顺序,直接决定了你能召回什么；
用户经常用「那个」「上次那个」「便宜的那款」来指代记忆里的对象。Query 改写模块如果直接把「上次那个」翻译成具体名词，问题不大。
但我们看到用户说「类似上次那种感觉的另一个」呢?（当然这是极少数）
「类似的另一个」是一个非常难处理的指代——你既需要找到「上次那个」(精确召回),又需要在它之上做相似度推荐(模糊扩展)。这两件事用同一个 Query 做不了。
可能的处理是：把这种 Query 拆成「锚点提取 + 扩展策略」两个子任务；
锚点用来定位上次那个对象，扩展策略用来描述「类似」的具体维度(是价格类似?功能类似?还是使用场景类似?)；
Query 改写的本质,是把「用户说的话」翻译成「记忆系统能听懂的话」
演讲里引用了 Karpathy 的一句话——「现在的 Agent 系统都有一个最致命的问题，就是它不会选择性遗忘。」我想one step further一下；
-
用户刚开始用一个 Agent 时，因为期待很低，体验反而最好;（甚至还有朋友直接下单）
-
用了一周，期待开始变高（「它应该懂我了吧?」），但 Agent 还是那个 Agent;
-
两周之后，这种gap演变成了愤怒——「为什么越用越笨?」
用户的期待是线性增长的，但 Agent 的记忆质量是非线性衰减的
用得越久，记忆里的噪声、过期信息、被推翻的偏好越多，召回时干扰越严重
假设记忆系统是只增不减的，那这条「我喜欢 X」就会永远地作为一个高优先级偏好被召回；每次用户问相关问题，Agent 都会先把 X 推过来（显然这并不一定符合预期）
缺点:粗暴。「我不爱吃香菜」这种偏好不会因为过了 30 天就改变
-
当新偏好和旧偏好语义冲突时,主动提示用户确认是否覆盖
So，「什么时候该忘」是个很tricky的事情——它本质上不是技术问题，是产品和模型的耦合问题；
在演讲里，提到了一个反方向的可能性—模型派会不会终结整个记忆系统?
千问3.5的 MoE 已经能扩展到1M token上下文，在 24G 显存上能跑；EverMind AI 把上下文推到了 100M token，并且做了 MSA（Memory Sparse Attention）来保证超长上下文的召回质量
如果哪天模型本身就能存下我所有的对话历史、所有的工作文件、所有的偏好——那会不会kill the game?
不是因为上下文不够长,而是因为长上下文有一个隐藏的成本曲线；
上下文越长，每次推理的成本和延迟都在增长。1M token 的推理成本，比 32K token 高了至少一个数量级。在实操中，没有产品愿意为每次对话都付这个成本（RT当然也是）
记忆系统的本质价值不是「存得下」，而是「按需召回」，i.e. 只把这次问题相关的几千 token 注入进去，而不是把所有 100M token 都塞进上下文—> 这个价值不会因为模型变长而消失
模型负责「语义理解和短期工作记忆」,外部记忆系统负责「长期事实存储和精准召回」
这跟人脑的海马体 + 新皮层的分工高度对应；人脑也没有把所有记忆都塞进皮层，而是在海马体做编码、在皮层做长期存储
这个中间层就是：Query 改写、写入策略、冲突检测、选择性遗忘
胶水不性感,没人想做胶水，但胶水决定了两端能不能配合得起来
(BTW：个人认为记忆的中间层，是产品差异化的护城河；
模型大家都能买到，数据库大家都能装，但 Query 改写的工程经验、遗忘策略的调参 know-how，以及在这个过程中产品注入的 taste 是很难被抄袭的)
回到肖涵演讲的核心推论：「2026 年做搜索就是做 Agent Memory」
2026 年做 Agent，本质上是做「用户和 Agent 之间的关系」。而关系靠的不是「记得多少事」，而是「在什么时候记起什么、在什么时候选择忘记」。
肖涵讲的是搜索人的视角，往下看到 Embedding、Reranker、Reader 这些底座模型；我从产品的视角，往上看到 Query 改写、写入策略、选择性遗忘这些中间层
夜雨聆风
