作者 | AICon 全球人工智能开发与应用大会

策划 | 李忠良

编辑 | 宇琪

你是否也遇到过这种尴尬：在 ChatGPT 里刚定好的方案，换到 Cursor 写代码时，一切又要重头说起。Agent 今年最大的坎儿，不是智商，而是“记性”。为什么“长文本”没能彻底解决记忆问题？当向量数据库撞上图数据库，谁才是真正的解药？开发者们又该如何填补技术与人类感受之间的鸿沟？

近日，InfoQ《极客有约》X AICon 直播栏目特别邀请 RBC senior application support analyst 马可薇担任主持人，和 EverMindCEO 邓亚峰、MemVerge 中国区 CTO 赵玥、OPPO 高级算法工程师 王闯闯一起，在 AICon 全球人工智能开发与应用大会 2026 上海站即将召开之际，共同探讨 Agent 的“记忆断片”问题如何破局。

部分精彩观点如下：

• 在 AI 时代，用户长期积累下来的 Memory，未来应该是一个稳定的数据基础层，而不是某个平台的附属品。

• 写入不是简单归档，读取也不是简单 Search。这两个阶段，都需要 Agent 和 Memory 系统协同完成。最终，再以 Context 的形式交给大模型。

• 向量负责“把相关内容召回”，图负责“把这些内容组织起来”。最终目的，是让 Agent 拿到的不是一堆零散聊天片段，而是一个真正有组织、能支撑当前任务的上下文。

• 端云协同的划分，本质上就是在效果、隐私、时延和成本四个维度之间做系统性平衡。

• 未来真正能落地的记忆系统，性价比是非常关键的，也就是计算成本和 performance 之间的 trade-off。用户并不会只看 benchmark，他更在意实际体验。

在 6 月 26-27 日将于上海举办的 AICon 全球人工智能开发与应用大会 2026 上海站 上，我们特别设置了【 Agent 数据、记忆与运行时基础设施】 专题。该专题将聚焦支撑 Agent 长期运行的状态、记忆与基础设施底座，涵盖 RAG 与长期记忆、上下文工程等方向，进行全面探讨。

查看大会日程解锁更多精彩内容：

https://aicon.infoq.cn/2026/shanghai/schedule

以下内容基于直播速记整理，经 InfoQ 删减。

棘手的 Agent“记忆断片”

马可薇：Agent 今年最大的坎儿不是模型智商不够，而是记忆断片。我们先请三位分别从操作系统层、独立中间件层、终端应用层来聊聊这个局，亮出各自的核心挑战。在大家所深耕的那个层面，Agent Memory 今天面临的最核心、最棘手的一个挑战是什么？

邓亚峰：这里面有两个核心挑战。第一个是，作为一个 Infra 层，不同 Agent 的诉求差异非常大，你怎么去适配不同 Agent 的需求。另外一个延伸出来的问题是：用户用了你的 Memory 之后，能不能明确感知到价值。

赵玥：最棘手的问题，其实不只是技术层面的“怎么存”“怎么 search”。真正麻烦的是：技术定义里的 Memory，和用户真实体感里的 Memory，中间其实存在很大的鸿沟。

从工程角度看，一个 Agent 可能已经觉得自己“有记忆”了。它做了内容摘要，有用户画像，有历史上下文，也能召回用户偏好。但用户真正感受到的，并不是这些技术模块本身。用户在意的是：你到底有没有真的懂我？你有没有记住我上次说的话？你会不会偏偏在不该忘的时候，把重要的信息忘掉？

每个 Agent 都有自己的 Memory 算法、更新策略、遗忘机制。但用户对 Memory 的期待，其实是连续的、情绪化的，而且千人千面。所以我认为最大的挑战，还是怎么去弥补“机器感知的记忆”和“人类对记忆的真实感受”之间的鸿沟。

很多人觉得 Memory 底下就是个数据库，但其实不是，它本质上是一个用户信任层的问题。技术系统当然要把存储、检索这些能力做好，但最终还是得形成一个用户真正能感知到的、完整的端到端体验。

王闯闯：从终端应用层来看，我们的问题和学术界那种“在对话里存储记忆”的场景还不太一样。终端每天面对的是海量碎片化的信息，比如截图、文档等等。很多内容甚至都不是用户和 AI 的对话，而是“我看过什么东西，你能不能自动帮我记住”。而且这些信息本身还是跨模态、异构的。

所以问题就在于：你怎么把这些碎片化、多模态的信息，整理成真正有价值的结构化记忆？而且这个“有价值”，还得和用户体验强相关。接下来还涉及怎么存、怎么召回，怎么在正确的时候把它调出来，真正帮到用户。所以从终端角度看，核心其实是两件事：第一，你怎么记；第二，你怎么把这些记忆真正用起来。

