背景

在过去几年里，逐渐膨胀的大模型上下文，使得LLM的性能受到巨大的挑战。另外，LLM的上下文窗口有限，也使得其丢失记忆的情况很常见。为了解决这一问题，目前市面上提供了一些方案，包括

• 上下文工程：滑动窗口、对话摘要、动态裁剪
• RAG
• Summarize/Compact：压缩上下文，通过算法稀疏注意力
• 外部记忆系统：分层记忆、mem0

目前来说，大部分工具都采用了压缩方案，即当窗口达到70%左右时，对上下文进行压缩。当然，压缩也有策略，比如对长期记忆进行全量压缩，中期记忆进行稀疏化压缩，短期记忆保留活性。不同的技术方案，可能采取的策略不同，比如Mem0和LightMem就采用类似的空间压缩与动态缓冲管理。

然而，我认为，所有的压缩方案都存在细节丢失的问题，而且即使通过压缩，也无法提示大模型的性能。丢失细节比较容易理解，而大模型的性能，会因为压缩的上下文所提供的背景信息，以及本身也在逐渐膨胀的消息列表，仍然会比较低。

因此，寻找一种更优的大模型上下文工程方案，是我本篇文章的目标。

目标

这种新方案，必须符合两个点：1. 保留聊天的细节，让大模型记忆不丢失，甚至得到增强。2. 大模型性能不受损。

第一性分析

当前所有的记忆系统，都是基于LLM的对话模式设计的。在当前的所有方案中，它们需要输出非常长的聊天历史，来遵照大模型的API接口设计。但是，目前公开研究发现，丢掉所有聊天历史，在没有历史记忆的情况下，大模型所驱动的Agent会有更准确的效果表现。这或许是一个突破口。

当前的技术设计是

# 原始方案
用户输入 -> push到messages列表 -> LLM

# 优化方案
用户输入 -> 上下文工程 -> LLM

上下文工程本质上包含两个部分：压缩和存储，用户输入后会被直接添加到从存储器中读取出来的记忆后面，形成messages队列。

上下文工程：压缩 -> 存储 ↴

用户输入 ------------>消息列表 --->LLM --↰(再次压缩)

从中我们可以看到一些破绽。

所有的类似方案，它们对上下文记忆的优化算法，都是针对已经形成的消息列表做注意力优化，这些算法会在每次LLM完成对用户的响应后执行，形成新的上下文缓冲。

智能推送方案的提出

我提出一种智能推送的上下文方案。在这套方案中，注意力算法不再针对用户消息，不再在LLM完成响应时执行，而是在向LLM推送消息时执行。具体流程如下：

假设，当前用户已经与Agent对话了很多轮。当用户提交新的输入时，我们这套系统首先会拿着用户的输入去识别用户的意图，从历史数据中找出与用户意图相关的全部数据，忽略那些与用户意图无关的其他数据，并最终生成上下文，交给AI去运行。系统输出给AI的消息内容必须回答如下的这些问题：

• 用户是怎样的一个人
• 当前大背景是正在做一件什么事
• 目前的进度是什么
• 用户现在想要让你做什么
• 要实现用户目标可以参考的资料如下……
• 你可以用的工具如下……

只要回答了上述这些问题，无论输出消息的长短，都能非常高效的提升模型性能。

后台常驻服务

当前所有的AI对话系统，都是Request/Repsonse模式，也就是用户提问，AI回答。虽然我们会构建Chat系统来组织上下文，但是对于整体Chat系统来讲，它仍然秉持着“用户问- AI答”的单链条式来回交互。

而我所设计的这套系统，是后台常驻型服务，用户的问和AI的答并不需要同步进行。用户可以在AI干活的时候，继续提出质疑，例如，当用户发现聊天窗口输出的执行过程存在疑惑时，可以立即向系统提问，为什么要这么做？而系统接收到消息后，会先识别用户意图，同时以当前执行阶段的已有信息，把组织好的消息，发送给另外一个AI实体。由这个实体完成对用户的解答。虽然在消息流中，消息来源来自两个AI，但是对于用户而言，它只是一个抽象的单一机器人。

系统可以识别用户意图。这是非常关键的一点，因为只有识别了用户意图，才能决定使用哪些信息作为将要发送给AI的上下文。同时，系统还可以根据用户意图，决定是只需要调用一个LLM，还是需要向Agent发送请求，因为有些交互，用户仅仅只需要得到一个回答，而不需要调用工具来执行。

当外部环境发生变化时，系统可以实时作出响应。例如，在一个协作系统中，用户A向系统提交了一个表单之后，系统可以立即向用户B推送基于用户A提交消息而生成的新内容。外部环境包含各个方面，比如在编程环境中，用户用另外一个编程工具修改了当前项目的代码，我们的系统需要实时感知，在用户二次请求时，这些变更被反应在上下文中。甚至，系统可以了解当前世界各地的重大新闻，来对当前的行为进行干预，例如在一些投资AI系统中，重大行为可能随时影响投资标的的动向。只有常驻服务才能够做到对环境的实时监控。

结语

目前，这套方案只是我的一种设计，并没有经过验证。其中，实施构造上下文会比老的压缩方案更消耗时间，在AI的响应速度上必然受到影响。但是，这并不绝对，因为通过精准的意图识别，可以减少上下文的长度，剔除无用的信息，这又可以提升大模型首个token响应时间。在整套系统的算法上，也可以通过划分等级来降低算法消耗，比如让用户手动设置当前任务的精确等级，如果是不需要很精准，那么通过对所有数据建立索引，直接通过高召回率的向量查询的方式，把与用户输入关联的内容全部拉出来即可，毕竟大模型本身也有应对噪声的能力，这样可以更快；但是如果在需要高度精准的任务背景下，就可以在常驻服务中，再加载一个高性能的专用Agent来专门做意图识别和消息构造的任务。总之，我并不是去实现这套系统，而只是提出了这样的一个构想方案。如果你对此也有自己的一些想法，不妨在下方留言，我们一起探讨。

2026-01-08 161