窗口从 32K 扩到 200K为什么答案反而更差因为真正稀缺的从来不是 token而是模型用于判断的注意力。1. 一个反直觉的故障先看一个 2025 年以来越来越常见的工程场景。一个团队做文档问答原先使用 32K 上下文窗口效果尚可但经常因为资料放不下而漏答。模型升级后窗口扩大到 200K团队顺势取消了大部分检索裁剪把所有相关文档、完整对话历史、工具返回结果一起塞进 prompt。直觉上信息越完整答案应该越准确。为叙述方便这个场景合并了多个团队遇到的类似问题不指代某一家公司。结果却相反。回答开始遗漏关键条款引用张冠李戴遇到互相矛盾的两份文档时倾向于复述更显眼的那一份与此同时首 token 延迟上升单次请求成本成倍增加线上重试率也变高。团队最初的判断是“模型变笨了”于是换模型、改 prompt、加 few-shot 示例折腾两周仍无明显改善。真正的问题不在模型而在上下文。更准确地说在于团队把“上下文窗口”误当成了“信息仓库”只要容量足够就可以无限堆放。窗口确实变大了但模型用于判断的注意力并没有同比例变大上下文中的每一段文字也不会因为“被放进去”就自动变成有效证据。这就是本文想论证的核心观点上下文工程的本质不是把更多信息塞进窗口而是在有限的注意力预算下最大化单位上下文的信息增益并最小化干扰、污染与成本。窗口大小是容量指标不是质量指标。把上下文当仓库系统会越来越臃肿把上下文当预算系统才可能越来越准确。2. 长上下文的三个幻觉2.1 窗口大小不等于可用容量厂商宣传的上下文长度通常指模型在技术上能够接收的最大 token 数而不是它能够稳定利用的长度。这两者之间存在显著差距。RULER 基准在 13 类任务上评估了 17 个长上下文模型结论相当直接所有被测模型都宣称至少支持 32K 上下文但只有大约一半在 32K 长度上表现可接受一些宣称支持 200K 的模型性能仍随输入变长而持续下降[3]。换句话说“支持 200K”描述的是接口上限不是有效工作区间。NoLiMa 把这一问题推得更远。它刻意降低问题与答案之间的字面重合要求模型通过间接关联找到信息而不是依赖关键词匹配。在 13 个宣称至少支持 128K 的模型中输入长度达到 32K 时有 11 个模型的成绩跌到短上下文基线的一半以下GPT-4o 从 99.3% 降到 69.7%[4]。这些数字说明长上下文能力并不是一条平滑延伸的曲线而更像一块会随任务难度、干扰强度和位置变化而收缩的“有效区域”。对工程实践的启示是不要把最大窗口当作设计目标而要把有效窗口当作容量规划的依据。一个 200K 窗口的系统如果关键证据经常落在模型注意力薄弱的区间它的实际可靠性可能还不如一个精心组织的 32K 系统。2.2 信息更多不等于判断更准“多给一点信息总没坏处”是上下文设计中一个危险的直觉。Liu 等人在 TACL 上发表的研究给出了经典反例在多文档问答和键值检索任务中当相关信息位于上下文开头或结尾时模型表现最好当它被放在中间时准确率显著下降。更关键的是这种“中间遗忘”并不是某个旧模型的偶发缺陷即使在专门为长上下文优化的模型上也能观察到[2]。Chroma 在 2025 年的《Context Rot》报告中进一步指出随着输入 token 增加多个主流模型即使在相对简单的任务上也会出现性能退化传统的“大海捞针”测试得分很高并不能证明模型具备真实的长上下文理解能力[5]。这类退化并不总是断崖式的它更像慢性中毒答案仍然成形语气仍然自信但细节开始漂移约束开始被忽略。指令密集的场景中退化更明显。IFScale 基准用 500 条“必须包含某个关键词”的指令测试了 20 个模型表现最好的前沿模型准确率也只有 68%而且模型普遍表现出对较早指令的偏好越靠后的要求越容易被牺牲[6]。这说明上下文不是一块均匀的画布模型对其中不同位置的敏感度并不相同。2.3 一次塞入不等于系统更简单把所有信息一次性塞进上下文表面上省掉了检索、排序、压缩和状态管理的复杂度实际上只是把复杂度转移到了模型内部并且以更贵、更慢、更难调试的方式呈现出来。Transformer 的自注意力计算随序列长度呈二次增长上下文翻倍计算与显存成本通常不是简单翻倍[15]。这还只是算力账。更大的上下文意味着更长的首 token 延迟TTFT、更高的单位请求成本、更大的 KV cache 显存占用、更复杂的缓存策略以及更大的故障面一段过期的记忆、一条被注入的恶意指令、一个格式错误的工具返回都可能长期滞留在上下文中持续污染后续推理。所以长上下文并不是“免费简化”。它把原本可以在系统层显式管理的选择、排序、淘汰和验证变成了模型层不可见的注意力竞争。工程上看似少写了代码运维上却多了一堆无法解释的失败。3. 从提示词工程到上下文工程Anthropic 在 2025 年的一篇工程文章里将上下文工程context engineering概括为“在 LLM 推理过程中策划并维护最优 token 集合的策略”大意并强调它不只关乎 prompt 的措辞还关乎“所有可能进入上下文的其他信息”[1]。这个概括值得拆开理解对象是 token 集合动作是策划与维护目标是“最优”而不是“最多”。提示词工程和上下文工程并非替代关系更像不同层次的优化。前者主要关心“如何把任务说清楚”后者关心“模型在做出判断的那一刻眼前到底有什么”。前者偏重单次请求中的表达技巧后者是贯穿请求生命周期的资源调度。维度提示词工程上下文工程优化对象指令的措辞、示例、格式进入上下文的全部信息及其结构时间尺度单次请求多轮对话、长任务、跨会话核心问题模型是否理解任务模型是否拥有足够且干净的证据典型失败指令含糊、输出格式不稳证据缺失、干扰过多、上下文污染成功指标回答符合预期任务成功率、证据忠实度、单位 token 收益一个大语言模型LLM应用的上下文通常来自五类来源系统指令与约束、当前任务状态、外部证据检索结果、数据库、网页、文件、工具观察以及长期记忆。它们的重要性、可信度、时效性和生命周期完全不同却被很多系统粗暴地拼接成一个字符串。上下文工程要做的第一件事就是承认这些差异并给它们不同的预算和治理规则。我认为判断一个团队是否真正进入了上下文工程阶段有一个很简单的标准他们是否能回答“这段上下文为什么在这里”。如果答案是“因为它在数据库里”“因为它是最近十条消息”“因为 top-k 返回了它”那还停留在拼接阶段只有当答案变成“因为它能补上回答该问题所需的某个证据缺口且其可信度和时效性满足要求”上下文才真正被当作工程对象。4. 上下文为什么会“腐烂”要设计更好的上下文先要理解它是如何变坏的。下面四种机制经常叠加出现最终表现为“模型不听话”或“答案变差”。4.1 注意力稀释自注意力机制通常会在所有可见 token 上分配权重。上下文越长参与竞争的 token 越多相关证据获得的相对注意力就倾向于被稀释。更麻烦的是干扰项往往不是随机噪声而是与问题语义相近、格式相似、甚至包含相同实体名的内容。检索系统越“努力”地召回越可能把这类高相似度但低价值的段落送进上下文。这并不意味着模型无法处理长上下文只是说“相关 token 的注意力份额”会随上下文构成而变化。Anthropic 也指出token 数量增加会让注意力计算量呈二次增长并讨论了长输入下召回能力下降的现象[1]。工程上不能假设模型会像数据库查询一样精确地定位每一条信息它更像一个在噪声中做加权的读者噪声越多读错的概率越高。4.2 位置偏差“Lost in the Middle”揭示的 U 形曲线说明信息放在开头和结尾更容易被利用放在中间更容易被忽略[2]。这与人类的序列位置效应有相似之处但在 LLM 上表现得更加机械关键约束如果埋在一大段背景材料之后模型可能在前半段就已经“决定”了答案后续内容只是被用来佐证既有判断。位置偏差对上下文编排有直接影响。重要的系统约束应放在稳定的前部并在结尾以简短形式复述证据应按任务相关性排序而不是按数据库返回顺序堆放对于超长文档应先给出结构索引和章节摘要再放置最关键的原文片段。结构不是装饰它会改变模型阅读和分配注意力的方式。4.3 干扰与冲突真实企业数据很少是干净的。同一份政策可能有新旧两个版本同一客户可能在 CRM 和工单系统里有两个地址同一指标可能因统计口径不同而有两个数值。把这些内容同时放进上下文模型并不会自动成为事实核查员它更可能选择表述更流畅、位置更靠近问题、或与提问措辞更相似的那一份。IFScale 发现的“偏向较早指令”说明冲突不仅发生在事实之间也发生在约束之间[6]。当系统提示说“只输出 JSON”中间又插入一段来自网页的“请用自然语言总结”时模型未必知道后者不属于系统指令它最终服从哪一条取决于位置、措辞显著性和上下文结构而不是我们期望的权威顺序。上下文工程必须显式标注来源、时间和权威级别并在冲突无法消解时让模型输出不确定性而不是强行编造一个统一答案。4.4 误差累积与上下文崩塌多轮 agent 场景里错误会沿着上下文累积。一次工具调用返回了错误字段模型在下一轮把它当作事实继续推理一次摘要漏掉了关键否定词后续所有结论都建立在相反的语义上。ReAct 式的“推理—行动—观察”循环让模型能借助外部工具纠错但每一次观察也会成为下一轮上下文的一部分因此对观察结果的清洗和验证不能省略[13]。更隐蔽的是“上下文崩塌”如果系统反复用摘要替换历史摘要的偏差会一代代放大最终丢失领域细节。Agentic Context EngineeringACE将这种现象描述为迭代重写导致细节侵蚀并把“为了简洁而丢弃领域洞察”称为 brevity bias[14]。因此压缩不是没有代价的。每一次摘要都是一次有损的重新创作压缩率越高越需要保留可回溯的原始证据锚点。对于金额、日期、法律条款、医疗剂量这类高风险信息宁可保留原文片段也不要用一段“看起来更简洁”的摘要替代。需要说明的是上述机制来自不同模型、不同任务和不同评测条件不能简单外推为“所有长上下文都必然变差”。其中RULER、NoLiMa 和“Lost in the Middle”属于经过同行评审的研究IFScale 是预印本Chroma 与 Anthropic 的报告则属于工业界证据结论应结合自身模型和任务重新验证。尽管证据等级不同它们指向同一个工程结论上下文的质量取决于选择、结构和验证而不只取决于长度。这也是上下文工程存在的理由。5. 把上下文当预算四个账户如果把上下文视为预算那么至少要同时管理四个账户。只盯着 token 数往往会做出局部最优、整体糟糕的决策。预算账户稀缺资源超支后的表现主要控制手段Token 预算窗口容量、显存、费用截断、成本上升、延迟增加分块、压缩、缓存、按需加载注意力预算模型对关键信息的关注中间遗忘、细节漂移、指令忽略排序、去重、结构化、减少干扰时间预算检索与推理延迟、数据新鲜度首 token 变慢、答案过期并行检索、缓存、TTL、增量更新信任预算来源可靠性与指令层级提示注入、错误传播、合规风险来源标注、权限隔离、冲突检测Token 预算是最容易量化的也是大多数团队唯一在管的。但真正决定答案质量的是注意力预算同样 8K token一份是结构清晰、证据密度高的材料另一份是重复、矛盾、夹杂大量无关内容的材料模型的表现可能完全不同。时间预算则提醒我们上下文不是越新越好也不是越全越好更重要的是匹配任务的时效要求。信任预算最容易被忽视把网页抓取内容、用户上传文件和系统指令放在同一个层级本身就是一种安全设计缺陷。可以用一条启发式规则来衡量某个上下文片段是否值得保留一个片段的价值 ≈ 它使正确答案概率提升的幅度 − 它带来的干扰、成本与风险。这个式子不需要精确计算它的作用是改变讨论方式。团队不再问“还能不能再加一点”而是问“加了它模型的判断会变好吗如果删掉它答案会变差吗”后者尤其重要因为删掉之后毫无变化的上下文本质上只是昂贵的噪声。6. 上下文编译器选择、结构化、压缩、隔离、淘汰如果把上下文拼接看作字符串操作那么上下文工程应该被看作一次“编译”输入是任务、候选信息和预算输出是一份结构化、可验证、可追踪的上下文程序。它不是一个 prompt 模板而是一条流水线。flowchart LR A[任务与约束] -- B[查询规划] B -- C[候选召回] C -- D[重排与去重] D -- E[证据集] E -- F[结构化与压缩] F -- G[预算分配] G -- H[生成] H -- I[证据校验] I --|不通过| B I --|通过| J[输出与追踪]图 1 是数据流示意选择、结构化、压缩、隔离、淘汰这五个治理动作贯穿其中并不与图中节点一一对应。案例部分会把它展开为七个可执行阶段。这条流水线涉及五个核心动作。它们不必按顺序执行更像是五种可以组合的上下文治理策略。6.1 选择从 top-k 到证据集检索的第一目标不是“找全”而是“找够”。检索增强生成RAG的基本思想是把模型的参数化记忆与可更新的外部检索记忆结合起来让生成可以引用检索到的原文[7]。但很多实现把这一步简化成“用向量相似度取 top-k然后按分数拼接”。问题在于相似度衡量的是语义接近不是证据充分性。一个段落可能和问题高度相似却只是重复问题本身另一个段落可能措辞不同却恰好包含缺失的关键条件。更合理的做法是先做查询规划把用户问题拆成若干子问题识别需要的时间范围、实体、比较维度和约束再分别召回。召回阶段可以混合 BM25 与稠密向量前者擅长精确术语和编号后者擅长语义改写随后用 cross-encoder 或 LLM 重排按“是否直接支持某个子结论”而不是“是否像问题”打分。最后做去重和多样性约束避免十个段落其实来自同一份文档的相邻三句话。当然查询规划本身也有成本不是所有问题都值得拆解简单事实查询可以走单轮快速路径复杂比较和跨文档总结才需要多步规划。GraphRAG 提供了一个有价值的补充对于“整个语料库在讲什么”这类全局性问题单纯的段落召回很难覆盖需要实体图谱和社区摘要来提供结构化视角[12]。但这不意味着所有场景都要上图谱图谱的构建和维护成本很高数据频繁变动时尤其不划算。选择策略应该由问题类型决定事实型问题需要精确证据比较型问题需要对齐维度全局型问题需要层次化摘要。把所有问题都交给同一个 top-k是检索设计中一种常见的偷懒。6.2 结构化让位置和边界参与推理结构化至少有三个作用降低歧义、提供可引用的锚点、帮助模型分配注意力。降低歧义靠的是明确的边界。用清晰的标题、分隔符和字段名把系统指令、用户输入、检索证据、工具返回分开避免模型把网页里的“忽略以上指令”当成系统要求。提供锚点靠的是稳定的证据编号例如[E1]、[E2]让模型在回答中引用也让校验器能够逐条核对。帮助注意力分配靠的是排序把最关键的约束放在开头把最相关的证据放在问题附近把次要背景放在后面并在结尾重申输出格式和禁止事项。一个常被忽略的细节是时间。对于政策、价格、版本说明这类内容结构化不只是加标题还要标注生效时间、抓取时间和版本号。模型无法可靠判断哪一版对当前任务生效除非上下文明确标注生效时间、版本关系和适用范围。结构化本质上是在把人类的领域知识编码进上下文布局让模型少做它不擅长的推断。6.3 压缩压缩的是注意力不是存储存储很便宜上下文很贵。因此压缩的目标不是节省磁盘而是提高单位 token 的信息密度让模型把注意力集中在真正重要的内容上。压缩有两条路线。抽取式压缩保留原文中的关键句子或片段优点是忠实、可引用缺点是可能不够连贯生成式压缩用模型重写或摘要优点是紧凑缺点是有损、可能引入幻觉并且会丢失原文中的限定条件。LLMLingua 通过预算控制和迭代式 token 压缩在多个基准上实现了最高 20 倍压缩而性能损失较小[9]RECOMP 则把检索文档压缩到低至原大小的 6%在语言建模和开放域问答上保持接近原性能[10]。这些结果说明压缩可以非常有效但它们的实验条件也提醒我们压缩策略必须针对任务训练或验证不能假设通用摘要器在任何领域都无损。我的经验法则是压缩导航信息保留证据原文。目录、背景介绍、重复的客套话可以大胆压缩金额、日期、否定词、适用范围、例外条款应尽量保留原文。历史对话也不必整段摘要更好的方式是把历史压缩成结构化状态用户目标、已确认事实、已排除选项、待解决问题。状态比摘要更不容易丢失关键约束也更容易被程序验证。6.4 隔离用边界换清晰隔离是上下文工程中常被低估的手段。它不是把信息藏起来而是让不同的任务在不同的上下文空间中处理避免相互污染。子智能体是一种典型实现。主智能体负责规划和最终决策子智能体在独立上下文中处理某个子任务只返回结构化结果。Anthropic 提到子智能体可能消耗数万 token 探索但最终只向主智能体返回约 1000 到 2000 token 的摘要[1]。这是一种用计算换上下文清晰度的交易探索过程很脏但返回结果很干净。隔离也适用于工具输出。网页、邮件、用户上传文件都是不可信内容不应与系统指令处于同一信任层级。更安全的做法是把工具返回放入带边界标记的“隔离区”先做内容清洗和指令剥离再决定哪些片段可以进入主上下文。多智能体系统尤其要避免“所有 agent 共享完整对话历史”这种设计那不是协作而是把每个 agent 的噪声复制了多份。当然隔离有成本。边界越多信息丢失和协调开销越大子任务之间的依赖如果很强拆分的收益可能抵不过通信成本。隔离的判断标准不是“能不能拆”而是“拆开之后每个子问题是否拥有独立、可验证的上下文”。6.5 淘汰遗忘是一项能力任何长期运行的系统都需要遗忘。把所有历史都保留下来不仅昂贵而且会让旧目标、旧约束和旧错误持续干扰当前任务。MemGPT 借鉴操作系统的分层内存思想把上下文分成快速但有限的工作区与较慢但更大的外部存储通过“虚拟上下文管理”在两者之间移动信息[11]。这个类比很有价值上下文窗口是内存不是硬盘记忆系统的核心不是“存了多少”而是“在需要时把什么换入、把什么换出”。淘汰策略不能只看新近程度。一个三个月前的架构决策可能比昨天的一句闲聊更重要一个已经完成的子任务可能不再需要保留全部过程但它的结论和证据链接应该留在长期记忆中。更合理的做法是给每个上下文块定义生存时间、重要性和可替代性临时工具输出很快过期用户偏好长期保留高风险决策的原始证据需要可追溯。淘汰不是删除知识而是把知识从“占用注意力”转换为“可按需取回”。7. 案例把 RAG 从“拼接”改成“编译”回到开头那个文档问答团队。一个典型的朴素 RAG 流程是把用户问题转向量检索 top-8 段落按相似度拼接附上系统提示交给模型回答。问题出现后团队的第一反应往往是增大 top-k、换更大的 embedding 模型或者直接升级长上下文模型。这些动作都可能在短期内提升召回却也让干扰和成本同步上升。把流程改成“编译”之后系统会多出几个显式阶段查询规划判断问题类型事实查询、条款比较、跨文档总结抽取时间、主体、版本等约束生成 1 到 3 个子查询。混合召回每个子查询同时走关键词检索和向量检索再用元数据过滤掉过期版本和低权限文档。重排与证据集构建按“是否直接支持子结论”重排去重保留来源和段落定位形成带编号的证据集。预算分配给系统指令、任务状态、证据、输出预留分别设定 token 上限证据不足时明确返回“无法回答”而不是用背景知识补全。结构化渲染按固定模板输出证据块每块包含来源、时间、可信级别和原文片段。生成与校验要求回答中的每个关键结论引用证据编号校验器检查引用是否存在、是否支持结论、是否遗漏了相互矛盾的证据。回流把校验失败的案例加入回归集调整检索、重排或压缩策略。举个例子。用户问“2025 年框架协议里数据泄露的通知时限和赔偿上限分别是多少”朴素 RAG 可能召回三段都提到“数据泄露”的文本其中一段来自已经废止的 2023 版编译流程则会先识别出这是一个跨条款比较任务需要“当前版本、通知时限、赔偿上限”三个证据槽再用版本元数据过滤旧文档分别召回对应条款最后在证据集中保留原文和生效日期。生成时模型只需要在有限的、已对齐的证据上做比较而不是在十段相似文本里自己发现版本冲突。可以用一段伪代码表示这个“上下文编译器”的核心逻辑def compile_context(task, budget): plan plan_query(task) # 拆解子问题与约束 candidates [] for subquery in plan.subqueries: candidates hybrid_retrieve(subquery) candidates recall_memory(subquery) ranked rerank(plan, dedupe(candidates)) # 按证据支持度排序 evidence select_evidence(ranked, budget.evidence) blocks [] for i, item in enumerate(evidence): blocks.append({ id: fE{i 1}, source: item.source, published_at: item.published_at, trust: item.trust_level, text: item.text, # 高风险内容保留原文 }) return render( instructionstask.constraints, statetask.state, evidenceblocks, output_schematask.schema, reservebudget.output, )注意这段代码里没有“把所有东西拼起来”的步骤。每一个进入最终 prompt 的块都要先经过选择、排序、预算分配和结构化。伪代码省略了错误处理和缓存但它展示了一个关键转变上下文是编译产物不是原始数据的堆叠。预算分配也需要从“拍脑袋”变成显式配置。即使模型支持 200K 窗口这个问答请求也可以只分配 8K token 的总预算输入 输出例如区域示例预算token说明系统指令与安全约束800稳定前缀便于缓存当前任务状态600目标、约束、已确认事实检索证据5000按子问题分配保留引用锚点输出格式与示例400只保留必要示例输出预留1200防止生成被截断这些数字不是标准答案而是一种预算意识的体现。真正重要的是当证据超预算时系统必须做选择而不是让框架在尾部静默截断。尾部截断危险的地方在于它往往截掉的正是最新、最具体、最可能包含例外条款的那部分内容。改造后的收益不一定立刻体现在“答案准确率”上。更早出现的变化通常是引用可核对、失败可解释、成本可控制、回归可复现。团队终于能回答“为什么这次答错了”而不是只能把整段 prompt 打印出来对着几千 token 发呆。8. 如何评测从答案准确率到上下文因果性如果只用一个端到端的答案准确率来评价上下文策略我们很难知道问题出在检索、排序、压缩还是生成。上下文工程需要一套更接近因果推断的评测方法。RAGAS 提供了有价值的起点它把 RAG 质量拆成 context relevance、faithfulness、answer relevance 三项分别对应检索到的上下文是否相关、生成是否忠实于上下文、答案是否回应了问题[8]。RAGAS 框架后续还提供了 context precision、context recall 等实现级指标。这些指标比单一准确率更能定位问题但它们仍然主要描述“结果好不好”而不是“上下文中的哪一部分导致了结果”。我建议在离线评测中加入四类“反事实测试”测试操作期望结果能发现的问题证据删除删掉某条关键证据准确率明显下降模型是否真的在使用证据证据替换换成过期或错误版本模型应识别冲突或拒绝回答是否盲目信任上下文干扰注入加入语义相近但无关的段落准确率应基本稳定上下文抗干扰能力位置扰动把关键证据在首/中/尾之间移动性能波动应尽可能小位置偏差与编排问题这四类测试对应两个核心属性证据敏感性和干扰鲁棒性。一个好的上下文系统应该对关键证据敏感对无关干扰鲁棒。只有敏感性没有鲁棒性系统会被噪声带偏只有鲁棒性没有敏感性说明模型根本没在用检索结果RAG 只是装饰。在线指标也应围绕“单位上下文的生产力”设计而不是只看总量。例如可以跟踪在同一评测集上每 1000 个输入 token 的成功任务数、一次成功率、重试率、人工升级率、p95 延迟、每次成功任务的综合成本、引用可验证率。把这些指标与上下文策略版本绑定才能判断一次改动究竟是在优化系统还是只是把成本转移到了另一个环节。线上比较时最好用 A/B 测试固定模型和任务分布只改变上下文策略否则很容易把模型升级的效果误归因于上下文改动。还有一点常被忽略记录上下文清单。每次请求应至少记录哪些证据块被选中、各自多少 token、来源和版本、检索分数、最终是否被引用。这样做的好处不是增加日志而是让“上下文”从不可见的 prompt 字符串变成可审计的工程对象。发生事故时团队能快速回答“当时模型看到了什么”而不是只能复现一个模糊的对话。9. 五个常见的反模式反模式一全量历史。把全部对话历史原样带入认为这样最安全。结果是旧目标、旧约束和旧错误持续干扰当前任务成本和延迟同步上升。更好的做法是把历史压缩成结构化状态只保留与当前任务相关的决策、事实和未决问题。反模式二摘要一切。为了省 token把所有检索结果和历史都换成摘要。摘要确实能降低长度但它会丢失限定条件、否定词和例外条款反复摘要还会导致细节逐代侵蚀[14]。更合理的策略是“导航信息摘要化关键证据原文保留”。反模式三top-k 越大越好。召回数量增加会提高覆盖率但也会引入更多语义相近的干扰项并稀释注意力。真正应该优化的是证据集的充分性和多样性而不是 k 的大小。先定义“回答这个问题最少需要哪几类证据”再决定召回和重排策略。反模式四工具输出原样回灌。把网页、邮件、日志、数据库返回直接拼进上下文既不清理格式也不标注信任级别。这既浪费 token也带来提示注入和错误传播风险。工具输出应该先经过解析、裁剪、脱敏和信任标记再进入主上下文。反模式五多智能体共享完整上下文。认为多个 agent 看到同一份完整历史就能更好协作。实际上这会把每个 agent 的噪声和错误复制多份并让上下文边界失效。更合理的做法是让每个 agent 拥有独立、最小的上下文通过结构化消息传递结论和证据而不是传递整段思维过程。这些反模式的共同点是把“更多信息”误认为“更好信息”。上下文工程的第一个动作往往不是加而是删不是扩大窗口而是缩小每个 token 的职责范围。10. 结语更少的上下文更好的判断回到最初的问题为什么上下文窗口变大了系统反而更差因为窗口扩大解决的是“能不能放进去”而系统效果取决于“模型有没有把注意力放在正确的地方”。前者是容量问题后者是预算问题。上下文不是仓库而是预算。它至少包含 token、注意力、时间和信任四个账户。一个成熟的 LLM 应用不会问“还能塞多少”而会问这段信息是否直接支持某个结论它是否比其他候选更可靠、时效性更好它放在什么位置最容易被正确使用如果删掉它答案会变差吗它是否来自一个可信、可追溯的来源这些问题没有一次性的标准答案。它们需要评测、观测和迭代需要把上下文从“prompt 工程师的手感”变成“系统设计的一部分”。但方向是清晰的更少的上下文更高的信息密度更明确的边界更可验证的证据。最终优秀的 LLM 系统不是读得最多的系统而是最清楚什么不该读的系统。模型的能力决定了它能走多远上下文的质量决定了它每一步是否走在正确的路上。参考文献[1] Anthropic. Effective context engineering for AI agents. 2025-09-29. https://www.anthropic.com/research/effective-context-engineering-for-ai-agents[2] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., Liang, P. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12: 157–173, 2024. https://aclanthology.org/2024.tacl-1.9/[3] Hsieh, C.-P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., Zhang, Y., Ginsburg, B. RULER: Whats the Real Context Size of Your Long-Context Language Models? COLM 2024. https://arxiv.org/abs/2404.06654[4] Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S., Schütze, H. NoLiMa: Long-Context Evaluation Beyond Literal Matching. ICML 2025. https://arxiv.org/abs/2502.05167[5] Chroma Research. Context Rot: How Increasing Input Tokens Impacts LLM Performance. 2025. 报告页面https://www.trychroma.com/research/context-rot代码与数据https://github.com/chroma-core/context-rot[6] Jaroslawicz, D., Whiting, B., Shah, P., Maamari, K. How Many Instructions Can LLMs Follow at Once? arXiv:2507.11538, 2025. https://arxiv.org/abs/2507.11538[7] Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-t., Rocktäschel, T., Riedel, S., Kiela, D. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. https://arxiv.org/abs/2005.11401[8] Es, S., James, J., Espinosa-Anke, L., Schockaert, S. RAGAs: Automated Evaluation of Retrieval Augmented Generation. EACL 2024 System Demonstrations, pp. 150–158. https://aclanthology.org/2024.eacl-demo.16/[9] Jiang, H., Wu, Q., Lin, C.-Y., Yang, Y., Qiu, L. LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. EMNLP 2023. https://arxiv.org/abs/2310.05736[10] Xu, F., Shi, W., Choi, E. RECOMP: Improving Retrieval-Augmented LMs with Compression and Selective Augmentation. ICLR 2024. https://arxiv.org/abs/2310.04408[11] Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., Gonzalez, J. E. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560, 2023. https://arxiv.org/abs/2310.08560[12] Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., Truitt, S., Metropolitansky, D., Ness, R. O., Larson, J. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130, 2024. https://arxiv.org/abs/2404.16130[13] Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. https://arxiv.org/abs/2210.03629[14] Zhang, Q., Hu, C., Upasani, S., Ma, B., Hong, F., Kamanuru, V., Rainton, J., Wu, C., Ji, M., Li, H., Thakker, U., Zou, J., Olukotun, K. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. ICLR 2026. https://arxiv.org/abs/2510.04618[15] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., Polosukhin, I. Attention Is All You Need. NeurIPS 2017. https://arxiv.org/abs/1706.03762