请先确认以下事项
功能描述
希望增强 Easydict 现有“自定义 OpenAI 服务”的配置能力与兼容性，使其能够更好地适配更多 OpenAI-compatible 接口。
目前很多服务虽然大体兼容 OpenAI 接口，但在实际细节上并不完全标准，它们可能大体兼容，但仍然会在参数、stream 行为、system message 支持、响应格式等细节上存在差异，例如调用阿里巴巴百炼（千问）、OpenRouter 中部分模型接口、以及一些代理层或聚合层提供的兼容接口等等。对用户来说，这些通常都会被理解为 “OpenAI-compatible”，因此也会自然认为它们应当可以通过“自定义 OpenAI 服务”接入。
这个需求其实和 #1062 里暴露出来的问题比较接近。该 issue 里作者提到 qwen-mt-turbo 实际使用时仍然会遇到一> 些“并非完全标准”的兼容性问题，例如：
- 需要通过
extra_body 传入 translation_options
qwen-mt-plus 不支持流式输出- Qwen-MT 系列不支持设置
system message
- 这些选项目前在自定义 OpenAI 翻译界面中缺少可配置入口
但实际使用时，如果接口不完全符合 Easydict 当前的预期，请求往往会直接失败，而且错误信息不够清晰，用户很难判断到底是 endpoint 配置方式不在支持范围内、返回格式不兼容、stream 相关行为不兼容，还是程序本身只支持较严格的标准 OpenAI 接口。
因此，希望可以增强 Easydict 现有“自定义 OpenAI 服务”的配置能力与兼容性，使其能够更好地适配更多 OpenAI-compatible 接口，具体而言：
- 尽可能兼容更多 OpenAI-compatible endpoint；
- 如果某个接口暂时不在支持范围内，给出更明确的兼容提示或错误说明；
- 可选地在设置中增加类似 stream option 的高级选项，例如允许用户手动关闭或调整 stream 相关行为，以提升部分兼容接口的可用性。
使用场景
这个功能的主要使用场景是：用户希望通过 Easydict 现有的“自定义 OpenAI 服务”入口，接入除官方 OpenAI 之外的其他 OpenAI-compatible 服务，例如百炼、OpenRouter，或一些代理层、聚合层提供的兼容接口。这个场景下：
第一，常见的 OpenAI-compatible 接口能够尽可能更容易接入；
第二，当某个接口无法使用时，能够明确知道到底是当前不在支持范围内，还是某个配置项需要调整。
实现方案（可选）
从开发和维护成本来看，为了避免为每个特殊服务分别做大量适配，可以优先考虑几项更克制的改进：
-
区分错误分类和提示，根据 HTTP status、content-type、响应体结构以及是否为 stream 响应，区分是 endpoint 不在支持范围内、返回格式不兼容、stream 行为不兼容，还是请求参数不兼容，避免统一落成较模糊的解析错误。
-
在自定义 OpenAI 服务中增加少量高级兼容选项，例如允许用户手动控制是否启用 stream、是否附带 stream usage，或关闭部分默认请求行为，这样可以用较小的配置成本覆盖一部分兼容问题。
-
在实现上尽量减少对单一标准格式的强假设，把 endpoint、默认参数和响应格式判断收敛到相对独立的适配层中。进一步来说，也可以考虑增加一个轻量的兼容识别层或 router，根据 endpoint 特征、返回头信息或已知能力差异，选择对应的请求构造与响应解析策略，而不是把所有自定义 OpenAI 服务都按完全相同的方式处理。这样即使只逐步兼容最常见、最接近标准 OpenAI 的接口，后续扩展和维护也会更容易。
是否愿意提交 PR 实现该功能
请先确认以下事项
功能描述
希望增强 Easydict 现有“自定义 OpenAI 服务”的配置能力与兼容性，使其能够更好地适配更多 OpenAI-compatible 接口。
目前很多服务虽然大体兼容 OpenAI 接口，但在实际细节上并不完全标准，它们可能大体兼容，但仍然会在参数、
stream行为、system message支持、响应格式等细节上存在差异，例如调用阿里巴巴百炼（千问）、OpenRouter 中部分模型接口、以及一些代理层或聚合层提供的兼容接口等等。对用户来说，这些通常都会被理解为 “OpenAI-compatible”，因此也会自然认为它们应当可以通过“自定义 OpenAI 服务”接入。但实际使用时，如果接口不完全符合 Easydict 当前的预期，请求往往会直接失败，而且错误信息不够清晰，用户很难判断到底是 endpoint 配置方式不在支持范围内、返回格式不兼容、stream 相关行为不兼容，还是程序本身只支持较严格的标准 OpenAI 接口。
因此，希望可以增强 Easydict 现有“自定义 OpenAI 服务”的配置能力与兼容性，使其能够更好地适配更多 OpenAI-compatible 接口，具体而言：
使用场景
这个功能的主要使用场景是：用户希望通过 Easydict 现有的“自定义 OpenAI 服务”入口，接入除官方 OpenAI 之外的其他 OpenAI-compatible 服务，例如百炼、OpenRouter，或一些代理层、聚合层提供的兼容接口。这个场景下：
第一，常见的 OpenAI-compatible 接口能够尽可能更容易接入；
第二，当某个接口无法使用时，能够明确知道到底是当前不在支持范围内，还是某个配置项需要调整。
实现方案（可选）
从开发和维护成本来看，为了避免为每个特殊服务分别做大量适配，可以优先考虑几项更克制的改进：
区分错误分类和提示，根据 HTTP status、content-type、响应体结构以及是否为 stream 响应，区分是 endpoint 不在支持范围内、返回格式不兼容、stream 行为不兼容，还是请求参数不兼容，避免统一落成较模糊的解析错误。
在自定义 OpenAI 服务中增加少量高级兼容选项，例如允许用户手动控制是否启用 stream、是否附带 stream usage，或关闭部分默认请求行为，这样可以用较小的配置成本覆盖一部分兼容问题。
在实现上尽量减少对单一标准格式的强假设，把 endpoint、默认参数和响应格式判断收敛到相对独立的适配层中。进一步来说，也可以考虑增加一个轻量的兼容识别层或 router，根据 endpoint 特征、返回头信息或已知能力差异，选择对应的请求构造与响应解析策略，而不是把所有自定义 OpenAI 服务都按完全相同的方式处理。这样即使只逐步兼容最常见、最接近标准 OpenAI 的接口，后续扩展和维护也会更容易。
是否愿意提交 PR 实现该功能