第六章　信息约束：Context 作为有限带宽信道

核心命题：从信息论角度，Context 窗口是 Harness 与 LLM 之间的一条有限容量信道——带宽有限（token 上限）、传输有损（压缩引入信息损失）、信息价值不对称（不同内容对任务的贡献差异悬殊）。理解这条信道的约束结构，是理解为什么 Context Engineering 需要分层策略、淘汰机制与 Compaction 设计的理论前提。

本章不追求信息论的系统性综述，而是选取三个与 Context Engineering 直接相关的理论支柱展开：Rate-Distortion 揭示了压缩的结构性必然（§6.1）；信道容量与互信息确立了意图传递的理论上界（§6.2）；最小描述长度原则则为信息密度的度量提供了可操作的框架（§6.3）。§6.4 将三者汇合为一个统一的工程命题——信息价值在 Context 中的结构性不均匀分布——作为后续工程策略（第八章）的直接前提。

6.1　Rate-Distortion：有损压缩的结构性必然

理论起点

Rate-Distortion 理论由 Shannon 在 1959 年提出，研究的核心问题是：在允许一定失真（Distortion）的前提下，最少需要多少比特（Rate）来表示一个信源？形式化地，对于信源 XX，失真度量 d(x,x^)d(x, \hat{x})，以及允许的最大平均失真 DD，Rate-Distortion 函数定义为：

R(D)=min⁡p(x^∣x):E[d(X,X^)]≤DI(X;X^)R(D) = \min_{p(\hat{x}|x): \mathbb{E}[d(X,\hat{X})] \leq D} I(X; \hat{X})

其几何意义是：以失真 DD 为横轴、最小传输率 RR 为纵轴，R(D)R(D) 是一条单调递减的凸曲线（Rate-Distortion 曲线）。曲线的斜率反映了”多容忍一单位失真能换回多少比特的压缩收益”。当曲线进入平坦段，继续增加失真也难以显著减少所需比特数；当曲线进入陡峭段，少量失真的代价是大量信息丢失。

在 Context Engineering 中，这个问题的对应形式是：在可接受的质量损失范围内，如何用最少的 token 表达最多的有效信息？

三个对 Context Engineering 直接有用的理论推论

推论一：存在最优压缩率（帕累托拐点）

对于特定任务，token 使用量存在一个”帕累托拐点”——超过这个点继续增加 token，质量提升的边际收益趋近于零，但成本线性增长。这对应 Rate-Distortion 曲线从陡峭段进入平坦段的转折处。

这个推论的实践含义并不是”越少越好”，而是反对两种极端：一是盲目堆砌内容——把所有相关文档、所有历史对话、所有工具描述全部塞入 Context，不仅浪费成本，还会稀释高价值信息的有效权重；二是过度压缩——为追求 token 节省而删去必要细节，使模型缺乏完成任务所需的基本语境。帕累托拐点因任务类型而异：代码生成任务对精确上下文敏感，拐点靠后；开放式问答任务对背景信息容忍度更高，拐点靠前。

推论二：有损压缩是结构性必然，而非工程失误

当 Context 逼近 token 上限时，信息压缩（Compaction）不可回避。Rate-Distortion 定理的核心结论是：当目标编码率低于 R(D)R(D) 时，期望失真不可能被压制在 DD 以内——失真不是工程实现的瑕疵，而是 Rate 与 Distortion 之间数学边界所要求的代价。

这个结论有时被误读为”Compaction 是不得已的退而求其次”。正确的理解是：失真是数学边界，不是工程设计失误。一旦接受这个前提，工程问题就从”如何避免失真”变成”如何控制失真的方向与幅度”——允许哪些信息失真、在何处失真、以多大幅度失真，这是可以主动设计的。被动截断是最糟糕的失真策略，因为它没有任何对失真方向的控制。

推论三：选择性保留优于随机截断

最优有损压缩不是随机丢弃内容，而是保留信息量最高的部分、允许信息量低的部分失真。Rate-Distortion 理论的最优解总是倾向于将”失真预算”集中分配给信源中熵最低（即信息冗余度最高）的部分，而对高熵部分（不可预测、高信息密度的部分）保持较高保真度。

这为 Context 的分层设计与淘汰策略提供了理论基础：应当保留信息密度高的内容，淘汰信息密度低的内容，而非均匀截断。具体而言：

  • 系统提示中的任务定义、约束规则、角色设定——信息密度极高，接近无损保留
  • 近期对话轮次与直接相关工具调用结果——信息密度高，优先保留
  • 早期对话中的闲聊与重复确认——高冗余，可摘要或淘汰
  • 大段原始文档中与当前任务无关的段落——冗余度高，可截断

