OmniRoute/docs/i18n/bg/docs/reference/PROVIDER_PLUGIN_MANIFEST.md

Provider Plugin Manifest (Български)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

open-sse/config/providerPluginManifest.ts дефинира безопасния за JSON договор за добавки на доставчици. open-sse/config/providerPluginManifestRegistry.ts свързва този договор с текущия регистър на доставчиците за странични процеси като Bifrost, CLIProxyAPI или бъдещ маршрутизатор на Go/Rust. Регистърът на TypeScript остава източникът на истина, но страничните процеси могат да използват манифеста, без да импортират код на изпълнители, настройки по подразбиране за OAuth, заглавки или състоянието на средата на процеса.

Същият манифест е достъпен чрез HTTP на GET /api/v1/provider-plugin-manifest за странични процеси, които се изпълняват извън основния процес.

OmniRoute съобщава този URL адрес на Bifrost и CLIProxyAPI чрез заглавката на заявката X-OmniRoute-Provider-Manifest-Url. Задайте OMNIROUTE_PROVIDER_MANIFEST_URL, когато страничният процес се нуждае от публичен URL адрес или адрес в контейнерната мрежа вместо локалния източник на заявката.

Опресняване на манифеста

HTTP крайната точка връща Cache-Control: public, max-age=60 и силен ETag. Страничният процес трябва да запази последния валидиран манифест и да изпраща неговия ETag в If-None-Match при опресняване. Отговорът 304 Not Modified няма тяло; страничният процес запазва кеширания си манифест. Ако не съществува валидиран кеширан манифест, страничният процес трябва да изпрати безусловна заявка, вместо да приема отговор 304.

Цел

Преместване на метаданните за доставчиците към договор за добавки, така че обработката на заявките по критичния път евентуално да може да бъде поета от страничен процес с по-ниска латентност, докато OmniRoute запазва маршрута на TypeScript като контролна точка за правилата и резервен вариант. Манифестът е допълващ: сам по себе си той не променя маршрутизирането на заявките.

Договор

Манифестът съдържа:

• идентификатор и псевдоним на доставчика
• формат на услугата нагоре по веригата и име на изпълнителя
• тип удостоверяване, заглавка за удостоверяване и незадължителен префикс за удостоверяване
• статични метаданни за крайната точка
• допустимост за страничен процес и изрични причини, когато доставчикът трябва да остане на TS
• безопасни за JSON метаданни за моделите, като дължина на контекста, флагове за визуални възможности/разсъждение и неподдържани параметри
• тагове за възможности, включително apikey, oauth, custom-executor, passthrough-models, responses, sidecar-candidate, usage-fetch и usage-supported

Манифестът умишлено изключва:

• клиентски тайни за OAuth и стойности на тайните по подразбиране
• разрешаване на средата по време на изпълнение
• заглавки на заявките и публични помощни функции за идентификационни данни
• динамични конструктори на URL адреси
• функции на изпълнителите
• вътрешни механизми на пула от сесии

Тагове за възможности

capabilities е сортиран масив от тагове, извлечени от записа в регистъра. Интеграторите трябва да го приемат като машинночетимия отговор на въпроса „какво може да прави този доставчик“, вместо да препрочитат изходния код на TypeScript.

Таг	Значение
apikey	Приема API ключ (authType е apikey или optional).
oauth	Използва OAuth или поток със сесия.
responses	Предоставя базов URL адрес за OpenAI Responses-API.
passthrough-models	Обслужва модели директно от услугата нагоре по веригата вместо от статичен каталог.
custom-executor	Изпълнява нестандартен изпълнител, поради което остава по пътя на TypeScript.
sidecar-candidate	Отразява sidecar.eligible — безопасно е да бъде разглеждан за импортиране в страничен процес.
usage-fetch	Има свързан механизъм за извличане на използването или квотата (getUsageForProvider).
usage-supported	API за използването приема този доставчик (isSupportedUsageConnection).

usage-fetch служи само за откриване. Той съобщава, че OmniRoute знае как да прочете използването за доставчика; не активира извличането, не променя семантиката на квотите и не означава, че компонентът за квоти в Dashboard е активиран за доставчика — този компонент се управлява отделно чрез USAGE_SUPPORTED_PROVIDERS. Източникът на истина е USAGE_FETCHER_PROVIDERS в open-sse/services/usage/fetcherProviders.ts.

Този списък използва като ключове низовете, които диспечерът за използване приема, затова смесва канонични идентификатори с псевдоними и е малко по-дълъг от броя на маркираните доставчици: записите, които не са доставчици на чат в регистъра на манифеста (например доставчикът за търсене firecrawl и ACP доставчикът amazon-q), нямат запис в манифеста, който да бъде маркиран.

usage-supported показва дали маршрутите на сървъра и Dashboard за използване приемат връзка за доставчика. Той отразява isSupportedUsageConnection() (src/lib/usage/providerLimits.ts) и supportsProviderQuota() (src/shared/utils/providerQuotaVisibility.ts), като и двете се управляват от USAGE_SUPPORTED_PROVIDERS (open-sse/services/usage/supportedProviders.ts). За разлика от usage-fetch, той се генерира само въз основа на идентификатора на доставчика — проверката по време на изпълнение извършва USAGE_SUPPORTED_PROVIDERS.includes(providerId) без разрешаване на псевдоними, така че манифестът запазва същото правило. Двата тага имат различен обхват: 3 доставчика имат само usage-fetch (opencode, opencode-zen, xai), а 1 има само usage-supported (xiaomi-mimo-token-plan), така че единият не предполага другия.

Използване на sidecar

Sidecar компонентите трябва да третират sidecar.eligible като консервативен сигнал за потенциален кандидат, а не като безусловно решение за маршрутизиране. Първоначално трябва да се импортират доставчици с API ключове и статични крайни точки, които използват изпълнителя по подразбиране. Доставчиците с персонализирани уеб изпълнители, OAuth/сесийни потоци, динамични конструктори на URL адреси или конфигурация на пулове остават по резервния TypeScript път, докато даден sidecar не реализира еквивалентно поведение и телеметрията не докаже съответствие.

Предложени фази на миграция:

1. Генериране и валидиране на манифеста на приставките за доставчици от TS регистъра.
2. Конфигуриране на Bifrost или CLIProxyAPI да импортира манифеста за доставчици с API ключове и статични крайни точки.
3. Маршрутизиране на отговарящите на условията доставчици през sidecar зад OMNIROUTE_RELAY_BACKEND, като резервният TS път остане активиран.
4. Повишаване на доставчиците само когато процентът на успеваемост, p99 латентността, поведението при поточно предаване и обработката на неподдържани параметри съответстват на TS пътя.
5. Добавяне на собствени за sidecar приставки за персонализирани изпълнители, по едно семейство доставчици наведнъж.

Защо доставчиците да не се вграждат директно в Next

Next интерфейсът не трябва да отговаря за изпълнението на доставчиците. Той трябва да извиква API границата. След това бекендът може да реши дали да използва TypeScript изпълнителя, Bifrost, CLIProxyAPI или бъдещ нативен sidecar. Така подписването на заявки, проверките спрямо списъка с разрешения, политиката на базата данни и резервното поведение остават централизирани преди всяко предаване към sidecar.