上下文工程实战：为什么全保留打败了压缩摘要

从一次愤怒的对话说起

几乎每个用过 AI Agent 的人都经历过这样的场景：你反复向智能体解释需求，它却始终做着你不想要的事，最后你气急败坏地敲下一行反馈，期待它能"学乖"。Towards AI 团队在 AI Engineer 大会上分享的这场关于上下文工程的实战研究，正是从这种普遍的挫败感出发。

他们指出，问题的根源往往不是模型"变笨了"，不需要你急着从 Claude 切换到 Codex，而是上下文正在被塞满，结果越来越差——这就是所谓的"上下文腐烂"（Context Rot）。对于 Towards AI 这样一家为 AI 工程师提供课程和 AI 导师（AI Tutor）服务的公司来说，一次糟糕的交互甚至可能直接导致学生要求退款。

为了系统性地解决这个问题，团队围绕开源的 AI Tutor 做了大量实验，并将全部实验结果和代码在 HuggingFace 上公开。本文将梳理他们的核心发现，其中最反直觉的结论是：在很多情况下，什么都不压缩、保留全部上下文，反而是最优解。

上下文工程的两大核心问题

上下文工程，本质上是决定"每次调用模型时，模型能看到什么"。而这一切之所以困难，源于大语言模型的两个根本约束。

有限的上下文窗口

模型的上下文窗口是有限的。从系统提示词、工具定义、聊天历史、旧的工具输出，到检索到的课程片段和用户问题，所有内容都挤在同一片有限空间里。你堆进去的东西越多，结果质量越差，成本也越高——因为你为更多 token 付费。

团队通过分析发现，扩展上下文的主要瓶颈是"旧的工具输出"：包括历次检索到的片段、所有工具调用与结果的配对、以及智能体的历史搜索记录。它们不仅昂贵，更会因为上下文腐烂而拖垮回答质量。

无状态的模型

模型本身是无状态的。当学生重新打开 AI 导师时，如果你没有额外构建任何机制，模型对之前发生的一切一无所知。这就衍生出两个工作方向：单次会话内的上下文管理，以及跨会话的记忆能力。本次研究聚焦于前者——因为如果单次会话本身就很糟糕，谈跨会话记忆毫无意义。

上下文工程的收敛趋势

值得一提的是，团队在实践中观察到一个行业趋势：大家正在向**更多、更小的技能（skills）**收敛。构建精确的小技能、按需逐个加载、甚至为单个技能启动专属子智能体，这种"渐进式披露"（progressive disclosure）的思路能极大节省上下文。

压缩策略与提示词缓存的博弈

压缩的思路很简单：让上下文尽可能小，只保留回答问题所需的信息，其余部分丢弃或转存。团队总结了几类无需大模型也能做的廉价技巧：

自动截断异常长的工具输出：只保留头尾，中间标注"已截断"，模型需要时可重新调用；
滑动窗口：只保留最近 N 轮对话；
针对特定工具清空输出。

更进一步，可以用（甚至是本地小型）语言模型做"选择性保留"、"持续摘要"，或者像 Claude Code 那样在触及上限时生成全局摘要并重置。

缓存机制改变了成本计算逻辑

然而，一个关键变量彻底改变了压缩的性价比：提示词缓存（Prompt Caching）。

如今几乎所有主流 API 都提供缓存功能。已发送过的 token 会被预计算（保存 embedding 和 KV cache），重新使用时极其便宜——在 DeepSeq 等 API 上甚至能便宜 50 倍。这意味着，如果你发送一段很长但已缓存的上下文，你只需为新增的用户提问支付全价。

AI导师的系统设计

问题在于：当你压缩、摘要、对上下文做任何变换时，提供商就无法使用缓存了——因为这是一段"全新"的上下文。于是你要为这些新变换出来的 token 支付全价。

这就得出了一个惊人的结论：要让压缩真正划算，你必须把上下文压缩超过 50 倍，且不能损失质量——这在绝大多数场景下几乎不可能。因此，摘要（summarization）可能是一个陷阱。这也是为什么 Claude Code、Codex 等成熟框架都严重依赖上下文缓存，而非无脑摘要。

AI Tutor 实验架构与评测方法

为了验证哪些上下文管理技术真正有效，团队搭建了一套完整的评测体系。他们的 AI Tutor 本身非常简单：一个基于 LangChain 的单一 React 型智能体，通过工具调用和思考循环工作，用中间件（middleware）来定制摘要、清理工具输出等行为。

两个核心工具的设计

