大模型使用中role的定义

在大模型的对话式 API（Chat Completion）中，role 是每条对话消息的身份标识字段，用来明确标记这条消息的发送方身份，是所有主流大模型（OpenAI、豆包、通义千问、Ollama 等）通用的标准规范。

简单来说：大模型的对话上下文是由多条消息组成的数组，每条消息必须用 role 说明「这是谁发的」，再用 content 说明「发了什么内容」。

---

一、核心作用

1. 构建对话逻辑结构：让模型清晰区分「系统规则」「用户提问」「自己的历史回复」，正确理解多轮对话的上下文。
2. 传递全局指令：通过专属的 system 角色，给模型注入全局生效的规则、身份设定、输出要求，优先级高于普通对话。
3. 支持扩展能力：通过 tool/function 角色，实现工具调用、RAG 检索、智能体等复杂能力，让模型能和外部系统交互。
4. 规范对话格式：统一的角色标准让不同模型、不同框架的对话逻辑可以通用。

---

二、标准核心角色（最常用）

主流大模型通用的 4 个核心角色，覆盖绝大多数开发场景：

1. system：系统角色

• 定义 ：代表开发者/系统给模型的全局指令，对整个对话全程生效，通常放在对话消息的最开头。

• 核心用途 ：

  • 设定模型的身份、人设（比如"你是一个专业的 Python 开发助手"）
  • 定义输出规则、格式要求（比如"用 Markdown 格式输出，分点回答"）
  • 设定约束条件（比如"不知道的问题直接说不知道，不要编造"）
  • 注入全局背景知识、工具定义（RAG、Agent 场景）

• 特点：优先级最高，模型会优先遵循 system 里的规则；简单对话可以省略，但复杂场景强烈建议添加。

• 示例 ：

  {"role": "system", "content": "你是一个专业的RAG智能助手，只能基于给定的参考资料回答用户问题，答案要简洁准确。"}

2. user：用户角色

• 定义 ：代表人类用户的输入，也就是向模型提出的问题、指令、补充信息。

• 核心用途：传递用户的实际需求，是模型响应的核心依据；RAG 场景中，检索到的上下文资料通常会拼接在 user 消息里。

• 特点：多轮对话中，user 和 assistant 通常交替出现；连续多条 user 消息大多数模型也能兼容，但不符合规范，容易产生歧义。

• 示例 ：

  {"role": "user", "content": "华为最新发布的手机是什么型号？"}

3. assistant：助手角色

• 定义 ：代表大模型自身输出的回复内容。

• 核心用途 ：

  • 记录模型的历史回答，构建多轮对话的上下文
  • 工具调用场景中，用来承载模型生成的工具调用指令（tool_calls）

• 特点：是模型输出的默认角色；多轮对话中必须和 user 交替对应。

• 示例 ：

  {"role": "assistant", "content": "华为最新发布的旗舰手机是Mate 70系列，于2024年9月发布。"}

4. tool（旧称 function）：工具角色

• 定义 ：代表外部工具/函数的返回结果，是智能体（Agent）、工具调用场景的专属角色。

• 核心用途：把搜索、代码执行、数据库查询等外部工具的执行结果返回给模型，让模型基于工具结果继续生成最终答案。

• 特点 ：必须紧跟在 assistant 的工具调用消息之后，需要对应工具调用的唯一 ID；是实现 RAG、智能体的核心角色之一。

• 完整示例（Agent 工具调用流程） ：

  messages = [
      {"role": "system", "content": "你可以调用搜索工具查询实时信息。"},
      {"role": "user", "content": "今天北京的天气怎么样？"},
      # 模型返回工具调用指令
      {"role": "assistant", "tool_calls": [
          {"id": "call_001", "type": "function", 
           "function": {"name": "weather_search", "arguments": "{\"city\":\"北京\"}"}}
      ]},
      # 工具执行完成后，用tool角色返回结果
      {"role": "tool", "tool_call_id": "call_001", "content": "北京今日晴，气温22-28℃，微风。"}
  ]

---

三、扩展特殊角色

部分大模型会提供额外的角色，用于特定场景：

1. developer 角色：OpenAI 推出的高阶角色，用来替代部分 system 的开发者指令，优先级高于 system，专门用于注入底层规则、安全约束，避免被用户 Prompt 注入覆盖。
2. 部分国内模型会扩展 system 的子类型（比如知识库角色、插件角色），但本质都是基于 system 角色的能力扩展，没有脱离标准体系。

---

四、使用规范与最佳实践

1. 基础格式规范

• 对话消息是一个有序数组，顺序严格按照对话时间先后排列。
• 普通多轮对话遵循 user → assistant → user → assistant 交替的格式，语义最清晰。
• system 消息通常放在数组的第一个位置，全局生效；不推荐中途插入 system 消息。

2. 不同场景的最佳实践

• 简单对话：可以省略 system，直接传 user 消息即可。
• RAG 场景：把检索到的参考资料拼接在 user 消息的内容里，system 设定回答规则和约束。
• Agent/工具调用 ：system 里定义工具列表和使用规则，严格按照 user → assistant(工具调用) → tool → assistant(最终答案) 的流程传递。
• 高精度场景：把输出格式、约束条件明确写在 system 里，不要散落在 user 消息中。

3. 常见误区

• ❌ 误区1：把「人设设定」当成 role。比如"你是一个老师"是写在 system 的 content 里的，不是 role 的取值，role 只有固定的几个枚举值。
• ❌ 误区2：连续多条 assistant 或 user 消息。大多数模型能兼容，但会增加上下文理解的歧义，尽量交替排列。
• ❌ 误区3：tool 角色随意放置。必须对应前面 assistant 的工具调用，不能凭空出现 tool 消息。

---

五、模型兼容性说明

• 主流商用大模型（OpenAI、豆包、文心一言、通义千问）全部兼容 system / user / assistant / tool 标准角色。
• 部分开源小模型（比如早期的小参数 Llama）可能不支持 system 角色，需要把系统指令拼接在第一条 user 消息里；Ollama 上的主流模型（Qwen、Llama 3、Mistral）都完整支持标准角色。