Мотивация рефакторинга модуля аутентификации

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

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

Цели

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

Архитектура

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

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

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

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

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

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

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

1. Alibaba ModelStudio

   • План кодинга
   • Токен-план
   • Стандартный API-ключ

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

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

3. OAuth

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

4. Пользовательский провайдер

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

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

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

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

Нецели

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