这个优先级排序不是经验直觉，而是 Rate-Distortion 最优压缩策略的工程映射。

失真度量的选取：一个被忽视的设计决策

Rate-Distortion 理论的另一个工程启示常被忽视：失真度量 d(x,x^)d(x, \hat{x}) 的选取决定了压缩结果的质量方向。在音频压缩中，人类听觉的感知模型决定了哪些频率失真可被接受；在 Context 压缩中，“失真”的度量应当是”对任务输出质量的影响”，而非字面的 token 数差异。

这意味着：评估一段 Context 是否可以压缩，正确的问题不是”这段内容删掉后 token 减少了多少”，而是”这段内容删掉后模型输出的质量下降了多少”。两者并不等价——一段 100 token 的关键约束描述删去后，可能导致任务完全失败；而一段 500 token 的背景铺垫删去后，任务质量几乎不变。这正是信息价值不对称性的核心所在。

Rate-Distortion 给出的是”压缩侧”的边界——在 token 预算压力下能压到多紧。但 Context 还面临”传输侧”的边界：即使没有压缩问题，token 数也并不等价于”实际进入模型决策的信息量”。下一节转向这一侧，讨论信道容量与互信息如何刻画意图传递的理论上界。

6.2　信道容量与互信息：意图传递的理论上界

Shannon 信道容量定理的工程隐喻

Shannon 信道容量的一般定义是互信息在所有可能输入分布上的最大值：

C=max⁡p(x)I(X;Y)C = \max_{p(x)} I(X; Y)

信道编码定理由此给出：当传输速率 R<CR < C 时，存在编码方案使错误概率任意低；当 R>CR > C 时，错误不可避免。一个被广泛引用的特例是加性高斯白噪声（AWGN）信道，其容量取闭式：

CAWGN=Wlog⁡2(1+SN)C_{\text{AWGN}} = W \log_2\left(1 + \frac{S}{N}\right)

其中 WW 是带宽，S/NS/N 是信噪比。AWGN 公式之所以适合作为工程直觉的脚手架，是因为它把容量分解成了”带宽”与”信噪比”两个可独立讨论的因子——这两个因子在 Context 信道中各有清晰的对应物。

在 Harness 语境中，这个定理的工程隐喻是：Context 信道存在有效容量上界，超过这个上界，增加 token 反而会降低信息传递的有效性。“带宽”对应 token 上限（名义容量），“信噪比”对应注意力机制对各位置的有效权重——当低密度内容稀释了高密度信号在注意力分布中的权重，等价于压低了信道的有效信噪比，进而压低了实际可用的容量。

边界说明：信道容量定理来自带反馈或不带反馈的离散无记忆信道分析；将其类比到 LLM 的注意力机制是一个启发性模型——LLM 的”信道”既非无记忆也非线性，公式的定量形式不直接成立。本节使用这个类比来论证”为什么有效容量低于名义 token 上限”的结构性事实，不用于定量预测注意力权重的衰减幅度。

“Lost in the Middle”效应：有效容量衰减的实证证据

Liu et al.（2023, “Lost in the Middle: How Language Models Use Long Contexts”）的实证研究系统地揭示了这一现象：当关键信息被置于超长 Context 的中间位置时，模型的任务表现相比信息置于开头或结尾有显著下降。该研究覆盖多个开源与商用模型，但效应的具体幅度因模型、任务、Context 长度而异——以下结论以”位置依赖性存在且方向稳定”为前提，不依赖任一具体衰减曲线。这个现象在信息论框架下可以被理解为位置依赖的信道噪声——Context 信道的”信噪比”不是均匀分布的，而是在开头和结尾处最高、在中间处最低。

这个效应对 Context Engineering 有直接的布局策略含义：

  • 关键约束与任务定义应置于 Context 开头（高信噪比区域）
  • 最相关的参考信息应置于 Context 结尾（紧邻生成位置，注意力最集中）
  • 低优先级的背景信息若必须保留，可置于中间，但需接受其权重衰减的事实
  • 避免将多个关键信息分散在超长 Context 的中间段，这等同于将高价值信号发送到信道噪声最大的频段

互信息：Context Engineering 的形式化目标

