混元模型在长对话中出现上下文丢失，通常并不是模型记性变差，而是输入侧的History无限增长，超出了上下文窗口后被强制截断。早期的系统指令、角色设定、用户说过的重要约束，如果只存在于最前面几条消息里，就很容易在截断中消失。要让模型持续稳定地记住关键信息，比较务实的方案是对History做压缩与摘要：最近几轮保留原始对话，更早的内容提炼成结构化摘要，再用摘要作为新的系统上下文参与后续推理。这篇文章会拆解一套可直接落地的压缩流程，并给出混元API接入时的代码示例和参数建议。

一、上下文丢失的机制与History压缩边界

混元系列模型在处理对话时，客户端会把每一轮用户消息和模型回复拼进一个messages数组。这个数组最终会转换成token序列参与计算。不同模型版本的上下文窗口长度不同，可能是4K、8K、32K甚至更长，但无论窗口多大，输入token加上输出token的总量始终有限。一旦消息数组不断追加，早期内容就会被推到远端。服务端如果执行硬截断，往往直接丢弃最旧的消息；如果客户端不做任何处理，系统提示词也可能一起被切掉。这类问题在长对话应用里非常常见，模型突然忘记自己是谁，或者忘记用户最初下发的任务目标，根源就在这里。

单纯加大窗口只能延缓问题，不能根除。即使模型支持128K上下文，把所有历史无脑塞进去也会碰到两个现实问题：一是token成本线性增长，二是模型对长上下文中部信息的注意力会被稀释。History压缩的目标不是保留所有原始文字，而是保留决策所需的关键语义。一个比较合理的边界是：最近几轮保留原始消息，因为当前讨论的细节和语气不能失真；更早的内容则交给摘要模块，把用户目标、硬性约束、已完成事项、待办事项等提炼出来。这样上下文占用从线性增长变成缓慢增长，同时原始系统提示词也能稳定保留在摘要之后。

def build_messages_with_summary(history, summary, recent_turns=6):
    # 只保留最近 recent_turns 轮原始消息，更早内容用摘要替代
    system_msg = {"role": "system", "content": summary}
    recent = history[-recent_turns * 2:]
    return [system_msg] + recent
def build_messages_without_compression(history):
    # 无脑拼接历史，窗口满了之后早期信息会被服务端截断
    return history

上面两个函数展示了两种策略的差异。无脑拼接虽然实现简单，但当历史长度超过窗口时，最前面的system提示词可能直接被服务端丢弃。带摘要的构建方式则把全局信息压缩到一条system消息中，同时仍然保留最近轮次的原始上下文。这里把recent_turns设为6，意味着保留最近6轮共约12条消息；如果你的对话每轮内容很长，可以按token数而不是轮数来动态调整。

二、摘要式压缩的实现方案与代码示例

摘要式压缩的核心是调用一次模型生成结构化摘要。与直接让模型自由发挥不同，结构化摘要要求输出JSON，字段固定，方便后续解析和拼接。常见的字段包括用户目标（user_goal）、关键约束（key_constraints）、已完成任务（completed_tasks）、待办任务（pending_tasks）和最近事件（recent_events）。这样设计有两个好处：一是摘要信息密度高，不容易混入无关闲聊；二是后续逻辑可以按字段读取，比如把关键约束单独注入到系统提示词中。

下面是一段调用混元API生成摘要的Python代码。示例使用OpenAI兼容接口，密钥和地址需要替换成自己的腾讯云配置。

import json
import re
from openai import OpenAI
client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.hunyuan.cloud.tencent.com/v1")
def summarize_history(history, max_summary_tokens=800):
    prompt = (
        "请将以下对话历史压缩为JSON摘要。"
        "输出字段包括：user_goal、key_constraints、completed_tasks、pending_tasks、recent_events。"
        "只输出JSON对象，不要添加解释。"
    )
    history_text = "\n".join([f"{msg['role']}: {msg['content']}" for msg in history])
    messages = [
        {"role": "system", "content": "你是对话历史压缩助手，擅长提取关键信息。"},
        {"role": "user", "content": prompt + "\n\n历史对话：\n" + history_text}
    ]
    resp = client.chat.completions.create(
        model="hunyuan-turbo",
        messages=messages,
        temperature=0.2,
        max_tokens=max_summary_tokens
    )
    content = resp.choices[0].message.content
    match = re.search(r"\{.*\}", content, re.S)
    if not match:
        return {
            "user_goal": "",
            "key_constraints": [],
            "completed_tasks": [],
            "pending_tasks": [],
            "recent_events": []
        }
    return json.loads(match.group(0))

