必须每次请求显式携带完整历史消息数组，首条为system设定角色，之后按时间顺序交替拼接user和assistant消息，最后追加当前user输入，且role字段须严格小写、无控制字符，签名时需紧凑json格式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在火山引擎API中正确传递聊天记录实现多轮对话，必须每次请求都显式携带完整历史消息数组，否则模型会把新输入当作孤立问题处理，导致上下文断裂、重复解释、角色设定失效。
构造符合规范的messages数组
第一步：固定插入system消息作为首条，明确AI身份与约束边界。例如{"role": "system", "content": "你是一名证券开户顾问，只解答实名认证、银行卡绑定、风险测评类问题，不提供个股推荐。"}。
第二步：按真实时间顺序拼接user和assistant交替出现的历史对话。不能跳过某轮回复，也不能把两条user消息连在一起——这会导致400报错。
第三步：将当前用户新输入作为最后一条追加进数组，确保role为"user"，且整个messages长度≥2（system + 至少一条user）。
示例合法结构：
[{"role":"system","content":"客服角色设定"},{"role":"user","content":"我的身份证照片传不上去"},{"role":"assistant","content":"请确认是否使用最新版App，并检查照片是否大于5MB"},{"role":"user","content":"是3.2MB，还是上传失败"}]
避免常见格式错误
方法一：检查role字段拼写——必须严格为"user"或"assistant"，写成"User"、"USER"、"client"均会触发400错误。
方法二：验证消息顺序——必须以system开头，之后严格user→assistant→user→assistant交替。若上一轮是user，本轮却仍是user，【模型将拒绝解析并返回空响应】。
方法三：删除content中的不可见控制字符。从富文本编辑器或网页复制的文本可能含零宽空格、软回车，用JSON.stringify再parse一次可清除。
不同调用方式下的传参位置
同步调用：在POST请求体JSON中，直接将messages数组赋值给顶层字段messages，同级包含model、temperature等参数。
流式调用：同样放在messages字段，但需额外添加stream: true。注意流式响应中每chunk只含delta内容，完整历史仍必须在请求时全量传入。
C#签名请求：messages需先序列化为紧凑JSON（无换行/缩进），再参与X-BC-Signature签名原文拼接，【若格式化后带空格，签名将校验失败】。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