互信息 I(X;Y)I(X; Y) 度量两个随机变量之间的信息共享程度，定义为：

I(X;Y)=H(X)−H(X∣Y)=H(Y)−H(Y∣X)I(X; Y) = H(X) - H(X|Y) = H(Y) - H(Y|X)

其中 H(⋅)H(\cdot) 是 Shannon 熵，H(⋅∣⋅)H(\cdot|\cdot) 是条件熵。直觉上，I(X;Y)I(X; Y) 回答的是：“知道 YY 之后，XX 的不确定性减少了多少？”

Context Engineering 的目标，在信息论框架下可以精确表达为：最大化意图与行动之间的互信息 I(意图;输出)I(\text{意图}; \text{输出})，在 token 预算 BB 的约束下：

max⁡ContextI(意图;输出)s.t.∣Context∣≤B\max_{\text{Context}} I(\text{意图}; \text{输出}) \quad \text{s.t.} \quad |\text{Context}| \leq B

展开这个优化目标：

I(意图;输出)=H(输出)−H(输出∣意图)I(\text{意图}; \text{输出}) = H(\text{输出}) - H(\text{输出} | \text{意图})

  • H(输出)H(\text{输出})：模型输出的边际熵，反映输出的多样性——过高意味着模型行为不可预测，过低意味着输出缺乏灵活性
  • H(输出∣意图)H(\text{输出} | \text{意图})：给定意图后输出的条件熵，反映意图传递的歧义性——这是 Context Engineering 最直接的优化对象，目标是将这一项压低

一个设计良好的 Context 应当做到：在意图明确的情况下，将 H(输出∣意图)H(\text{输出} | \text{意图}) 压缩到接近零——即模型知道”应该做什么”以及”应该怎么做”，输出空间被充分约束。而设计糟糕的 Context 的特征是：H(输出∣意图)H(\text{输出} | \text{意图}) 居高不下，模型面对相同任务产生高度不稳定的输出，不是因为任务本身有歧义，而是因为 Context 没有传递足够的约束信息。

这个优化目标不是工程经验的总结，而是信息论框架在 Context 设计问题上的直接推论。

互信息分解：诊断 Context 设计缺陷的分析工具

互信息的链式法则提供了一个诊断工具。将 Context 分解为多个组件 C=(C1,C2,…,Cn)C = (C_1, C_2, \ldots, C_n)（系统提示、工具描述、历史对话、当前任务等），则：

I(意图;输出∣C1,…,Ck−1)≥I(意图;输出∣C1,…,Ck)I(\text{意图}; \text{输出} | C_1, \ldots, C_{k-1}) \geq I(\text{意图}; \text{输出} | C_1, \ldots, C_k)

即增加 Context 组件不会减少互信息（数据处理不等式）。但这个不等式还告诉我们：当某个组件 CkC_k 与意图高度相关时，加入它能大幅减少条件熵；当 CkC_k 与意图无关时，加入它几乎不改变互信息，却消耗了宝贵的 token 预算。

这为 Context 组件的取舍提供了一个直观判断标准：对每个候选内容，追问”加入这段内容，是否能让模型更准确地理解意图、减少输出的歧义？“如果答案是否定的，这段内容的信息论贡献为零，应当首先被淘汰。

6.3　最小描述长度：信息密度的可操作度量

Kolmogorov 复杂度与 MDL 原则

信息量的终极度量是 Kolmogorov 复杂度 K(x)K(x)：一段内容 xx 的信息量，等于能够生成 xx 的最短程序的长度。Kolmogorov 复杂度不可计算（Turing 不可判定），但其工程近似——最小描述长度（Minimum Description Length，MDL）原则——提供了一个实践可用的框架。

MDL 原则的核心思想：最好的模型或描述，是在拟合数据的同时保持自身最简洁的那个。对于 Context Engineering，这个原则的翻译是：最好的 Context，是在传递完整任务意图的同时，使用尽可能少的 token 的那个。

边界说明：MDL 原则的严格版本以”比特”为度量单位，并假设描述长度可被精确计算。Context Engineering 中以”token”作为代理单位是一个启发性近似——token 不等价于比特，token 间存在统计依赖（一个 token 携带的边际信息低于其字面长度），且不同分词器会给出不同的 token 数。本节将 MDL 用作 Context 设计的判断启发，而非作为严格的优化目标。

信息密度的定义与度量

借助 MDL 思想，可以为 Context 的局部片段定义信息密度：

