ChatGLM3 开放AI流式对话接口中消息处理的优化实践

在ChatGLM3项目的开放AI API兼容层实现中，消息处理模块存在一个潜在的问题：当使用工具调用功能时，系统指令会被重复添加，且第二次添加时丢失了工具信息。本文将详细分析这一问题，并提出改进方案。

问题背景

ChatGLM3提供了与开放AI API兼容的接口实现，其中process_chatglm_messages函数负责将开放AI格式的消息转换为ChatGLM3内部格式。原始实现中，当存在工具调用时，会先添加一个包含工具信息的系统消息，但在后续处理中又可能再次添加系统消息，导致：

1. 系统指令被重复添加
2. 第二次添加的系统消息丢失了工具信息
3. 虽然不影响功能运行，但逻辑上存在矛盾

技术分析

原始代码的核心逻辑是：

1. 如果存在工具定义(tools)，先添加一个包含工具信息的系统消息
2. 然后遍历所有输入消息进行转换
3. 对于function角色消息转换为observation
4. 对于assistant角色且包含function_call的消息进行特殊处理
5. 其他情况直接添加消息

问题出在第5步：当输入消息中包含system角色消息时，会无条件添加，导致与第一步添加的系统消息重复。

解决方案

改进方案引入了msg_has_sys状态标志：

1. 当添加了带工具的系统消息后，设置msg_has_sys=True
2. 在处理普通消息时，如果遇到system角色且msg_has_sys为True，则跳过该消息
3. 这样可以确保：
   • 工具调用场景下，只保留带工具信息的系统消息
   • 普通聊天场景下，保留原始的系统消息
   • 两种场景都能正确处理

实现效果

改进后的实现能够正确处理两种场景：

1. 工具调用场景：在多轮对话中，只保留最初添加的带工具信息的系统消息，后续的系统消息会被过滤

2. 普通聊天场景：当不存在工具调用时，保留原始的系统消息，确保普通聊天功能正常

技术意义

这一改进虽然看似简单，但体现了API设计中的重要原则：

1. 消息处理的幂等性：确保相同输入产生相同输出
2. 状态管理的清晰性：通过显式状态标志控制流程
3. 场景兼容性：同时支持工具调用和普通聊天两种模式

这种设计模式可以推广到其他类似的消息处理场景中，特别是在需要支持多种对话模式的AI系统中。

总结

通过对ChatGLM3消息处理模块的优化，我们解决了系统消息重复添加的问题，同时保持了功能的完整性和场景的兼容性。这一改进不仅提升了代码的健壮性，也为后续的功能扩展奠定了更好的基础。