为什么每个“上下文层”工具都在谎报token节省量？
摘要
作者批评了新兴的上下文层和MCP优化器工具缺乏透明的基准测试，这些工具承诺大幅节省token，但实际测试却无法复现其声称的效率。他们敦促开发者要求公开、可复现的基准测试，并寻求真正能提供可衡量结果的工具推荐。
我做agent已经一年半了。最近，几乎每隔一个发布就是一个“上下文层”或“MCP优化器”，承诺能削减70-90%的token。我装了五个。情况如出一辙：* 没有方法论的README图表* “基准测试代码即将发布”* 节省效果只出现在演示语料库上，在我实际使用的、带有6个MCP服务器和140多个工具的Claude Code上却不见踪影如果你的工具真能大规模削减token，就把语料库、查询、种子、模型、成本都公开出来。其他的都只是个截图。我想找到一个真正管用的。可至今没见哪个能提供凭据。有人见过经得起严格检验的基准测试吗？
相似文章
@omarsar0: // The Efficiency Frontier // 关于上下文管理的有趣论文。随着代理在多次交互中重复使用相同的文档和历史记录……
本文介绍了The Efficiency Frontier，一个用于LLM上下文管理成本-性能优化的统一框架，它将上下文策略选择建模为一个部署感知的优化问题，通过摊销内存压缩，与全上下文提示相比，实现了25%的token使用量减少和超过50%的token成本降低。
使用上下文分析器优化LLM调用并减少Token使用
ContextSpy 是一款本地代理工具，用于分析 LLM 应用如何使用其上下文窗口，按类别细分 Token 使用情况，帮助开发者优化并降低成本。
令牌压缩幻象：为什么我对RTK持怀疑态度
本文批评了RTK，一种用于LLM代理的令牌压缩工具，认为其声称的60-90%成本节省具有误导性，引入了静默失败风险，缺乏严格的准确性基准，并且作为独立产品在结构上脆弱。
MCP已死？
对模型上下文协议（MCP）的技术批评，指出其消耗过多的上下文窗口令牌、运行可靠性低，且与现有CLI/API方法重叠。Quandri技术栈的测量显示上下文使用率达10.5%。
TokenPilot：面向LLM代理的缓存高效上下文管理
TokenPilot是一个双粒度上下文管理框架，通过稳定提示前缀和保守管理上下文片段，降低长时程LLM会话中的推理成本。在基准测试中实现了61-87%的成本降低，同时保持竞争性性能。