马可薇：针对这些问题，大家的核心解法是什么？

邓亚峰：我们其实很早就开始设计这个系统了，大概是去年 10 月、11 月。当时到现在，中间整个认知和方案已经迭代过很多次了，尤其是 Long Context 之后，很多想法都变了。

最早的时候，我们的系统是一个比较分层的架构：输入层、记忆处理层、索引层，以及最上面的记忆应用层。而且在架构设计里，我们给了非常大的自由度。比如每一层都可以灵活选择不同语言模型、不同 prompt。这样上层应用需求变化的时候，就能很容易地添加或调整策略。

同时我们会有很多 online 策略来保证响应速度，也有很多 offline 策略。因为 Memory 的处理其实很像人的记忆机制。人睡觉、反思、回想事情的时候，大脑其实会重新整理、固化记忆，甚至修正错误记忆。AI 的 Memory 也一样。

最近我们还有一次比较大的迭代。其中一个很重要的新功能，是我们提出了 self-evolving 的概念。因为我们认为，未来 Agent 最核心的体验之一，就是主动性和自我演化。就像今天我们在这里聊天，聊完以后，大家都会有新的成长和变化。未来 Agent 也应该是这样，在人和 Agent、Agent 和 Agent 的交流过程中，它本身的智能也在持续演进。

另外，我们也重点加强了多模态能力。传统 Memory 更多还是偏文本，但未来无论是人类世界还是 Agent 世界，本质上都会是多模态的。

还有一个很关键的问题，就是性价比。现在有些很火的方案，能做到 99% 的成功率，但本质上是把所有上下文都塞给最强的大模型，这在真实场景里根本不起效。所以我们用了一个只有 4B 的小模型，再通过强化学习去优化训练，最后做到和几百 B 的模型接近的效果。大概是 1/50 的参数量，却能达到相近性能，这样应用层才能真正付得起这个成本。

所以我们其实已经形成了一整套从算法到工程的完整体系，当然我依然觉得 Memory 还处在非常早期的阶段，后面一定还会有大量迭代和发展。

马可薇：现在技术发展真的太快了，一个版本刚出来，过几天可能又是新范式。所以相比不停人工迭代，让系统具备自我演化能力，可能反而是更高性价比的方向。

赵玥：用户的 AI Memory，应该形成一个独立存在的记忆系统。因为现在几乎所有 Agent 都宣称自己有 Memory，但本质上它们还是各自为战。每个 Agent 都有自己的算法、自己的记忆管理方式。从单个 Agent 的角度看，它的 Memory 可能是成立的；但从用户整体体验来看，记忆其实是高度碎片化的。

模型、Agent、应用都在不断变化，比如今年年初的 OpenClaw，现在又有各种新的 Claude 系产品。但对于用户来说，那些真正希望沉淀下来的长期 Memory，本质上应该是稳定存在的。

举个简单例子。今天你可能在 ChatGPT 里讨论方案，明天在 Cursor 或 Claude Code 里写代码，后天又在企业内部 Agent 里做数据分析。整个过程中，Agent、模型、应用都在持续变化，甚至同一个产品背后的模型都在频繁升级。

但用户自己的长期上下文，不应该随着工具变化而发生“数据漂移”。否则就会出现一个特别尴尬的问题：每换一个 Agent，你都得重新解释一遍“我是谁”“我在做什么”“我的偏好是什么”“之前聊到哪了”。就像我们不会把通讯录只存在某一个聊天 App 里一样，你换手机的时候，也不会希望所有数据全部丢失。所以在 AI 时代，用户长期积累下来的 Memory，未来应该是一个稳定的数据基础层，而不是某个平台的附属品。

另外一个原因是：未来的工作方式，一定不会是“一个通用 Agent 干所有事”，更大的趋势一定是多 Agent 协同。比如一个用户同时在用代码 Agent、写作 Agent、会议 Agent。会议 Agent 负责生成纪要，另一个 Agent 再基于这些纪要做数据分析。

每个 Agent 的能力侧重点都不一样，但它们服务的可能是同一个人、同一个团队、同一个项目。如果没有统一的 Memory 层，它们之间就会像“临时拼桌”的人一样，每个人只知道局部信息，像盲人摸象。而如果每个 Agent 都得重新理解用户，协同效率就会变得极低。

