智能体记忆应拆成三类工程问题

给 AI Agent 加记忆，先得回答：它要记住当前对话、过去某次交流，还是今后都要遵守的偏好？原文把这三件事拆成了三种工程问题，核心判断是：它们需要不同的处理方式，一个向量数据库解决不了全部需求。

这篇短文的价值在于帮开发者划清需求边界。不过，标题里的「Actually Work」并没有实验数据支撑。作者给出的是设计思路，没有展示实现代码、效果评估或团队实践过程。

当前对话里的记忆，先管好上下文

会话记忆（Session Memory）解决的是：同一轮对话中，Agent 能否记住前面发生过什么。

比如你先让它调整组件布局，随后补充「保留刚才的配色」。只要前面的内容仍在模型可见的上下文里，就具备继续处理的条件。原文给出的做法很直接：管理上下文窗口，对话太长时进行摘要。

这里的「记住」，依赖的是本次请求提供给模型的信息。摘要可以压缩历史，但作者没有解释怎样选择保留内容，也没有讨论摘要遗漏约束的问题。

当前对话能接上话，不代表跨会话也能记住你。

跨会话找旧事，需要记录和检索

情景记忆（Episodic Memory）处理的是具体的历史事件，例如「上次讨论 X 时，你说过 Y」。

作者建议保存过去会话的结构化记录，在新会话开始时，通过相似度或元数据检索相关内容。可以把它理解成查工作记录：先找到对应的那次交流，再把内容交给 Agent 使用。

相似度负责寻找语义相关的内容，元数据则提供另一种筛选依据。原文没有给出记录结构、检索数量或排序策略，也没有指定必须使用某款数据库。

因此，这里能拿走的是「存储加检索」的处理路径，不能据此判断具体方案的召回效果。

长期偏好为什么不能只靠向量检索

习得偏好（Learned Preferences）要保存的是持续生效的事实或规则，而非某次交流的经过。

例如，「上次生成过 TypeScript 代码」是一条历史事件；「以后代码示例默认使用 TypeScript」才是一项长期偏好。两者可能来自同一段对话，后续用途却不同。

原文主张主动写入并维护结构化档案。检索解决「找回什么」，档案维护还要决定「哪些信息应该继续生效」。作者认为，许多 AI 记忆产品承诺的正是这一层能力，它需要刻意设计，不能只接一个向量数据库。

但怎样识别偏好、何时更新或删除，原文都没展开。

我的判断

我赞同这种拆分。它能避免把「能找到聊天记录」直接当成「理解用户长期习惯」，也能让开发者先确定验收目标。

局限也很清楚：这是一篇概念短文，作者没有提供对照数据。「长期偏好最难」是其工程判断，不能当作经过验证的效果结论。

和每次手动提供一份固定规则相比，自动维护偏好档案更省输入，却增加了误写和过期信息的处理成本。这是实际落地时需要补上的取舍，原文没有给出答案。

能拿来做什么

• 给 AI 编程助手设计记忆前，先列出它应当记住的具体内容，区分当前修改要求、过去任务记录和长期编码偏好。
• 如果需求只是连续修改同一个组件，可以先做好上下文管理和长对话摘要，再判断是否需要跨会话存储。
• 如果需要找回上次讨论的方案，就保存可检索的会话记录；如果需要持续遵守编码偏好，就单独维护结构化档案，并明确更新方式。