消息角色与对话结构
一次请求在服务端被拼成固定顺序的 token 序列：tools → system → messages。system 是稳定前缀、优先级最高、缓存友好；API 本身无状态，多轮对话靠客户端把历史重新发一遍。角色是分工不是权限边界 —— 敏感规则放 system 挡不住注入。
也叫：system prompt · 系统提示词 · 消息角色 · user / assistant · 无状态 · 对话结构
再学流式输出：SSE 与 WebSocketAgent 与 Workflow 的边界Few-shot 与上下文学习上下文工程提示词注入与防线LLM 网关：限流与多模型路由Prompt 缓存结构化输出与约束解码Function Calling 机制
核心概念：先打比方，再给定义出自 T0-3
把一次请求想象成一份庭审卷宗：
- system（系统消息）：庭审规则与法官身份说明。每一轮都在、内容基本不变，定义模型「是谁、在什么产品里、遵守什么」。
- user（用户消息）：本轮的诉求。变化的部分。
- assistant（助手消息）：模型自己此前说过的话。你把它回传，模型才知道「我刚才承诺过什么」。
- tool / tool_result：工具调用与其返回（T3-2 展开）。
第一个必须祛魅的点：Messages API 是无状态的。
所谓「多轮对话」，是你每一轮把 system + 全部历史 user/assistant + 本轮 user 重新发一遍。模型没有记忆，记忆在你的应用里。
这一条解释了两件事：为什么长对话越来越贵（历史每轮重发，成本是累加），以及为什么「上一轮你说过 X」这种引用有时会失效（你没回传，或者它被压缩掉了）。
第二个必须祛魅的点：角色是训练出来的优先级，不是权限边界。
模型倾向于更重视 system 里的内容，但这是概率上的倾向，不是操作系统级的隔离。这条是 T1-5 和 Q1-15 的地基，本篇末尾还会回来。
一次请求像一份庭审卷宗：规则在前、本轮诉求在后，
tool_result 也要进卷宗（T3-2）庭审规则 · 法官身份说明
对应每一轮都在，内容基本不变
规则写在卷宗最前面，不是抄在每一页证词上
system · 系统消息
定义模型是谁、遵守什么
每一轮都发，但内容恒定 —— 所以它能被缓存
稳定前缀优先级最高缓存友好
本轮诉求 · 每轮新添的一页
对应变化的部分，卷宗一轮厚一页
法官只看眼前这份卷宗 —— 没抄进去的，等于没发生过
user / assistant · 消息
本轮意图，与模型说过的话
你把 assistant 回传，模型才知道「我刚才承诺过什么」
Messages API 无状态历史每轮重发成本累加
角色的另一面必须一起记住：它是训练出来的优先级，不是权限边界。模型倾向于更重视 system 里的内容，但那是概率上的倾向，不是操作系统级的隔离 —— 这一条是本篇末尾安全边界那一节的地基（T1-5、Q1-15）。
以上节选自T0-3 消息角色与对话结构：system / user / assistant 的真实分工，读全文能看到前后语境。