多轮对话压缩历史消息时保留任务状态的提示设计

多轮对话压缩历史消息时，真正要保留的不是“上一段对话的缩写”，而是下一轮任务能够继续执行的状态。实践中建议把摘要固定成六类字段：任务目标、已确认决策、硬约束、未完成动作、待确认问题、证据引用。这样即使删掉几十轮闲聊，模型仍知道做到了哪里、不能改什么、下一步要补哪项信息。

Hugging Face Transformers 的聊天输入使用带有 role 和 content 的消息列表，随后由 chat template 转换为模型需要的序列。摘要最好作为独立的状态消息注入，而不是把所有历史重新拼进一个超长字符串。

官方参考地址：https://huggingface.co/docs/transformers/main/chat_templating

先把历史消息拆成可恢复的状态字段

摘要提示的第一条规则是“只写会影响后续动作的事实”。例如用户已经确认使用 PostgreSQL，就应落在“已确认决策”；“暂时不考虑迁移”应落在“硬约束”；“还没有提供生产数据样本”则属于“待确认问题”。三者混在一段话里，恢复时很容易被模型重新解释。

建议使用固定键名，并允许空数组，不要为了让摘要看起来完整而编造内容。下面的模板是提示设计示例，字段名稳定比修辞更重要：

# 这个函数只负责生成摘要提示；它不执行模型调用，也不替代业务校验
def build_summary_prompt(messages):
    return f"""
你是对话状态整理器。只根据给定消息提取已明确说出的事实，禁止猜测。
输出 JSON，必须包含：goal、decisions、constraints、open_actions、questions、evidence。
每个数组元素都写成可独立理解的一句话；没有内容就输出空数组。
保留否定约束、数值、文件名和未完成动作的负责人；不要复述寒暄和重复背景。

历史消息：
{messages}
"""

这里的关键不是让模型“总结得像人”，而是让输出能被程序和下一轮提示稳定读取。若某条结论没有明确来源，就放入 questions 或 evidence，不要悄悄升级为已确认决策。

用固定提示模板区分事实、约束和未完成动作

压缩失败通常不是摘要太短，而是优先级没有写进提示。可以把规则分成三层：第一层保留用户明确决定；第二层保留会导致返工的限制；第三层记录下一步和阻塞点。对于冲突消息，保留最近一次明确决定，同时把冲突写进 questions，等待用户确认。

摘要恢复时，不要把它伪装成用户原话。可以使用单独的状态消息，再接最近几条原文：

# 恢复顺序让模型先看到状态，再看到最近语境；recent_messages 只保留必要窗口
def build_context(state_summary, recent_messages):
    state_text = "对话状态（仅使用其中已确认事实）：\n" + state_summary
    recent_text = "最近消息（用于补充语境，不覆盖硬约束）：\n" + recent_messages
    return [
        {"role": "system", "content": state_text},
        {"role": "user", "content": recent_text},
    ]

如果使用支持 chat template 的模型，仍应遵循目标模型要求的消息角色和模板，不要自行拼接特殊控制符。状态摘要解决的是内容记忆，chat template 解决的是消息格式，两者不能互相替代。

按触发阈值和质量检查决定压缩粒度

不要等到上下文已经超限才压缩。可以在预计输入 token 达到窗口的 60%～70% 时触发一次，先保留最近一小段原文，再生成状态摘要。这里的比例是工程起点，不是所有模型都适用；真正上线前要结合模型窗口、工具调用长度和输出预留空间调整。

压缩结果至少做四项轻量检查：goal 不为空、硬约束没有消失、每个 open action 都有动作描述、questions 没有被错误地写入 decisions。高风险任务还应保留对应的原文片段或消息 ID，方便追溯，而不是只保存模型改写后的句子。

用决策表选择摘要加原文的组合方式

常见误区是只压缩“用户消息”，丢掉助手已经承诺的动作；或者把工具返回值全文塞进摘要，导致摘要再次膨胀。更稳妥的做法是只保存工具结果中的结论、标识和可复查引用，并给每个待办保留状态：pending、blocked 或 done。

常见问题

摘要越短，模型就越不容易跑偏吗？

不一定。删除硬约束和未完成动作会让摘要更短，却会增加返工。应先保证状态字段完整，再压缩重复背景。

能不能只保留最后一条 assistant 消息？

不建议。最后一条消息可能只包含局部回答，无法覆盖用户的否定条件、尚未确认的分支和待办责任人。

摘要里要不要保留原始对话全文？

低风险任务通常不需要；代码、合规或争议场景应保留消息 ID、关键片段或外部存档引用，让摘要可以被追溯。