所以我们做独立 Memory 系统，并不是为了取代某个 Agent，而是为多个 Agent 提供统一的上下文底座。Agent 负责执行任务，而 Memory 系统负责沉淀长期上下文，并在合适的时候，把最相关的记忆提供给对应 Agent。归根到底，我们解决的不是“某个 Agent 能不能记住”的问题，而是：当 Agent 越来越多、变化越来越快的时候，用户的长期记忆能不能持续、稳定、可复用地沉淀下来。

王闯闯：数据孤岛这个问题，对手机厂商来说，其实天然就是一个入口优势，因为我们本身就是系统级的。但我们的挑战也很现实：亿级用户每天都会产生大量碎片化 Memory。所以相比追最新技术，我们更优先考虑的是：怎么真正落地一个“好用、可维护”的 Memory 系统，给用户稳定体验。

核心其实是平衡四件事：效果、隐私、成本和时延。而面对多模态、异构、碎片化 Memory，我们采用的是端云协同方案。这个概念其实不新，但它是我们整个架构设计里的第一性原则。我们不追求“最新技术”，而是追求真正能落地。

具体来说，并不是所有 Memory 都要上最强模型。我们会做场景分流：哪些任务复杂，哪些简单；哪些涉及高隐私，哪些对时延要求高。高隐私、低时延的任务，就留在端侧；真正复杂、需要深度推理的，再放到云端的大模型。这样不仅隐私和响应速度能得到保证，整体成本也更可控，而不是把所有任务一股脑全堆到云上。

马可薇：三位的方案分别从 OS 层、中间件层、终端层切入，看起来各有侧重。但我好奇的是，在底层能力上，三套方案有没有一个相同点？比如，是否都依赖某种形式的向量检索？是否都需要解决“记忆衰减”或“优先级排序”的问题？还是说，你们各自定义的“记忆”本质上是三件不同的事？

邓亚峰：底层上没有特别本质的区别。因为今天所谓的 Memory，本质上还是在利用语言模型本身的能力，再结合一些专用模型，形成一个完整系统。所以我们为什么会叫它 OS？一方面是因为它需要和整个 Agent 生态深度结合；另一方面，它本身其实也已经是一个 Agent 系统了。

如果把 Memory 做一个最简单的抽象，其实就是“存”和“取”——把数据存进去，在需要的时候再取出来。但真正难的地方在于：你怎么能在非常低时延的情况下，把最关键的信息精简地提供给语言模型。因为 token 消耗直接决定了模型的成本和速度。而难点恰恰在中间的数据处理和信息处理过程。这里会涉及大量策略，比如怎么切分记忆、怎么提取记忆、怎么做渐进式披露（progressive disclosure），以及 search 等等。

所以从底层技术角度，我觉得整体方案其实是比较相近的，只是不同团队会有一些自己的特殊能力。比如我们有一个比较特别的技术，可以用一个只有 1 亿参数的模型，完成大规模 Memory 的召回和处理。当然，整体大框架上，大家还是有很多共通性的，只是在设计理念和体验细节上会有区别。

赵玥：从技术底座上来看，大家本质上解决的问题其实都差不多：数据捕捉、语义理解、结构化组织、检索召回、优先级排序、权限控制等等。真正拉开差异的，更多还是场景。

我们现在大概会重点针对三类场景做额外优化。第一类是最基础的聊天记忆，也就是用户和不同大模型、不同 Agent 交互过程中产生的上下文，比如用户正在讨论什么项目、表达偏好是什么等等。

第二类其实是我们后来慢慢融合进来的 RAG。最开始跟客户聊的时候，大家其实分不清什么是 Memory、什么是 RAG。但随着模型能力提升，我们越来越觉得：尤其是一些轻量级 RAG，其实完全可以和 Memory 系统融合。因为很多企业里的专业知识，既存在聊天记录里，也存在文档、PPT、知识库里。所以这类“内容型记忆”，处理方式和聊天记忆有相似之处，但也有很多不同。比如它更像固定知识资产，需要更强的语义索引能力，以及更严格的数据权限控制。

第三类是最近行业里特别火的方向，叫“流程化记忆”。尤其在企业场景里，记录的已经不只是单条记忆，而是工作流。也就是说：你能不能快速总结用户的工作流程，并沉淀成一个可复用的 skill。

这三类场景的 Memory 处理方式其实差异非常大。所以作为底层 Memory 系统，我们更重要的事情，是建立一个足够通用的技术底座，让它能够比较容易地长出、适配各种不同场景。

马可薇：最近业内还有一个挺新的思路。以前大家做的是 RAG，也就是 Retrieval-Augmented Generation；现在有一种想法，是把 Retrieval 本身变成 Context，直接作为上下文。这样用户就可以把自己的 Knowledge Base 和 document 一起融合进上下文里，再做 Retrieval 和 Generate。这个方向其实和您刚才讲的场景非常契合。

