传统编程助手的一个明显短板是健忘：同一个会话里你反复解释过的项目结构、命名规范，换个会话就全部归零。MiMo Code Memory Agent（其核心框架常被简称为MiCoMe）针对这个问题提出了完整的记忆演进方案，让智能体在持续交互中不断积累、压缩和重组项目知识，最终形成一份可长期维护的代码记忆库。本文从架构设计、记忆生命周期和工程实践三个层面展开分析。
一、分层记忆架构：为什么记忆必须分层而不是一张大表
MiCoMe将智能体的记忆划分为三个层次：会话内短期记忆、跨会话工作记忆和持久化项目记忆。短期记忆保存当前对话的上下文窗口，生命周期以会话为单位；工作记忆保存最近若干次会话中被高频引用的实体，例如核心模块路径、关键函数签名；持久化记忆则是一个结构化知识库，存储项目骨架、依赖关系、历史决策等长期有效的信息。
之所以要分层，直接原因是检索成本和噪声控制。如果把所有历史信息塞进同一个向量库，检索时大量过期的会话碎片会稀释真正有用的项目级事实。分层之后，检索请求先路由到工作记忆，命中则直接返回；未命中再降级到持久层，同时附带一次记忆晋升判断——某条信息被频繁命中时，会被提升到更上层以加速后续访问。这个思路和操作系统的高速缓存层级非常相似，本质是用空间换时间的工程取舍。
每一层的数据形态也不同。短期记忆是原始文本片段，工作记忆是带嵌入向量的键值对，持久层则是以代码实体为节点的图结构，节点上挂载摘要、修改历史和置信度分数。图结构的优势在于能自然表达模块间依赖，回答诸如某个函数被哪些地方调用这类问题时，不需要依赖大模型的模糊推理，直接沿边遍历即可，准确率明显更高。
二、记忆演进的核心流程：写入、压缩、合并与淘汰
记忆演进并不是简单的追加写入，而是一个持续的信息加工过程。每当一次会话结束，后台的记忆管理器会执行四步操作：抽取候选事实、生成摘要压缩、与既有记忆合并、淘汰过期条目。下面用一个简化的Python伪代码展示这一流程的关键环节。
class MemoryEvolver:
def on_session_end(self, session_log):
# 第一步：从会话日志中抽取候选事实
facts = self.extractor.extract(session_log)
# 第二步：对冗长片段做摘要压缩，控制单条记忆体积
for fact in facts:
fact.summary = self.summarizer.compress(fact.content, max_tokens=256)
# 第三步：与既有记忆合并，冲突时按置信度和时间戳裁决
for fact in facts:
self.merge(fact)
# 第四步：清理低置信度且长期未命中的条目
self.evict(threshold=0.35, stale_days=30)
def merge(self, fact):
existing = self.store.lookup(fact.entity_id)
if existing is None:
self.store.insert(fact)
return
if fact.confidence > existing.confidence:
# 新信息置信度更高，保留旧版本到历史链以支持回滚
fact.history = existing.history + [existing]
self.store.update(fact.entity_id, fact)
else:
# 否则只做增量补充，避免覆盖正确记忆
existing.addons.append(fact)
摘要压缩这一步值得单独说明。原始会话片段往往包含大量寒暄、试错过程和重复内容，直接入库会让记忆库快速膨胀。MiCoMe的做法是用小参数量模型先做事实抽取，再用摘要模型压缩到固定token预算内，并且要求摘要保留可验证要素：文件路径、函数签名、版本号。这些要素在后续检索时会被当作硬约束过滤条件，保证召回的记忆不会张冠李戴。
合并环节的冲突裁决是记忆演进中最微妙的部分。同一个实体在不同会话中可能产生矛盾描述，比如某接口的返回类型从字典改成了dataclass。MiCoMe的策略是置信度优先、时间戳辅助：置信度由信息来源决定，来自用户明确声明的信息置信度最高，来自代码库静态分析次之，来自模型推断的最低。同时所有被覆盖的旧版本不会删除，而是挂到历史链上，这样当用户发现新信息有误时可以快速回滚到先前版本，避免记忆污染不可逆。
三、检索增强与记忆策略对比：演进效果如何评估
记忆存下来的价值最终体现在检索质量上。MiCoMe采用混合检索：先做向量相似度召回top-k候选，再用BM25关键词匹配补充精确命中的条目（例如用户直接提到某个文件名时），最后经过一个轻量级重排序模型融合两路结果。实测中混合检索比纯向量检索在代码补全场景下的首条命中率提升约百分之十五，主要收益来自路径名、函数名这类符号精确匹配场景。
评估记忆演进是否有效，MiCoMe设计了三个指标：记忆命中率（检索返回的记忆中被实际采用的占比）、记忆新鲜度（采用的记忆距离最近一次更新的平均时间）、以及重复解释率（用户需要重复说明同一事实的频率）。在开源代码仓库的长周期维护任务上，随着记忆条目从零增长到数百条，重复解释率持续下降，说明演进机制确实在把会话经验转化为可复用资产。但记忆规模超过一定阈值后，命中率会出现平台期，此时需要依赖淘汰机制裁剪长期未命中的条目来维持检索精度。
与常见方案的对比也能说明问题。朴素的RAG方案每次都从固定文档库检索，没有演进能力；全量上下文方案把整个历史塞进长窗口，成本随对话轮次线性上涨且容易被无关内容干扰。MiCoMe的记忆演进方案处于两者之间，用适度的后台加工成本换取检索精度和上下文成本的双重优化，特别适合需要长期维护同一代码库的团队场景。
四、工程实践建议
如果要在自己的智能体中落地类似机制，建议先从工作记忆这一层做起，实现成本最低，收益立竿见影。持久层图结构可以在项目复杂度上来之后再引入。此外要特别注意摘要压缩的token预算控制，预算过大记忆库膨胀快，预算过小会丢失关键细节，实践中两百到三百token是比较稳妥的区间。最后，务必保留记忆的版本历史与人工修正入口，自动演进再聪明也难免出错，可回滚、可干预才是一个生产级记忆系统应有的形态。