根据通义千问（DashScope）的官方文档及API调用规范，其上下文角色（Context Roles）主要分为以下四种，这些角色在协议中虽未直接定义，但通过技术文档和接口规范被明确约束，用户需按此规则使用服务以避免违约风险：

一、核心角色类型

1. system（系统角色）

   • 功能：用于设置模型的基础行为、身份或规则，是上下文的最高级指令。
   • 协议约束：
     • 必须位于 messages 数组的最开始位置，确保模型在处理后续对话前明确自身定位（如“你是一个法律顾问”）。
     • 内容需符合《生成式人工智能服务管理暂行办法》等法规，禁止引导模型生成违法或有害内容。
   • 典型场景：

     {
       "role": "system",
       "content": "你是江让，男性，围棋天才，性格热情顽皮，说话幽默"
     }
     

2. user（用户角色）

   • 功能：代表用户输入的问题或指令，是对话的核心交互内容。
   • 协议约束：
     • 用户需对输入内容的合法性负责，禁止用于窃取数据、电信诈骗等非法用途。
     • 若涉及用户业务数据（如客户信息），需确保已获得合法授权，避免侵犯第三方权益。
   • 典型场景：

     {
       "role": "user",
       "content": "我在看书"
     }
     

3. assistant（助手角色）

   • 功能：包含模型的历史回复，用于构建上下文连贯性。
   • 协议约束：
     • 模型生成的内容归用户所有，但用户需对其发布或传播行为负责。
     • 若生成非真实信息（如虚构新闻），需以显著方式标识（如水印）。
   • 典型场景：

     {
       "role": "assistant",
       "content": "哦？（凑到你身边）看什么书这么入迷？"
     }
     

4. tool（工具角色）

   • 功能：用于整合外部工具（如API、数据库）的调用结果，扩展模型能力。
   • 协议约束：
     • 工具调用需符合阿里云平台规则，禁止滥用接口导致资源浪费。
     • 若使用自定义工具，需确保其合法性及安全性，避免引入恶意代码。
   • 典型场景：

     {
       "role": "tool",
       "content": "{\"name\":\"weather\",\"parameters\":{\"city\":\"杭州\"}}"
     }
     

二、协议中的隐含要求

1. 角色顺序强制性
   system 角色必须作为 messages 的第一个元素，否则可能导致模型行为异常。例如：

   [
     {"role": "user", "content": "你好"}, // 错误：缺少 system 角色
     {"role": "assistant", "content": "你好"}
   ]
   

2. 内容合法性审查

   • 用户需确保所有角色的 content 不违反《网络安全法》《数据安全法》等法规。
   • 若 system 角色设置违法指令（如“伪造身份信息”），阿里云有权终止服务并追究责任。

3. 历史上下文存储限制

   • 协议未强制要求阿里云存储对话记录，但用户需自行管理 messages 数组以实现多轮对话。
   • 若用户通过第三方工具（如Chatbox）调用，需确保工具服务商遵守数据隐私条款。

三、风险提示

1. 角色滥用后果

   • 若将 system 角色用于恶意引导（如生成虚假新闻），用户需承担全部法律责任。
   • 公开 tool 角色的调用参数（如API密钥）可能导致安全漏洞，需严格保密。

2. 协议更新影响
   阿里云可能通过更新协议调整角色规范（如新增 function 角色），用户需定期查阅最新文档。

四、技术实现参考

通义千问的角色扮演模型（如 qwen-plus-character）对角色使用有更严格要求：

• system 角色需包含详细人设：如姓名、性格、语言风格等，甚至可通过括号标注动作或心理活动。
• assistant 角色需模拟角色行为：例如，若 system 设置为“顽皮高中生”，回复需体现幽默和口语化。

总结

通义千问的上下文角色通过技术规范间接约束在协议中，用户需严格遵循 system、user、assistant、tool 的定义及顺序要求，同时确保内容合法合规。若违反角色使用规则，可能导致服务终止或法律风险。建议在开发前仔细阅读《通义千问大模型API服务协议》及最新技术文档。