避免记忆滥用：智能体不是无底洞

2025 年 Q3，我们交付的一个客户成功智能体运行到第三个月时，第一次发生了上下文溢出。日志里满屏都是 Token limit exceeded，用户投诉响应速度从一秒跌到了十二秒。排查发现，并非系统吞吐量不够，而是智能体把每一次"你好""在吗""谢谢"都写进了长期记忆。三个月里，它忠实地记住了两万多条无意义对话，导致检索延迟暴增、成本翻了三倍。

这是记忆滥用的典型症状。

在上一章里，我们解决了记忆系统在经济性上的两大难题——如何控制成本、如何提升检索速度。但在这些"花多少钱"和"跑多快"的问题之后，还悬着一个更根本的问题：并非所有信息都值得被记住。当我们为智能体打开了长期记忆的大门，却没有制定准入规则时，记忆系统本身就会蜕变为一项新的技术债务。它不仅会蚕食性能，还会产生"检索噪音"——大量无用信息淹没真正有价值的上下文，让智能体在海量记忆中迷失方向。

本章将回答一个核心问题：何时该让智能体主动遗忘，以及如何设计记忆的准入策略。 我们会从"遗忘机制的设计"切入，看一个因只记不用而引发雪崩效应的真实案例，最后建立一个持续运转的记忆治理机制。

忘记也是一种特性：设计遗忘优先的框架

经验框：先定义生存周期，再考虑存储方案

在我参与的三个 Agent 项目中，最早遇到性能瓶颈的都是"先把所有东西存下来，以后再想要不要删"的团队。这不是技术选型问题，是设计顺序问题——当你把遗忘视为事后补救，记忆系统已经对上下文质量造成了不可逆的损伤。

多数开发者对记忆设计的直觉是"先存下来再说"。这个直觉来自传统软件开发:数据库盘便宜，数据总会有用。但在 AI Agent 的上下文工程中，冗余记忆不是沉积的资产，而是持续消耗算力的活债务——每次检索都要扫过这些数据，每次推理都要为无关信息支付 Token 成本。

让我们来看一组对比:

表格揭示的核心洞察是：遗忘不是设计的缺陷，而是设计的特性。 在记忆系统中，最巧妙的设计不是去想"怎么存"，而是去想"什么不配存"。

从被动遗忘到主动治理

这并非简单的配置参数问题，而是范式转换。我们可以用三层递进来理解：

• 被动遗忘（系统溢出）：依赖上下文窗口的物理限制自动截断。结果是非关键信息可能被保留，而用户三个月前的核心偏好被冲刷掉。这是"让系统替你做决策"，通常是最差的决策。

• 主动遗忘（人工规则）：开发者根据信息类型定义生存周期。例如，"确认订单"的记忆有效期是整个购买流程，流程结束后立即清除。这需要设计者理解业务上下文，但规则是静态的。

• 独立治理（策略分离）：记忆的写入和淘汰由一个跨职能委员会（技术 + 产品 + 运营）定期审查。策略不是一次性写成，而是随着产品演进而调整。这是下一节会详细展开的机制。

核心建议框：为每种信息类型建立"生存周期"（TTL）

在你的记忆 API 中，每一次写入都应该携带一个 expires_at 或 ttl 字段。让"是否记得"从代码层面可执行，而不是存在于文档中的设计原则。LangChain 的 LangMem 库已经支持为记忆消息添加元数据，你可以封装一层 TTLMemoryWrapper，在检索时自动过滤过期信息。

反模式：只记不用的雪崩效应

2025 年 9 月，一个开源的客服 Agent 项目在 GitHub 上引发了讨论。开发者在 Reddit 的 r/LangChain 板块发帖求助:"我们的智能体在运行四个月后，检索速度从 200ms 飙升到了 4 秒，成本从每月 120 美元涨到了 900 美元。"

项目背景并不复杂：一个基于 LangChain 的电商客服智能体，对接了三家店铺的售后系统。架构师在设计之初定义了一条简单规则:"所有用户对话都存入向量数据库，便于未来分析"。

下面是我们对该项目代码库的复盘：

# 反模式代码片段：无鉴别的记忆写入
def store_conversation(user_id, message, response):
    memory = ConversationMemory(
        user_id=user_id,
        content=f"User: {message}\nAssistant: {response}",
        timestamp=datetime.now()
    )
    vector_store.add(memory)  # 无条件写入

