智能AI
evening
让 Coding Agent 「开始记住过去」:MemoraX Code 的长期记忆系统
摘要
机器之心发布 过去一年,Coding Agent 正在迅速改变开发者写代码的方式。 Claude Code、Codex 已经可以理解代码库、定位 Bug、跨文件修改代码、运行测试,甚至独立完成复杂开发任务。 它们越来越像一群真正参与项目的工程师。 但只要进入长期开发,一个反常的问题很快就会出现: Agent 越来越会写代码了,却还是常常像第一次来到这个项目。 比如,一个开发者刚刚和 Codex 完...
Agent
Memory
Code
Codex
Coding
Claude
MemoraX
这正是
机器之心发布
过去一年
2026-08-18
1 阅读
约10分钟阅读
机器之心
字号:
机器之心发布 过去一年,Coding Agent 正在迅速改变开发者写代码的方式。 Claude Code、Codex 已经可以理解代码库、定位 Bug、跨文件修改代码、运行测试,甚至独立完成复杂开发任务。 它们越来越像一群真正参与项目的工程师。 但只要进入长期开发,一个反常的问题很快就会出现: Agent 越来越会写代码了,却还是常常像第一次来到这个项目。 比如,一个开发者刚刚和 Codex 完成了一次权限系统改造。 在几轮协作中,Agent 已经知道:为什么项目采用现在的权限架构,哪些历史代码不能轻易修改,哪个方案此前已经尝试过但因为兼容性问题被放弃,修改数据库时又必须保证旧版本平滑升级。 这些都不是简单读一遍代码就能获得的信息,而是一次真实开发留下来的 项目经验 。 问题是 —— 第二天呢? 重新打开一个对话,Agent 可能又开始扫描同样的代码;昨天已经解释过的背景需要重新说明,失败过的方案可能再次被提出,刚排查完的问题也可能重新调查一遍。 对话足够长、早期信息被压缩时如此,从 Codex 换到 Claude Code 时也是如此。 于是,我们拥有了越来越聪明的 Coding Agent,却依然在反复做一件事情: 让它重新认识同一个项目。 当 Coding Agent 从一次性的编程工具走向长期协作者,它需要的不只是更大的上下文窗口,还需要一种持续积累的能力 —— 知道什么值得留下,也知道什么时候应该再次想起。 这正是 MemoraX Code 想解决的问题。 第二天回来,它还知道昨天发生了什么 如果 Agent 真正拥有长期记忆,最直接的变化不是多了一个 “Memory” 按钮,而是很多原本需要重复解释的事情开始消失。 前一天,开发者和 Codex 完成一个任务,并在过程中形成了一些关于项目的经验。 第二天重新打开一个全新的对话,开发者没有复制昨天的聊天记录,也没有再次解释完整的项目背景。 但当新任务再次涉及相关模块时,过去积累的经验会重新进入当前工作,并继续影响 Agent 的判断。 新对话,项目经验没有归零。 新对话自动使用上一轮任务形成的 Memory 这种连续性也不需要绑定某一个 Agent。 开发者可以在 Codex 中完成一个任务,再切换到 Claude Code 处理另一个问题。此前已经形成的项目认知仍然可以继续发挥作用。 Agent 换了,项目记忆还在。 Codex 中形成 Memory,Claude Code 在后续任务中直接使用 即使始终使用同一个 Agent,长任务中的对话也不可避免地会被整理和压缩 —— 这是 compaction 在真实系统中的常态。 但问题在于:被压缩掉的内容里,往往混着两类信息。 一类是无关细节,比如中间的无效尝试、调试输出或重复解释;另一类则是关键经验,例如 “修改该模块必须兼容旧版本数据库” 这样的约束,可能只出现过一次,却会在后续重构中起决定作用。 Compaction 解决的是 “如何不丢上下文”,但并不保证 “哪些经验应该被保留”。 这正是 MemoraX Code 试图补上的部分:让被压缩进历史中的关键信息,在后续任务中仍能被识别、提取,并在合适时机重新进入上下文。 被压缩的关键信息在新任务中被重新召回 长期记忆并不是试图永久保存每一句对话。 恰恰相反,它真正需要解决的是: 从持续发生的开发过程中,留下那些未来仍然值得被想起的东西。 Memory 不只是记住,更要学会怎么记 看到这里,一个自然的问题是:Agent 本身已经能保存历史对话,也能一次处理越来越多的信息,为什么还需要独立的 Memory? 因为真正困难的,并不是把更多历史保存下来,而是判断: 什么值得记住,什么已经过时,以及什么时候应该重新想起来。 MemoraX Code 为此构建了本地代码仓记忆与云端长期记忆:前者帮助 Agent 快速理解代码仓当前的结构、关键入口和历史演进;后者则持续承载跨任务、跨对话、跨 Agent 的项目经验和开发者习惯。 当新的任务到来时,系统不会把全部历史重新塞给模型,而是只找回当前真正相关的信息。 但我们认为,这仍然不是 Coding Memory 的终点。 今天很多 Memory 系统仍然高度依赖人工规则:工程师通过提示词和预先设计的策略,规定什么应该写入、如何整理、什么时候召回。 MemoraX Code 希望进一步把这些判断变成一种 可以通过训练持续提升的能力 。 围绕 Coding 场景,我们构造专门的记忆训练任务和长程开发轨迹,并建立针对 Memory 的评估与奖励机制。系统不仅判断 “一条信息有没有被记下来”,还会进一步学习: 它是否真的在后续任务中帮助 Agent 做出了更好的决策? 基于这些训练信号,Memory Model 可以持续学习 什 么值得写入、什么应该更新、哪些经验应该被提炼,以及在什么任务中应该重新出现。 支撑这一过程的,则是一套用来训练和测试 Agent 的基础系统,包括运行环境、任务执行、反馈打分、效果评估和分布式训练等能力。在架构设计上,这套训练体系与用户的私有记忆数据相隔离。可学习的 Memory 能力通过专门构造的训练与评测体系不断演进,再以更强的模型能力服务线上系统。 我们希望让 Memory 从规则驱动,逐渐走向数据与奖励驱动 —— 让 Agent 不仅拥有记忆,还能不断学会怎样更好地记。 Memory 到底有没有 让 Coding Agent 变得更好? 要判断 Memory 有没有真正让 Coding Agent 变得更好,最直接的方法,就是把它放进标准化的 Coding Memory Benchmark 里测试。 MemoraX 首先在近期受到高度关注的赛事 AML(Agent Memory Leaderboard)的 Coding Track 上,取得了 62分 的成绩,位列 第一 ,相 比较业界主流方案 Claude Mem 解题率提升 10% 。 除了 Benchmark 测评外,我们还想进一步回答一个问题: 过去完成过的开发任务,能不能被自 动沉 淀 成下一次可以复用的工程经验? 从 “记住发生过什么”,到 “学会下一次怎么做” 为此,MemoraX Code 支持 Procedure Memory 的自动化构建 。 它可以从历史 Coding 轨迹中,自动识别具有复用价值的解决过程,把一次任务里零散的分析、执行和验证步骤进一步提炼成结构化的工程经验,并最终以 Skill 的形式沉淀下来,供后续类似任务直接使用。 在一组实验中,MemoraX Code 从 123 个历史任务片段 中自动提炼出 15 条工程经验 ,进一步归纳为 4 类 Procedure Memory 。 Procedure Memory 自动提炼 这里留下来的不再只是: “上一次发生了什么。” 而是进一步提炼: 面对这一类工程问题,过去哪些分析方式、执行步骤和验证方法被证明是有效的。 这也是我们理解的 Memory 从 “记录历史” 走向 “从历史中学习”。 学到的经验,能不能真的帮助下一次任务? 真正的验证发生在下一步。 我们把这些自动提炼出的 Procedure Memory,用到了一个新的、持续
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