Agent 跑得越久、检索文档越长，LLM 上下文窗口正在成为新的计算瓶颈。NYU、Columbia、Princeton、马里兰、Harvard 与 LLNL 联合发布的 LCLM（Latent Context Language Models）走了一条新路线：用 0.6B 编码器把输入 token 序列压成更短的「潜变量」再交给 4B 解码器生成，压缩在 prefill 之前完成——压缩比直接折算为解码端算力和显存节省。 与 KV Cache 压缩的差别在于：主流方案要先 materialize 完整上下文再 evict，省的是存储而非解码端算力；LCLM 把整条压缩链路前置。论文在 RULER 长上下文基准上：4 倍压缩准确率 91.76%，相对 94.41% 的无压缩基线只掉 2.6 个百分点；16 倍压缩时为 75.06%，但生成速度比 KV Cache baseline 快 8.8 倍，所有被对比的 KV Cache 方法在同等压缩比下都更差。 训练上 0.6B + 4B 在 350B token 上端到端训练，反直觉的发现是「解码器尺寸比编码器更重要，资源应优先放给解码端」。模型已开源 HuggingFace，可作为「前置压缩器」嵌进 RAG/Agent 链路，研究者也演示了「选择性解压」——Agent 先扫读再聚焦关键段。 「上下文即成本」在 2026 年已是常识。LCLM 的真正贡献不在 8.8 倍这个数字，而在于它证明「对输入本身做端到端压缩」是一条比 KV Cache 修剪更彻底、可工程化的路线。4 倍压缩（2.6 个百分点精度损失）是 RAG/Agent 落地的甜点区间，16 倍更适合离线「先存后解压」类场景。对国内做长上下文优化的团队（DeepSeek V4 稀疏注意力、MIT CompreSSM、KVTC 等）来说，这篇论文给出的方向值得认真对照。