第 11 章 长上下文问题¶
上下文窗口变长，并不等于上下文问题自动解决。现实中的 Agent 系统恰恰相反：一旦可以塞更多信息，很多团队就会开始把问题延后处理，结果模型虽然“看起来都看到了”，但实际行为越来越不稳定。长上下文带来的，常常不是更强理解，而是更复杂的失真。
本章讨论的不是模型支持多少 token，而是当上下文持续增长时，系统会遇到哪些结构性问题，以及可以采用什么工程手段来减轻这些问题。
11.1 信息过载¶
最直接的问题是信息过载。只要输入里同时存在大量规则、历史、检索结果、工具说明和任务状态，模型就需要在一个过密的工作面里寻找真正重要的信号。即使它理论上“能看到”，也不代表它会稳定优先使用。
信息过载最常见的表现包括：
- 关键约束被忽略。
- 最新状态被旧历史覆盖。
- 证据存在但结论仍然依赖猜测。
- 工具描述被其他文本淹没。
本质上，这是注意力分配问题，而不是“没输入到模型里”的问题。
11.2 顺序偏置与位置衰减¶
长上下文的第二个问题，是位置信号不均衡。某些模型会更关注前部规则，某些模型在超长输入时会更依赖最近内容，某些模型则会对中段信息出现明显遗忘。
这意味着同一条信息放在不同位置，效果可能完全不同。工程上不能假设“只要内容存在，位置就无所谓”。对高优先级内容，应尽量保持稳定位置与稳定形式；对一次性补充信息，应尽量靠近当前任务相关段落，避免被历史噪声隔开。
11.3 历史膨胀¶
很多 Agent 系统的长上下文问题，最开始都来自历史膨胀。系统不断把聊天记录、工具结果和中间结论累加进去，久而久之，历史本身变成最大噪声源。
历史膨胀的危险在于，它会让系统产生一种幻觉：既然都保留了，就不会丢信息。实际上，模型面对的是越来越难用的输入，而不是越来越完整的记忆。历史如果不被提炼成结构化状态，最终只会拖垮当前决策质量。
11.4 压缩策略¶
处理长上下文，最常见的手段不是硬裁，而是压缩。有效的压缩通常包括：
- 把已确认结论提炼成短状态。
- 把无关历史从会话层移到存档层。
- 把长工具日志转成结构化摘要。
- 把重复证据合并成统一引用。
压缩的难点在于不能把关键不确定性一起压没。好的压缩不仅保留结论，还应保留“依据来自哪里”和“还有哪些未解决点”。
11.5 分层上下文¶
一个成熟的解决方案是分层上下文。系统不再试图让所有信息都同时处于同一输入层，而是把信息按稳定性和相关性划分：
- 顶层：规则与目标。
- 中层：当前阶段状态。
- 底层：按需召回的历史、知识和工具结果。
这样，模型每次面对的是一个较稳定的输入骨架，再叠加少量本轮特有信息，而不是一个从头到尾都在膨胀的大包。
11.6 本章小结¶
长上下文问题并不是“窗口不够长”那么简单，更常见的是信息过载、位置偏置、历史膨胀和压缩失真。一个工程上成熟的 Agent 系统，不会把上下文长度当作万能解法，而会通过压缩、分层和状态化设计，让模型始终面对一个能被稳定利用的工作面。
下一章会继续讨论，当上下文已经变成工程对象之后，团队到底该怎么调试它，才能知道问题出在信息没进来、进错了，还是进来了却没被用上。