打造自进化的编码伙伴：Qoder 记忆系统落地实践

当 Coding Agent 成为 开发者最亲密的协作者，一个根本性问题逐渐浮现——它记不住你。每一次会话重启都意味着知识归零，技术决策、项目规范、踩过的坑全部遗忘，这是当前所有 AI Coding 工具共同面临的挑战。本文整理自阿里云技术专家王世杰在 QCon 全球软件开发大会 2026 北京站的分享《打造自进化的编码伙伴：Qoder 记忆系统落地实践》。王世杰系统阐述了他们在编码领域构建 Agent 记忆系统的完整实践。从记忆的定义和价值出发，他梳理了类脑记忆、模型记忆和外挂记忆三条技术路线，分享了独立记忆系统的架构设计、多阶段混合检索机制、记忆网络的进化能力等核心技术方案。文章还将触及记忆评估、模型遵循、记忆自进化以及专家团模式等更深层的技术探索，为 Agent 记忆系统的大规模落地提供了宝贵的工程参考。以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。记忆的价值在我看来，记忆系统是在 Agent 跟外界交互的过程中，所有生成的个性化信息或知识，要能够被 Agent 管理和检索，我们才称之为记忆。这不是一个宽泛的数据存储概念，而是具备管理能力和可检索性的动态知识体系。为什么要在一个 Coding Agent 中构建记忆系统？这个问题可以从一个非常日常的场景切入。我经常跟 Qoder 做编程，但每一次打开它的时候，我会发现它根本不认识我。我们之前聊过什么东西，做过什么技术决策，用了什么技术架构，或者之前修过什么 bug，它全部不记得。这是目前所有或大部分编码工具都会碰到的问题——怎么让这个编码工具真正认识使用者。如果一直没有记忆系统，可能会碰到三个核心问题。第一个是知识遗忘， Agent 无法继承之前协作中积累的任何信息。第二个是重复沟通，用户需要反复向 Agent 说明相同的背景和偏好，这不仅是时间的浪费，也极大降低了协作效率。第三个是经验无法复用，用户之前成功完成某个任务的经验， Agent 完全没有记录，也就无法在类似场景中复现。这些问题的本质在于，我们与 Agent 的协作是连续的，但 Agent 本身却是无状态的。每一次会话都是一个全新的开始，人和 Agent 之间积累的协调成本被完全抛弃。这种体验在浅层交互中或许可以接受，但在深度编码协作中，代价是不可忽视的。这正是记忆系统要解决的核心命题。为了让大家更快理解我们在 Qoder 产品中构建的记忆系统，我先用几个具体的功能案例来说明它究竟能做什么。最基础的一层是沟通偏好的记忆。Qoder 会记住用户的沟通风格、基本信息以及对回复方式的要求。如果你在执行任务时不关注中间过程，只想要结果，可以告诉它简单一点。它会帮你做更简洁的回答，这既能加速任务完成速度，也能减少不必要的 token 消耗。这类偏好记忆的积累，让 Agent 逐渐适应每个用户独特的工作节奏。再进一步是项目信息的记忆，包括技术栈、环境信息等。一个典型的例子是项目初始化场景。第一次创建项目时，我可能需要详细描述技术架构、限制技术栈要求。但到后面我再创建项目，直接告诉它初始化一个项目，它很快就会完成。它已经记住了我对项目结构的偏好，不需要每次重新解释。开发规范的记忆同样重要。虽然现在很多场景下代码可能不再需要人直接阅读，但仍有大量情况需要人工参与代码评审。我们可以让 Agent 记住注释规范、测试规范等开发约定。只要第一次明确告知这些规范，后续写代码时它会全部按照规范去实现，不需要每次重申。还有一个不可忽视的价值是踩坑记忆。我自己的电脑上遇到过这样一个场景：我跑了一个 Python 程序，直接让 Agent 去执行，但它跑不了，因为我电脑上没有装 Python，装的是 python3。它第一次执行失败，但尝试之后成功了。等到下一次我再让它去跑的时候，它直接用了 python3。这本质上是记住了一些缺陷和修正方案，好处是省下大量 token，避免了重复尝试错误的行为。这种纠错知识的积累，让 Agent 在特定环境中的表现越来越稳定。经验记忆是更有价值的部分。如果我们之前完成过一个比较好的项目， Agent 能够记住这些经验。实际上大家写代码的时候会发现，我们很多时候不是在写代码，是在抄代码。以我自己开发记忆系统的经历来说，有一个类目我想增加，但我之前已经加过类目了。 Agent 就会参考之前加类目的完整过程，完全按照那个流程帮我去完成。相关文件的记忆也类似。每次需求变更时，它能记住上次这个需求涉及的代码范围。等到下一次我再去改需求的时候，它会立刻定位到这些文件，少走很多弯路，直接去做修改。代码重构是一个更复杂的场景。如果我需要完整重构一个文件系统，第一次我可能比较耐心，详细告诉它我应该怎么重构，包括做抽象、删除冗余代码、加注释、加测试。但我不希望每次都说。只要第一次跟它说清楚了，后面再告诉它重构一个文件，它就会按照我原来设计好的重构流程去执行。这种流程性经验的记忆，让复杂操作变得可复用。技能系统是目前行业里比较受关注的方向。大家可能了解过，最近阿里推出的相关技术也是通过技能系统完成整个 Agent 的进化。以前的技能通常是用户手动编写的，这种方式成本很高，而且基本不会自进化。很多人写完技能之后很少会去更新和优化。我们期望技能可以自进化。举个实际例子：在专家团模式中有一个角色叫 leader，负责分配任务。如果我要开发一个需求，leader 可能会帮我安排一个后端去写代码。但如果我提的需求需要前后端都要，而且还要在后端起来之后做端口测试和接口测试，我就会告诉 leader 这个要求。跟他聊完之后，下一次他就会学到一个新的技能。等到下一次我提类似需求的时候，他就会按照这个技能去分配三个任务给后端、前端和测试三个不同角色，同时执行。最后我们还在尝试一个比较有意思的附加功能：让 Agent 拥有可选择的性格。现在写代码 99.9%我都在用 Qoder，基本自己不写代码了。而且我一天其实跟同事也没什么好聊的，大部分时间都是在跟 Qoder 聊。既然 AI coding 没法避免了，那我在想我是不是可以选择跟什么样的 Qoder 去合作。有的人希望有一个有温度的协作者——如果做错了，它会安慰你一下、鼓励你一下。也有一些人可能不喜欢这种风格，希望上一点强度，用更直接甚至有点幽默的方式来沟通，这个性格可以自己选。这听起来像是一个产品层面的微调，但它本质上也是记忆系统在工作——记住并始终如一地运用用户偏好的交互风格。实现记忆系统理解了记忆系统在产品层面的表现后，我们来看技术实现层面的路线选择。目前我认为可能就三个方向比较靠谱：第一是类脑记忆，第二是模型记忆，第三是现在用得最多的外挂记忆。类脑记忆目前虽然不是主流，但我认为还挺有潜力的。前一段时间有科学家把果蝇的 12.5 万个神经元扫描，做成了数字化果蝇。他们现在在扫小老鼠，随着计算能力的提升，我觉得很快就可以扫人脑了，说不定未来人脑上云是可行的。当然这是一条比较远的路，短期内不太可能成为工程落地的主要方案。模型记忆，也就是把记忆直接训练进模型参数里，这在泛化场景或效率要求比较高的场景可能会比较好。目前业界不少人认为模型记忆可能是一个中台形态。但从我的判断，模型记忆这条路还是比较远的，因为训练的成本和准确性目前还解决不了。尽管如此，我们也有一些相关的工作在推进。虽然现在没法解决模型如何从零开始记忆知识的问题，但可以训练模型让它怎么把记忆系统用得更好。这里面有两个方向。第一个是模型遵循能力。有时候记忆检索出来了，但模型不去用。记忆不是说你检索出来就万事大吉了，因为现在很多团队做 RAG 时可能主要关注召回率这类存储指标，但实际上很多时候记忆是能召回的，但模型不会遵循。所以一个很大的方向就是怎么训练模型，让它遵循记忆的指示，把检索到的记忆真正用起来。第二个方向是让模型学习怎么使用这个记忆系统。我们有很多记忆工具，但很多时候模型不知道在什么时候应该用记忆，什么时候应该怎么查。我们会用自己的场景数据训练它，让它更加完善，我觉得这是目前落地比较快的一种模型化路径。外挂记忆是目前业界的主流方案，大家能看到的记忆系统基本都属于这一类。在编码领域，外挂记忆内部有两条技术路线。一种是基于文件系统的，通过主 Agent 直接去编辑记忆文件来达到管理效果。另一种是基于数据库加索引能力的独立记忆系统。其实核心不在于用文件还是数据库，因为 SQLite 这种数据库本身就是一个文件，所以存储形态并不是本质区别。真正的核心问题是：谁来管理记忆系统。在 CC 或 OpenClaw 这类产品中，基本上是主 Agent 去管理记忆。在数据量少的时候没有问题，但在数据量大的时候问题比较大。举个例子，写一个支付接口时，很多情况下需要去翻文件找到某一条记忆来使用。但主 Agent 很多时候不会去找，因为它根本不知道有这样一条记忆存在。如果是独立的记忆系统，它在意图识别的时候可以通过多跳或场景识别来做关联，主动性更强。基于这些观察，我有两个核心判断。第一个判断是，记忆系统要有独立的 Agent 去承接。主 Agent 有自己的编码任务，如果让它同时做记忆系统管理，首先会影响主任务的质量和效率。记忆系统本身是全局系统，它不只是在会话里主 Agent 觉得应该记什么，而是要通过全局判断来决定应该记什么、应该忘什么。这不是一个会话维度的决策，而是跨会话、跨时间的持续管理。第二块核心判断是关于自动维护。文件系统做记忆的缺点是有人可以去改记忆文件，但实际上极少数人会真的去手动修改。大部分人还是期望 Agent 的记忆可以自进化，而不是自己像写草稿一样去手动编辑记忆条目，那绝对不是真正的记忆系统。基于这两个判断，我们做了一个独立的记忆系统。它有