LMDeploy中多轮对话历史包含Tool Calls时的参数嵌套问题解析

在开源项目LMDeploy的使用过程中，开发者们发现了一个关于多轮对话历史中包含Tool Calls时出现的参数嵌套问题。这个问题主要影响使用Qwen2.5-32B-Instruct-AWQ和Internlm2等模型的用户，会导致工具调用时参数解析失败。

问题现象

当在多轮对话历史中保留带有tool_calls的message时，新生成的response中tool_calls的arguments参数会被额外嵌套一层字符串。具体表现为：

1. 正常期望的arguments格式应为：{"location": "Beijing, China"}
2. 实际得到的格式却是："{\\"location\\": \\"Beijing, China\\"}"

这种双重转义的结果会导致后续调用工具时arguments解析失败，特别是在使用Pydantic Model进行参数验证的框架（如LangChain）中，会抛出ValidationError。

问题根源

经过分析，这个问题源于LMDeploy在拼接prompt template时的处理逻辑。具体来说：

1. 按照OpenAI API规范，messages.tool_calls.function.arguments应该是一个已经经过JSON序列化的字符串
2. 但LMDeploy的实现中，默认将arguments视为字典对象，并自动执行了一次json.dumps()
3. 这导致当客户端已经提供了JSON字符串时，服务器端又进行了一次序列化

这种双重序列化的结果就是模型学习到了错误的格式，在后续响应中也返回了双重转义的JSON字符串。

技术影响

这个问题对开发工作流产生了多方面影响：

1. 工具调用失败：直接导致后续工具调用时无法正确解析参数
2. 框架兼容性问题：与使用严格类型检查的框架（如LangChain）不兼容
3. 开发体验下降：开发者需要手动处理额外的转义层，增加了开发复杂度

解决方案

项目维护团队已经意识到这个问题并在最新版本中进行了修复。修复的核心思路是：

1. 严格遵循OpenAI API规范，将arguments视为已经序列化的字符串
2. 在拼接prompt template时不再对arguments进行额外的JSON序列化
3. 确保模型接收和返回的格式一致性

最佳实践建议

对于正在使用LMDeploy的开发者，建议：

1. 升级到包含此修复的最新版本
2. 如果暂时无法升级，可以在客户端添加额外的处理逻辑：
   • 对返回的arguments执行两次json.loads()
   • 或者在发送请求前确保arguments已经是字符串格式
3. 在使用第三方框架时，注意检查参数验证逻辑的兼容性

总结

这个问题很好地展示了在构建复杂AI系统时，接口规范一致性的重要性。LMDeploy团队及时响应并修复了这个问题，体现了开源社区对用户体验的关注。开发者在使用类似工具时，应当注意遵循官方API规范，并在遇到异常行为时及时反馈，共同推动工具生态的完善。