第一个是混合检索工具：在超过 800 万 token 的语料库（涵盖两年的课程 + LangChain、LlamaIndex、OpenAI、Claude Code 等开源文档）上，结合语义搜索与 BM25 关键词搜索，取 top 30 片段合并后重排到 top 5 返回，并设有 10 万 token 上限。

第二个是让智能体用 bash 命令浏览知识库文件系统（借鉴 Karpathy 的 wiki 思路，含 raw / generated / wiki 三个文件夹）。有趣的是，实验发现加上这个工具后，召回率几乎没有提升，反而慢了 50%——因为团队使用的真实学生问题还不够复杂，不足以从中受益。

每一轮对话都记录完整指标

评测数据与对比方案

团队定义了几个关键概念：preset（AI 导师的一种配置）、task（单轮问答 vs 多轮会话）、run（在某任务上运行某配置）、bundle（结果 JSON）。评测数据不是合成的——单轮任务用 Codex 从官网抓取了真实的师生问答，清洗后保留 60 对；多轮会话任务则测试"经过多轮对话后，导师能否回忆起开头陈述的事实"。

他们对比了 11 种 preset，包括"完整历史"（不动上下文）、"生产默认配置"，以及滑动窗口、提示压缩、选择性保留等 6 种技术。

实验结论：全保留为什么打败了压缩

第一轮基于 Gemini 3.5 Flash 的实验（花费超过 500 美元）就给出了出乎意料的结果：在多轮会话的事实回忆上，「不动上下文、保留全部历史」是最佳策略，甚至优于团队自认为不错的生产默认配置。

更重要的是，保留全部历史在三个维度上同时获胜：召回率更高、延迟更低、成本更便宜。原因在于——如果你频繁清理工具输出，智能体就不得不重新检索它本已拥有的信息，产生更多工具调用，反而推高了 token 消耗和延迟。

在三种不同上下文中做评测

便宜模型 + 缓存命中 = 成本与质量双赢

针对高昂成本，团队换用 DeepSeq V4 Flash 重跑实验，发现成本大幅下降（缓存折扣高达 50 倍），而"保留全部"依然获胜。在记忆测试中：

保留全部上下文时，模型 95% 的情况能准确回忆出学生提到的具体细节；
一旦先做摘要或压缩，命中率骤降至 32%——因为摘要恰恰抹掉了那些关键细节。

在一次 36 轮、约 178 万 token 的长对话中，发送 token 最多的"全保留"配置反而最便宜，因为其中 97% 的 token 都命中了缓存。长上下文实验中，即便到 800K token，模型对独特事实的检索依然稳定，几乎没有上下文腐烂。

本地部署场景：约束条件改变最优策略

当把场景切换到本地模型时，结论发生了逆转。受 MacBook 硬件限制，最大上下文窗口只有 32K，而单节课程本身就超过这个长度——一旦对话装不进窗口，缓存就失效了。此时"保留全部"不再可行，本地聊天记忆的得分从云端的 92%~95% 跌至约 33%。而且，试图硬塞超过窗口容量的上下文时，模型花了约 340 秒才吐出一个 token，纯属浪费。

不过，本地场景下检索（RAG）表现出色：处理粘贴的长文档时准确率达 100%，处理时间 25~65 秒。检索策略上，纯语义搜索（dense RAG）在 400K token 时对埋藏在中间的事实召回率跌至 0%，而 BM25 始终保持 100%——这正是团队采用混合检索的原因。

规模化部署的成本对比

按每天 10 万到 100 万轮问答估算，DeepSeq 每月成本约 1.8 万至 18 万美元。以 1000 名学生规模计，Gemini 约 4 万美元/月，而 DeepSeq 仅约 1900 美元/月，本地部署则进一步省钱（虽有吞吐限制）。

最终决策与核心启示

综合所有实验，Towards AI 的最终选择是：采用 DeepSeq V4 Flash + 混合检索，在记忆策略上"尽量保留全部"，仅设定 30K token 的压缩阈值作为兜底。

这场研究最重要的启示可以浓缩为一句话：

不要默认就去压缩上下文。先明确你的约束条件，再寻找更优的替代方案。

具体而言：

记忆保留：保留完整聊天历史的细节回忆率达 95%，摘要仅 32%；
长上下文稳定性：单一事实检索即便到 800K token 也很轻松，无明显腐烂；
单轮成本：发送 token 最多的配置往往最便宜，因为缓存让重发上下文极其廉价；
规模化部署：换用更便宜的模型和本地方案能大幅降本，但需权衡上下文窗口和吞吐限制。

压缩和摘要看起来很"聪明"，但在提示词缓存机制的博弈下，它们常常得不偿失。上下文工程的核心，或许更多是一门关于"何时不做什么"的艺术。