赵玥：对，因为现在聊天记忆和文档记忆之间，其实已经没有特别明确的边界了。大模型越强，你越会希望把聊天内容沉淀成文档；而已有文档，也希望能自然融入聊天上下文，所以这其实对底层 Memory 系统提出了更高要求。

王闯闯：真正的差异还是在场景。比如手机厂商这边，我们面对的是大量跨任务、多模态的数据。想把这些记忆真正用起来，首先就得把这些异构信息整理成统一的 Memory 单元。只有结构化之后，下游的检索和召回才能真正工作。不然的话，后面根本没法用。

另外一个比较大的区别是：我们会更强调主动式能力。因为用户在手机上的场景，和 AI 长时间对话其实不一样。很多时候，用户不会主动问，而是希望系统主动理解和推荐。比如我今天记录了一张出行订单，又保存了一份旅游攻略。

那系统能不能自动把这些碎片关联起来？进一步主动给我推荐对应目的地的旅行路线？或者当我问“最近去哪玩比较好”的时候，它不是去网上搜一条千篇一律的网红路线，而是基于我自己的 Memory，生成真正个性化的推荐。我觉得这就是场景层面能做出差异化的地方，底层技术可能类似，但体验层面的空间其实非常大。

记忆系统的架构边界

马可薇：邓博的 EverOS 定位是“长期记忆操作系统”，赵总的方案强调“独立 AI Memory 系统”，那这两种“独立”在真实调用链路里到底意味着什么？它是在模型前面拦截请求？还是在 Agent 旁边挂一个旁路服务？多这一跳的延迟，到底换来了什么能力？

赵玥：我们这边的方案，其实更多不是直接对接模型，而是作为 AI Agent 的一个旁路服务。这样做最大的好处，是我们把模型本身视为一个相对独立、偏算力执行层的角色。

真正落地的时候，我们更多是在做 Memory 系统和各个 Agent 上下游之间的深度协同。整个 Memory 的写入和读取，其实都发生在 AI Agent 这一层。比如你接一个聊天 Bot，我们真正对接的接口其实是在 Bot 侧。原因很简单：Agent 才是 Memory 的第一道入口。用户聊天数据，首先是 Agent 接住的；用户上传文档，也需要 Agent 先做格式转换、内容抽取，之后才能进入底层 Memory 系统。

企业场景更明显。很多 CRM、知识库、工单系统、研发系统，本身也是通过 Agent 暴露 API 来接入的。所以 Agent 不只是 Memory 的使用者，它其实也是原始数据的采集者、初加工者。同时，它还会告诉底层 Memory：“这些数据应该按什么方式加工。”因为最终还是要被上层 Agent 使用。

所以 Agent 最清楚：哪些是临时上下文，哪些是真正值得长期沉淀的记忆。当然，Memory 系统本身也会做这些判断，但如果能和 Agent 深度协同，最终效果会更好。所以在写入阶段，我们希望 Agent 和 Memory 系统一起完成这件事。

读取阶段其实也是一样。Agent 在执行任务的时候，需要明确告诉 Memory 系统：“我现在到底要解决什么问题。”因为本质上，它描述得越准确，我们检索出来的数据就越精准。写入不是简单归档，读取也不是简单 search。这两个阶段，都需要 Agent 和 Memory 系统协同完成。最终，再以 Context 的形式交给大模型。

关于“多一跳”的问题。其实现在整个 AI 系统的接口已经相对开放了，所以这部分调试成本，并没有传统数据库系统那么重。而真正决定时延的，很多时候也不是“多了一跳”。关键在于：你给大模型的上下文质量够不够高。

举个例子。如果我能精准抓取到真正关键的信息，只需要几十 K token 的上下文，就能让模型拿到它需要的内容。那反过来，如果你把一堆无关内容全塞进去，把上下文窗口全部填满，真正的时延反而会更高。所以问题的核心，其实不是“有没有旁路”，而是你到底能不能提供高质量 Context。

马可薇：不同模型对输入输出的数据格式要求可能不太一样。现在业内也有人在讨论，说 JSON 这种形式太耗 token，未来可能会出现新的数据格式。那这会对 Memory 系统带来新的挑战吗？还是说你们内部其实已经处理掉了？

赵玥：从底层大模型 infrastructure 的角度来看，中间可能确实会有一些差异。但如果从端到端的角度来看，我觉得更核心的问题其实不是“你用 JSON 还是别的数据格式”。

