历史压缩的总结，为什么按 token 数触发而不是按轮次？

先这样答

历史压缩应按 token 数触发，而不是按对话轮次触发。因为每轮对话的长度差异很大。用户和 Agent 可能只交换很短的内容，也可能产生很长的回复。轮次只能表示发生了几次交互，不能直接表示上下文占用了多少空间。

如果按轮次触发，长回复场景可能还没来得及压缩，上下文窗口就已经被撑满。短回复场景又可能频繁触发压缩，产生不必要的调用和成本。按 token 数触发，直接对应上下文窗口这个资源约束。系统可以在接近限制前处理历史，压缩时机也更可控。

具体采用哪种摘要方式，还要看对话的重要度和成本要求。增量摘要只处理新增内容，成本更低，但多次摘要会产生误差累积。全量摘要重新处理完整历史，结果更准确，但成本更高。工程上可以根据对话重要度选择策略，再用 token 数控制何时触发。

面试官会怎么追问

• 「为什么轮次不能作为一个简单的工程阈值？」 因为一轮对话的 token 数并不固定。长回复和短回复会让相同轮次对应完全不同的上下文占用。轮次无法稳定反映窗口压力。

• 「按 token 数触发时，你会把阈值设在哪里？」 核心原则是围绕上下文窗口的资源限制设置，而不是围绕固定轮次设置。要在窗口接近限制前完成压缩，保证后续对话还有可用空间。具体阈值需要结合摘要结果和对话重要度确定。

• 「增量摘要和全量摘要，你会怎么选？」 增量摘要只处理新增内容，成本更低，但重复累积后可能带来误差。全量摘要重新处理完整历史，准确性更好，但成本更高。对重要对话可以优先考虑全量摘要，对成本更敏感的场景可以考虑增量摘要。

回答的坑

• 只说按 token 数更精确，却不解释长回复会导致窗口先被撑满，答案缺少资源约束这一层。
• 只比较增量和全量摘要的成本，却漏掉增量摘要会累积误差、全量摘要成本更高。