参数覆盖无法识别原始模型名称

[chung1912]

目前最新版本0.9.25，已经合并了这个pr #2276

// 目前内置以下字段：
// - model：优先使用上游模型名（UpstreamModelName），若不存在则回落到原始模型名（OriginModelName）。
// - upstream_model：始终为通道映射后的上游模型名。
// - original_model：请求最初指定的模型名。

测试的参数覆盖如下：

{
  "operations": [
    {
      "path": "enable_thinking",
      "mode": "set",
      "value": true,
      "keep_origin": false,
      "conditions": [
        {
          "path": "model",  //  path为original_model时可以正常触发条件
          "mode": "contains",
          "value": "thinking"
        }
      ],
      "logic": "AND"
    }
  ]
}

其中原始模型名为deepseek-v3.2-exp-thinking，上游模型名为deepseek-v3.2-exp；
经过测试，path是model无法设置enable_thinking参数为true；当我将条件的value改为“3.2”，此时上游模型因为有3.2，可以触发思考，说明判断模型名称model时仍然不能兼容两种情况，当判断上游模型不含有关键词thinking时，就没有再继续判断原始模型了

[seefs001]

意思是说还是和之前的一样使用的是重定向后的模型名字吗？
或许我应该改一下描述，对于OpenAI兼容接口，这个为了保证兼容，model的用法和之前没有变化，之所以弄original_model就是为了解决这种问题。
model：优先使用上游模型名（UpstreamModelName），若不存在则回落到原始模型名（OriginModelName）
这里的model在你的这个用法里是必然存在的而且只会是上游模型名，他不会同时包括这两个的。
把model提出来的原因是Gemini的请求没有模型名称，这个内置model在这里用的。

稍后会在文档更新用法。

[chung1912]

意思是说还是和之前的一样使用的是重定向后的模型名字吗？ 或许我应该改一下描述，对于OpenAI兼容接口，这个为了保证兼容，model的用法和之前没有变化，之所以弄original_model就是为了解决这种问题。 model：优先使用上游模型名（UpstreamModelName），若不存在则回落到原始模型名（OriginModelName） 这里的model在你的这个用法里是必然存在的而且只会是上游模型名，他不会同时包括这两个的。 把model提出来的原因是Gemini的请求没有模型名称，这个内置model在这里用的。

稍后会在文档更新用法。

是不是这么理解：对于model，如果有上游名称就判断上游名称（不会再继续判断原始模型名称）；如果上游名称不存在，则判断原始模型名称。是这个意思吗？
我原来以为是model是先判断上游名称是否满足条件，如果不满足，则进一步判断原始模型是否满足条件

[seefs001]

意思是说还是和之前的一样使用的是重定向后的模型名字吗？ 或许我应该改一下描述，对于OpenAI兼容接口，这个为了保证兼容，model的用法和之前没有变化，之所以弄original_model就是为了解决这种问题。 model：优先使用上游模型名（UpstreamModelName），若不存在则回落到原始模型名（OriginModelName） 这里的model在你的这个用法里是必然存在的而且只会是上游模型名，他不会同时包括这两个的。 把model提出来的原因是Gemini的请求没有模型名称，这个内置model在这里用的。

稍后会在文档更新用法。

是不是这么理解：对于model，如果有上游名称就判断上游名称（不会再继续判断原始模型名称）；如果上游名称不存在，则判断原始模型名称。是这个意思吗？
我原来以为是model是先判断上游名称是否满足条件，如果不满足，则进一步判断原始模型是否满足条件

没有，这个pr不会做对之前的破坏性更新，如果需要用原始模型就用新增加的确定的字段，一个变量只会对应一个字段。

可以这么理解，model只是上游模型的别名，毕竟上游模型不存在那就代表没有重定向，上游模型=原始模型。