为什么 TencentDB Agent Memory、OpenViking、PageIndex 的核心思想越来越像？

为什么 TencentDB Agent Memory、OpenViking、PageIndex 的核心思想越来越像最近深入看 TencentDB Agent Memory、字节火山引擎的 OpenViking以及 PageIndex会发现一个很有意思的现象它们虽然名字不同、定位不同、实现方式不同但底层思想正在快速收敛。它们都在回答同一个问题Agent 不可能把所有历史、文档、工具结果、用户偏好都塞进上下文窗口里那它到底应该怎么“记住”、怎么“找回”、怎么“按需加载”答案越来越清晰不能只靠向量搜索也不能只靠摘要压缩而是要把记忆组织成“分层结构 可导航索引 按需召回”的系统。一、传统 Agent 记忆为什么不够用了早期 Agent 记忆系统很简单基本就是三板斧第一把历史对话做摘要。第二把摘要塞回下一轮上下文。第三把文档切 chunk做 embedding存在向量数据库里。这个方案在短任务里能用但一旦进入真实的长周期 Agent 场景问题会非常明显。比如用户昨天反复告诉 Agent“这个项目用 TypeScript提交信息要带 Signed-off-byPR 不能直接 squash。”今天新开一个会话Agent 又忘了。再比如 Agent 读了十几个文件、跑了很多命令、拿到一堆报错日志。如果这些东西都塞进上下文Token 成本爆炸如果简单摘要又容易丢掉关键细节。腾讯在 TencentDB Agent Memory 的介绍里也直接点出了这几个痛点跨会话断裂、事实与偏好混淆、上下文膨胀。它的方案是把不同粒度的信息放在不同“楼层”里L0 原始对话、L1 原子记忆、L2 场景归纳、L3 用户画像。(腾讯新闻)所以 Agent 记忆系统的核心矛盾是既要不丢原文又不能把原文全塞给模型既要能快速召回又不能只靠语义相似度瞎匹配。这就是 TencentDB、OpenViking、PageIndex 思想相似的根本原因。二、它们相似在哪里本质都是“反扁平化”传统 RAG 最大的问题是把知识拍扁了。一篇长文档、一段长期任务、一组工具调用记录本来都有天然结构文档有目录、章节、段落、表格、附录。任务有目标、阶段、约束、决策、错误、结论。用户记忆有临时信息、稳定偏好、项目习惯、长期画像。代码仓库有目录、模块、依赖、调用链、历史修改。但传统向量 RAG 会把它们切成一堆 chunk然后扔进向量库。这样做的问题是检索看到的是碎片不是结构。PageIndex 对这个问题的批评最直接传统向量 RAG 依赖语义相似度但“相似”不等于“相关”固定 chunk 会破坏文档语义完整性普通向量检索也很难处理多轮上下文和文档内部引用。(PageIndex)PageIndex 的做法是不把文档切成孤立 chunk而是先生成类似目录的树状索引让 LLM 像人读文档一样先看目录再选择章节再进入具体内容。它官方称之为基于层级树索引的 reasoning-based RAG。(GitHub)OpenViking 的思路也很像。它不是把 memory、resource、skill 分散放在不同地方而是用类似文件系统的范式统一管理 Agent 需要的上下文。它强调 L0/L1/L2 的分层上下文加载、目录递归检索、语义搜索结合目录定位、可视化检索轨迹。(GitHub)TencentDB Agent Memory 也是类似逻辑。它把原始对话、原子记忆、任务场景、用户画像分层管理并通过“提取—聚合—蒸馏”的管道连接起来。(腾讯新闻)所以它们共同反对的东西是不要把所有记忆都压成一个摘要。不要把所有知识都切成一堆向量 chunk。不要让 Agent 在一堆平面碎片里盲搜。它们共同追求的是结构化保存分层管理按需召回可溯源返回。三、TencentDB Agent Memory偏“长期记忆系统”TencentDB Agent Memory 更像是一个面向 Agent 的长期记忆引擎。它的核心是四层记忆金字塔层级作用L0 原始对话层全量保留每一轮交互L1 原子记忆层提取事实、偏好、约束、阶段结论L2 场景归纳层按任务、场景自动聚合L3 用户画像层蒸馏长期稳定偏好和画像这个设计非常像人类记忆系统。我们不会把每天看到的所有信息都当成长期记忆。大部分信息只是原始经历其中一部分会被抽成事实再有一部分会按场景归类最后极少数稳定信息才会变成“我知道这个人长期是什么习惯”。TencentDB Agent Memory 还有一个关键点是它不只是省 Token而是强调“原文不丢、结构可查”。腾讯介绍中提到它通过上下文卸载和 Mermaid 无限画布把原始工具结果搬到外部文件把任务结构折叠成可导航画布上下文里只保留摘要和索引。(腾讯新闻)这很重要。因为 Agent 做长任务时很多信息当下不需要但未来可能突然变得关键。比如一次失败的命令、某个文件的旧版本、一次用户临时补充的约束。直接丢掉会出问题全部塞回上下文又太贵。所以 TencentDB 的核心不是“记住所有东西”而是把所有东西留在外部把重要东西提炼成记忆把可导航索引放进上下文。四、OpenViking偏“上下文数据库”OpenViking 的定位更像是Context Database也就是 Agent 的上下文数据库。它认为 Agent 的上下文不只有 memory还有 resources 和 skills。传统系统里记忆可能在数据库里资源可能在向量库里技能可能写在代码或 prompt 里整体非常碎片化。OpenViking 的解决方式是用“文件系统范式”统一组织这些内容。(GitHub)它的几个关键词非常有代表性Filesystem Management Paradigm像管理文件一样管理上下文。Tiered Context LoadingL0/L1/L2 分层加载减少 Token。Directory Recursive Retrieval先定位目录再结合语义搜索递归检索。Visualized Retrieval Trajectory检索过程可观察方便 debug。Automatic Session Management自动压缩会话、资源引用、工具调用并提取长期记忆。(GitHub)这其实已经不是传统“向量数据库”的思路了而是在做一个面向 Agent 的上下文操作系统。传统向量库解决的是“给我一个 query我返回相似文本。”OpenViking 想解决的是“Agent 当前执行这个任务它应该加载哪部分上下文这部分上下文来自哪个目录为什么被召回未来如何沉淀为长期记忆”这就是为什么它和 PageIndex 很像。PageIndex 是给文档建目录树。OpenViking 是给 Agent 上下文建文件系统。TencentDB 是给 Agent 记忆建分层金字塔。它们都在做一件事把上下文从一堆碎片重新组织成结构。五、PageIndex偏“结构化检索范式”PageIndex 表面上不是记忆系统而是一个 RAG 框架。但它对 Agent 记忆系统的启发非常大。PageIndex 的核心判断是检索不应该只是找“语义相似”的文本而应该推理“答案最可能在哪里”。所以它提出了一个很像人类阅读的流程先读目录。判断哪个章节可能相关。进入章节提取信息。如果不够再回到目录继续找。直到信息足够再回答问题。(PageIndex)这和传统向量搜索完全不同。传统向量搜索像是“这句话和你的问题在向量空间里很近所以我返回它。”PageIndex 更像是“你的问题问的是递延资产总额这通常不在正文描述里可能在附录表格里我应该沿着目录去找附录。”它的官方介绍里明确说PageIndex 会生成文档的 Table-of-Contents 树结构然后通过树搜索做 reasoning-based retrieval。(GitHub)这个思想放到 Agent 记忆系统里就是Agent 不应该只问“哪段记忆和当前 query 最相似”而应该问“当前任务处在哪个阶段需要的是用户偏好、项目约束、历史错误、工具结果还是长期画像”这就是 PageIndex 对记忆系统最大的启发检索不是匹配检索是导航。六、为什么它们都会走向“分层 索引 召回”因为这是由 Agent 的工作方式决定的不是某一家公司的偶然选择。1. 上下文窗口再大也不够用模型上下文窗口变大并不代表可以无限塞信息。PageIndex 的文章也提到长上下文虽然扩大了可输入内容但随着上下文变长模型表现可能下降。(PageIndex)Agent 的问题更严重。普通聊天只是文字历史Agent 还会产生工具调用、文件读取、搜索结果、错误日志、代码 diff、网页内容、用户反馈。如果每一步都全量保留上下文会指数级膨胀。所以必须外部化原文放外部。摘要放上层。索引放上下文。需要时再回源读取。这就是分层记忆的必然性。2. 向量搜索解决不了“任务结构”向量搜索很适合找语义相似内容但它不擅长理解任务结构。比如用户问“上次那个 PR 为什么没过”向量搜索可能会找出很多包含 “PR”“failed”“test” 的片段但真正相关的信息可能是某次 CI 日志。某个 reviewer 的评论。某条项目规范。某次用户让 Agent 修改过的提交策略。某个被忽略的 DCO 要求。这些信息不一定语义相似但在任务链路上高度相关。所以 Agent 记忆不能只靠 embedding它还需要时间线。任务阶段。文件路径。因果关系。目录结构。引用关系。用户偏好层级。工具调用轨迹。这就是 OpenViking 强调目录递归检索和可视化检索轨迹的原因也是 TencentDB 要做 L0 到 L3 分层的原因。(GitHub)3. 记忆有不同“半衰期”所有信息的价值不是一样的。“帮我查一下今天东京天气”这种信息可能只值一天。“我用 Windows Codex Clash”可能值几个月。“我喜欢用中文交流”可能是长期偏好。“这个项目必须用 TypeScript”只在当前项目内有效。“这个 bug 是因为某个依赖版本冲突”可能只在某个任务阶段有效。如果系统把它们都当成同一种 memory就会出问题。TencentDB 的 L0/L1/L2/L3 本质上就是在区分信息生命周期原始记录、原子事实、场景记忆、长期画像。(腾讯新闻)这也是大厂都在做记忆系统的核心原因之一谁能更好地区分“短期上下文”和“长期用户资产”谁就能让 Agent 越用越懂用户。4. 可解释性变得越来越重要传统向量检索经常是黑盒。Agent 召回了一段记忆但你不知道它为什么召回。Agent 没召回某条关键信息你也不知道它为什么漏掉。系统回答错了开发者很难定位是生成错、检索错、索引错还是记忆抽取错。OpenViking 明确把“可视化检索轨迹”作为能力之一原因就在这里。它希望开发者能看到目录检索路径从而优化上下文组织和召回逻辑。(GitHub)PageIndex 也强调 traceability因为它通过目录树和 section/page reference 来追踪信息来源而不是只返回一个相似 chunk。(GitHub)未来 Agent 进入生产环境后记忆系统必须能回答三个问题这条记忆从哪里来为什么这次被召回它是否还应该继续有效没有可溯源Agent 记忆就很容易变成“污染源”。七、为什么大厂都在抢着开源记忆系统这背后不只是技术炫技而是平台战争。1. 记忆是 Agent 的基础设施入口模型本身越来越强但 Agent 真正落地时最难的是上下文工程。Agent 要长期帮你写代码、管理项目、分析文档、处理工作流它必须知道你是谁。你在做什么项目。你之前踩过什么坑。你有哪些固定偏好。当前任务推进到哪里。哪些文件、工具、资源和技能可用。这些东西不属于单次 prompt而属于“上下文资产”。谁掌握这层上下文资产谁就掌握 Agent 应用的入口。2. 记忆系统会形成用户粘性一个没有记忆的 Agent每次都是新员工。一个有记忆的 Agent用得越久越像老同事。这会产生很强的迁移成本。因为你在里面沉淀的不只是聊天记录而是项目经验。个人偏好。代码规范。业务知识。工作流习惯。历史决策。错误教训。这些东西一旦沉淀到某个记忆系统里用户就不太愿意迁移。所以大厂开源记忆系统本质上是在争夺下一代 Agent 的“长期上下文层”。3. 开源是为了抢标准现在 Agent 记忆还没有统一标准。记忆怎么存怎么分层怎么召回怎么过期怎么去重怎么防污染怎么跨 Agent 共享怎么和 MCP、IDE、浏览器、数据库结合这些都还在早期。腾讯开源 TencentDB Agent Memory字节火山引擎开源 OpenVikingPageIndex 开源自己的 reasoning-based RAG 框架本质上都是在争夺开发者心智和接口标准。腾讯也在文章里说记忆这个产品远没有标准答案希望和开发者一起共建。(腾讯新闻)谁的接口被更多 Agent 框架接入谁就有机会成为事实标准。4. 数据库厂商必须重新定义自己过去数据库存的是业务数据。但 Agent 时代数据库还要存上下文。记忆。经验。任务轨迹。工具调用。用户画像。资源索引。技能目录。这就是为什么 TencentDB 这样的数据库团队会亲自下场做 Agent Memory。因为未来的数据库不只是存结构化数据也要成为 Agent 的“外部大脑”。OpenViking 直接把自己定义为 Context Database这个命名就很有信号意义它不是普通向量库而是面向 Agent 上下文的新型数据库。(GitHub)八、最终趋势向量搜索不会消失但会退居一层很多人看到 PageIndex 会以为“是不是向量数据库要被淘汰了”我认为不是。更准确的趋势是向量搜索会从核心架构变成分层记忆系统中的一个检索算子。未来的 Agent 记忆系统大概率是混合式的底层保留原始记录。中层抽取结构化事实。上层形成任务/用户/项目画像。旁路保留向量索引。主路径使用目录、树、图、时间线、标签、作用域进行导航。真正需要模糊匹配时再调用向量搜索。也就是说向量搜索不是没用而是不应该独自承担“记忆系统”的全部责任。它适合回答“有没有语义相似的历史内容”但完整的 Agent 记忆系统还要回答这条信息属于哪个项目是否已经过期是否是用户稳定偏好是否只是一次性任务信息是否和当前任务阶段有关是否有原文证据是否可以安全注入上下文这些问题都不是单纯向量相似度能解决的。九、总结TencentDB Agent Memory、OpenViking、PageIndex 之所以核心思想相似不是因为互相抄而是因为它们都被同一个问题逼到了同一个方向Agent 需要长期工作但模型上下文是有限的Agent 需要记住经验但不能把所有历史都塞回 promptAgent 需要召回信息但不能只靠语义相似度。所以它们最终都走向了分层记忆。结构化索引。按需加载。可溯源召回。从“相似搜索”升级为“上下文导航”。TencentDB 更像长期记忆引擎。OpenViking 更像上下文数据库。PageIndex 更像结构化检索范式。但它们背后的共同判断是一样的未来 Agent 的竞争不只是模型能力的竞争而是上下文管理能力的竞争。谁能让 Agent 更好地记住、组织、检索和复用经验谁就掌握了下一代 AI 应用的核心基础设施。