摊销上下文：持久化智能体记忆 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 正处于复杂的多步计划中，丢失任何中间状态都会导致需要重新计算

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

• 事实是在之前的会话中建立的，但在当前会话中未被引用
• 用户偏好、个人资料数据或先前的决策，这些内容为当前任务提供参考但并不直接驱动任务
• 提供背景信息但并非当前推理所需具体证据的对话历史

在以下情况放入结构化上下文：

• 多个 Agent 或会话需要一致引用的参考数据
• 与合规相关的审计记录
• 不会通过对话改变的系统定义（Schema、策略、分类法）

在以下情况从源数据重新获取：

• 底层数据变化非常频繁，以至于持久化副本可能会过时
• 文档足够大，即使是经过良好排序的摘录也足够，且比存储完整嵌入（Embedding）更便宜

判断失误的失效模式是微妙的。接收过多无关上下文的 Agent 会表现出更多的套话（例如，“我不确定，但是……”）、在标准评估中无法察觉的、随位置而变的准确性下降，以及基于部分证据产生的幻觉——模型会从过度饱和的上下文噪声中构建出看似合理的答案，而不是从精准检索的信号中获取。

排序而非填充，才是规模法则

改变经济效益的研究洞察是：在检索质量上，10 个经过排序的结果始终优于 200 个未排序的切片，而 Token 成本仅为后者的约 1/20。排序模型——无论是交叉编码器（Cross-encoders）、排序学习（Learning-to-rank）方法，还是经过微调的检索器——都能识别出真正有用的内容，而不仅仅是语义相关的内容。成本差距巨大：未排序填充的查询成本为每轮 0.16 美元，而采用排序检索的查询成本仅为 0.015 美元，Token 数量从 5 万减少到了 2500 个。

这相当于数据库索引的记忆版：你只需构建一次排序系统，并将其摊销到每一次查询中。前期成本是带有排序层的检索流水线；而持续的收益是单次调用成本降低了 10 到 20 倍，且答案质量更高。

抗拒这种投资的团队通常是因为检索流水线听起来更像基础设施工作，而非 AI 工作。这种定性是错误的。检索层是决定你的 Agent 在长对话的第 50 轮时是否真正知道自己在说什么的关键部分。把它做好就是 AI 工作。

盈亏平衡点究竟在哪里

在大约 10 轮对话之后，记忆系统的成本就会低于暴力长上下文方案。在此之前，提取、嵌入和索引的设置开销使得填充方案在边际上更具竞争力。10 轮之后，不断增长的上下文窗口带来的复合成本意味着每一轮额外的对话都会让原生方案变得更贵，而外部记忆方案的单轮成本则基本保持平稳。

在以下情况下，盈亏平衡点会更早到来：

• 知识库固定且检索摊销迅速的高流量应用
• 用户专属历史记录无限增长的 Agent
• 将完整上下文传播给子 Agent 会导致成本翻倍的多 Agent 系统

在以下情况下，盈亏平衡点会更晚到来：

• 知识库较小的单轮或少轮交互
• 尚不值得投入检索基础设施设置时间的原型
• 整个知识库可以装进模型有效上下文窗口四分之一的情况

构建经得起生产考验的记忆系统

生产环境中外部记忆的运行要求与研究要求不同。你需要删除语义——这不仅是为了合规（GDPR 擦除请求是真实存在的），还因为用户偏好会改变，过时的记忆会主动导致回答质量下降。你需要版本控制，以便当用户纠正 Agent 时（“我其实更喜欢 X，而不是 Y”），纠正后的内容能覆盖先前的事实，而不是在检索时与旧事实共存。你需要命名空间隔离，以确保一个用户的上下文不会渗漏到另一个用户的会话中。

向量数据库处理相似性搜索，但它们不处理数据管理生命周期。构建出经得起生产考验的记忆系统的团队，会在管理层上进行投入：什么触发写入、什么触发移除、什么触发检索，以及当检索到的事实与模型刚说的话冲突时该怎么办。正是这个管理层让记忆系统从 Demo 变成了产品。

经过 18 个月的研究和生产部署，得出的结论非常直接：长上下文窗口是处理单次会话、有限知识任务的有用工具，但它们不是记忆策略。构建外部记忆不是可选的复杂性——它决定了你的 Agent 是在第一轮会话后就了解你的用户，还是永远像对待陌生人一样接待他们。