TSR 分类器是聪明之处——根据任务给每个 MCP tool 打分，在它们膨胀上下文之前剥离无关的。这个分类器本身在每个请求上会带来多少延迟？它是每轮都跑，还是只在任务开始时跑一次？
PH 用户
Brevity being the biggest win makes sense to me — I notice Claude Code narrating plans I never asked for. Does suppressing that narration change how easy it is for a human to follow along mid-session, or is it only trimmed on the wire?
我是Sacha，@Edgee 的创始人。
今年三月我们发布了第一版压缩器。一种技术，工具结果修剪，灵感来自 RTK 项目。在真实编程会话中节省了约10%的成本。安全、简单、有限。
今天我们推出 Compression V2，它完全是另一个物种了。
三种正交技术，每一种针对智能体请求的不同层面，每种可以独立开关：
1. Brevity（输出层）。模型仍然执行每个工具调用并产生相同的最终补丁，只是不再叙述它的计划。输出是最昂贵的 token 类别，而这里才是大
头。
2. Tool Surface Reduction 简称 TSR（输入层）。智能体会在每次请求中把每个 MCP tool 的并集都发给模型，即使其中95%都是无关的。V2 运行一个快速分类器，根据任务对每个工具打分，在请求到达模型之前剥离掉其余部分。你的 IDE 仍然暴露所有内容，但模型看到的只是一个精选子集。
3. Tool Result Trimming（历史层，从 V1 改进而来）。清理那些在长会话中堆叠起来的冗长工具输出，同时不丢弃模型需要的内容。
因为三者作用于不同层面，它们可以干净地组合。结合起来，在典型会话中大约能降低50%的成本。
我最自豪的不是这个数字，而是我们如何测量的。我们的研究工程师 @0kham 在 SWE-bench Lite 上用智能体模式运行了它，做了配对符号检验、bootstrap 置信区间、每个副本的缓存随机数（不让任何运行获得不公平的缓存优势），并且直接从原始使用字段读取 token 计数。我们发布了完整的方法论，包括每种技术强在哪里、哪里效果一般。Brevity 在编程场景中位数约节省30%，TSR 在工具密集的 MCP 工作上节省大量 token，trimming 在长会话中不断累积。没有单个被夸大的标题数字，只有分解和每个宣称背后的统计数据。
这里有完整的技术文章，包含测试和置信区间：https://www.edgee.ai/blog/posts/introducing-compressor-v2-three-compression-layers-measured-end-to-end-for-a-50-cost-reduction
它对代码任务在语义上是无损的，可以直接替换到 Claude Code、Codex、OpenCode、Github Copilot 和 Cursor 中，网关开销 P50 低于12ms。你的 CLAUDE.md 和 MCP 服务器完全保持原样。
有几个问题想听听你的看法：对你来说这三种技术中哪种听起来对你的工作流最有用？有没有人在运行重型 MCP 设置，想试试 Tool Surface Reduction 并告诉我你看到了什么？我会在评论里待一整天。感谢你的关注。
我也很欣赏你们发布了方法论，而不是只说一句"节省高达50%"。配对检验、缓存随机数以及按技术分解，让这个说法更可信。好奇你们怎么看待 TSR 的风险。如果分类器移除了一个在后续任务中原本有用的工具，智能体还能恢复吗，还是需要重新启动并扩大工具集？