假设模型在执行一个任务，我们需要根据任务去决定：到底该返回哪些 Memory。如果我们做得不够精准，那可能只能返回 Top100 条相关记忆。但如果做得足够精准，可能只需要返回 Top10。

邓亚峰：现在有个挺流行的词，叫 Harness Engineering。Agent 基本可以看成“模型 + Harness”。而 Harness 又可以拆成两部分。第一部分是 data，也就是和数据有关的东西。广义上其实 Memory 就属于 data。它负责处理所有和 Agent 有关的数据——包括用户输入的数据、Agent 运行过程中产生的数据、主 Agent、子 Agent 之间的数据等等。第二部分则是 process，也就是 Agent loop 本身，比如 ReAct 这一类流程。

所以整个 Agent 的行为，本质上就是三个部分共同决定的：模型、Memory（或者 data），以及 process / loop。而在这个 Harness 体系里，我认为 Memory 其实是最重要的部分之一，因为现在大家的 Agent loop 已经越来越趋同了。

Memory 真正要解决的问题有三个。

第一，是上下文管理。现在可能是一百万 token，但当 Agent 长时间运行之后，Context 一定会超过这个长度。所以问题就在于：你怎么用尽可能少的 token，把最完整的语义保留下来，这里就涉及整个 Memory 系统的核心能力。你不能像有些系统一样一直压缩信息，因为压缩久了以后，一定会丢语义。所以中间一定需要一整套信息处理、搜索和组织系统。

第二，是个性化。过去很多虚拟陪伴或者 Agent 系统，之所以体验不够好，就是因为没有真正做到 personalization。你需要知道这个 user 的身份、目标、价值观、偏好等等，而这些都需要通过长期 Memory 去完成。

第三，是更高级的智能能力。比如主动性、自我演化，本质上都和“记忆”有关。所以未来 Agent 的很多高级能力，其实都要建立在 Memory 上，这也是它和传统 RAG、传统 Database 最大的不同。

另外你刚才还提到，不同模型、不同 Agent 会不会导致 Memory 系统差异很大。但我现在看到的趋势其实恰恰相反——Memory 正在逐渐标准化。现在大家对 Memory 的定义已经开始慢慢收敛了，最典型的，就是分成 User Memory 和 Agent Memory。

User Memory 主要和用户相关，比如：episodic Memory，也就是“什么时间、什么地点、发生了什么事”这类事实性记忆；还有 profile，比如用户偏好、个性化信息，甚至像 Long Context 里的 soul 之类，也都属于 profile。

另一类则是 procedural Memory，也就是过程记忆。比如一个 Agent 执行任务时，它第一步做了什么、第二步做了什么，整个 trace 都属于 procedural Memory。甚至还可以从中进一步抽取 skill。

未来我特别期待的一件事是：每个人都会拥有很多 Agent，但 Memory 本身应该属于用户自己。而且如果大家在 Memory 定义上越来越标准化，那不同 Agent 之间的 Memory 就可以共享、交换。

王闯闯：我们现在其实做的是三个 Agent 的联合强化学习：一个负责“记”（记忆生成），一个负责“管”（记忆管理），一个负责“用”（记忆使用）。

负责“记”的 Agent，需要知道应该记什么、结构怎么组织。但这些信息必须让“用”的 Agent 也知道，否则它们之间就是割裂的。负责“管”的 Agent，则负责去重、增删改，以及整个上下文管理。因为 Memory 不是越多越好，而是应该关联性越来越强、结构越来越清晰。经过压缩和整理后，再把上下文交给“用”的 Agent。而“用”的 Agent 也不是被动接受结果。它在使用过程中，会把反馈再返回给“记”和“管”两个 Agent。

这样系统就会知道：哪些信息真正值得保留。所以本质上，这是一个联合优化的问题，这样可以初步解决“上下文过长导致模型效果下降”的问题。

观众：大型 IT 项目应该怎么做 Memory 系统？怎么让 AI 更熟悉这个项目？

邓亚峰：第一种情况，如果是在 IT 项目里使用 Memory 系统。我觉得可以从两个角度去看，一个是 user Memory。如果你希望系统更个性化，那就需要建立用户长期记忆，包括 profile、偏好、历史行为、历史事实语义等等，这些都会直接影响最终体验。另一个则是 Agent Memory。未来很多应用都会是 AI-native 的，本质上会是多 Agent 系统。这里最关键的是 procedural Memory，也就是过程记忆。你需要把不同 Agent、多轮运行里的成功和失败经验沉淀下来，不断提升整个系统的成功率。