信息密度(ci)=ΔI(意图;输出∣ci)∣ci∣token\text{信息密度}(c_i) = \frac{\Delta I(\text{意图}; \text{输出} | c_i)}{|c_i|_{\text{token}}}

即：每消耗一个 token，能为意图传递贡献多少互信息增量。高信息密度的内容”以小博大”；低信息密度的内容”以大换小”甚至”以大换零”。

在实践中，这个度量无法精确计算，但可以近似评估：

  • 任务定义句（“你的目标是……”）：信息密度极高，每个 token 都在约束输出空间
  • 格式要求（“以 JSON 格式返回，字段包括……”）：信息密度高，强约束输出结构
  • 少样本示例（Few-shot）：信息密度中高，通过具体案例传递抽象模式，但存在冗余
  • 背景知识段落：信息密度中等，通常存在大量与当前任务无关的句子
  • 历史对话中的礼貌性寒暄（“好的，我明白了”）：信息密度接近零，高度冗余

冗余度与压缩收益

Shannon 熵的一个重要概念是冗余度（Redundancy）：信源实际使用的比特数与其熵之差。Shannon 在 1951 年对英语字母级冗余度的经典估计约为 50%；后续基于词级、句级语言模型的估计值在 50%–75% 区间——即日常文本中相当一部分内容在信息论意义上是可预测的、冗余的（具体数值依估计方法与语料而异）。

这个事实对 Context 压缩有直接意义：大多数 Context 片段存在相当大的无损或近无损压缩空间（注：以下压缩比为说明性示例，旨在量化呈现冗余度的工程含义，非实测基准）。历史对话的摘要往往能在损失不到 10% 信息量的情况下将 token 压缩到原来的 20%–30%；工具描述的精简往往能在保留功能语义的前提下减少 60% 以上的 token 消耗。这不是魔法，而是自然语言高冗余度的必然推论。

MDL 原则在 Context Engineering 中的终极建议因此是：在写入 Context 之前，先问”这段内容能被更短地表达吗？“，在淘汰 Context 之前，先问”这段内容携带了其他地方没有的信息吗？” 这两个问题一起，构成了信息密度驱动的 Context 管理策略的核心判断逻辑。

§6.1–§6.3 给出了三组工具：压缩的边界（R-D）、传输的边界（容量与互信息）、密度的度量（MDL）。三者各自作用于 Context 的某一侧面，但在工程决策中常常需要被同时调用。下一节将这三组工具汇成一个统一的工程命题——Context 中的信息价值是结构性不均匀的——并由此推导出 Context 不能被均匀对待的根本原因。

6.4　信息不对称性：为什么 Context 不能被均匀对待

信息价值的极端不均匀分布

前三节的理论分析共同指向一个实践结论：Context 中不同位置、不同类型的内容，其信息价值（对任务完成的贡献）呈现极端不均匀的分布。这不是偶然的工程观察，而是信息论的必然推断。

以一个典型的 Agentic 任务 Context 为例，假设总长度为 8000 token，粗略的信息价值分布可能如下：

组件Token 占比信息价值贡献信息密度
核心任务定义3%35%极高
关键约束与规则5%25%高
相关工具描述10%20%中高
近期 3 轮对话12%12%中
早期历史对话35%5%低
背景文档原文35%3%极低

这个分布的极端不均衡性——8% 的内容承载 60% 的信息价值——是 Context 管理策略不能依赖均匀截断的根本原因。均匀截断在最好的情况下是低效的，在最坏的情况下（恰好截掉任务定义）是灾难性的。

信息不对称性的三个来源

信息价值的不均衡分布源于三个相互叠加的机制：

来源一：语义层级不对称。任务定义、约束规则、角色设定等”元信息”对所有后续内容都有语义支配性——它们定义了信息解释的框架，是其他所有内容的语义锚点。失去这些锚点，其他内容的语义价值会大幅衰减。

来源二：时间衰减不对称。对于对话型任务，近期轮次携带的上下文信息通常远超早期轮次——因为早期的信息往往已经被近期轮次的内容所蕴含、更新或否定。这产生了一个自然的时间衰减梯度。

来源三：任务相关性不对称。即使在相同类型的内容（如背景文档）内部，与当前子任务直接相关的段落和与其无关的段落，其信息价值也可以相差一到两个数量级。检索相关性（RAG 的核心逻辑）本质上是在试图消除这种不对称性，只保留高相关性的内容。

信息不对称性对系统设计的结构性影响

