上下文压缩实验
这个客服 Agent 很便宜、很快，因为上下文被压得非常狠。隐藏的问题是：它已经记不住足够的政策、账户状态和订单证据，无法可靠判断退款。
上下文压缩不是“谁能把 Token 压得最少”；可辩护的策略应该先保住决定任务结果的指令和证据，再去删除低价值信息。
原始工作集包含 25,500 个教学模拟 Token，而生产工作上下文最多允许 16,000。先从一个节省超过三分之二 Token 的策略开始，再看看这些“节省”到底删掉了什么。
—
—
—
—
—
—
—
—
Token 留存率和语义留存率不是一回事。更深的摘要可以让每个保留 Token 携带更多有用含义，但 Retrieval 或 Memory 的预算如果在前面就把信息挡掉，摘要也没有机会保护它。
| Context 片段 | 原始 Token | 活动 Token | 语义保留率 |
|---|
初始策略只追求缩小工作上下文，任务真正依赖的信息被悄悄一起删掉。
为什么摘要看起来没错，压缩后的系统仍然可能更差？
模型不会直接看到应用里的完整真实状态，它只看到被构造出来的工作 Context。压缩改变的是这整个信息环境，所以一句很流畅的摘要，也可能刚好漏掉真正改变退款结论的账户标记、政策例外或订单证据。
压缩比例只是最显眼的旋钮
两个都只保留 40% Token 的策略，实际能保住的语义可能完全不同。关键取决于压了哪些片段、Retrieval 先放进来什么，以及哪些事实被禁止做有损压缩。
关键事实不应该和背景文本用同一套策略
System 安全规则、当前任务、账户资格、退款政策和订单证据都直接决定行动后果，应当比产品背景和低价值历史对话获得更强的保护。
Retrieval 和 Memory 的预算发生在生成之前
如果 Retrieval Budget 太小，证据从一开始就没进入工作 Context；之后再提高摘要质量也无法把它恢复出来。Memory 过多同样可能把过期或弱相关历史重新挤进工作集。
硬预算让另一种失败也显形
如果没有 16k 上限，最容易提高模拟质量的方法就是几乎什么都不压。但真实系统还有 Context Limit、延迟目标和单位成本，因此“信息全保留”也可能是不可发布的策略。
常见问题
高后果信息应该有更强默认保护，但真实系统仍需要任务分类、时效规则和冲突处理。
不是。深摘要可能保留更多含义，也会消耗更多 Token 和处理成本。
更大的窗口只能缓解容量压力，不能消除坏 Retrieval、陈旧 Memory、注意力分配、延迟和成本问题。
为可退款客服 Agent 定义一套 Context Policy。
明确哪些信息必须保住、Retrieval 最多允许引入多少证据、Memory 值得占多少预算，以及什么信息一旦缺失就应该直接阻止发布。