整理自公开社区讨论，重新表述为中文问题。
我在做 AI 编程助手，发现大家一提“长期记忆”，很容易直接落到“把历史对话 embedding 之后丢进向量库”。
但在真实工程里，我越来越怀疑这件事没那么简单，所以想请教：
- 对 coding agent 来说，长期记忆为什么不能只等同于向量检索？
- 哪些信息适合存成自由文本，哪些更应该存成结构化状态？
- 如果记忆会跨 session 持续生效，provenance、删除、更新、过期这些能力是不是必须前置？
- 在 Claude Code、Codex 这类工具链里，memory 文件、项目规则、向量召回三者应该怎么配合？
回答
如果只把“长期记忆”理解成向量库，通常只能解决找回来的问题，解决不了能不能信、该不该用、什么时候失效的问题。
我更认可把 coding agent memory 分成四层：
-
规则层：长期稳定的项目约束，例如代码风格、架构边界、禁止事项。这个更适合放在 AGENTS.md / 规则文件里，而不是混进普通记忆。
-
事实层：相对客观、会变化但可验证的信息，例如“服务 A 依赖服务 B”“测试环境入口是什么”。这类信息需要来源、时间戳和更新机制。
-
决策层：为什么采用某个方案、拒绝了哪些替代方案。这类内容对减少重复讨论很重要，但必须保留上下文和出处。
-
进行中状态层：当前任务做到哪一步、下次继续要看什么。这更像 checkpoint，不像知识库。
为什么不能只做向量库：
- 向量召回不天然区分“过时事实”和“当前事实”
- 很难表达删除、冲突解决和优先级
- 安全上有风险，错误写入会污染以后每次会话
- 对 coding agent 来说，很多关键状态并不是“最相似文本”问题，而是“当前真值”问题
务实做法通常是：
- 用规则文件承载硬约束
- 用结构化索引承载当前状态与来源
- 用向量检索补自由文本背景
- 在真正注入模型前再做一次筛选和权限判断
所以长期记忆不是“再加一个向量库”，而是“给可持久上下文补治理能力”。
评论
💬
还没有评论
欢迎留下第一条评论，帮助这篇内容更快形成讨论。