理解信息价值的极端不均衡分布，可以推导出若干系统设计层面的结构性建议：

  • 分层存储而非扁平化：高价值、低冗余的内容（任务定义、规则）应当受到架构层面的”写保护”，不进入常规的 Compaction 流程；低价值、高冗余的内容（早期对话、背景文档）才是压缩操作的主要对象。

  • 压缩不等于摘要：对高密度信息进行摘要往往引入严重失真（因为其本身已经是高度浓缩的）；对低密度信息进行摘要则可以在几乎不损失信息量的情况下大幅节约 token。“什么该摘要、什么该保留原文”是一个信息密度问题，而非规模问题。

  • 检索优于堆砌：将完整知识库塞入 Context，信息密度极低（大量内容与当前任务无关）；检索最相关片段，信息密度显著提升。RAG 的核心价值不在于”让模型看到更多信息”，而在于”在 token 预算约束下提高 Context 的平均信息密度”。

与第八章的分工：本章建立信息论理论框架——Rate-Distortion 揭示压缩的结构性必然、信道容量确立意图传递的理论上界、互信息提供优化目标的形式化表达、MDL 原则给出信息密度的可操作度量、信息不对称性分析揭示均匀截断的根本缺陷。第八章将这些理论转化为可操作的工程策略：分层存储与淘汰机制的具体设计、上下文熵度量的实现方案、Compaction 流程的触发条件与执行策略、token 预算在不同 Context 组件间的分配模型。理论与工程之间的桥梁，是本章末尾引入的信息密度概念——它既有理论根基，又有工程可操作性，是两章之间的核心连接概念。

章末案例剖析

同一个代码安全审查任务，两种 Context 构建策略产生了截然不同的结果——差异不在于 Agent 的推理能力，而在于信道的使用方式：一种把有限带宽用在高密度信息上，另一种把大量带宽浪费在低密度冗余上。

任务设定：对一个包含 3,200 行改动的 PR 进行安全审查。diff 覆盖 23 个文件，改动分布不均——其中 18 个文件是无安全影响的 UI 样式与注释调整，2 个文件涉及输入验证逻辑，3 个文件修改了 SQL 查询构造方式（其中 1 处存在潜在的 SQL 注入漏洞）。Agent 可访问的材料：12 轮历史对话（包含前期架构讨论和已关闭的问题线索）、公司内部安全编码规范文档（45 页）、工具描述（静态分析工具、数据库访问工具等 6 个工具）。目标 G\mathcal{G}：识别所有高风险安全问题，生成结构化报告。

策略 A：扁平堆砌

将所有可用材料不加筛选地推入 Context：

组件Token 数信息价值（§6.4 估算）
系统提示（角色 + 审查标准）2,100极高
工具描述（6 个工具，含完整使用说明）4,800中
历史对话（12 轮完整记录）9,600低（前 9 轮已无关）
完整 diff（23 个文件）11,200极不均匀（3 个关键文件 vs 20 个无关文件）
安全规范文档（全文）38,400极低（大量段落与当前 PR 无关）
合计66,100—

Context 总长度 66,100 tokens。SQL 注入漏洞所在的文件（query_builder.py，约 180 行 diff）位于 Context 的第 56,000–57,200 token 区间——处于 Context 窗口的 84% 位置，已超出 “Lost in the Middle” 效应的高注意力区间。

执行结果：Agent 产出了一份 12 条评论的审查报告，覆盖了 UI 层的潜在 XSS 风险（位于 Context 靠前位置）和两处代码风格问题，未发现 SQL 注入漏洞。任务 G\mathcal{G} 未满足，高风险问题被遗漏。

失败的信息论解读：安全规范文档的 38,400 tokens 平均信息密度极低（其中约 30,000 tokens 与 SQL 安全无直接关联），但它的物理存在把高价值的 query_builder.py diff 推到了 Context 中段的低注意力区域。这不是模型的推理失败，而是信道使用方式的系统性错误——将高价值信号淹没在低密度噪声中，超过了信道的有效容量（§6.2）。

策略 B：信息密度驱动

对每个 Context 组件分别做信息密度评估，再决定保留、压缩或淘汰。

第一步：按信息不对称性分层（§6.4）

识别两类内容：高密度内容（任务定义、约束规则、安全关键 diff）——受”写保护”，不进入压缩流程；低密度内容（早期历史、背景文档、无关 diff）——进入压缩或淘汰。

