yetone @yetone

这条推文的建议很好，但“把压缩调到 400K”对每个人都成立吗？不一定。 这就是 magpie 要做本地 agent 可观测性分析的原因。每个 agent 都有自己独特的行为，每个用户也有自己的使用习惯，任务难度也因人而异，所以不存在一份对所有人都最优的配置。 更麻烦的是，每个 agent 的配置项又多又复杂，还藏得很深。大多数人压根儿不知道有这些开关，就这么不知不觉地用着最不适合自己的配置，浪费了大量时间和 Token，甚至牺牲了完成任务的质量。 magpie 新功能「为你调优」：在本地用你自己的真实调用，按每个 agent、每个模型去回放压缩阈值和缓存时长，算出对你最省 Token 的那一组。千人千面，但对每个人都是最省的。 [引用 @realfxw]: 最近用 Claude Code 跑长任务经常感觉 5 小时额度像流水一样掉？之前社区甚至有人吐槽它根本没做上下文压缩，暗地里疯狂塞 token。今天看了 Anthropic 官方工程师 Lydia Hallie 的详细解释，才发现大家都误解了它的机制，实际问题出在默认策略太激进。 很多人不知道，auto-compact 其实是真正在做摘要的。只要一触发，前面所有的历史记录都会被一段很短的 summary 直接替换掉，根本不会在上下文里保留上百万的冗余内容。 那为什么大家的配额还是崩得飞快？ 关键在于 1M 上下文模型下，系统默认一定要憋到将近 967K 才会启动自动压缩。这就很要命了——在憋到 967K 之前的那段漫长对话里，你发过去的每一句话，背后都在默默拖着七八百 K 甚至近百万 token 的庞大上下文。即便大部分命中了 Prompt Cache 且读取单价很低，但只要基数膨胀…