在 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读取触发要绑到动作上而不是绑到关键词上准备新增文件、准备改构建脚本、准备执行测试、准备提交代码这几个时机各查一次对应类型即可。查询结果只注入少量条目避免把上下文塞满。下面是通用接入骨架不依赖具体 SDKdef build_context(task, store): signals [task.language, task.paths, task.intent] hits store.query(signals, types[convention, command], limit3) return [m.rule for m in hits if m.status active]写入方式可以先从手工维护一份 markdown 或 yaml 开始确认命中情况后再考虑自动抽取。自动抽取的风险是把一次性结论固化下来通常需要保留人工确认这一步。接入后逐项对照是否还会重复问验证不要看“感觉变好”要按问题类型逐项对照。每次会话结束后记录该类问题是否再次被问、是否命中记忆、没命中的原因是什么。可以先用下面的表结构出现次数按你自己的观察窗口填写问题类型窗口内出现次数命中记忆次数仍重复的表现未命中原因目录约定待填待填待填触发时机未覆盖命令用法待填待填待填scope 路径写窄代码风格待填待填待填条目过泛未被采用技术栈版本待填待填待填条目过期或与脚手架冲突常见的未命中原因有几类触发时机没覆盖例如只在新增加文件时查、删除或移动文件时没查scope 路径写得太窄任务落在别的目录条目没有过期策略旧约定一直命中两条记忆互相矛盾记忆写得太泛模型看到了也没采用。连续两个观察窗口都仍然重复的回到上一节改触发条件或颗粒度已经不重复的考虑是否还需要继续保留这条记忆。保留一份问题优先级调整记录记忆库需要一份单独的调整记录写清每次改动针对哪类问题、依据是什么。新增的依据通常是多任务重复出现且现有条目未覆盖降级的依据通常是条目存在但命中后仍反复解释说明表述不清或场景不匹配删除的依据通常是目录重构、命令废弃、约定被脚手架取代或该问题已不再出现。记录格式可以很短一行一条但要能和记忆条目 id 对上# 调整记录示例结构 新增 | 命令用法 | 多任务反复问测试脚本原条目只覆盖构建 | id: cmd-test-run 降级 | 代码风格 | 命中后仍需人工解释改由 lint 承担 | id: style-naming 删除 | 目录约定 | 目录已重构原路径约定失效 | id: dir-convention-api调整记录要同时保留原因避免过一段时间没人敢删。定期回看这份记录通常比继续往库里堆条目更有价值。