Auth Provider Registry の動機

認証モジュールは以前、各セットアップパスを別々のフローとしてモデル化していました：APIキー、OAuth、サブスクリプションプラン、カスタムプロバイダーです。実際には、これらのパスはすべて同じ種類の出力を生成します。~/.qwen/settings.json 内のユーザーのプロバイダー設定に対する更新です。

このリファクタリングにより、プロバイダーセットアップが共有の抽象化となります。プロバイダーは、どのように表示されるか、クレデンシャルがどのように収集されるか、どのモデルをインストールするか、どの設定パッチを適用すべきかを記述します。APIキー、OAuth、コーディングプラン、トークンプラン、カスタムウィザードは、プロバイダーに対するセットアップメソッドであり、別個の認証アーキテクチャではありません。

Goals

/auth のユーザーフェーシングフローをわかりやすく保つ：
- ファーストパーティのQwenセットアップのためのAlibaba ModelStudio。
- 一般的な組み込み統合（DeepSeek、MiniMax、Z.AIなど）のためのサードパーティプロバイダー。
- OpenRouterなどのOAuthプロバイダー。
- ローカルサーバー、プロキシ、または組み込まれていないプロバイダーのためのカスタムプロバイダー。
プロバイダー固有のデータを小さな宣言型プロバイダー設定に移行する。
サードパーティプロバイダーのコントリビューションを簡単にする：一般的なプロバイダーを追加するには、通常1つのプロバイダー設定とテストを追加すればよい。
設定の書き込みを ProviderInstallPlan と applyProviderInstallPlan を通じて集中管理する。
UIのグループ化をインストール動作から分離しておく。グループはユーザーが /auth をナビゲートするのに役立つが、設定ロジックを駆動すべきではない。
モデルリストの所有権とプロバイダーメタデータのためのパスを保持し、プロバイダーのモデル更新を検出して安全に適用できるようにする。

Architecture

新しい構造は、プロバイダー定義、インストールロジック、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フローから独立したままになります。

User flows

/auth は依然として異なるエントリポイントを提示できますが、それらはすべて同じプロバイダーインストールパスに収束する必要があります：

Alibaba ModelStudio
- コーディングプラン
- トークンプラン
- 標準APIキー
サードパーティプロバイダー
- 組み込みのデフォルトを持つ一般的なプロバイダー。
- 各プロバイダーは、そのベースURL、環境キー、デフォルトモデル、モデルメタデータを所有する必要があります。
- Z.AI はセットアップ固有のベースURLを使用する必要があります：
  - コーディングプラン: https://api.z.ai/api/coding/paas/v4
  - 標準APIキー: https://api.z.ai/api/paas/v4
OAuth
- OpenRouterなどのルーティングプラットフォームのためのブラウザベースの認証。
- OAuth固有の仕組みはプロバイダー実装内に存在できますが、最終結果は依然としてプロバイダーインストールプランであるべきです。
カスタムプロバイダー
- ローカルサーバー、プロキシ、またはサポートされていないプロバイダーのための手動セットアップ。
- ウィザードは、プロトコル、ベースURL、APIキー、モデルID、および思考、マルチモーダル入力、コンテキストウィンドウ、最大トークンなどの高度なモデルオプションを収集します。

Model ownership and updates

静的な組み込みプロバイダーは、providerMetadata.<providerId> の下にプロバイダーメタデータ（モデルリストのバージョンとベースURLを含む）を永続化できます。これにより、Qwen Code はプロバイダーの組み込みモデルリストが変更されたことを検出し、関連しないカスタムモデルを上書きせずに、ユーザーに所有モデルの更新を促すことができます。

カスタムプロバイダーは異なります：それらのモデルリストはユーザー作成であり、自動更新可能な組み込みモデルリストとして扱われるべきではありません。

Non-goals

APIキー、OAuth、コーディングプラン、トークンプランをトップレベルの設定アーキテクチャにしない。
設定の書き込みをReactコンポーネントやCLIコマンドハンドラに結合しない。
UIグループをビジネスロジックの軸にしない。
コントリビューターが単純なサードパーティプロバイダーを追加するために、完全な認証UIを理解する必要があるようにしない。