~93%ctx_read 文件减少
探索不熟悉的代码
紧凑的视图帮助工程师定位相关代码。当调查转向实现时返回完整源代码。
映射和签名视图在所跟踪的使用中实现了大约 97% 的压缩。
Wavect · 客户故事
重复的上下文更少。贯穿软件服务团队的工作流。
Wavect 在客户和内部项目中使用了编码代理。代理衡量了 LeanCTX 在日常开发过程中改变的交付的上下文。
64.1%
跟踪使用量中的上下文更少
跟踪快照 · 2026 年 7 月 26 日准备之前
100
准备之后
35.9
上下文量按 100 索引。观察到的使用情况，而不是受控的生产力研究。
- 公司
- Wavect GmbH
- 环境
- 客户端和内部仓库
- 最强的聚合渠道
- 92.7% MCP 压缩
- 估计的 token 成本减少
- 56.6%
代理环境
代理的工作负载。
所跟踪的工作涵盖新构建、继承的系统、错误调查、集成和内部工具。它们带来了不同的来源和读取深度。
重复读取。
跨不断变化的项目。
每个项目切换都会带来新的代码、模式和配置。相同的材料在后续的读取和命令输出中会返回。Wavect 衡量了 LeanCTX 如何改变其代理接收到的上下文。
- 项目切换
- 工程师在切换项目、堆栈或交付阶段时会重复支付定位成本。
- 审查需求
- 常规的内容更改和安全敏感的后端更改不能共享相同的恢复和审查规则。
- 工具输出
- 包管理器、Git、测试、容器、爬虫和基础设施命令都成为模型输入。
操作更改
先阅读更少。
需要时扩展。
从最小的有用表示开始，当决策需要更多证据时扩展，并根据仓库而不是摘要进行验证。
- 01
定位代码
找到下一步决策所需系统的形状、可能的所有权和证据。
- 02
缩小上下文
使用缓存的上下文和紧凑的表示来缩小范围。
- 03
编辑前阅读
在进行精确编辑之前检查确切的源。当含义不确定时恢复原始数据。
- 04
检查测试输出
保留来自构建、测试和命令的信号。压缩噪声，保留失败。
- 05
验证更改
审查差异，运行测试，检查实际系统。压缩不批准工作。
减少的来源
节省的来源。
在文件和命令输出中，总共减少了 64.1%。MCP 工具流量占节省的 token 的大部分。三种重复的模式解释了结果。
- MCP 工具流量
- 89.7%
- Shell 集成
- 10.3%
89.7%来自 MCP 的节省
减少重复读取
长时间的会话会回顾相同的材料。缓存的重新读取和增量视图减少了需要再次提供多少上下文。
这是总节省的一部分，而不是缓存命中率的压缩率。
高达 99%最佳 shell 输出结果
关注命令输出
构建器、测试器、Git 和包管理器会产生冗长的输出。Shell 压缩保留了结果和可操作的失败，同时减少了周围的文本。
观察到的最高 shell 结果。它不是所有命令的平均值。
估计的经济效益
估计的成本影响。
在所跟踪的工作负载中，Wavect 估计将 token 成本减少了 56.6%。输入和输出数据描述了该估计的不同部分。
定价、模型组合和缓存处理会影响实际账单的外观。这些百分比是不可累加的。
估计的总体 token 成本减少56.6%
- 估计的输入 token 成本降低
- 64.1%
- 估计的输出 token 成本降低
- 33.3%
工作负载估计 · 非审计的投资回报率
在上下文中阅读结果
研究确立了什么。
这些结果描述了跟踪的上下文减少。它们并未确立更快的交付、更好的代码或在每个工作流程中相同的节省。
观察到的使用情况
快照涵盖了 Wavect 跟踪的项目组合。它不是一个受控的 A/B 实验，报告并未确立周期时间或吞吐量的提高。
估计的经济效益
成本数字是工作负载估计。模型价格、缓存输入定价、订阅和模型组合会影响实际发票。
已验证的工作
较小的上下文不确立正确性或安全性。精确的编辑需要原始来源；接受性仍然需要真实的差异、测试和审查。
特定于工作负载的结果
压缩因文件格式、重复性和集成而异。无法将峰值结果应用于每个仓库或每个代理任务。
纳入您评估的内容
评估您自己的工作负载。
最强的匹配是重复访问大型仓库或冗长的工具输出。同时衡量设置、恢复和审查的努力以及 token 减少。
强匹配
大型、重复的工作流程——长的代理会话、不熟悉的仓库、重复的读取和冗长的工具输出。
衡量
小但频繁的工作流程——单独的节省可能不大，但重复使总量变得有意义。
也许
大型一次性工作流程——压缩可以有帮助，但设置、审查和恢复可能会主导经济效益。
保持简单
小的一次性任务——上下文层可能增加的运营复杂性超过了任务的合理性。
原始账户
阅读原始报告。
Kevin Riedl 的技术领域报告详细描述了 Wavect 的工作流程、恢复规则和评估限制。跟踪快照和后来的编辑审查是不同的日期。
- 跟踪快照
- 报告已审查
- 证据类型
- 观察性现场报告