现状
当前版本中(v.1.0.0),基本上所有供应商都基于 OpenAI 兼容来实现功能。这样做的优点是只需要维护一套请求即可满足绝大部分的供应商。
但缺点也很明显,由于不同供应商对于某些功能的支持不同,需要在 OpenAI 兼容接口中实现很多逻辑,而下发到各个供应商时,也需要对这些功能进行不同的兼容性。这会导致代码中广泛充斥着各类的兼容代码,而后续修改 OpenAI 兼容接口时,也将难以下手。
期望目标
期望对每个已知供应商都提供相对独立且完全适配目标供应商的底层请求,OpenAI 兼容只在动态添加未知供应商时使用。
可能的副作用
由于将每个供应商单独拆分实现,因此可以预知到的副作用有如下:
- 包的体积将会变大一部分。但这应当是可控的。
- 后续将需要积极维护不同的供应商。但在可维护性与健壮性上来说更优。
现状
当前版本中(v.1.0.0),基本上所有供应商都基于 OpenAI 兼容来实现功能。这样做的优点是只需要维护一套请求即可满足绝大部分的供应商。
但缺点也很明显,由于不同供应商对于某些功能的支持不同,需要在 OpenAI 兼容接口中实现很多逻辑,而下发到各个供应商时,也需要对这些功能进行不同的兼容性。这会导致代码中广泛充斥着各类的兼容代码,而后续修改 OpenAI 兼容接口时,也将难以下手。
期望目标
期望对每个已知供应商都提供相对独立且完全适配目标供应商的底层请求,OpenAI 兼容只在动态添加未知供应商时使用。
可能的副作用
由于将每个供应商单独拆分实现,因此可以预知到的副作用有如下: