企业官网建设流程全解析

窗口从 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 集合，动作是策划与维护，目标是“最优”，而不是“最多”。

提示词工程和上下文工程并非替代关系，更像不同层次的优化。前者主要关心“如何把任务说清楚”，后者关心“模型在做出判断的那一刻，眼前到底有什么”。前者偏重单次请求中的表达技巧，后者是贯穿请求生命周期的资源调度。

一个大语言模型（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 Engineering（ACE）将这种现象描述为迭代重写导致细节侵蚀，并把“为了简洁而丢弃领域洞察”称为 brevity bias[14]。

因此，压缩不是没有代价的。每一次摘要都是一次有损的重新创作，压缩率越高，越需要保留可回溯的原始证据锚点。对于金额、日期、法律条款、医疗剂量这类高风险信息，宁可保留原文片段，也不要用一段“看起来更简洁”的摘要替代。

需要说明的是，上述机制来自不同模型、不同任务和不同评测条件，不能简单外推为“所有长上下文都必然变差”。其中，RULER、NoLiMa 和“Lost in the Middle”属于经过同行评审的研究，IFScale 是预印本，Chroma 与 Anthropic 的报告则属于工业界证据，结论应结合自身模型和任务重新验证。尽管证据等级不同，它们指向同一个工程结论：上下文的质量取决于选择、结构和验证，而不只取决于长度。这也是上下文工程存在的理由。

5. 把上下文当预算：四个账户

如果把上下文视为预算，那么至少要同时管理四个账户。只盯着 token 数，往往会做出局部最优、整体糟糕的决策。

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. 查询规划：判断问题类型（事实查询、条款比较、跨文档总结），抽取时间、主体、版本等约束，生成 1 到 3 个子查询。

2. 混合召回：每个子查询同时走关键词检索和向量检索，再用元数据过滤掉过期版本和低权限文档。

3. 重排与证据集构建：按“是否直接支持子结论”重排，去重，保留来源和段落定位，形成带编号的证据集。

4. 预算分配：给系统指令、任务状态、证据、输出预留分别设定 token 上限，证据不足时明确返回“无法回答”，而不是用背景知识补全。

5. 结构化渲染：按固定模板输出证据块，每块包含来源、时间、可信级别和原文片段。

6. 生成与校验：要求回答中的每个关键结论引用证据编号；校验器检查引用是否存在、是否支持结论、是否遗漏了相互矛盾的证据。

7. 回流：把校验失败的案例加入回归集，调整检索、重排或压缩策略。

举个例子。用户问：“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": f"E{i + 1}", "source": item.source, "published_at": item.published_at, "trust": item.trust_level, "text": item.text, # 高风险内容保留原文 }) return render( instructions=task.constraints, state=task.state, evidence=blocks, output_schema=task.schema, reserve=budget.output, )

注意，这段代码里没有“把所有东西拼起来”的步骤。每一个进入最终 prompt 的块，都要先经过选择、排序、预算分配和结构化。伪代码省略了错误处理和缓存，但它展示了一个关键转变：上下文是编译产物，不是原始数据的堆叠。

预算分配也需要从“拍脑袋”变成显式配置。即使模型支持 200K 窗口，这个问答请求也可以只分配 8K token 的总预算（输入 + 输出），例如：

这些数字不是标准答案，而是一种预算意识的体现。真正重要的是：当证据超预算时，系统必须做选择，而不是让框架在尾部静默截断。尾部截断危险的地方在于，它往往截掉的正是最新、最具体、最可能包含例外条款的那部分内容。

改造后的收益不一定立刻体现在“答案准确率”上。更早出现的变化通常是：引用可核对、失败可解释、成本可控制、回归可复现。团队终于能回答“为什么这次答错了”，而不是只能把整段 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: What's 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