Apollo
全部栏目

上下文压缩

上下文压缩用更短的摘要或任务状态替代部分历史，使长任务能够继续。压缩后仍需保留会影响后续行动的条件、结果和未决事项。

返回概念图谱 →

理解与应用

上下文压缩是把已经积累的交互、工具结果和中间过程转换成较短表示的过程。它不同于普通文章摘要：读者不只是想知道前面大概讲了什么，还要据此继续执行任务。因此，压缩后的内容通常需要交代当前目标、已完成工作、仍缺什么和下一步能做什么。

例如助手准备周报邮件，先生成初稿，又根据反馈修订为第二版，此时还在等待用户确认收件人。完整历史中可能有多次措辞修改和重复预览，但恢复任务最需要知道的是当前草稿为第二版、尚未发送、收件人仍待确认。如果压成“周报邮件已处理”，接手者就无法判断是继续修改、等待确认还是检查送达。

压缩可以删除过期草稿的正文，却仍保留可重新打开它们的位置；也可以把重复工具结果合并成当前状态。关键金额、时间、尚未解决的冲突和外部动作回执往往值得直接保留。对于已经发起但没有收到明确结果的操作，“结果未知”也是重要信息，不能为了简短改写成成功或失败。

检查压缩质量时，可以问几个会影响下一步的问题：当前版本是哪一份？是否已经发送？还在等谁决定什么？若压缩前后答案不同，说明丢失了关键信息。自然语言摘要可能遗漏细节，因此原始历史最好仍能按需回看；结构化事件也可以确定性地归并，但这只保留了事件设计时已经表达的信息。

关系速览
上下文工程应用于 →上下文压缩

上下文压缩用于长任务中的预算管理，须验证关键信息未被摘要丢失。

上下文窗口约束 →上下文压缩

模型窗口与响应预算约束压缩后可保留的上下文大小；压缩结果仍须为响应和工具结果预留空间。

结构化笔记应用于 →上下文压缩

压缩时可以保留结构化事实、来源和未完成动作，以便检查摘要是否丢失约束。

动手试一试：把草稿历史归并成可继续工作的状态

较早的草稿不再占用当前状态，但最新版本的入口、等待事项和未发送状态仍在。程序根据明确事件进行归并，没有让模型概括自由文本；若事件本身漏记了实际发送，就无法靠这段归并自动发现。

将代码保存为 example.py，使用 Python 3.10+ 运行 python3 example.py。仅使用标准库，无需密钥，不会调用外部模型。

Python 代码

events = [
    {"type": "draft", "version": 1, "ref": "draft-1"},
    {"type": "draft", "version": 2, "ref": "draft-2"},
    {"type": "waiting", "value": "确认收件人"},
]
state = {"draft_version": None, "draft_ref": None,
         "waiting_for": None, "sent": False}

for event in events:
    if event["type"] == "draft":
        state["draft_version"] = event["version"]
        state["draft_ref"] = event["ref"]
    elif event["type"] == "waiting":
        state["waiting_for"] = event["value"]

print("当前草稿:", state["draft_version"], state["draft_ref"])
print("仍待处理:", state["waiting_for"])
print("已发送:", state["sent"])

运行结果

当前草稿: 2 draft-2
仍待处理: 确认收件人
已发送: False

常见误区

  • 用“已处理”“差不多完成”概括多个状态，会使接手者无法区分草稿、待确认和已交付。
  • 只保留摘要而丢弃证据入口，出现疑问时就无法回看压缩中省略的细节。

前置与延伸

建议先读

相关概念

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。