第二步：Rate-Distortion 最优压缩（§6.1）

历史对话：轮次 1–9 已被近期轮次涵盖（早期架构讨论已有结论），处于 R-D 曲线的平坦段——高压缩比、低失真。将 9 轮历史（约 7,200 tokens）摘要为要点列表（420 tokens），保留近期 3 轮原文（2,400 tokens）。压缩比 7200:420 ≈ 17:1，信息损失估计 < 8%。

工具描述：6 个工具的完整使用说明中，有大量自然语言解释（高冗余）。压缩为函数签名 + 一行功能描述，保留参数约束。4,800 tokens → 960 tokens，功能语义完整保留（MDL 合规，§6.3）。

安全规范文档：不做全文摘要（全文摘要会破坏高密度的具体规则条目），而是用关键词检索提取与 SQL 构造、输入验证、参数化查询直接相关的章节片段。38,400 tokens → 1,800 tokens，相关章节原文保留，无关段落全部淘汰。

完整 diff：对 18 个 UI/注释文件生成逐文件的一行摘要（“纯样式调整，无逻辑变更”），对 2 个输入验证文件和 3 个 SQL 文件保留完整 diff 原文。11,200 tokens → 3,600 tokens（60 tokens 摘要 × 18 + 完整 diff × 5 个关键文件）。

第三步：位置感知布局（§6.2）

按 Lost in the Middle 效应将 Context 重新排列：

[Context 开头 — 高信噪比区域]
系统提示（角色 + 审查重点：SQL 注入、输入验证）  ← 2,100 tokens
安全规范：SQL 与输入验证相关章节（原文）         ← 1,800 tokens

[Context 中段 — 低信噪比区域，存放次要信息]
工具描述（精简版）                              ← 960 tokens
历史摘要（轮次 1-9）                           ← 420 tokens
UI/注释文件的逐文件一行摘要                     ← 1,080 tokens

[Context 结尾 — 高信噪比区域，紧邻生成位置]
近期历史对话（轮次 10-12，原文）                ← 2,400 tokens
安全关键文件完整 diff（query_builder.py 等 5 个文件）← 2,520 tokens

合计：11,280 tokens，SQL 注入漏洞所在 diff 位于 Context 末尾（最后 22% 位置），处于注意力最高的区域。

执行结果：Agent 在第一轮即定位到 query_builder.py 中未参数化的 SQL 拼接，输出了包含漏洞位置、触发条件和修复建议的结构化报告。任务 G\mathcal{G} 满足。

两种策略的量化对比

维度策略 A（扁平堆砌）策略 B（信息密度驱动）
Context 总长度66,100 tokens11,280 tokens（↓83%）
API 成本（input tokens）基准 × 1.0基准 × 0.17
SQL 漏洞所在位置Context 84%（低注意力区）Context 最后 22%（高注意力区）
任务完成（G\mathcal{G} 满足）否（漏报高风险）是
历史对话压缩（估算信息损失）无压缩17:1 压缩，< 8% 信息损失
安全规范利用率（token/价值）低（大量无关内容）高（仅相关章节，原文精确保留）

策略 B 以策略 A 17% 的 token 成本完成了策略 A 未能完成的任务。这不是”用更少 token 换来稍差结果”——而是用更少 token 换来了更好结果。两者的差距不来自成本投入，而来自信道利用方式的本质不同。

四节理论的工程落点

理论工具在本案例中的具体作用
Rate-Distortion（§6.1）历史摘要（平坦段：17:1 高压缩低失真）；工具描述精简（更平坦段）；判断何时压缩是净收益
信道容量与 Lost in the Middle（§6.2）将 SQL 漏洞 diff 从 Context 84% 移至末尾 22%，同等 token 下注意力权重大幅提升
MDL 与信息密度（§6.3）工具描述从自然语言说明压缩为签名+一行描述；安全规范检索提取而非全文摘要
信息不对称性（§6.4）识别出 38,400 tokens 文档中仅 1,800 tokens 具有高任务相关性，其余淘汰而非摘要

这个案例的核心结论是：Context Engineering 的目标不是”让模型看到更多信息”，而是在有限信道带宽内最大化 I(意图;输出)I(\text{意图}; \text{输出})——这是 §6.2 给出的形式化表达在工程决策中的直接体现。策略 A 的问题不在于信息不够多，而在于低密度内容侵占了高价值信号在信道中的最优位置，导致有效互信息严重低于 token 消耗所能支持的上界。