压缩也有语义预算
节省 Token 只有在剩余表示仍保留任务依赖的指令和证据时才有意义。
上下文工程·进阶·25 分钟
上下文压缩实验
这个客服 Agent 很便宜、很快，因为上下文被压得非常狠。隐藏的问题是：它已经记不住足够的政策、账户状态和订单证据，无法可靠判断退款。
01
体验
先处理问题，再阅读解释。
正在加载实验…
02
反思
把结果整理成可以复用的判断。
关键要点
先保护关键事实，再优化平均指标
一个小小的安全规则或资格字段，可能比几千 Token 的背景信息更重要。
Retrieval Budget 是信息准入决策
没有被检索进来的证据，Summarizer 再强也保护不了。
更多 Context 也不自动更安全
什么都保留可能直接超过运行预算，并重新带来延迟和成本问题。
可辩护的点通常在中间
好的 Context Engineering 会接受一定信息损失来换成本，但不能跌破任务关键事实的最低保留线。
03
深入理解
把这次体验连接到概念、参考与迁移。
上下文工程
为什么摘要看起来没错，压缩后的系统仍然可能更差？
模型不会直接看到应用里的完整真实状态，它只看到被构造出来的工作 Context。压缩改变的是这整个信息环境，所以一句很流畅的摘要，也可能刚好漏掉真正改变退款结论的账户标记、政策例外或订单证据。
压缩比例只是最显眼的旋钮
两个都只保留 40% Token 的策略，实际能保住的语义可能完全不同。关键取决于压了哪些片段、Retrieval 先放进来什么，以及哪些事实被禁止做有损压缩。
关键事实不应该和背景文本用同一套策略
System 安全规则、当前任务、账户资格、退款政策和订单证据都直接决定行动后果，应当比产品背景和低价值历史对话获得更强的保护。
Retrieval 和 Memory 的预算发生在生成之前
如果 Retrieval Budget 太小，证据从一开始就没进入工作 Context；之后再提高摘要质量也无法把它恢复出来。Memory 过多同样可能把过期或弱相关历史重新挤进工作集。
硬预算让另一种失败也显形
如果没有 16k 上限，最容易提高模拟质量的方法就是几乎什么都不压。但真实系统还有 Context Limit、延迟目标和单位成本，因此“信息全保留”也可能是不可发布的策略。
常见问题
是不是所有标成关键的信息都应该永久保护？
高后果信息应该有更强默认保护，但真实系统仍需要任务分类、时效规则和冲突处理。
摘要越深越好吗？
不是。深摘要可能保留更多含义，也会消耗更多 Token 和处理成本。
直接换更大的 Context Window 不行吗？
更大的窗口只能缓解容量压力，不能消除坏 Retrieval、陈旧 Memory、注意力分配、延迟和成本问题。
所有数值都是教学模拟指标，用来暴露 Context 选择的因果关系，不是通用生产阈值。
LEARNING CONTEXT
学习连接
Compression 是否成功，要看决策关键证据有没有被保留下来，而不是只看 Token 是否减少。
未看过
Mental Model
- S02-M03Compaction vs 关键信息保留
建议补充前置
进入这起事故前，没有必须完成的已发布前置内容。
迁移这个模型
压缩一段事故 Trace，同时必须保留一个很少出现、但决定能否上线的关键信号。你会怎么做？
04
下一步
把这个判断带到另一个问题或构建中。
构建挑战
为可退款客服 Agent 定义一套 Context Policy。
明确哪些信息必须保住、Retrieval 最多允许引入多少证据、Memory 值得占多少预算，以及什么信息一旦缺失就应该直接阻止发布。
开始挑战你已经在信息保留与成本之间做出可解释的权衡。
下一步，Integrated Build 会把 Retrieval、Context Policy、受控执行、人工审批和 Evaluation 放进同一个架构决策。
继续到 Integrated Build