基础概念

一、三种角色简介

角色	英文名	作用	常见用法
system	系统角色	定义“模型身份”和“对话规则”	“你是一个专业的Python工程师，回答要简洁准确。”
user	用户角色	表示人类提出的问题或请求	“帮我写一个Dockerfile。”
assistant	助手角色	表示模型自己的输出	“好的，这是一个示例Dockerfile…”

二、他们是如何影响模型行为的

可以理解为：

system → 规定世界规则
user → 发出任务请求
assistant → 执行任务、给出回答

模型会从上到下读取整个“对话历史”来决定回答。
它会认为：

1. system 的内容是最高优先级指令（定义身份和限制）。
2. user 的内容是需要完成的任务。
3. assistant 的内容是模型自己的过往回答，可作为上下文记忆。

举个具体例子

[
  {"role": "system", "content": "你是一位资深Python开发专家。回答时要带有解释。"},
  {"role": "user", "content": "写一个快速排序算法"},
  {"role": "assistant", "content": "当然，这里是Python版本的快速排序..."},
  {"role": "user", "content": "解释一下它的复杂度"}
]

模型在生成下一个回答时，会综合前面所有信息：

• system 决定语气和身份；
• user 决定当前任务；
• assistant 是历史上下文；
• 最终输出一个新的 assistant 消息。

三、在不同框架中的用法差异

框架 / API	写法	特点
OpenAI API (Chat Completions)	messages=[{"role": "system", "content": ...}, {"role": "user", ...}]	最标准的写法
LangChain / LangGraph	SystemMessage(), HumanMessage(), AIMessage()	对 system/user/assistant 的封装
DSpy / Parlant 等提示工程框架	通过“角色模板”或“上下文块”构造提示	背后仍然映射到这三种角色逻辑

四、实践建议

场景	建议用法
设定模型风格或身份	放在 system（例如“你是一个严谨的数据分析师”）
用户的实际问题或命令	放在 user
示例对话或少样本学习(few-shot)	用 assistant 来展示“正确回答示例”
控制行为（例如输出格式、语气）	放在 system 中优于 user，因为优先级更高

使用例子

示例 1：最基础版（定义身份 + 问题）

[
  {"role": "system", "content": "你是一名精通 Python 的后端工程师，回答要简洁明了。"},
  {"role": "user", "content": "写一个函数来统计字符串中每个字母出现的次数。"}
]

模型理解流程：

• system 告诉模型：“你是Python工程师，要简洁。”

• user 提出任务。

• 模型输出 assistant：

  {"role": "assistant", "content": "当然，这里是一个示例：\n\n```python\ndef count_letters(s):\n    from collections import Counter\n    return Counter(s)\n```"}
  

示例 2：Few-shot 提示（示例教学法）

通过在提示中加上 “示例对话”（即历史的 user + assistant），你能让模型模仿某种风格或格式。

[
  {"role": "system", "content": "你是一位专业翻译助手，只翻译文本，不解释。"},
  {"role": "user", "content": "Hello, how are you?"},
  {"role": "assistant", "content": "你好，你好吗？"},
  {"role": "user", "content": "Good morning, my friend."}
]

模型会模仿前一个 assistant 的翻译风格：

{"role": "assistant", "content": "早上好，我的朋友。"}

示例 3：多步骤任务（推理 + 输出）

我们希望模型先“思考”，再“输出结果”，可以通过多段 user/assistant 来引导。

[
  {"role": "system", "content": "你是一位逻辑推理助手，先分析问题，再给出答案。"},
  {"role": "user", "content": "一个苹果2元，一个香蕉3元，我买了3个苹果和2个香蕉，总共多少钱？"},
  {"role": "assistant", "content": "先计算苹果：3 × 2 = 6元。香蕉：2 × 3 = 6元。总价：6 + 6 = 12元。答案是12元。"}
]

模型从中学会了：

• system 告诉它“要先分析”；
• assistant 提供“正确回答格式”；
• 下一次用户再提问，它会自动模仿这种推理结构。

示例 4：多 Agent 对话（模拟角色）

让模型模拟两个不同身份的对话者，只需在提示中使用不同的角色定义：

[
  {"role": "system", "content": "你要扮演两个角色：\n1. 设计师 A：负责提出创意。\n2. 开发者 B：负责实现方案。\n请用对话形式展开。"},
  {"role": "user", "content": "我们来做一个天气预报App，讨论一下界面设计。"}
]

模型输出的 assistant 可能是：

A（设计师）：我觉得首页可以显示当前温度、天气图标和未来三天预报。
B（开发者）：可以，我们可以调用OpenWeatherMap API来获取这些数据。
A：那背景颜色随天气变化怎么样？
B：好主意，可以用CSS变量实现动态主题。

这种结构在 LangGraph 或 LangChain 多Agent 协作里特别常用。

示例 5：严格控制输出格式（system 优先级最高）

[
  {"role": "system", "content": "你是一名 JSON 数据生成助手。只输出符合 JSON 格式的内容，不要任何解释。"},
  {"role": "user", "content": "生成一个包含姓名、年龄和城市的用户信息示例。"}
]

输出：

{"name": "Alice", "age": 28, "city": "Tokyo"}

如果没有 system 限制，它可能会说：

“好的，这是一个示例：{…}”，
那就不纯粹是 JSON 了。
这里其实还可以传入 assistant 给出例子，会更好。