Мотивация рефакторинга Auth Provider Registry

Ранее модуль аутентификации моделировал каждый путь настройки как отдельный поток: API-ключ, OAuth, тарифные планы и кастомные провайдеры. На практике все эти пути приводили к одному и тому же результату: обновлению конфигурации провайдера пользователя в ~/.qwen/settings.json.

Данный рефакторинг делает настройку провайдера общей абстракцией. Провайдер описывает, как он отображается, как собираются учетные данные, какие модели устанавливает и какие изменения настроек должны быть применены. API-ключи, OAuth, тарифные планы (coding plans и token plans) и кастомные мастера настройки — это способы настройки провайдера, а не отдельные архитектуры аутентификации.

Цели

• Сохранить пользовательские потоки /auth понятными:
  • Alibaba ModelStudio для настройки собственных (first-party) провайдеров Qwen.
  • Сторонние провайдеры для распространённых встроенных интеграций, таких как DeepSeek, MiniMax и Z.AI.
  • OAuth-провайдеры, такие как OpenRouter.
  • Кастомные провайдеры для локальных серверов, прокси или провайдеров, не встроенных в систему.
• Перенести данные, специфичные для провайдера, в небольшие декларативные конфиги провайдеров.
• Упростить добавление сторонних провайдеров: добавление распространённого провайдера обычно должно означать добавление одного конфига провайдера плюс тесты.
• Централизовать запись настроек через ProviderInstallPlan и applyProviderInstallPlan.
• Разделить группировку в UI и поведение установки. Группы помогают пользователям ориентироваться в /auth; они не должны управлять логикой настроек.
• Сохранить механизм для владения списком моделей и метаданными провайдера, чтобы обновления моделей провайдера можно было обнаруживать и применять безопасно.

Архитектура

Новая структура разделяет определения провайдеров, логику установки и состояние UI:

packages/cli/src/auth/
├── allProviders.ts
├── providerConfig.ts
├── types.ts
├── install/
│   └── applyProviderInstallPlan.ts
└── providers/
    ├── alibaba/
    ├── custom/
    ├── oauth/
    └── thirdParty/

ProviderConfig — это декларативный контракт для встроенных провайдеров. Он содержит метку провайдера, протокол, опции базового URL, ключ окружения, список моделей, метаданные моделей, группировку в UI и поведение настройки.

buildInstallPlan преобразует конфиг провайдера и собранные вводные данные настройки в ProviderInstallPlan. План установки — это единственный объект, который должен понимать механизм записи настроек.

applyProviderInstallPlan применяет этот план, обновляя настройки окружения, modelProviders, выбранный тип аутентификации, опциональный выбор моделей и метаданные провайдера. Это сохраняет независимость сохранения настроек от потока UI, который собирал входные данные.

Пользовательские потоки

/auth по-прежнему может предоставлять разные точки входа, но все они должны сходиться к одному и тому же пути установки провайдера:

1. Alibaba ModelStudio

   • Coding Plan (тарифный план для разработки)
   • Token Plan (тарифный план по токенам)
   • Стандартный API-ключ

2. Сторонние провайдеры

   • Распространённые провайдеры со встроенными значениями по умолчанию.
   • Каждый провайдер должен иметь свой базовый URL, ключ окружения, стандартные модели и метаданные моделей.
   • Z.AI должен использовать специфичный для настройки базовый URL:
     • Coding Plan: https://api.z.ai/api/coding/paas/v4
     • Стандартный API-ключ: https://api.z.ai/api/paas/v4

3. OAuth

   • Авторизация через браузер для роутинговых платформ, таких как OpenRouter.
   • Специфические механизмы OAuth могут жить в реализации провайдера, но конечный результат всё равно должен быть планом установки провайдера.

4. Кастомный провайдер

   • Ручная настройка для локальных серверов, прокси или неподдерживаемых провайдеров.
   • Мастер настройки собирает протокол, базовый URL, API-ключ, ID моделей и расширенные параметры модели, такие как режим рассуждений (thinking), мультимодальный ввод, контекстное окно и максимальное количество токенов.

Владение моделями и обновления

Статические встроенные провайдеры могут сохранять метаданные провайдера в providerMetadata.<providerId>, включая версию списка моделей и базовый URL. Это позволяет Qwen Code обнаруживать изменения во встроенном списке моделей провайдера и предлагать пользователю обновить принадлежащие модели, не перезаписывая несвязанные кастомные модели.

Кастомные провайдеры отличаются: их список моделей создаётся пользователем и не должен рассматриваться как автоматически обновляемый встроенный список моделей.

Нецели

• Не делать API-ключ, OAuth, coding plan или token plan верхнеуровневой архитектурой настроек.
• Не привязывать запись настроек к React-компонентам или обработчикам команд CLI.
• Не делать группы UI осью бизнес-логики.
• Не требовать от контрибьюторов полного понимания UI аутентификации для добавления простого стороннего провайдера.