上下文工程实测：不压缩反而更省钱高效的原因

在构建AI Agent的过程中，几乎每个开发者都经历过这样的场景：明明模型很聪明，但对话越长，结果却越来越差。很多人的第一反应是「模型变笨了」，于是切换到Claude、Codex或其他工具。但来自Towards AI团队在AI Engineer大会上的分享揭示了一个更深层的真相：问题往往不在模型本身，而在于上下文管理。

更颠覆认知的是，他们通过大量实测发现——对上下文进行摘要（Summarization）和压缩（Compaction）反而可能既费钱又降低质量，而「什么都不做、保留全部历史」竟然是最优解。这个反直觉的结论背后，隐藏着缓存机制带来的经济学变革。

上下文腐烂：Agent性能下降的真正元凶

Towards AI团队为其AI教学助手（AI Tutor）设定了五项核心要求：回答必须基于课程内容而非模型自身知识、锚定当前课程、支持长时间调试会话、能处理代码、以及保持低延迟。所有这些需求本质上都指向同一个技术挑战——上下文工程。

他们指出，模型带来两个根本问题。第一，上下文窗口是有限的。上下文窗口（Context Window）是指大语言模型在单次推理中能够处理的最大token数量——token是模型处理文本的基本单位，一个英文单词通常对应1-2个token，中文字符通常对应1-2个token。虽然如今的模型窗口已从早期的4K扩展到百万级别，但研究表明模型存在「Lost in the Middle」现象，即对窗口中间位置信息的关注度显著下降。从系统提示、课程内容、工具定义到聊天历史，所有信息都挤在同一个有限空间里，堆得越多，结果越差，成本也越高。第二，模型是无状态的。这是Transformer架构的根本特性：每次API调用都是独立的推理过程，模型没有内置的记忆机制，必须将所有需要「记住」的信息显式地放入输入中。学生重新打开助手时，模型对之前的一切一无所知。

经过分析，团队发现规模化上下文时的最大瓶颈是历史工具输出（old tool outputs）——包括历次检索的文本块、所有工具调用与结果对、以及文件搜索记录。这些内容不仅昂贵，更会引发所谓的「上下文腐烂」（Context Rot）。

上下文腐烂的深层机制源于注意力机制（Attention Mechanism）的局限性。Transformer模型通过自注意力计算每个token与其他所有token的关联权重，理论上能捕捉任意距离的依赖关系。但实际上，当上下文过长时，注意力权重会被大量无关信息稀释，导致模型难以精准定位关键信息。这类似于人类在阅读一本600页的书后被问及第37页某个细节——信息虽然「看过」，但检索效率大幅下降。由于大语言模型训练方式的局限，它们并不擅长在超长上下文中把握全局，只是被动地注入了大量事实，导致质量随长度增长而下降。

上下文压缩技术的完整武器库

为管理上下文，团队系统梳理了多种技术。最基础的是不依赖大模型的「廉价工具」：对异常长的工具输出进行截断（只保留头尾并标注已截断）、使用滑动窗口只保留最近N轮对话、以及针对特定工具直接清空大部分输出。

进阶方案则是「花token省更多token」，即用语言模型来压缩上下文。实测中效果最好的几种技术包括：

• 选择性保留（Selective Retention）：让模型根据对话走向决定保留或丢弃哪些内容
• 摘要（Summarization）：持续对前面轮次进行总结
• Delta摘要：Claude Code在派生子智能体时使用，持续更新一个动态摘要

你可能没注意到，团队因为单主智能体架构已经工作良好，并未采用子智能体，避免了不必要的复杂度。

此外还有「卸载」（Offloading）策略——将信息保存到内存或文件，配合检索增强生成（RAG）使用。RAG（Retrieval-Augmented Generation）是将外部知识库与大模型结合的经典范式：先用向量检索找到相关文档片段，再将其注入提示中供模型参考。团队还对比了GraphRAG与普通RAG。GraphRAG是微软在2024年提出的进阶方案，它在传统RAG基础上构建知识图谱——先用LLM从文档中提取实体和关系，形成图结构，再通过社区检测算法将图划分为层级化的社区，最后在检索时利用图结构进行多跳推理。GraphRAG在需要全局理解和跨文档推理的场景上显著优于普通RAG，但其构建成本高昂。结果发现在他们的场景下GraphRAG设置成本高得多，效果却与RAG打平，因此没有采用。

他们采用的是一套「LLM Wiki」方案：将所有内容切分为块（chunks）并交叉链接，块再关联到原始数据文件，模型只看一个约450 token的极小索引，按需逐层检索——这正是「渐进式披露」（Progressive Disclosure）的思想。渐进式披露源自人机交互设计理论，核心思想是「只在需要时才展示信息」。在上下文工程中，这意味着不将全部知识库一次性塞入提示，而是构建多层索引结构，模型通过阅读索引决定需要深入哪个主题，再通过工具调用获取下一层详细内容。类比来说，这就像图书馆的检索系统——你先查目录卡片，找到书架位置，再取出具体的书，而不是把整个图书馆的书都搬到桌上。

提示缓存：让摘要变成陷阱的游戏规则改变者

这是整场分享最核心的洞察。当你在对话中追问时，系统需要重新计算之前所有token，等于为相同内容付费两三次。为此，各大厂商推出了提示缓存（Prompt Caching），预计算并保存embedding和KV cache。