这段代码在逻辑上毫无错误，但忽略了两个致命前提:

1. 99% 的对话永不回访
   四个月积累的 14 万条记忆中，真正在后续检索中被命中的仅 1700 条（命中率 1.2%）。其余 98.8% 的记忆不仅存储成本被浪费，更严重的是——它们在每次检索时都会被扫过，拖慢速度。

2. 上下文污染放大延迟
   当用户问"我上次退的那个红色衬衫，能换蓝色的吗？"，检索返回的前 10 条结果里有 7 条是三月前的寒暄记录、点赞表情和已过期的物流查询。真正相关的退货记录排在第 8 位。智能体需要更长的提示词（更多的 Token）去甄别这些噪音，进一步推高了延迟和成本。

这是一个典型的只记不用的雪崩效应：无用记忆的数量一旦越过某个临界点，检索质量会发生非线性的崩溃。不是因为系统不够快，而是因为系统不够"干净"。

从实际项目中汲取的教训

该项目的修复方案花了三周:

• 清理存量的 97% 无用记忆，只保留包含"订单""退款""退货""投诉"等业务关键词的对话
• 重构写入逻辑，引入"重要性评分"——智能体在生成回复的同时，额外判断这条对话是否值得跨会话保留（评分 1-5，低于 3 分的仅活在当前上下文）
• 部署定期巡检脚本，每周自动清理超过 90 天未访问的记忆

效果立竿见影：检索延迟回到 350ms，月度成本降至 180 美元。

不要高估"未来可能用上"的价值。与物理世界的仓储不同，数字记忆的持有成本不是占用多少硬盘，而是占用多少检索时间和上下文空间。这两个资源在 AI Agent 系统中远比存储空间昂贵。

治理委员会：定期审查记忆留存策略

如果说上一节的反模式教会我们"防患于未然"，那么这一节要回答的问题是：即便设计了一个尚可的准入规则，如何保证它在产品演进的六个月后依然有效？

答案是：建立一个跨职能的记忆治理委员会。

这个委员会不负责写代码，而是定期（建议每两周或每月）审查三个核心问题:

我们来看一个具体场景：一个 SaaS 产品的智能体最开始只服务企业客户，因此"公司规模"被写入用户画像长期记忆。半年后产品转向也服务个体开发者，"公司规模"这个字段在 80% 的对话中不再有意义。但在没有治理委员会的情况下，写入逻辑没人修改、存储持续膨胀、检索被污染——所有成本都由系统和用户默默承担。

治理委员会的核心价值，是把"记忆策略应该更新"这个隐性知识从工程师的直觉，变成一个制度化流程。

委员会构成与运作节奏

• 技术代表（工程 Lead）：提供检索延迟、成本数据、命中率等指标
• 产品代表（PM）：判断哪些业务信息仍有价值，哪些已过时
• 运营/客户成功代表：从用户投诉和反馈中识别记忆污染的信号（比如"智能体总是提到我已注销的公司"）

节奏建议：轻量级，30 分钟站会制。每次会议聚焦三个数字：

1. 本月记忆总量增长率
2. 检索命中率（低于阈值则触发清理议题）
3. 因记忆污染导致的用户投诉数量

注意框：不要等性能报警响了再行动

记忆治理是预防性的，而非响应性的。当检索延迟飙升到用户投诉的程度时，清理存量记忆的代价往往是新增的数十倍——你需要逐条评估哪些能删、哪些不能删，而不是从一开始就规定好"这一类在 X 天后自动删"。成本的区别是 O（1）与 O（n）的区别。

截至当前调研资料，LangChain 的 DeepAgents 和 LangMem 已提供文件系统级记忆控制和元数据管理能力（官方文档，2025 年），而 Letta 的 MemGPT 设计模式（来源 P2，需验证最新版本）也为选择性持久化记忆提供了参考架构。但工具不论多先进，都无法替你回答"这个信息值不值得记"。这是上下文工程中属于人的判断力的保留地。

在下一章《下一代基础模型原生支持长上下文的冲击》中，我们会看到 1M Token 上下文窗口如何改变记忆治理的算力账本——以及为何即便上下文看似"无限"，治理依然不可或缺。因为容量的扩容从未解决过分类的问题，就像更大的硬盘不会帮你整理文件。