第二种情况，是怎么让 AI Coding 更好理解已有的大型项目。新项目现在 AI Coding 已经做得很好了，但真正困难的是已有项目怎么迭代。核心问题在于你能不能把历史文档、设计 Spec、代码等等，转化成 AI 更容易理解的知识结构。如何把这些东西组织成适合 Coding Agent 使用的上下文。然后再结合你的编程原则、项目规范，一起交给 Coding Agent。

检索与存储的技术内核

马可薇：赵总，您的方案里图数据库和向量数据库是协同工作的。能不能用一个真实的检索例子，走一遍请求在两种存储引擎里的流转路径？图解决了什么向量做不到的事？

赵玥：比如在企业环境里，一个售前去问内部 Agent：“你帮我整理一下上次某个客户的 AI 平台方案，重点讲一下我们和某些存储厂商合作的点。”这句话对于人来说其实特别好理解，但对系统而言，里面全是坑。比如“上次”到底是哪次？“某某客户”具体指的是哪个客户？“和存储厂商合作的点”，那到底是 NAS、知识库，还是其他数据管理相关内容？

所以系统第一步，一般会先去向量数据库里搜索。向量数据库很擅长做“语义相似”这件事。它会从历史聊天记录、文档数据里，找到那些“意思相近”的内容片段。比如和这个行业客户相关的内容、和 AI 平台相关的内容、和企业存储相关的数据片段等等。

它相当于能从一大堆零散的数据海洋里，先把“可能相关”的东西捞出来。但问题在于：捞出来以后，它其实未必知道这些数据之间到底是什么关系。它知道这些对话可能都在讨论同一个 topic，但它不知道：哪部分是客户真实需求、哪部分是方案背景、哪部分是合作细节、哪些内容是当前任务真正相关的。

这个时候，就需要图数据库了。因为图数据库更像是在帮系统建立一张“关系地图”。它会知道：这个客户方案和哪些历史项目相关、这些项目又关联到哪些文档、这些文档里又提到了哪些关键技术点、哪些内容之前已经和客户聊过、哪些是最近新增的内部技术判断。

所以图数据库回答的问题，不是“像不像”，而是：“谁和谁相关？为什么相关？这条关系链是怎么串起来的？”而且它还能进一步关联出一些向量搜索本来没搜出来的数据。

所以一个比较理想的流程其实是：用户提问后，先通过向量搜索找到相似内容；再通过图数据库，把这些内容真正串联起来；过滤掉无关信息；然后梳理它们之间的关系、时间顺序、任务背景等等；最后系统再做综合排序，整理成一个干净、结构化、足够准确的 Context，再交给 Agent。

其实这很像人的记忆方式。比如我跟你聊天时提到一件事，你第一反应可能只是一个片段，但慢慢地，你会因为其中某个小细节，联想到另一个人、另一场会议、另一段经历。本质上，人类记忆就是一个不断联想、串联的过程。

所以现在很多 Memory 系统里，图数据库和向量数据库其实不是替代关系。向量负责“把相关内容召回”，图负责“把这些内容组织起来”。最终目的，是让 Agent 拿到的不是一堆零散聊天片段，而是一个真正有组织、能支撑当前任务的上下文。

马可薇：邓博，您的 MSA 稀疏注意力解决的是检索效率问题，它和底层存储引擎之间是什么关系——是上层调度算法，还是存储结构本身的一部分？

邓亚峰：MSA，全称是 Memory Sparse Attention。我们最开始做这个工作的出发点，其实很简单。人一生中的文本记忆，大概是几亿 token 级别。所以我们当时就在想：能不能做一个“亿级 token”的 Memory Engine。

MSA 的核心，本质上可以理解成一种端到端的 RAG。传统 RAG 大家一般会理解成“双塔结构”。也就是说：query 会被编码成 embedding，文档库里的 doc 也会变成 embedding，然后通过 embedding 相似度去匹配。

但我们当时发现一件事：如果你直接把“问题”和“文档”一起交给语言模型，让模型判断它们是不是相关，其实效果会非常好。这其实更像“单塔结构”，但太慢了。因为你等于每个 query 都要和大量 doc 做完整推理。所以后来我们对整个 Decoder 架构做了很多底层改造。包括位置编码、KV Cache 存储等等。我们甚至把 KV 存储压缩到了几十倍。

最终做到的效果是：用很少的计算量和存储量，就能在 1 亿 token 上下文里，实现端到端 RAG。而且它不仅做检索，也同时完成问答。也就是说，它把“检索”和“记忆应用”一起端到端做掉了。而端到端本身，其实在效果上天然是有优势的。

所以它并不只是一个 retrieval 系统，而是一个更完整的 Memory 使用层能力。当然，它也可以构建在其他 Memory 系统之上。比如前面 Memory 系统已经完成信息处理，MSA 再在“使用层”做后续推理。

