对话历史 Conversation History

对话历史是产品保存的旧消息。下一轮请求可以从中找回与当前问题有关的内容，但聊天界面显示的全部记录，不代表这些消息都真的发送给了模型。

• 应用需要根据当前问题取回相关消息，让“第二条”这样的指代有明确对象。
• 无关或过早的历史可以被截取、摘要或清除，避免挤占本轮请求空间。
• 只有进入本次 messages 的内容，模型才可以据此回答；保存不等于发送。

对话历史说的是产品保存了哪些旧消息；无状态请求说的是每次调用都要重新提供本轮需要的内容。两者都可能出现在同一个聊天产品里，但职责不同。

• 聊天界面还能显示旧消息，只能说明产品记录还在，不能证明这些消息进入了当前请求。
• 每次都原样发送完整历史会增加长度、费用和无关信息，也可能碰到上下文窗口限制。

判断 AI 为什么答错时，要检查本次发送的 messages，而不是只看屏幕上有没有那条旧消息。

拆开这次“把第二条改短”的请求，可以看到保存的消息、相关筛选、历史整理和最终发送内容各自承担什么作用。

• MESSAGE TIMELINE 保存按轮次排列的用户消息和助手回复，供界面展示或后续查找。
• RELATED HISTORY 找回当前问题所依赖的原始内容，补足指代和上下文。
• TRIM / SUMMARIZE 处理过早、无关或过长的消息，减少本轮不需要的历史。
• CURRENT REQUEST 显示最终进入 messages 的历史片段和新问题，模型只能依据这里回答。

请检查聊天产品的对话历史：用户第一轮让 AI 写出“快速开始、常见问题、联系我们”三个标题，下一轮说“把第二条改短”。从保存的消息中找回这三个标题，只把相关历史和当前请求放进本次 messages；无关的旧配色讨论可以截取或摘要。验收时不要只看界面还显示什么，要检查模型实际收到的内容。