消息角色是什么
对话接口用 messages 数组表达上下文，每条消息带一个角色：系统角色定义长期行为约束，用户角色承载用户输入与部分附件内容，助手角色保存模型此前说过的话与它发出的工具调用请求，工具角色回填工具执行结果。多轮对话的实现方式就是把模型回复按原样追加回数组再发下一次请求，角色用错是很多诡异行为的根源。
基本信息
| 系统角色 | 定义行为边界、语气与格式要求，长期有效 |
|---|---|
| 用户角色 | 用户输入；图片与文件块通常挂在用户消息里 |
| 助手角色 | 模型历史回复，也承载工具调用请求 |
| 工具角色 | 回填工具执行结果，需与调用标识对应 |
| 顺序要求 | 多数接口要求系统消息在最前，其余按时间排列 |
| 多轮实现 | 把上一轮助手回复原样追加，再发下一次请求 |
角色对照与常见误用
| 角色 | 职责 | 常见误用 |
|---|---|---|
| 系统 | 长期行为约束与输出规范 | 把业务数据塞进系统消息，导致内容与指令混淆 |
| 用户 | 本次输入与附件内容 | 把模型的历史回复也写成用户消息 |
| 助手 | 历史回复与工具调用请求 | 回填工具结果时改写或丢弃调用标识 |
| 工具 | 工具执行结果 | 结果里的错误信息被当成正常数据继续推理 |
典型使用场景
- 多轮客服：保留必要历史轮次，让上下文连贯
- 工具链路：助手请求调用、工具回填结果、模型继续作答
- 角色扮演：系统消息里固定语气与知识边界
- 结构化流程：系统消息规定输出格式，用户消息只放数据
- A/B 测试：固定系统消息，只改变用户输入以对比效果
多轮与工具调用的消息结构
多轮与工具调用的消息结构
[
{ "role": "system", "content": "你是订单客服，只依据查询结果回答" },
{ "role": "user", "content": "我的订单到哪了" },
{ "role": "assistant", "content": null, "tool_calls": [ { "id": "call_1", "function": { "name": "query_order", "arguments": "{\"id\":\"A001\"}" } } ] },
{ "role": "tool", "tool_call_id": "call_1", "content": "{\"status\":\"已发货\"}" },
{ "role": "assistant", "content": "您的订单已发货" }
]
# 助手消息里的调用请求要原样带回，工具结果必须对应同一个调用标识历史轮次并非越多越好：把无关旧消息留在数组里既涨 token 也干扰判断，多轮应用要配合裁剪或摘要策略。
系统消息里不要直接拼接用户可控的内容：那等于把用户的输入提升成系统级指令，是提示注入最常见的入口。