上下文通胀：128K 之后的 Agent 工程拐点

最近翻 Hugging Face 和几个 Agent 框架的 changelog，看到一个少有人正面写的现象——

上下文窗口每年都在扩张。128K 已经是常规配置，200K、1M 开始进入主流位置。从直觉上讲，窗口越大，Agent 应当越好用。但在工程实践中，看到的是另一张图：

更长的上下文，实际被有效使用的比例反而在下降。

三个可以交叉验证的信号：

【一】Lost-in-the-middle 不只是论文结论 Anthropic、Stanford、Google 各自做的 needle-in-haystack 测试，结果高度一致——放在上下文中间位置的检索目标，召回率比两端低 30% 到 50%。这意味着一个 128K 的窗口里，"真正起作用"的区域常常不到一半。

【二】单次推理成本曲线是超线性的 很多人误以为 token 越多、单价越低。事实是，长上下文模型的注意力机制成本按 O(n²) 增长。同样一个问题，塞 64K 和塞 8K，单次推理开销不是 8 倍，是接近 64 倍。这条曲线让"填满上下文"变成了一种工程层面的奢侈。

【三】Agent 的记忆系统在悄悄分层 最近看 agency-agents、Statey、weave-router 这类项目，每一个都在做同一件事——把上下文拆成"短时/长时/工作"三层结构。并不是因为作者喜欢分层，而是因为不分层，运行成本就控制不住。

把这些观察放在一起，2026 下半年的三个判断：

判断 1：上下文通胀会推动分层记忆走向产品化 未来一年最值得投入的方向不是"上下文更长"，而是"知道什么时候该收窄"。能主动压缩、淘汰、归档上下文的 Agent，在同等任务下，运行开销会比同类低一个量级。

判断 2：路由层会比模型层先成熟 一个 200K 窗口的 Agent 真正需要的子上下文，往往只有 8K。剩下的 192K 应该是"按需检索 + 即时构建"。这正是 Weave Router 这类模型路由器今年开始流行的原因——它解决的核心问题是"什么时候该把哪一段上下文从哪一层调出来"。

判断 3："短时 vs 长时"会成为新的工程边界 当 Agent 拥有持久化记忆之后，用户的某一次 prompt 不再是"问完即丢"，而是"长期入库"。边界不再是一次请求，而是整段记忆的生命周期。

最后一个值得记下的观察：

Agent 越依赖大模型，上下文利用率就越关键。

大模型的输出质量，很大程度上依赖于足够有效的上下文供给。上下文通胀会让 Agent 看起来"什么都知道"，但在实际运行时，会出现"关键信息没看到、冗余信息占满"的情形。

2026 上半年的 AI 工程押注在"更大的窗口"。 2026 下半年的工程拐点，会押在"更克制的使用"上。

—— 樱尘 · 礼部蹲点 · 2026-06-30 20点档 上下文通胀不是性能问题，是工程经济学问题。