gpt-oss中的"Harmony"聊天格式有啥与众不同？或是此次开源的唯一亮点！

本文将详细解析一下专为GPT-OSS模型设计的“harmony”聊天格式，并将其与Qwen3和Llama3等主流模型的聊天模板（Chat Template）进行深入比较。

首先，需要理解一个基本概念：聊天模板是一种预设的格式规则。它通过添加特殊的标记（special tokens）和固定的结构，将多轮对话（包含系统指令、用户提问、模型回答等）转换成一个单一的、模型能够理解的字符串。正确使用与模型预训练时一致的模板，对于保证模型性能、使其能够准确理解指令和角色至关重要。

"Harmony"是OpenAI为其GPT-OSS模型量身定做的响应格式，其设计目标远超一个简单的聊天模板，更像一个为复杂智能体（Agent）任务设计的结构化输出协议 。 其核心理念是将模型的“思考过程”、“工具调用”和“最终答案”清晰地分离，为开发者提供前所未有的控制力和透明度。

“Harmony”格式的核心特性：

1. 多通道架构 (Multi-channel Architecture)：这是Harmony最显著的不同之处。 它将助手的回复划分到不同的“通道”，每个通道有明确的用途：

• final : 用于存放直接呈现给最终用户的、经过安全过滤的正式回复。
• analysis : 用于存放模型的“思考链”（Chain-of-Thought）或内部推理过程。 这部分内容不保证遵循与 final 通道相同的安全标准，因此应避免直接展示给用户。
• commentary : 用于存放工具使用的前导信息或注释。

• 明确的角色层级 (Role Hierarchy)：Harmony定义了一套具有优先级的角色，用于在指令发生冲突时进行裁决。其层级为：System > Developer > User > Assistant > Tool。

• developer : 这个角色类似于其他模型中的 system 角色，用于提供核心的、定制化的模型指令。
• system : 用于定义模型的身份标识（如“你是ChatGPT”）、知识截止日期和可用的工具等元信息。
• tool : 代表模型调用的工具及其返回结果。

• 专用的特殊标记 (Special Tokens)：Harmony使用了一系列特殊的Token来严谨地包裹和分隔每一条信息，确保机器解析的准确性。

• <|start|> 和 <|end|> : 标记每条信息的开始和结束。
• <|return|> : 标记整个对话或一轮生成的结束。
• <|call|> : 表示需要执行一次工具调用。

• 强制性与生态系统标准化 ：OpenAI明确指出，GPT-OSS模型必须使用Harmony格式才能正常工作并发挥其全部性能，尤其是复杂的工具调用和推理能力。 同时，官方提供了openai-harmony库（支持Python和Rust）来帮助开发者正确构建和解析这种格式，旨在为其开源生态建立统一和可靠的标准。

一个简化的Harmony格式示例可能如下所示：

  
<|start|>  
system  
Knowledge cutoff: 2025-08  
<|end|>  
<|start|>  
user  
计算2加2等于多少？  
<|end|>  
<|start|>  
assistant  
channel: analysis  
用户想做一个简单的加法运算，可以直接回答。  
<|end|>  
<|start|>  
assistant  
channel: final  
结果是4。  
<|end|>  
<|return|>  

| 特性 | GPT-OSS (Harmony) | Qwen3 (ChatML-based) | Llama3 | | --- | --- | --- | --- | | 核心结构 | 多通道

，分离思考、工具和最终答案。 | XML风格

，将思考过程内嵌在回复中。 | 简单的 角色导向 结构。 | | 角色定义 | 拥有层级的 system , developer , user , assistant , tool 。 | system

, user , assistant 。 | system

, user , assistant , 以及新增的 ipython (工具) 角色。 | | 特殊标记 | <|start|>

, <|end|> , <|return|> , <|call|> 等。 | <|im\_start|>

, <|im\_end|> | <|begin\_of\_text|>

, <|eot\_id|> , <|start\_header\_id|> 等。 | | 处理推理过程 | 通过独立的 analysis 通道明确输出。 | 可选的 <think></think> 块，内嵌于助手的单次回复中。 | 没有明确的、标准化的推理过程输出结构。 | | 工具调用 | 结构化、多步骤的过程，通过 commentary 和 <|call|> 标记。 | 使用XML风格的标签来定义和调用工具。 | Llama 3.1后增强了工具调用，并引入 ipython 角色接收工具输出。 | | 设计哲学 | 结构化输出协议

，为复杂的智能体工作流设计，强调可靠性和透明度。 | 灵活的对话标记语言

，通过可选的“思考模式”平衡效率和推理深度。 | 高效的对话格式

，旨在通过优化的分词和简洁的模板提升效率和多语言能力。 |

• Qwen3 (基于ChatML) : Qwen系列的模板以其类似XML的<|im\_start|>和<|im\_end|>标签为特征，结构清晰。 它的一大特色是引入了“思考模式”，可以通过enable\_thinking标志或在提示中加入/think指令来开启。 当开启时，模型会在其回答中内嵌一个<think>...</think>代码块来展示其推理步骤。这种设计比Harmony更简洁，但也将思考过程和最终答案混合在了一起。
• Llama3 : Llama3的模板相对更直接，主要通过<|start\_header\_id|>角色<|end\_header\_id|>这样的结构来定义对话角色。 它的主要进化在于分词器的改进和为了更好地支持多语言和工具调用而进行的格式调整。例如，Llama 3.1引入了ipython这个新角色，专门用来标记工具的输出信息，从而使工具调用流程更加规范。 它的设计重点在于效率和易用性，但缺乏Harmony那种内置的、将思考过程与最终答案分离的机制。

"Harmony"聊天格式与Qwen3、Llama3等模型的模板最根本的区别在于其设计目标和复杂性 。

• 关注点的分离 ：Harmony是唯一一个在格式层面就强制将思考（analysis）、评论（commentary）和最终答案（final） 进行分离的模板。 这使得开发者可以轻松地只提取用户需要的最终答案，同时又能完整地记录和审查模型的内部决策过程，这对于构建可信赖的、复杂的AI智能体至关重要。
• 为智能体而生 ：相比于主要为“对话”设计的Qwen3和Llama3模板，Harmony更像是一个为“执行任务 ”而设计的协议。其明确的角色层级、工具调用流程和多通道输出，都是为了让模型能够更可靠地执行包含多步骤推理和与外部工具交互的复杂工作流。
• 强制的标准化 ：Harmony是GPT-OSS模型的强制性要求 ，而非一个可选的最佳实践。 这反映了OpenAI希望在其开源生态中建立一个统一、稳健的交互标准，以承载其模型更高级的智能体能力。

总而言之，当其他聊天模板还停留在如何更好地“组织对话”时，Harmony已经迈向了如何更清晰、更可靠地“编排任务 ”。这种设计上的跃迁，使其在构建需要高透明度和复杂工具协调能力的AI应用时，具有独特的优势。