用户已经聊了四十轮。系统生成一句摘要：“用户希望退回 A1042，已讨论运费和取件安排。”这句话没有明显语病，却漏掉了决定下一步行为的关键约束：“先别提交。”
下一次模型据此发起申请，问题不在摘要是否流畅，而在它没有保存继续任务需要的信息。压缩的目标应是让后续动作仍然有正确根据。
先看一份能够继续工作的快照
针对同一售后任务，可以保留：
{
"task_id": "T9",
"state_revision": 4,
"objective": "确认 A1042 的退货条件和运费归属",
"constraints": ["当前仅咨询，未获准提交申请"],
"confirmed_facts": ["签收时间来自订单 revision 12"],
"user_claims": ["用户称商品存在质量问题，尚未核实"],
"decisions": ["取件意向已由明天下午改为后天上午"],
"open_items": ["核实质量问题", "确认可用取件时段"],
"evidence_refs": ["P7-v2", "order:A1042:r12", "U19"],
"covered_events": ["U1", "U19"],
"summary_version": 1
}原始的日期表达应在任务状态中转换为带时区的绝对时间；这里保留相对表达只是为了展示用户变更过程。后续执行读取结构化状态，而不是从这句摘要再次计算日期。
目标、约束、已知事实、用户陈述和待办分开后，“讨论过”不会轻易被误当成“已完成”。证据引用允许应用必要时回到原始记录核实。摘要必须与覆盖的事件范围关联，否则新事件可能被误以为已经纳入。
有哪些不同的缩减办法
最简单的办法是截断旧消息。它便宜，但可能丢掉仍有效的约束。其次是抽取关键原文，保留原句的表达准确性，但压缩率可能不高。
生成式摘要可以合并重复讨论，却存在改写错误和遗漏。结构化状态提取将关键值固定成字段，适合订单、阶段和时间，不适合完整保留细微语气。原文外置则主要减少当前载荷，不一定减少外部存储。
例如一份五千行工具结果，当前只需其中三行，优先保存原结果并提取相关行；让模型总结所有五千行既有成本，也可能引入不必要的改写。十轮反复修改计划则更适合形成当前决定及变更依据。
这些方法可以组合：长期有效约束进入任务快照，近期完整交互保留原文，大结果留引用，已结束的重复讨论不再每轮发送。
为什么要在满之前开始压缩
如果原会话已经超过模型输入上限，再把它全部交给同一个模型要求总结，同样会超限。压缩请求本身需要规则、历史和输出空间，因此应该留出提前处理的余量。
假设动态容量为 20000，计划在历史达到 15000 时压缩，并为下一次最大工具返回预留 3000。这个阈值是教学选择，需要结合实际结果大小调整。如果单次工具可能返回 15000，先控制或外置工具结果更重要。
按消息数触发容易理解，但一条工具消息可能比一百条短聊天更大。消息数适合作为辅助条件，生产预算最终仍应围绕输入大小和下一步可能增加的内容安排。
压缩成功后可能只留下 4000 单位摘要与近期消息。可设置不同的触发和目标水位，避免刚压完就再次压缩。这里的数字是策略示意，不是实测最优配置。
压缩一次和压缩十次不同
如果每次只根据上一份摘要和新消息生成下一份摘要，第一次漏掉的信息后面不会自动回来。更糟的是，“可能存在质量问题”第一次变成“存在质量问题”，下一次又变成“已核实质量问题”，不确定性被逐步抹去。
应为摘要保留来源事件、覆盖范围和版本。关键约束及业务字段从结构化状态重建，必要时回读原文，而不是把上一版自然语言摘要当成唯一事实。
用户纠正信息时，需要同时处理摘要。任务状态已经改成后天取件，但摘要仍写明天，两个输入会互相冲突。可以让快照记录依赖的状态版本，状态变化后重建相关部分；不能只更新数据库而忽略已经生成的派生文本。
怎样避免压缩时丢掉新消息
假设后台开始压缩事件 1—30，过程中用户又发送 31、32。压缩结果提交时必须明确只覆盖到 30，并将 31、32 接在后面。若直接用新摘要覆盖整个消息列表，新消息就消失了。
一种做法是记录开始时的事件游标与状态版本，生成后用条件更新提交摘要指针。若依赖状态变化，就重建或重新校验；不满足条件时不覆盖。原始事件日志应先保留，新的摘要失败不影响当前任务继续读取旧上下文。
已经发出的工具调用和待返回结果也不能被拆散。可以延迟到交互单元完成再压缩，或者采用符合目标接口协议的专门保留方式。不能把 pending 工具调用总结成“已查询完成”。
摘要不产生业务授权
即使摘要写着“用户已经同意”，执行端仍要核对对应的确认事件、操作参数和任务版本。摘要是派生说明，不应成为退款、付款或访问控制的唯一依据。
compaction_snapshot.py下载 演示从结构化状态构建快照，并检查关键约束、状态版本和必需来源是否保留。它不调用摘要模型，也不会证明任意自然语言摘要没有语义错误。
这类检查能发现“未授权”字段丢失，却发现不了所有语气变化。实际评估还需要让系统继续同一任务，观察下一步选择是否正确，以及是否会重复操作。文本相似度高不等于继续任务正确。
压缩后的信息怎样找回来
快照应告诉后续调用哪些记录可按需读取，例如完整条款、原始质量照片、用户确认事件。引用失效时，返回明确缺口并重新获取允许读取的数据。不能因为“摘要里曾出现过”就假装现在仍有证据。
原始日志保存、敏感信息删除和恢复能力需要一起设计。某项来源已被删除，相关摘要也应失效；不能以可恢复为由永久保留用户要求删除的信息。
现有 AgentScope Java 示例使用消息数触发和尾部保留配置，相关机制见 Context Compaction。本系列保留 Java 示例，但不会把这个简单配置等同于上面完整的生产压缩方案。
继续阅读
上一篇： 哪些信息值得长期记住：记忆的提取、读取、纠正与遗忘 。
下一篇： 哪些上下文可以复用：缓存机制、命中条件与失效 。
完整文件、依赖与运行边界见配套指南下载。