必须显式传递完整对话历史，混元接口不维护会话状态；messages需按时间顺序包含全部user/assistant消息，system消息（如有）须置首且唯一；超长时应截断保留近5～8轮关键交互。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在调用腾讯混元大模型时真正实现多轮对话的上下文连贯，不能依赖模型自动“记住”历史——每次请求都必须显式携带完整对话历史，否则 assistant 的回复会丢失前序逻辑、角色设定或关键约束条件。
基础原则：上下文必须手动拼接
混元/chat/completions 接口本身不维护会话状态，【所有 user 和 assistant 交互记录必须在本次请求中完整传入 messages 数组】。漏掉任意一条历史消息，模型就无法理解当前提问的语境，比如用户说“按刚才的风格再写一段”，模型根本不知道“刚才的风格”指什么。
这一步操作起来很简单，直接把之前所有 role: user 和 role: assistant 的 message 对象按时间顺序放进 messages 列表里就行。
正确构造 messages 数组
方法一：逐条追加历史消息（推荐）
第一步：初始化一个空列表 messages = []；
第二步：将首轮 user 提问作为第一条消息加入，role 设为 "user"；
第三步：收到模型首次回复后，提取 content 字段，新建一条 role 为 "assistant" 的消息加入 messages；
第四步：后续每轮新提问前，先将本次 user 输入追加为新消息，再把整个 messages 数组作为 payload 提交——不是只传最新一条，而是全量重传。
注意：messages 中每条消息必须包含 role 和 content 字段，system 角色消息可选，但若含 system 指令（如“你是一名法律助理”），必须放在最前面且仅出现一次。
避免上下文断裂的关键操作
方法一：用对话 ID 管理多轮链路（适用于生图等异步场景）
当调用混元生图(多轮对话)接口时，首次提交任务会返回一个 dialog_id；后续每轮调整图像需求，必须在请求体中带上该 dialog_id，并将此前全部文本对话 history 一并提交；【dialog_id 不代表上下文缓存，仅用于服务端关联任务流，实际语义仍靠 messages 字段承载】。
方法二：截断超长上下文（256k 模型也需谨慎）
即使使用 hunyuan-standard（256k 上下文版本），也不要无限制堆叠历史；当 messages 总字符数逼近 38 万时，模型可能主动截断早期内容；建议优先保留最近 5～8 轮关键交互，删除冗余寒暄或重复确认语句。
这一步容易踩坑：有人以为“用了 256k 模型就不用管长度”，结果发现模型对首条提问已无响应——其实是 token 超限后前端静默丢弃了开头部分。