刚才其实也提到了图数据库和向量数据库的关系。最简单的理解是：向量搜索解决的是“表面语义相似”。语言模型本身其实已经很强了，如果你把所有相关信息都给它，它完全可以自己推导出关系。

但问题在于：很多时候语义关系是“多跳”的。比如一个信息需要经过两三层间接关联，向量搜索就很难直接召回，这时候就会出现信息缺失。所以你需要图，或者其他机制来解决多跳问题。

而 MSA 里面其实也有类似机制。它有一个“多跳推理”的过程。当你问一个问题后，它会基于第一次召回的结果，继续生成新的问题，再继续召回下一层答案，这样它就能不断沿着推理链往下走。所以整体来看，MSA 更像一个非常底层、非常基础的 Memory 基础能力。

马可薇：那我感觉在实际调用层面，王老师这边应该也会很有感触。因为用户一般不会一次性扔一个超长大文本，更多还是一个个问题地去问。

王闯闯：站在终端场景来看，其实调用过程比大家想象中更繁琐，很多事情不能只靠简单语义召回。举个例子，最近我们在做一个很火的需求，比如用户说：“帮我做个北京三日游。”但用户之前记下来的信息，其实可能非常碎，很多内容甚至不直接包含“北京”这个词。所以如果只靠语义搜索，很多东西根本召不回来。

语义层面最多只能先召回一些和“北京”明显相关的内容，剩下的就必须靠“关联关系”。比如：北京这条记忆关联到了签证，签证又关联到了旅行记录，旅行记录又关联到了美食收藏。只有通过这种图关系，系统才能把这些碎片真正串起来。最后用户会觉得：“这个系统真的懂我。”而不是你说一个关键词，它机械地按语义给你搜回来。真正的智能感，其实很多时候就来自这种关联能力。

端云边界的划分逻辑

马可薇：王老师，OPPO 的方案里 端云任务划分逻辑是什么？什么样的数据“必须上云才能理解”，什么样的“上了云用户就不放心”？

王闯闯：端云协同的划分，本质上就是在效果、隐私、时延和成本四个维度之间做系统性平衡。

先说效果。在端侧，通常适合处理的是“单屏、单任务、单实例”的场景。比如一张图片里只有一个日程、一笔订单或者一条记账，这种相对简单的任务，可以通过端上的 planner 和 routing 直接处理。但如果是多屏、多窗口、多实例的复杂任务，比如平板上同时开多个窗口，每个窗口任务不同，那就需要交给云端处理，才能保证整体效果。

再说隐私。哪怕云端效果更好，只要涉及高敏感数据，比如相册图片、支付信息，这些必须留在端上处理，这是硬约束。

第三是时延。比如用户刚记了一条出行订单，希望马上弹出卡片确认，这种强实时反馈的场景，一定要在端上做，否则体验会被长延迟拖垮。

马可薇：本质还是在效果、隐私、延迟、成本之间做权衡，不可能全部放端，也不可能全部放云。

王闯闯：而且这个比例不是固定的，它会随着用户行为、模型能力、以及端侧算力变化动态调整。

马可薇：这个动态调整是根据任务场景，还是技术能力在变？

王闯闯：两者都有。一方面是场景驱动，比如新增了某类任务；另一方面是能力驱动，比如端侧模型变强了，那原来在云上的任务就可以迁移到端上。另外我们还会做一个闭环评估，用模型去评测路由和任务分配是否合理，再根据数据不断调整四个维度的平衡。

马可薇：赵总、邓博，如果用户要求记忆永不上云，你们的系统能力会打几折？有没有可能跑一个端侧轻量版？

赵玥：我们其实也在做一个可以跑在端侧设备上的版本。但我们更关注的是：当设备上的 Agent 想访问 Memory 的时候，它能不能稳定访问到。至于到底用本地算力还是云端算力，这个可以交给用户或者 Agent 自己去决策。

我们更关注的是底层 Memory 的统一性，所以我们做的是一个 Memory 底座，而不是具体算力策略。比如用户同时有手机、平板等多设备，那这些设备上的 Memory 必须是统一的。哪怕完全在本地算力运行，也要保证跨设备一致体验。

邓亚峰：我们其实是同时有端和云两套方案的。云端方案比较容易理解，我们也有开源版本，可以直接部署在本地。所以从结构上来说，其实已经覆盖了两种模式：一种是所有计算都在端上；另一种是数据在端上，但部分计算仍然调用云能力。

