供应商 profile 全表

非 OpenAI 供应商的端点与字段映射是供应商的属性，所以随供应商一起发布，而不是控制台里一个需要操作员点击、再手工验证的预设按钮。 保存渠道时 ApplyProviderProfile 按 type_hint（留空取 site.platform）查表，只填空位：已经手写请求 / 响应映射的渠道完全不动。路径覆盖是这条闸门的豁免项——「把完整端点 URL 粘进 base_url」写的就是那个字段，属同一意图。 profile 自己会先过一遍 ValidateUpstreamMap，所以不可能存进一份非法映射。

共 1 个profile。

类型	别名	路径覆盖	接受的推理档位	端点匹配
typesafe	typesafe-systemone、typesafe-system-one、systemone	v1/systemone	none、low、medium、high、xhigh	v1/systemone

运行时能力与保存期映射是两件事

• 接受的推理档位 是运行时能力：转发前把下游的 reasoning_effort 落到上游真认的档位，否则上游会直接 400。查表先按 type_hint，查不到再按端点后缀匹配。
• 保存期的字段映射刻意不适用端点匹配。 手写映射的主人是操作员，运行时只借能力、不碰映射。
• 操作员声明的天花板 max_reasoning_effort 与 profile 的能力独立生效：留空或选 max 表示不降档。改写会记录在 mapped_reasoning_effort 上（如 max→xhigh），降档不消耗故障转移预算。

typesafe 的映射

路径覆盖：v1/systemone

请求映射

[
  {"from":"messages.0.content","to":"state"},
  {"keep":["model","state"]},
  {"to":"questions.answer.type","value":{"str":"noul"}},
  {"to":"questions.answer.instructions","value":{"str":"Respond to the state."}}
]

响应映射

[
  {"to":"object","value":{"str":"chat.completion"}},
  {"to":"choices.0.message.role","value":{"str":"assistant"}},
  {"to":"choices.0.message.content","template":"{answers.answer.noul}"},
  {"to":"choices.0.finish_reason","value":{"str":"stop"}},
  {"from":"usage.input_tokens","to":"usage.prompt_tokens"},
  {"from":"usage.output_tokens","to":"usage.completion_tokens"}
]

新增一个非 OpenAI 供应商要动四处

• Go 的 OpenAICompatibleBrands() + CanonicalType（映射到 openai-compatible，让模型清单与转发解析命中）；
• providerProfiles 注册 profile；
• 前端 connectionTypes.ts 的 CONNECTION_TYPE_OPTIONS 与 base URL 预设；
• 前端 helpers.tsx 的 NO_USER_AUTH_TYPES（否则抽屉里会多出无用的用户令牌字段）。