Skip to Content
デザインAuthAuth Provider Registry の設計背景

Auth Provider Registry の設計背景

auth モジュールはかつて、API キー、OAuth、サブスクリプションプラン、カスタムプロバイダーといったセットアップ経路をそれぞれ独立したフローとして扱っていました。しかし実際には、これらすべての経路が同じ種類の出力、つまり ~/.qwen/settings.json のプロバイダー設定の更新を生成します。

このリファクタリングにより、プロバイダーのセットアップを共通の抽象化として位置づけます。プロバイダーは、表示方法、認証情報の収集方法、インストールするモデル、適用する設定パッチを記述します。API キー、OAuth、コーディングプラン、トークンプラン、カスタムウィザードはプロバイダーのセットアップ方法であり、独立した認証アーキテクチャではありません。

目標

  • /auth のユーザー向けフローをわかりやすく保つ:
    • Alibaba ModelStudio：ファーストパーティの Qwen セットアップ。
    • サードパーティプロバイダー：DeepSeek、MiniMax、Z.AI などのよく使われる組み込みインテグレーション。
    • OpenRouter などの OAuth プロバイダー。
    • ローカルサーバー、プロキシ、または組み込みでないプロバイダー向けのカスタムプロバイダー。
  • プロバイダー固有のデータを小さな宣言的なプロバイダー設定に移動する。
  • サードパーティプロバイダーのコントリビューションを簡単にする：一般的なプロバイダーの追加は、通常プロバイダー設定とテストを 1 つ追加するだけで済むようにする。
  • 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

    • コーディングプラン
    • トークンプラン
    • 標準 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 キー、モデル ID、およびシンキング・マルチモーダル入力・コンテキストウィンドウ・最大トークン数などの詳細なモデルオプションを収集する。

モデルの所有権と更新

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

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

対象外

  • API キー、OAuth、コーディングプラン、またはトークンプランをトップレベルの設定アーキテクチャにしない。
  • 設定の書き込みを React コンポーネントや CLI コマンドハンドラーに結合しない。
  • UI グループをビジネスロジックの軸にしない。
  • シンプルなサードパーティプロバイダーを追加するために、コントリビューターが auth UI 全体を理解する必要がないようにする。
Last updated on
適応的出力トークンエスカレーション設計Auto-Compaction Threshold Redesign