长上下文窗口竞赛降温：记忆力没换来预期生产力
窗口大了，不等于用满了
基准测试常给出漂亮的数字：模型在满窗口的百万 token 基准上拿到高分。但生产使用是另一回事。有团队对上千次智能体会话做诊断，发现 GPT、Claude 与 Gemini 的有效上下文利用率只在 54% 到 61% 之间。模型对开头和结尾权重更高，中间部分容易模糊，这就是经典的"迷失在中间"，长文档中部的信息常被忽略。
工具协议成了隐藏税
更隐蔽的是 MCP 这类工具协议带来的开销。每次工具调用会把定义、schema 与返回数据塞进上下文，一个中等工作流十几二十次调用就能吃掉十万级 token，而真正与任务相关的可能只有三成。工具调用的便利性，在账单上是一笔反复出现的隐性支出，基准对比通常不会把它算进去。
厂商也在补短板
正视问题后，厂商开始把上下文当成工程课题而非营销数字。谷歌 Gemini 4 Argon 把单次输出上限拉到 100 万并给出约 95% 的缓存折扣，试图摊薄多轮智能体循环的账单；国内蚂蚁开源的 Ling-3.1-flash 也把上下文上限设到 1M，主打"智效比"而非单纯堆长度。方向都是从"更大"转向"更省"。
架构层面的两个结论
一是上下文压缩成了头等工程事项，把利用率从六成提到八成，可能就是盈利管线与亏损管线的分界；二是网关级缓存不再可选项，把重复注入的 schema 去重，单次会话 token 可降七成。对跑规模智能体的团队，这是实打实的成本线，而非锦上添花。
如何看待这场竞赛
更大的窗口不必然等于更好的表现，它只是给了浪费更多钱的头顶空间。真正有趣的工程问题，是让模型用更少的上下文做更多事。把窗口大小当卖点看，已经不够；能证明有效利用率与单位成本，才是下一阶段的硬指标，也是采购时该追问的细节。
给工程团队的行动项
若你正在跑规模化的智能体，三件事值得马上做：给每次会话记录有效上下文利用率，把它变成看板指标而非黑箱；部署带 schema 缓存的网关，把重复注入的工具定义去重，单次会话 token 往往能降七成；并在提示与路由层做上下文压缩，只保留任务相关的近因与远端信息。这三项加起来的回报周期常以周计，远比继续追求更大的窗口来得实在。对大多数团队来说，先把利用率这张表建起来，比急着换更大窗口的模型更有性价比，也更能暴露真实瓶颈。
