什么是消息列表？一次请求里 messages 的结构

在豆包里连续追问"那第二种方法呢"，AI 能接得住，靠的是每次请求都把完整对话原样重发一遍，这份按先后顺序排列的对话清单就是消息列表。它是任何一次大模型请求的骨架：你发什么、模型之前答过什么，全都在这份清单上。这个设计初看很笨——明明刚聊过，为什么还要重发？原因很简单：模型侧不保存任何会话状态，无状态是它保持简单可靠的前提。

一条消息列表里都有什么

标准写法是三类角色各司其职。system 是幕后导演，负责定调子，比如"你是严谨的客服，回答不超过三句"；user 是观众提问；assistant 是模型此前的回答。三者交替排列，拼成一条完整的对话线。角色名在各家接口里写法高度一致，个别平台换了叫法，对应关系以官方最新版本为准。模型答到一半想停在哪里，靠的是另一组参数，比如停止序列，和角色分工是两码事。

类比：一份排练用的对话剧本

把消息列表想象成话剧剧本最合适：谁念什么台词、按什么顺序念，白纸黑字写死。演员上台不靠临场回忆，照着剧本走；哪里演砸了，改剧本、重排一遍就行，别的场次不受影响。新开一轮对话，等于换了一整本新剧本，之前演过的东西一概清零。

类比失效在哪里

话剧演员脑子里装着前几幕的记忆，大模型却没有任何记忆：每次请求都是全新开演，你给多少剧本，它就知道多少。上一轮说过的话，这一轮不带进来，它就真的不知道。这也解释了为什么对话越长账单越贵——每一轮都在为完整剧本付全款，分档规则可以看计费梯度。所以"让 AI 记住我"这类需求，实际做法是把要点写进 system 或每轮重申，不能指望它自己长记性。

新手最容易写错的三处

第一，只发最新一句、不带历史，模型自然答非所问，等于只给演员最后一页剧本。第二，角色标错，把模型的回答标成 user，对话就乱了辈分。第三，历史塞得太满，把留给回答的空间挤没了——列表连同回答一起受输出上限约束，用词重复太多还会触发频率惩罚那一侧的调整。还有一种隐蔽错误：把历史顺序发反了，模型会顺着错乱的因果往下接，答案看起来通顺，逻辑却是倒的。

一版实用的整理习惯

长对话定期做减法：把已经解决的来龙去脉压缩成一句背景，替换掉原来的十几条往返，通义千问这类产品的多轮会话背后也是同一套机制在运转。判断标准很朴素——删掉这条消息之后，模型还能不能答对下一句；能删就删，既省钱又让模型少受无关细节的干扰。压缩历史时保留三样东西：任务目标、已经确定的结论、还没解决的问题，其余对话细节都可以舍弃。

消息列表自查清单

• system 放规则，user 放问题，assistant 放历史回答，三者别混。
• 顺序和时间线保持一致，别让回答出现在提问前面。
• 每轮请求前扫一遍：没用的历史，删。
• 逐篇收尾一句：列表是骨架，参数是配菜，骨架搭正了，配菜才有意义。

关于消息列表的三个常问问题

• system 消息必须放第一条吗？：惯例是放开头让规则先入场，多数模型对靠前的指令权重更高，具体以官方最新版本为准。
• 一轮里可以有多条 user 消息吗？：可以，把连续的提问按原顺序一起发送即可，模型会当作同一轮输入来理解。
• 历史消息会被模型记住吗？：不会，它每次只看你这次发来的内容，下一条请求不带，它就忘得干干净净。