必须每次API请求显式构造含system、历史问答及当前追问的完整messages数组，且需确认知识库已启用RAG并绑定带橙色“嵌入”标识的模型，否则追问将无法命中知识片段。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在火山引擎知识库中实现追问并让模型准确理解前文信息，必须在每次API请求中显式构造完整的消息数组，不能依赖平台自动记忆；否则追问会被当作全新问题处理，导致知识召回错位、答案断裂或重复解释。
确认知识库已启用RAG问答且绑定嵌入模型
登录火山引擎方舟控制台 → 进入「知识库」→ 找到目标知识库（如“售后FAQ”）→ 点击「设置」→ 检查「启用RAG问答」是否为开启状态，并确认「嵌入模型」下拉项中已选中一个带【橙色“嵌入”标识】的模型（如ep-xxxxx-qwen2.5-7b）。若未勾选橙色标识，向量索引无法生成，所有追问都将命中不到知识片段。
这一步不可跳过。即使知识库显示“构建完成”，只要嵌入模型未正确绑定，后续所有请求都等同于无知识库调用。
构造含历史上下文的messages数组
多轮追问的本质不是“记住”，而是“每次请求都重传全部有效上下文”。你必须把system设定、用户原始提问、AI首轮回答、用户追问按时间顺序拼成数组，role字段严格交替为user/assistant，且首条必须是system。
第一步：固定写入system消息，明确角色与知识边界。例如：
{"role": "system", "content": "你是一名[XX科技]售后客服，仅依据已导入的知识库内容作答，不编造、不推测，不确定时回复‘暂未在知识库中找到相关信息’。"}
第二步：追加原始提问和首轮回答。假设用户第一次问“保修期是多久？”，模型返回“整机保修1年，主要部件保修3年”。这两条必须原样保留，role分别为user和assistant。
第三步：把本次追问作为数组末尾新元素加入，role设为user。例如：{"role": "user", "content": "那主板坏了算主要部件吗？"}
最终messages数组长度至少为3（system + user + assistant + user），少于3条即丧失上下文连贯性，模型会忽略知识库中“主要部件”的定义上下文。
通过session_id在服务端持久化上下文
方法一：Redis缓存最近3～5轮对话
为每个用户生成唯一session_id → 每次请求前从Redis读取该session_id对应的messages数组（不含system）→ 将system消息与读出的历史+当前追问合并 → 调用火山引擎API → 把本次assistant回复追加进Redis并设置30分钟过期。
方法二：前端透传轻量上下文
用户每输入一次，前端将当前session内全部user/assistant消息（不含system）序列化为JSON数组 → 通过你自己的后端接口转发 → 后端仅校验格式合法性，不做存储，直接透传至火山引擎API。适合单页应用且用户不跨设备的场景。
注意：两种方式都要求【每次请求的messages数组必须包含完整的system消息】，不能只缓存user/assistant部分后动态拼接system——因为system内容可能随业务规则变更，硬编码会导致策略失效。