但如果说“所有计算都在端上”，我觉得真正的挑战其实不在 Memory，而在 Agent。因为只要 Agent 还要调用云模型，就意味着数据会出端，这本身就会带来隐私风险。所以从设计角度来看，没有必要强行把所有计算都锁死在端上。更合理的方式是：敏感数据留在端侧，必要计算可以上云，整体通过端云协同完成。

本质上这是一个信任问题。像微信、各种云服务，其实大家数据都在云上，但依然在用。关键不是“在不在云”，而是“你信不信这个系统”。

成本的真相：牺牲了什么换来了什么

马可薇：赵总，做到 LoCoMo 90% 准确率，你们在响应延迟或存储成本上付出了什么？

赵玥：本地模型、跑分这些，其实更多是在测“查询准确率”。但在真实 Memory 系统里，我们关心的是端到端效果。

这里面其实有一个核心 trade-off：你到底愿意用多少 token 成本，换多少准确率。理论上，如果未来模型足够强，上下文无限大，Agent 设计足够好，你可以把所有 Memory 分批塞给模型，让它逐步推理。但现实问题是 token 太贵，延迟太高，所以你很难追求 100% 准确率。在真实场景里，90% 和 95% 的体验差距，其实没有想象中那么大。

真正关键是“性价比”。比如 Memory 系统里一个常见问题是 reranking。向量 + 图检索之后，会拿到很多候选结果。你可以用云端 reranker 做排序，但这意味着额外调用大模型，也意味着更高成本。如果你想要更低成本，就要在本地做 rerank，用小模型完成排序，同时配合 embedding 做相似度计算。本质上就是不断在系统里“抠细节”：每一步减少一点 token 消耗，换一点计算成本，最终换来一个在真实场景中可用的准确率，这才是一个真正可落地的 Memory 系统设计方式。

马可薇：邓博，EverOS 作为 OS 层方案，对上层应用的改造要求有多高？

邓亚峰：我们自己在做 EverOS 的时候，最早其实在 LOCOMO 上大概只能做到百分之八十几的水平。去年十月左右，我们其实已经做到 93、92 这一档了，当时用的还是比较大的模型，比如 GPT-4.1 或者千问的 235B 这种级别。但最近我们用 RL 做了一些新的方案之后，其实在 4B 模型上，在 LOCOMO 上也能做到 91，在 LongMEM Evo 上大概是 87 左右，在 PersoMEM 上也同样是比较高的水平。

其实在记忆这个任务里，已经证明了一个很关键的点：你不一定需要很大的模型，小模型经过训练之后也可以达到很高的指标。所以我们现在线上默认其实是 4B 模型，它在纯指标上可能不是最高，但从实际应用角度来说，反而是更好用、更可用的。未来真正能落地的记忆系统，性价比是非常关键的，也就是计算成本和 performance 之间的 trade-off。用户并不会只看 benchmark，他更在意实际体验。

另外从系统角度看，当它和 Agent 协作时，本质上更像是一个“可调用的数据库”。你把数据写进去，中间我们做很多复杂计算。真正用的时候，其实就是两个核心接口：一个是 search，通过 embedding 或图结构去做语义匹配；另一个是 get，直接拿某些字段，比如 user profile 之类的内容。所以对上层来说，它的使用方式是非常轻量和简单的。我们现在也在把这些能力封装成更标准的接口，比如 scales、渐进式披露这些方式，让 Agent 可以非常低成本地调用。

从更长远的视角看，我们也在思考 Agent OS 的形态。包括 Memory 应该怎么组织，Agent loop 应该怎么定义，可能最终会收敛成类似操作系统的结构，有比较明确的模块划分，甚至模块之间会有协议标准，方便互通。

马可薇：王老师，端侧跑 AndesVL 做 端侧流量的推理，对手机功耗和存储的压力有多大？

王闯闯：这块其实在手机端更明显，因为端侧推理是一个很硬核的工程问题，算力、功耗、发热都是一点一点抠出来的成本，这些是必须要解决的。所以我们一方面会做自研的大模型，比如 AndesVL，也会跟芯片厂商做深度联合优化，尽量把算力压榨到极致。同时在模型侧也会做 sparsification，比如 sparse 稀疏化，降低存储成本。

在架构上，我们也会用 1+N LoRA 的方式，让一个基础模型高效支持多个业务，而不是每个业务都单独跑大模型，这在端上是不可承受的。应用层这边，我们做的更多是工程优化：压缩上下文、精简 prompt、裁剪推理链路，把整个 pipeline 做短，让算力和存储消耗降下来，最终减少发热，提升体验。

马可薇：很多时候不是模型越大越好，而是看场景里谁更合适。小模型 + 优化，可能反而比大模型更好用。

会议推荐