当 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 的记忆可以自进化，而不是自己像写草稿一样去手动编辑记忆条目，那绝对不是真正的记忆系统。
基于这两个判断，我们做了一个独立的记忆系统。它有三大优势。第一是生成能力强，通过全局判断在什么场景下可以高效提取关注的记忆，生成率比较高。第二是索引能力强，文件系统那种检索能力本质上不是在回忆，而是在翻书——它没有真正记住，只是找得快。像 CC 这种产品可能翻得很快就能找到想要的内容，但它缺少理解层面的记忆关联。第三是自进化能力，我们的记忆在运行中不是静态的，会持续对记忆进行评估、打标，评估效果，推动记忆的演化整理或遗忘，保证留下来的记忆质量最好、检索效果最好。它是一个动态自进化的过程，不是一成不变的。
接下来讲一下我们记忆系统的具体设计。核心是右边这个元记忆系统，加上工作记忆、检索链路，还有记忆的生成链路。元记忆系统基本等于是我们的第二大脑，它会管控整个记忆系统的生命周期。除了监控 Agent 的行动、做记忆生成和检索之外，它还有监控和反思的能力。它会通过心跳机制做监控和处理，做一些遗忘清理的动作。它也会做反思，每次任务完成之后，评估这个记忆有没有效果，是好的还是坏的。如果是好的，就奖励它；如果是坏的，就惩罚它，逐步优化记忆库的质量。
在记忆生成方面，我们首先需要确定提取时机。一开始我们只在对话聊天时提取记忆，而且只提取用户的记忆，不提取模型的通用知识，因为模型的知识没必要再存一遍。后来我们扩展到了任务完成后的总结场景，去提取这个任务过程中有没有产生什么经验和技能，这是第一类提取场景。
第二类提取场景和我们的编码业务紧密相关。因为编码场景跟其他通用 Agent 场景不太一样，我们的代码写完是要做 code review 的。有些用户会去 CR 代码，点击代码采纳。我们会把采纳行为作为一个信号，这表明用户觉得这次任务完成得比较好。那我们就去提取这个任务相关的经验和流程，把它固化为可复用的记忆。
第三类是用户指令驱动的提取。我们主观上不希望用户去管记忆系统，希望它是自动化的。但我们发现，尤其对于高阶用户，主动跟 Agent 沟通协作，让 Agent 去反思，反而能总结出更好的记忆质量。这种有反馈的记忆提取质量，往往高于记忆系统自己默默提取的。用户的一句"记住我这次的做法"比任何自动判断都精准。
在工程实现上，目前很多记忆系统主要靠大模型来驱动。我列一下在写提示词时需要注意的几个要点。首先是模板设计，要明确定义几个核心模块。有一个需要特别提醒的点：重要规定我们在提示词的最开始和最后都会重复写。因为像语言偏好这样的要求，我是国际化产品，需要前后都去提醒模型，确保它不会在长篇推理中遗忘这些基础设定。
输出格式的统一也很关键。我之前和很多同学聊过，他们模型输出时没有用 JSON Schema 限制输出格式。JSON Schema 的好处是自描述性强，可以很强地约束输出，模型遵循能力也强。我们换了 JSON Schema 之后，解析成功率大约提升了百分之二十。
但有个问题需要注意：在最快速响应的场景里，JSON 不是很合适，因为它有大量冗余信息。这种情况下推荐试用一下 TSV 格式，它更精简。如果模型在输出时仍然不遵循格式要求，还有一个比较好的方案是让模型先做思考，让它自己先复述一下要输出什么内容，说出来之后再输出，这样遵循度会很高。
再说一个精简原则：工程能做的事情就不要给大模型。比如输入时，记忆 ID 很长，模型很容易出现幻觉。我们的做法是把记忆 ID 在工程侧转换成索引 1，2，3 传给它，等工程处理完它的输出之后，再反向解析回完整的 ID。这样保证幻觉率很低，还能降低一些 token 消耗。
关于记忆提取的内容范围，一开始我们提得比较宽泛，大概覆盖了 Agent 相关的记忆、用户相关的、项目相关的这几类。但后来发现太宽泛后准确性很差，因为给了模型很大的发挥空间。所以我们会限制每一个类目场景，明确限定要提的内容，这样提出来的记忆才比较稳定可靠。最终我们提取的体系大概有五个大类，二十六个小类。
存储方面，我们目前是在端侧存储，用的是 SQLite，包含关系表和向量表。SQLite 本身有插件可以支持全文检索，但它的中文分词能力比较弱，所以我们用了 Bleve 做全文索引。当然也可以安装 SQLite 的 simple 这个插件来支持中文全文检索，效果会好一点。
还有一些数据包括记忆网络和主题树，是我们自定义的数据结构。我们会对这些数据进行序列化，存到本地文件，在启动的时候进行内存加载，然后在内存里做管理和检索。这是我们的整体存储结构。
说完了记忆是怎么生成的，接下来讲怎么用它，这会涉及到我们检索链路的核心设计。为了兼顾效率和准确性，我们做了一个多阶段的混合检索方案。
第一阶段是做意图识别。用户的输入进来后，我们先判断他的主要意图是什么、次要意图是什么、有没有隐藏意图。这一步不是简单地匹配关键词，而是理解用户当前任务的上下文和深层需求。
第二阶段是根据意图进行多路并发召回。比如我们会有六路召回同时进行。召回之后还有一个事情不能忘：很多时候模型不回忆，是因为它不知道你记得什么。所以每次检索时，除了召回当前任务相关的记忆，还要把记忆相关的其他记忆也一并告诉它。这样模型自己会判断要不要再加载更多记忆。在实际工作中，模型可能在任务执行到某个节点时，突然发现有一条记忆自己之前知道，它会主动去再搜索一次。这形成了一个动态的检索闭环。
但这六路召回的数据量通常比较大，我们不会把所有数据全部返回给模型。会有重排步骤，根据不同场景执行不同重排逻辑：效率要求高的场景用轻量小模型，准确性要求高的场景用大模型，最后用工程的规则过滤做兜底。
链路里还有一个特殊的组成部分叫固定查询。为什么会有这个东西？看起来一点技术含量都没有，就是把固定的记忆写在那儿直接拿回去。但这是因为很多时候有一些记忆是立马要用的，必须一开始就告诉模型。比如沟通风格——你怎么回复用户消息，这必须一开始就拿到，不能等它回复完之后再回忆。还有一些 Agent 的行为规范也属于这一类。比如有的用户诉求是 Agent 每次执行完成后推荐两个下一步的问题，这会影响到整个 Agent 的行为模式，所以需要一开始就直接把它加载进去。
在检索技术选型上，现在市面上一般都用全文检索跟向量检索做混合查询然后排序返回。但我们除了这个，还自己做了一套记忆网络和主题树的检索方案。
记忆网络主要是解决两个问题：多跳和进化。有些检索没法直接通过语义召回。比如我要做代码重构，有经验的人都知道重构之后要做测试。但模型肯定不会在你说"重构"的时候主动去找测试的开发规范，因为两者没有直接的语义关系。我需要有一个关联关系：如果要代码重构，就找一下测试的规范，然后用测试的规范去写测试代码。这就是多跳的实际价值。
我这块的图谱和大家常见的不太一样。一般图谱基本就是 Memory Graph 的概念，通过三元组从业务领域去提取知识，我这边其实只做相关性。我觉得现在大模型的理解能力很强，没必要把所有的推理逻辑全部塞进记忆系统，我们只做相关性关联就足够了。
具体是怎么激活的？一个请求进来之后，我先做一层语义激活，用向量做的。这个过程会做多次，每次让阈值变得更高，在扩散中对相关性要求越来越严格。然后我拿到一批激活节点，再用这批激活节点去做图谱的多跳。图谱同样会计算当前所有激活的节点，根据权重激活记忆。而且图谱有权重，有权力就可以进化。每次做记忆检索之后，我会记住这条激活链路是怎么走的。任务完成之后进行评估：这个记忆用得好，说明这条激活链路质量好，就奖励它，提高权重。如果记忆效果不好，这条激活链路可能就不太好，就降低它的权重。这就是记忆网络自我进化的能力。
检索链路里另一个重要组件是主题树。记忆网络的核心思路是聚焦再扩散，这个思路有一个前提，就是聚焦要聚焦得对。如果一开始就聚焦错了，再怎么扩散也扩散不到想要的记忆。主题树的不同之处在于，它先拿到全量的记忆，然后逐步探索。这个思路跟人类的记忆非常像。人在思考一个问题的时候，肯定是先回忆这个事情跟哪几个领域相关，然后再往里面探，找到下一层更相关的，再往下探。逐层往下探，不断发现更相关的细节，同时把不相关的枝节裁掉，最后拿到跟这个任务最相关的一批记忆详情，这就是主题树的探索过程。
目前我们碰到比较大的挑战还是在检索这块，尤其是模型不遵循的问题。模型对我们工具调用的积极性很差。你告诉它有个 Search Memory 工具，这个时候你应该去查，但它不听话怎么办？我梳理了三个方向的探索。
第一个方向是利用模型本身的能力特征。我们观察到，大模型现在对文件的管理能力远大于对自定义工具的管理能力，因为它们在工作过程中被专门训过文件操作。基于这个观察，有一个解决方案是做一个虚拟的文件系统，把所有记忆挂在虚拟文件下面。模型看到的是文件，但在后台操作的是记忆系统。这种方式可以降低工具使用门槛，模型更愿意去"打开文件"而不是"调用工具"。但我们在测试中也发现了一些问题：记忆量比较大的时候问题比较明显，加载量可能太多，多跳能力也会比较弱。这个方案可以证明降低工具使用门槛有助于模型去使用工具，但不能简单地只做到这一步，还是需要做一些索引优化的事情。
第二个方向是改变工具的表达方式。我们一开始有 Search Memory 这个工具让大模型去用，但它不主动用。后来我们加了一个模式叫 Fetch 模式，就是告诉模型：当看到某个记忆想拉取时，直接用这个方法去拿，不要去搜索了。这个语义非常直接，成本很低——就是"拿"而不是"搜"。模型调用积极性变得很高，只要看到相关记忆的提示，它就可能去做 Fetch。这个改动让我们在模型遵循率上有了明显提升。
第三个方向我觉得是更根本的解决方案。我们根本不需要让主 Agent 的模型去做决策了。我们直接搞一个第二大脑，持续监控主 Agent 在干什么事儿，分析它的上下文，预测它需要什么样的记忆，然后主动把需要的记忆推给它。这样的话，主 Agent 在做自己的编码任务，记忆系统会像一个灵光乍现的助手——你干活干着干着，突然有一个好想法出现了，但它不是你主动想出来的，而是被推送到你面前的。这就是我们期望达到的效果。
对于记忆整理，大家已经形成共识：记忆是活的，肯定要去管理。记忆系统持续运行，数据越来越多，整个系统会越来越混乱。这会带来几个问题：降低数据存储效率，增加存储成本，更重要的是降低准确性和有效率。
有两个解决方案。第一个方案是让用户手动修改记忆，或者跟 Agent 沟通做记忆管理。但这个方案有两个比较大的问题。首先，很多用户不知道一条记忆有没有用、有没有效果、以后能不能用。拿到一条记忆，在生成的时候不知道它以后有没有用，只有在实际用的时候才知道。所以让用户判断一条记忆好不好，不太靠谱。其次，数据量大之后，用户自己判断成本很高，根本管理不过来。所以我们的推荐方案是让 Agent 、让记忆系统自己去做维护，自己判断哪些记忆质量好、哪些用得多、表现好就留下，不好的就遗忘或降权。
但这个方案实现起来，遇到了一个更深层的问题。我发现记忆系统核心的瓶颈可能不在于工程或技术链路的实现，而在于怎么评估它。没有进化方向，就进化不了，评估是目前最大的问题。
评估记忆效果
现在的公开 benchmark 其实不可信，这基本已经是业界的共识。基于我们自己编码的特殊场景的需求，我们自己做了一套测评集。拿 CC 和 OpenClaw 在我们自己的数据集上做对比，我们的评分会高一些。有几个发现：
CC 对记忆的管理能力其实相当强，但核心问题是所有记忆都得主 Agent 提取管理。管理的时候它的提取能力很弱，因为主 Agent 的注意力不在提取记忆上。虽然系统提示词要求它提取记忆，但主 Agent 会优先考虑用户的主任务，先完成那个，其次才考虑记忆提取。所以它的提取能力很弱，除非用户有明确的意图告诉它"记住这个"。很多时候不让它记，它可能就不会去记。还有多跳能力，一跳再跳多次关联的能力，也比较弱。
OpenClaw 的情况类似，但比 CC 更弱的一点是它根本不关注编码相关的场景。CC 有时候编码相关的也会去存一下，比如技术架构有变更会去记录。但 OpenClaw 完全不管编码场景的记忆，只管聊天的事。所以在我们的测评里评分最低。
在测评体系上，我们给出了几个指标，这些是线上的实际数据而非离线 benchmark。解释一个关键指标：参与率。就是一次会话中有没有记忆参与这个任务。如果有，说明参与了。你参与了而且表现好，那这次就是有效的。
评估是怎么做的？用的是 Qwen Plus 进行大模型评估，当然这也不是很可靠。我们会做人工校验，我觉得可能可靠度在 80%到 90%之间。但很多时候大模型自己也评估不准确，这只能算参考指标。
业务指标同样不好统计。我们的方法是：在相同场景下，判断记忆生效和不生效时业务指标的变化，取了 top 5 的业务指标变化。为什么必须在相同场景下？大家要想一个问题：好的记忆系统会让 token 变多还是变少？答案是不一定。有些时候确实会变少。比如记忆已经存了你问过的问题，或者你在咨询问题时直接告诉你答案，这绝对是减少 token 的，因为它帮你省去了代码翻阅或整理的过程。但还有一些场景，比如让他完成一个任务，他直接只写了一个后端代码就结束了——任务完成得不好。如果加了记忆，他写了前端代码、后端代码，还加了测试，任务质量变好了，但 token 变多了。所以在编码场景，没法简单地通过平行对比 token 的多少来判断记忆系统好不好。必须找到具体的、可比的场景去做对比。这是我们评估的原则，也是线上评估的核心方法论。
探索发展方向
去年这个时候聊记忆的人还比较少，今年大家就都开始聊了，随着大家对记忆系统关注度的提升，发展速度会越来越快，因为关注本身就会推动它往前走。我对未来方向有几个判断。
第一个方向是双轮闭环驱动的系统进化。生成、整理、检索、反思这个闭环，都是在让记忆资产的质量变好。但记忆质量这次变好了，下次还可能变坏，因为记忆系统本身也面临问题。所以需要通过元记忆的管控，让所有策略可升级。生成策略、检索策略、系统提示词——包括记忆提取的系统提示词——都要有能力进化。如果发现某一次某个记忆质量变差了，要能反思是不是提示词哪里写错了，去修改它，让它变得更好。这样整个记忆系统的能力才会持续提升。就像有的人记东西特别快，是因为他的记忆系统本身进化了，而不是记了一个什么特定质量的记忆。所以我期望可以通过双轮闭环：一轮作用于记忆资产的质量，一轮作用于记忆系统本身的能力，来快速让整个 Agent 进化。还要强调一点，进化方向是因用户而异的。Qoder 记忆系统对每个用户的表现是不一样的。有的用户希望在某些方向记得更好，不同场景有不同的进化方向，这个方向最终由用户的评价和任务来决定。
第二个判断是专家团模式带来的记忆分化。我们最近在刷专家团模式时发现，很多任务以前要自己考虑前端怎么开发、后端怎么开发、怎么测试，现在一个需求提出来，专家团就自己分配一堆任务给所有角色去完成。为什么专家团更强？因为团队由多个不同角色组成，每个角色有自己的特长，角色的组合让整个团队变强。但更重要的是，每个角色关注的事情不一样，该记的东西也不一样。比如团里有个 leader 不干活，只做任务分配。它要记住的是用户偏好、怎么拆解任务、拆分成什么子任务分配给什么子 Agent 。它要记的东西集中在任务拆解和分配技能上。而前端开发角色要记的是 UI 设计相关的技能。不同角色记不同东西，这是一个很值得探索的方向。
第三个判断是记忆共享。我觉得以后每一个人时时刻刻都会有 Agent 在自己身旁，但你不会想去调教每一个 Agent 。现在有一个很奇怪的现象：我们发现人在学习怎么用 Agent 。这很不对劲—— Agent 都出来了，你还让我学什么？你服务好我就行了。如果 Agent 学会了服务你，那你肯定希望在任何时间、任何场地都跟同一个 Agent 说话。这就需要在任何端都能跟同一个 Agent 对话，而实现这个的基础就是记忆同步。记忆只有同步了，你在手机上跟它聊天的体验和在工作站上跟它聊天的体验才是一致的，它才真正是你那个熟悉的 Agent 。
最后一个思考关乎更长远的竞争力。现在大模型发展快、训练强，所有通用知识是不是会全部被模型吃掉？吃完之后，个人和公司的竞争力在哪儿？我的答案是记忆。 Agent 存储的记忆，是某个人更好的经验或私有化的东西，这有价值。通用知识未来可能没有价值。对于公司来说，如果一个团队有一个很牛的人，他的经验可以被 Agent 分析、分解，给到公司所有 Agent 使用。我们现在做了一个 team 版本，所有记忆只要表现好，就会被提取成知识给公司所有 Agent 共享。这样一个人的经验能让整个公司变强。
我觉得可能以后工作方式会发生根本变化。我现在基本每天都在跟 Agent 聊天。以后可能还是跟它聊天——但跟一个有记忆的 Agent 聊天，他基于历史记忆帮我创建一个产品。到那时候，我甚至都可能不愿意关注产品本身了，我只需要跟它聊天就行了。在这种模式里，人的核心价值可能在于提出好问题，做出有价值判断的决策。这对个人来说是比较重要的能力。前两天有人在群里把这种能力叫"品味"，不知道这个词准不准确，但我感觉个人确实需要发展这方面的技能。
作者介绍
王世杰，阿里云技术专家，Qoder 记忆系统负责人，持续深耕记忆领域。致力于创造可自进化的 Agent ，越来越强，越来越懂用户，让创造力变成现实。 曾就职于网易、蚂蚁、阿里云，有丰富的产品和平台开发经验，涉及电商、保险、交通等多个行业。
会议推荐
AICon 全球人工智能开发与应用大会·深圳站，限时 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。