实际调用中，模型偶尔会在JSON前后附加解释文字，或者把JSON中的双引号写成中文引号。为了增强稳定性，代码里用正则先提取第一个花括号包裹的内容，再交给json.loads解析。如果解析失败，则返回空字段，避免压缩流程因为一次摘要异常而整体中断。另一个容易忽略的点是摘要模型的选择。摘要任务对创造性要求很低，但对事实提取的准确度要求高，因此temperature建议设置在0.1到0.3之间，max_tokens不要给太大，否则摘要本身也会变成新的上下文负担。

三、滑动窗口与递归摘要的工程取舍

在实际工程里，摘要不是每轮都做，而是配合滑动窗口触发。简单做法是维护一个token上限，比如6000。每轮结束后统计当前messages的总token数，如果超过上限，就把最早的一部分消息压缩成摘要，最近几轮继续保留原始内容。这样上下文长度会被拉回到阈值以下，同时关键信息仍然留在摘要中。滑动窗口的优点是实现直观，延迟可控；缺点是压缩边界比较生硬，可能正好把一段连续讨论切到摘要里，导致细节丢失。

def estimate_tokens(text):
    # 粗略估算：中文约1字1token，英文约4字符1token，这里统一按4字符估算
    return len(text) // 4
def compress_history(history, summary, max_context_tokens=6000, recent_turns=8):
    total_tokens = sum(estimate_tokens(msg["content"]) for msg in history)
    if total_tokens <= max_context_tokens:
        return history, summary
    recent = history[-recent_turns * 2:]
    older = history[:-recent_turns * 2]
    if older:
        draft = older
        if summary:
            draft = [{"role": "system", "content": "已有摘要：" + summary}] + older
        summary = summarize_history(draft)
    merged = [{"role": "system", "content": summary}] + recent
    return merged, summary

当历史持续增长，摘要自身也会越变越长。比如第一次压缩生成了300字摘要，后面又新增了几轮对话，下一次压缩时不能把旧摘要丢掉，否则早期的用户目标就彻底消失了。递归摘要的做法是把已有摘要和新增的旧消息一起交给摘要模型，要求它输出一个合并后的新摘要。这样摘要长度可以控制在固定范围内。但递归摘要存在误差累积风险：模型每次压缩都可能丢失少量细节，经过多次递归后，早期信息可能被逐步稀释甚至扭曲。为了降低这种风险，建议把关键约束单独提取出来存储，不要只依赖摘要模型在长链条中传递。

每次调用摘要模型都会引入额外延迟和费用。如果每轮对话都做一次摘要，用户体感可能变慢。更实用的方式是增量触发：每累计5到10轮新对话再更新一次摘要，或者将摘要任务放到后台异步执行。对于高并发场景，还可以用更小的模型做摘要，用主力模型做回答。只要摘要能覆盖用户目标和约束，回答质量不会明显下降。监控方面可以记录压缩前后的prompt token数量，观察是否存在摘要无限膨胀的问题。

四、混元API接入时的参数与提示词建议

摘要质量很大程度上取决于提示词。提示词需要明确三个信息：输入是什么、输出是什么、约束是什么。比如可以这样写：请将以下对话历史压缩为JSON摘要，输出字段包括user_goal、key_constraints、completed_tasks、pending_tasks、recent_events；只输出JSON对象，不要添加解释；如果某项信息不存在，用空字符串或空数组表示。这个提示词如果写在system消息里，模型会更倾向于遵守输出格式。

def build_final_messages(global_summary, original_system_prompt, recent_history):
    # 先放摘要，再放原始系统设定，最后放最近原始对话
    system_content = global_summary + "\n" + original_system_prompt
    messages = [{"role": "system", "content": system_content}]
    messages.extend(recent_history)
    return messages

在混元API中，system消息会作为全局上下文优先参与计算。把摘要放在system消息的最前面，有助于模型先建立整体记忆，再阅读最近对话。原始系统提示词可以紧跟在摘要之后，这样角色设定和任务规则不会被摘要完全覆盖。参数方面，摘要生成建议使用较低temperature和较低top_p，保证输出稳定；正式回答时则可以恢复正常参数，让表达更自然。如果混元支持JSON模式或函数调用，也可以直接约束输出结构，但不同版本能力有差异，用正则提取JSON仍然是兼容性最好的做法。

此外，可以给摘要模块设置独立的max_tokens，避免摘要过长。对于特别重要的数字、日期、姓名等精确信息，建议在应用层单独保存一份键值结构，而不是完全依赖摘要。比如用户说“预算上限是5000元”，这条约束既写进摘要，也存进业务字段，后续即使摘要误差，也不会影响关键决策。最终目标是把上下文成本压到可预测范围内，同时让模型在几十轮之后仍然能准确执行最初的任务要求。