摊销上下文：持久化智能体记忆 vs 长上下文窗口

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

“迷失在中间”效应并非提示工程问题​

长上下文填充的结构性问题在于注意力稀释（attention dilution）。当你向模型发送 20 万个 token 时，注意力机制必须在所有内容中分配权重。位于长上下文中间位置的信息系统性地获得的注意力少于开头或结尾的内容。一个基准测试系列报告称，当同一文档在 20 个文档的上下文中从第 1 位移至第 10 位时，准确率下降了 30% 以上。这种情况在多个前沿模型中都普遍存在。

即使是那些具有最佳长上下文处理能力的模型 —— 那些在宣称的完整窗口内都能保持准确性的模型 —— 在实践中也只能在 60-70% 的容量范围内保持可靠的高效。宣称的上下文窗口大小与有效的上下文窗口大小并不是同一个数字。营销噱头是上限，而工程现实则要低得多。

延迟带来的惩罚更为显著。在 70B 参数模型上的生产基准测试衡量出，与聚焦检索相比，填充上下文（stuffed-context）查询的延迟增加了 719%。更重要的是：相同查询的 token 计数从填充模式下的 3,729 个 token 变为定向检索下的 67 个 token —— 这是一个 55 倍的差异。在规模化运行中，这种差异不是噪音。它是响应迅速的智能体与被用户弃用的智能体之间的区别。

三层记忆架构​

高效的智能体记忆不是一个单一的系统，而是三个协调的层，每一层都有不同的成本概况和访问模式。

短期上下文记忆保存当前的对话、活动的运行状态以及任何需要跨过当前轮次保留的固定事实。这是模型的即时工作空间。诱惑是让它在轮次之间无限制地增长；而纪律则是将其视为一个工作集，在溢出之前进行压缩。

长期外部记忆通过使用具有混合检索功能的向量数据库跨会话持久化 —— 将语义相似性搜索与关键词匹配和元数据过滤相结合。在这里，时效性很重要：最近未被检索的记忆其相关性会衰减，这模仿了人类记忆的工作方式，并减少了陈旧事实被注入当前上下文所产生的干扰。外部记忆使得在第一轮学到的事实在第五十轮依然可用，而无需占用第二到第四十九轮的任何上下文 token。

结构化上下文 —— 这是大多数团队跳过的层 —— 存储了在对话中永远不会改变的企业定义、策略、血缘数据（lineage data）和参考信息。这属于一个单独的索引存储，而不是上下文窗口，因为它不需要被语义化检索 —— 当智能体在受监管的领域操作时，它需要被确定性地查找到。

扩展有效上下文的压缩模式​

使外部记忆变得实用的架构技术是递归压缩（recursive compaction）。当上下文容量填满时（例如在 16k token 时），系统不再是简单的截断或报错，而是逐出最旧的 50% 消息，根据现有摘要加上逐出的内容生成一个新的摘要，将完整的消息存储在归档记忆中，并仅在窗口内保留压缩后的摘要。

这种模式将有效的上下文从模型的物理限制扩展到了任意大的历史记录。根据内容类型的不同，这种方法在长文档基准测试中的困惑度（perplexity）降低幅度在 16-30% 之间。成本是增加了一次摘要调用；收益是智能体能够维持连贯的长周期对话，而不会导致单次调用的 token 计数爆炸。

MemGPT 架构正式确立了这种方法：一个主上下文（快且贵）加上归档记忆（慢且便宜），并配有一个管理层来决定哪些内容被提升、逐出、总结和检索。该设计的生产部署报告称，智能体处理对话历史所需的直接上下文可能需要数百万 token，但其每轮成本却低得多。

决策框架：内容放在哪里​

决定哪些内容保留在上下文（In-context）中，哪些内容持久化到外部记忆中，是一个信息质量问题，而不仅仅是成本问题。

在以下情况保留在上下文中：

• 在当前轮次中，信息会被多次主动引用
• 对话中的顺序或位置至关重要（例如，用户刚刚纠正了某些内容，而该纠正需要覆盖早期的上下文）
• Agent 正处于复杂的多步计划中，丢失任何中间状态都会导致需要重新计算

在以下情况持久化到外部记忆：