2.8 KiB
2.8 KiB
Change: 增加供应商协议路由与请求体适配架构
Why
当前多供应商架构已经能够保存多个 baseUrl + apiKey,并通过 ModelRef(profileId + modelId) 将模型归属到特定供应商。
但运行时请求仍然主要依赖“模型 ID / 厂商标签 -> adapter”的方式来决定执行链路,这在以下场景下会失效:
- 同一个模型 ID 在不同上游中需要走不同协议,例如:
- 上游 A 将
gemini-3-pro-image-preview暴露为/v1/images/generations - 上游 B 将同名模型暴露为 Google 官方
:generateContent
- 上游 A 将
- 同一个上游中的同一个模型可能支持多个调用协议,需要为不同操作或高级模式选择不同入口
- 即使协议相同,不同模型之间也可能要求不同的请求体字段、序列化格式、轮询方式和结果提取规则
- 文本链路目前仍然绕过现有图片/视频适配层,无法与多供应商路由形成统一模型
这意味着当前系统已经具备“凭证路由”,但还不具备“协议路由”和“请求体路由”。
What Changes
- 引入
ProviderModelBinding,将“模型如何被调用”从modelId中解耦出来 - 引入
InvocationPlanner,统一根据profileId + modelId + operation选择协议绑定 - 引入
ProviderTransport,统一处理鉴权、基础 URL 归一化、额外 Header、查询参数和供应商级发现入口 - 将现有
model-adapters重构为按protocol注册的协议适配器,而不是按模型猜测执行器 - 为协议适配器引入
requestSchema / responseSchema / pollingStrategy概念,覆盖同协议不同请求体格式的场景 - 将文本、图片、视频三类调用统一接入同一套规划器与协议注册器
- 扩展运行时模型发现存储,保留每个供应商下模型的原始元数据、推断出的能力和绑定信息,避免仅依赖扁平化
ModelConfig
Impact
- Affected specs:
provider-protocol-routing
- Affected code:
packages/drawnix/src/utils/settings-manager.tspackages/drawnix/src/utils/runtime-model-discovery.tspackages/drawnix/src/services/model-adapters/*packages/drawnix/src/services/generation-api-service.tspackages/drawnix/src/utils/gemini-api/*packages/drawnix/src/services/video-api-service.tspackages/drawnix/src/services/async-image-api-service.tspackages/drawnix/src/services/media-executor/*
Relationship To Existing Changes
- 本变更建立在
add-multi-provider-profiles的profiles + catalogs + presets结构之上 - 本变更进一步落实
add-multi-provider-profiles/design.md中“将ProviderType/AuthType/capabilities下沉到适配层”的决策 - 本变更会扩展
add-runtime-model-discovery的职责,使其不只负责模型列表同步,还要为运行时路由保留协议与绑定信息