在 MemoraX Code 这类编码 Agent 上接长期记忆，最先该解决的通常不是“所有重复提问”，而是跨会话稳定复现的那几类：技术栈与版本约束、目录与分层约定、命令与脚本用法、代码风格与命名。判断优先级的方法很直接——看最近若干次会话里，同一类问题是否由不同任务、不同时间反复触发，且答案本身不随分支或本地环境变化。满足这两点的，先写进记忆；只在某次报错排查里出现过一次的，先别放。下面按统计、筛选、写入、验证、调整五个动作展开，每一步都能用会话日志、项目配置或页面行为核对，不依赖对记忆效果的估算。

想把长期记忆加在关键处，适用场景是“重复问题很多、但不确定先做哪个”。操作动作是先按技术栈、目录约定、命令用法、代码风格四类统计最近会话，再按稳定、可复用、能一句话说清、跨会话可命中来筛选，最后做接入前后对照。验证方式是对比会话日志与记忆条目命中记录。风险边界：记忆会过期、会与脚手架冲突、会挤占上下文，所以要限量、可删除、可降级。

统计最近会话里重复出现的问题类型

先别急着设计记忆结构，先把重复问题数出来。按四类分类计数：技术栈（语言、框架、运行时版本、依赖取舍）、目录约定（新建文件放哪、分层边界、目录命名）、命令用法（安装、构建、测试、lint、迁移脚本及其参数）、代码风格（命名、导入顺序、错误处理、提交信息格式）。统计窗口取最近一个功能迭代周期即可，窗口太长会把已经废弃的约定混进来。

如果会话有落盘结构，先用关键词粗筛，再回读上下文确认，别只依赖关键词命中。下面只是命令骨架，路径与字段要按你自己的会话存储替换：

# 假设每行一条会话记录，字段名按实际结构改
grep -h 'user' ~/.agent/sessions/*.jsonl \
  | grep -E '哪个目录|放哪|怎么跑|用什么版本|怎么命名|格式化|构建' \
  | sed -E 's/.*text: *(.{0,50}).*/\1/' \
  | sort | uniq -c | sort -rn | head -40

计数时不要只看总次数，还要看来源任务数：同一个任务里反复追问同一件事，多半是提问表达或上下文不足；多个任务都在问，才是长期记忆的候选。结果先记成四列：类别、问题描述、出现次数、涉及任务数。

判断哪些重复问题适合交给长期记忆

适合的记忆对象一般满足四个条件：答案稳定，不随分支和本地环境变化；跨会话复用，不是单次调试；能用一条规则或一个命令写清；命中后不需要再读大量上下文。例如“新增页面组件放 src/pages 还是 src/views”“测试跑哪个脚本”“提交信息用哪种前缀”，都符合。

不适合的先排除：一次性报错排查（堆栈、依赖冲突、环境变量缺失），答案和当天环境强绑定；频繁变动的依赖版本号，写进记忆容易过期；涉及密钥、内网地址、个人 token 的内容，不该进记忆库；项目脚手架已经强制固化的约定，例如 lint 能自动报错的，交给工具比交给记忆更可靠。

设计每类问题的记忆内容与读取方式

颗粒度建议一条记忆只回答一件事，标题写明类别，正文给规则加一个最小示例。太粗的记忆（例如“遵守项目规范”）几乎不会命中，太细的记忆（例如某个函数的具体实现）又会被频繁改写。下面是一个通用条目骨架，字段名按你自己的存储替换，不要当成某个产品的接口定义：

id: dir-convention-api
type: convention          # convention | command | style | stack
scope: ['src/api/**']
rule: '新增接口文件放 src/api/<domain>/<action>.ts，业务逻辑放 src/service。'
trigger: ['新增文件', '新建模块', '接口放哪']
ttl: null                 # 稳定约定不过期，版本类才设过期
status: active

读取触发要绑到动作上，而不是绑到关键词上：准备新增文件、准备改构建脚本、准备执行测试、准备提交代码，这几个时机各查一次对应类型即可。查询结果只注入少量条目，避免把上下文塞满。下面是通用接入骨架，不依赖具体 SDK：

def build_context(task, store):
    signals = [task.language, task.paths, task.intent]
    hits = store.query(signals, types=['convention', 'command'], limit=3)
    return [m.rule for m in hits if m.status == 'active']

写入方式可以先从手工维护一份 markdown 或 yaml 开始，确认命中情况后再考虑自动抽取。自动抽取的风险是把一次性结论固化下来，通常需要保留人工确认这一步。

接入后逐项对照是否还会重复问

验证不要看“感觉变好”，要按问题类型逐项对照。每次会话结束后，记录该类问题是否再次被问、是否命中记忆、没命中的原因是什么。可以先用下面的表结构，出现次数按你自己的观察窗口填写：

常见的未命中原因有几类：触发时机没覆盖，例如只在新增加文件时查、删除或移动文件时没查；scope 路径写得太窄，任务落在别的目录；条目没有过期策略，旧约定一直命中；两条记忆互相矛盾；记忆写得太泛，模型看到了也没采用。连续两个观察窗口都仍然重复的，回到上一节改触发条件或颗粒度；已经不重复的，考虑是否还需要继续保留这条记忆。

保留一份问题优先级调整记录

记忆库需要一份单独的调整记录，写清每次改动针对哪类问题、依据是什么。新增的依据通常是：多任务重复出现且现有条目未覆盖；降级的依据通常是：条目存在但命中后仍反复解释，说明表述不清或场景不匹配；删除的依据通常是：目录重构、命令废弃、约定被脚手架取代，或该问题已不再出现。

记录格式可以很短，一行一条，但要能和记忆条目 id 对上：

# 调整记录示例结构
新增 | 命令用法 | 多任务反复问测试脚本，原条目只覆盖构建 | id: cmd-test-run
降级 | 代码风格 | 命中后仍需人工解释，改由 lint 承担       | id: style-naming
删除 | 目录约定 | 目录已重构，原路径约定失效               | id: dir-convention-api

调整记录要同时保留原因，避免过一段时间没人敢删。定期回看这份记录，通常比继续往库里堆条目更有价值。