要理解提示缓存为何如此重要，需要了解Transformer的推理过程。在生成每个新token时，模型需要计算当前token与所有前序token的注意力权重，这涉及Key和Value矩阵的计算——即KV Cache。对于一个包含10万token的上下文，每次用户追问时都需要重新计算这10万个token的KV Cache，计算量巨大。提示缓存的核心思想是：如果两次请求的前缀相同，就将第一次计算的KV Cache保存下来，第二次直接复用。这不仅节省了GPU计算资源，更大幅降低了首token延迟（Time to First Token, TTFT）。Anthropic的Claude、Google的Gemini和DeepSeek都已支持这一机制，但实现细节不同——有的要求严格前缀匹配，有的支持部分匹配。

关键在于：这些复用的缓存token极其便宜。以DeepSeek为例，缓存token的价格可低至原价的1/50。也就是说，发送超长上下文时，历史部分只需付1/50的价格，只有新增的用户问题才付全价。

这就导致了一个致命的矛盾：当你进行摘要或压缩时，上下文变成了「新内容」，缓存立即失效，你必须为这些转换后的token支付全价。换算下来，压缩要真正划算，就必须把上下文压缩50倍以上——这在不损失质量的前提下几乎不可能实现。

因此团队得出结论：摘要可能是个陷阱。Claude Code、Codex等成熟框架都在使用上下文缓存，并采用不同于粗暴摘要的压缩方法。当你自建框架时，理解何时用哪种技术、并做实测就变得至关重要。

实测结果：保留全部上下文全面胜出

为验证这些技术，团队搭建了完整的评测体系。他们用Codex从官网抓取了学生的真实问答，清洗后保留60对；同时构建多轮会话任务，测试模型在多轮对话后是否还能回忆起早期的关键事实。评测涵盖11个预设配置，包括「保留全部历史」「生产环境默认配置」以及滑动窗口、提示压缩、选择性保留等6种技术。

结果令人意外。在使用Gemini 3.5 Flash的多轮会话任务中，「不触碰上下文、保留全部历史」在记忆召回、成本和速度三个维度上全部胜出。他们原以为足够好的生产环境默认配置反而表现更差。

为什么延迟也更低？团队分析：如果持续清除工具输出，Agent就需要重新检索已经拥有过的信息，这反而导致更多工具调用，最终既费token又更慢，记忆召回还更差。这形成了一个恶性循环——压缩导致信息丢失，信息丢失触发重复检索，重复检索增加延迟和成本，而新检索到的内容又进一步膨胀了上下文。

从Gemini到DeepSeek再到本地部署：成本的三重验证

初期实验花费了近600美元，促使团队转向更便宜的模型。他们发现DeepSeek V4 Flash成本大幅降低，且因为享有50倍的缓存折扣，「保留全部」依然是最优解。

记忆测试的数据极具说服力：保留全部上下文时，模型95%的情况下能准确找到学生提及的具体细节；而一旦摘要压缩，准确率骤降至32%。原因很直白——摘要会移除必要细节。团队还将会话扩展至80万token，发现对于「独特事实」的检索几乎没有出现上下文腐烂，只有模糊事实的表现降至一半。

在成本层面，实测证实「发送token最多的配置反而最便宜」——因为97%的token都被缓存了。以1.78百万token的长会话为例，保留全部依然领先。

但故事在规模化和本地部署时发生了转折。当学生量达到10万级别，Gemini每月约需4万美元，而DeepSeek仅约1900美元。而在本地MacBook上运行时，受限于32K上下文窗口，连单节课程都装不下，缓存彻底失效——此时RAG检索成为唯一可行的方案，本地文档检索准确率达100%，但强行塞满窗口会导致340秒才输出一个token的灾难。

检索策略上，纯语义搜索（Dense RAG）在50K-200K token时表现良好（约80%），但到400K时对埋在中间的事实召回率归零。这正是「Lost in the Middle」现象在检索场景的体现。而BM25关键词检索始终保持100%。BM25是一种经典的基于词频的检索算法，属于稀疏检索方法，通过计算查询词在文档中的出现频率（TF）和在整个语料库中的稀有程度（IDF）来评分，对精确关键词匹配极为敏感。Dense Retrieval则使用神经网络将文本编码为高维向量，通过余弦相似度衡量语义相似性，擅长处理同义词和语义相近但用词不同的查询，但可能遗漏精确的术语匹配。这正是团队最终采用**混合检索（Hybrid Search）**的原因——通常采用倒数排名融合（Reciprocal Rank Fusion, RRF）等方法将两者的结果列表合并，在实践中被证明比任何单一方法都更稳健。

最终决策与核心启示

综合所有实验，Towards AI团队最终选择：DeepSeek V4 Flash + 混合检索的云端方案。在记忆管理上「保留全部」，仅在超过30K token后才触发压缩。

最重要的启示是：不要默认就压缩上下文。你必须先明确自己的真实约束——是成本、延迟、上下文窗口限制还是硬件条件，然后再针对性地寻找方案。缓存机制已经彻底改写了上下文工程的经济学，让「保留全部」在很多场景下成为质量、成本、速度三赢的选择。而当被迫走向本地或超大规模时，RAG与混合检索才是回归舞台的主角。

这一发现也对整个AI Agent开发社区提出了警示：很多被视为「最佳实践」的技术（如积极摘要、滑动窗口）可能是在缓存机制普及之前形成的经验。当基础设施发生根本性变化时，工程决策也必须随之重新评估。不做盲目优化、用数据驱动决策，可能是当前上下文工程最重要的方法论。

核心要点