大模型记忆工程：为什么塞满上下文是条死路

你有没有算过，每次对话都让AI"回忆"全部历史，成本到底多高？

这不是理论问题。OceanBase开源的PowerMem团队刚放出一组实测数据：当记忆层外置、按需检索时，同样的任务token消耗能压到传统"全量注入"模式的零头。而质量——用人工评估的连贯性和事实一致性打分——反而更高。

矛盾吗？一点都不。这正是大模型工程里最难啃的骨头：记忆不是存储，是筛选。

上下文膨胀的三重税

行业对"长上下文"的迷恋近乎本能。模型厂商卷窗口长度，从4K到128K再到200万token；应用开发者把MEMORY.md往提示词里一贴，觉得"全量可见=可控可审计"。

这两种做法在小规模演示时都很漂亮。但一旦进入真实生产环境，三座大山压过来：

第一座是速度。推理时间与上下文长度基本线性相关。用户每等一秒，流失率都在爬升。

第二座是成本。token账单随历史长度膨胀，没有天花板。一个服务了三个月的企业客户，单次对话的上下文可能膨胀到初期的几十倍。

第三座最隐蔽，也最具破坏性：注意力稀释。Transformer的注意力机制不是均匀分布的，上下文越长，中间信息被"看见"的概率越低。结果不是"记得更多"，是"记得更乱"——矛盾信息混入，模型输出质量反而断崖下跌。

原文作者说得直白：你不是在买记忆，是在买噪音。

工程分叉口：全量注入还是按需检索

真正的工程决策在这里分叉。

路径A是"全量保留+全量注入"——把对话历史、用户画像、业务文档尽可能塞进上下文。简单、直观、调试方便。但前面说的三重税全中。

路径B是"外置记忆层+智能检索"——在模型之外维护一个结构化记忆库，每次只取当前决策最需要的片段。复杂、需要额外基建，但理论上能同时解决速度、成本、质量三个问题。

PowerMem选的是路径B。作为Apache 2.0协议的开源项目，它来自OceanBase团队的数据库工程背景——这很关键，因为记忆层的核心挑战不是"存得下"，是"找得准"和"忘得掉"。

三个旋钮：写、读、生命周期

外置记忆层的设计可以拆解成三个可调参数。

写路径：从原始对话里提炼什么？不是存原文，是存"对未来决策有用的事实"。需要做多步处理——去重、冲突消解、相关合并。比如用户三次提到"不喜欢香菜"，最终只存一条偏好记录，附带时间戳和置信度。

读路径：检索什么、检索多少？这里需要混合策略：向量检索捕捉语义相似，全文检索匹配精确关键词，图结构维护实体关系。"只用向量嵌入"的方案在产品里老化得很快，用户 query 的模糊意图和精确指代都需要覆盖。

生命周期：旧事实怎么退场？不是永久保留，是主动遗忘。艾宾浩斯遗忘曲线在这里不是心理学梗，是明确的工程权衡——存储容量有限，信号噪声比需要维护。给记忆条目加衰减权重，长期未调用的自动降级或删除。

这三点听起来像功能清单，但原文作者强调：在工程语境里，它们回答的是同一个问题——怎么让模型看到的最小有用切片，真的最小且真的有用。

生产环境的四个硬需求

从PowerMem的实践中，原文提炼了四个在真实部署中不可妥协的特性。

混合检索。向量+全文+图链接，缺一不可。用户问"上次那个阻塞我们的依赖项"——"依赖项"需要精确匹配，"上次"和"阻塞"需要语义理解，而"我们"指向的是对话历史中的特定实体关系。

主动遗忘。不是bug是feature。存储成本、检索效率、信息时效性都要求旧数据有明确的退场机制。衰减策略可以是时间驱动的，也可以是访问频率驱动的，但必须显式设计。

多代理支持。私有记忆（单个用户、单个会话）和共享记忆（团队知识库、跨会话上下文）需要并存。多代理不是未来场景，是现在就在发生的架构需求——一个客服机器人、一个工单系统、一个知识库助手，需要协调各自的记忆边界。

多模态。文本、图像、音频的统一处理。不是为了炫技，是工作流本身已经混乱——用户截图报错、语音留言补充信息、文档附件里的表格，记忆层需要能消化这些异构输入。

为什么这 matters now

大模型应用正在从"演示期"进入"运营期"。

演示期的核心指标是"能不能做"——长上下文让demo看起来很聪明，全量注入让调试很安心。运营期的核心指标变成"做不做得起、做不做得好"——成本结构、响应延迟、长期一致性。

记忆层的外置化，本质是把"上下文管理"从模型的黑箱里抽出来，变成可工程化调优的独立组件。这和数据库的发展轨迹类似：早期应用自己管存储格式，后来统一交给关系型数据库，再后来针对特定负载分化出缓存、搜索引擎、数据仓库。

PowerMem的开源释放了一个信号：这个分层正在LLM栈里发生。OceanBase团队的数据库背景让他们对"检索效率"和"存储生命周期"有本能的敏感——这些恰恰是当前多数LLM工程团队的经验盲区。

原文作者没有给出具体的性能数字对比，但明确提到了"real numbers from an open-source memory layer on OpenClaw"。这组数据的存在本身，说明路径B已经跑通了从原型到可观测的闭环。

对于正在搭建生产级LLM应用的团队，这意味着什么？

至少三件事需要重新评估：你的上下文策略有没有成本模型？你的"记忆"是 verbatim dump 还是结构化可检索的？你的旧数据有没有明确的退场机制？

这三个问题答不清楚，长上下文窗口只是延迟暴露问题，不是解决问题。