智能体记忆设计：存取、过期与删除

Agent 能记住你的写作偏好，不代表模型在两次请求之间自动保留了记忆。它背后通常是应用在保存数据、筛选信息，再把相关内容放进下一次请求的上下文。该存什么、什么时候取、过期后怎么办，都需要开发者设计。

这篇文章的主张很明确：可靠的记忆来自有选择的保存和检索。它没有给出性能实验或框架选型对比，但梳理了一组实用的工程边界。对正在给 AI 应用增加历史会话、用户偏好或项目知识的程序员，这些边界比先选一个向量数据库更有用。

先分清四类信息，再决定怎么存

作者把 Agent 使用的信息分成四类。它们可以同时存在，但用途不同。

第一类是工作记忆，即当前任务需要的上下文，包括最近的消息、工具结果和用户约束。任务结束后，其中不少内容就失去了价值，没必要全部转成长期记录。

第二类是会话历史。完整聊天记录适合展示、审计和追溯，却未必适合整段塞给模型。历史里既有已经失效的要求，也有重复讨论和无关插曲。保存了记录，不代表每次请求都应该读取全部记录。

第三类是长期事实与偏好，例如用户选择的时区、写作语气和项目名称。这些信息能跨会话复用，但需要维护，也需要允许用户修改。

第四类是外部知识，包括文档、产品目录和项目记录。它们通常应留在原有业务系统或知识库里，需要时再检索。把文档内容复制进用户档案，会让数据归属和更新关系变得混乱。

保存历史是为了留下记录，构建记忆是为了改善后续任务。

决定是否长期保存前，作者提出四个问题：以后还会用到吗，信息足够稳定吗，是否敏感，用户能否理解并控制这条记录。临时截止日期和长期语言偏好，显然不该采用同一种保留策略。

过期也应成为正常流程。项目关闭后清理相关期限，临时偏好到期后停止使用，可以减少旧信息悄悄干扰新任务的机会。

用户偏好可以很小，但覆盖关系必须明确

文章用写作助手说明：与其每次重放所有聊天，不如保存一个小型、可编辑的偏好记录。

下面这段代码展示了偏好如何进入当前请求，代码按原文保留：

from dataclasses import dataclass

@dataclass
class WritingPreferences:
    tone: str = "professional and friendly"
    length: str = "concise"
    include_headings: bool = True
    include_examples_for_technical_topics: bool = True

def build_article_context(preferences: WritingPreferences, request: str) -> str:
    """Combine durable preferences with the user's current request."""
    headings = "Use clear headings." if preferences.include_headings else ""
    examples = (
        "Add practical examples for technical topics."
        if preferences.include_examples_for_technical_topics else ""
    )
    return f"Default tone: {preferences.tone}. {headings} {examples}\nCurrent request: {request}"

要看最后一行：它把默认语气与当前请求放到一起。但这段示例没有明确编码冲突处理规则，而且 length 虽然定义了，实际没有进入生成的上下文。因此，它能解释数据结构，不能直接当成完整实现。

作者补充的行为规则才是重点：用户平时喜欢简洁，这次要求详细展开，就应该遵循这次的要求。长期偏好提供默认值，当前请求可以覆盖它。

真实应用还需要把偏好关联到账户标识，落到数据库，并执行授权检查。代码里的 WritingPreferences 没有覆盖这些部分。

另一个容易踩坑的地方是把推断当事实。用户连续几次要求短回答，并不一定代表他永远偏好短回答。对于推断出来的偏好，作者建议在有必要时保存来源和置信度，或者先向用户确认，再变成长期档案。

这也是摘要需要保留不确定性的原因。「用户考虑蓝色方案」不能被压缩成「用户选择了蓝色方案」。少几个字，可能就把讨论变成了决定。

检索、权限与删除，决定记忆是否可靠

存下来只是开始。检索错误，同样会让回答跑偏。

作者给出的检索流程是：先判断当前任务需要哪类信息，再搜索对应存储，按用户、项目和权限过滤，结合相关性与时间排序，最后只放入少量有用内容，并说明这些内容的来源和用途。

这里没有要求所有信息都经过向量搜索。

写作语气、计量单位等结构化偏好，直接按用户 ID 查询即可。大量非结构化文档适合语义检索，再结合所有者、日期、项目和访问级别等元数据缩小范围。精确标识符、日期、金额和状态值，则应查询权威数据源。

向量搜索擅长找到语义相关的文字，却不能保证拿到当前有效的精确值。文章以账户余额为例：能查询安全的金融服务时，就不该依赖过去记下的余额。

权限也必须在检索层执行。漏掉用户或租户过滤条件，可能把别人的数据送进上下文。提示词里写一句「不要泄露其他用户信息」，无法替代查询时的授权检查。

检索内容可以提供信息，不能因为被取回来就获得指挥 Agent 的权限。

系统与开发者指令定义行为，当前用户请求表达任务，记忆和文档提供参考资料。外部网页、上传文件或团队文档里即使出现「忽略之前规则」，也不应因此覆盖应用指令。这是记忆系统需要处理的提示注入问题。

长会话摘要同样属于需要核查的资料。作者建议摘要保留目标、已确认决定、偏好、未解决问题、重要约束、待复查来源和最后更新时间，并尽量关联原始消息。涉及精确金额、日期或批准记录时，应回到来源验证。

删除还要沿着数据流继续处理。只删原始记录，却留下派生摘要或索引，旧信息仍可能再次出现。用户要求忘记某件事时，需要检查所有仍会参与检索的相关存储。

我的判断

这篇文章最有价值的地方，是把记忆放回普通软件工程的范围：它需要明确的数据归属、查询方式、生命周期和修改入口。对只有少量用户偏好的应用，先用普通数据库保存结构化字段，比一开始搭建向量检索链路更容易检查和维护。等到确实要搜索大量非结构化内容，再增加语义检索，理由更充分。

但原文是一份设计指南，没有提供实际团队的上线结果，也没有给出准确率、成本、延迟或用户满意度的对照数据。它关于选择性保存的建议有工程合理性，收益大小仍属于未经本文验证的判断。

几个关键参数也没有说清：检索多少条算合适，相关性与新鲜度如何平衡，摘要多久更新，推断偏好达到什么置信度才保存。一般团队仍需根据自己的任务评估，不能从这些原则直接推导出一套通用配置。

「当前输入覆盖旧偏好」也有适用范围。它解决的是偏好冲突，不能顺带覆盖访问权限或应用规则。文章已经区分了指令与资料，落地时需要把这层边界表达清楚。

作者提出的评估方式值得采用：构造应该保存、不该保存、后来改变以及要求删除的信息，检查后续检索、覆盖关系、来源归属和跨用户隔离。评价记忆质量，应该看它是否在正确场景使用了正确内容，而不是档案里累计了多少条记录。

能拿来做什么

• 给 AI 写作或编程助手增加偏好时，先挑少量明确字段，例如回复语言、详细程度和是否需要示例，并提供查看、修改和删除入口。把当前任务的临时要求与长期默认值分开处理。
• 在 Node 服务里组织检索逻辑时，先执行用户、租户和项目的权限过滤，再向模型提供结果；对精确状态查询，直接读取负责维护该状态的业务系统。
• 压缩长会话时，把已确认决定、待确认想法和未解决问题分别记录，并保存来源引用，避免把「考虑采用某方案」压缩成「已经批准」。
• 为记忆功能准备覆盖信息变更与遗忘的测试对话，同时检查原始记录、摘要和索引。验收时既要确认该记住的内容能找回，也要确认无关内容和已删除内容不会再次出现。