ガイド · 2026 年 11 月 10 日更新 · Cameron Voss および West Mao 著
Windows 上の DeepSeek SuperAgent: WSL とネイティブ Windows のセットアップ (2026 年 11 月)
インストール前に Windows ルートを選択し、制限を理解し、環境を確認してください。
Windows マシンの場合、WSL 2 は、公開されている Unix 指向のセットアップに近い Linux 環境をプロトタイプに提供します。ネイティブ Windows には、コミュニティによって報告された互換性の問題があります。サードパーティのポートは別のプロジェクトです。 WSL は互換性に役立ちますが、信頼できないエージェントの作業に対するセキュリティ境界ではありません。
DeepSeek SuperAgent は、DeepSeek Harness に基づいて構築された研究プロトタイプであり、正式な DeepSeek 製品や運用準備が整ったソフトウェアではありません。別途構成されたモデルプロバイダーが必要です。このガイドは、公開されているドキュメントに従っています。この記事ではエンドツーエンドの導入を実行していません。
Windows 上で実行されている DeepSeek Harness は、それ自体では、すべての SuperAgent サービス スクリプトとワーカー フローがそこで実行されることを確立しません。ワークフロー全体（インストール、GitHub 認証情報、チケットごとのワークツリー、サービスの監視とレビュー）の環境を選択します。
WSL 2、ネイティブ Windows、または別の Linux ホストのどれを選択しますか?
| Route | 提供内容 | 確認事項 |
|---|---|---|
| WSL 2 | Windows マシン上の Linux ツールとファイル システム。公開された tmux と Python のワークフローに近づきます。 | Windows のマウント、相互運用、資格情報、およびネットワーキングは、引き続きホスト リソースを公開する可能性があります。この展開はエンドツーエンドでテストされていません。 |
| ネイティブ Windows | Windows ネイティブ ツールとデスクトップ ワークフロー。 | コミュニティ レポートには、特定のバージョンでのサービス スクリプト、パス、およびワーカー ツールの問題が記載されています。パッチ適用されたセットアップがご使用のバージョンに適用されると想定しないでください。 |
| Linux ホストまたは VM を分離します。 | ランタイムと認証情報を管理するためのより明確な場所。 | 分離は、VM 構成、共有フォルダー、ネットワーク アクセス、認証情報によって異なります。 VM は自動的に安全ではありません。 |
ネイティブ Windows では元のセットアップが扱いにくいのはなぜですか?
公開されたサービス ワークフローは、Python と tmux を使用します。 Windows ユーザーは、サービス スクリプトが Unix 専用の fcntl モジュールをインポートしていること、一部のディレクトリ検証で Windows のドライブ文字パスが拒否されていること、ワーカー セッションに特定の設定で予期されるツールが不足していることを報告しました。このレポートでは Windows 11 と DSH CLI 0.2.1-rc.3 が使用されました。すべてのバージョンに同じ障害があること、またはそのローカル パッチが修正を維持していることを証明するものではありません。
コミュニティ Windows ポートとラッパーは、これらの前提を変える可能性があります。これらをサードパーティの実装として扱い、コードと権限を確認し、実行する前にバージョンとメンテナンス ステータスを確認してください。このガイドではネイティブ ポートを独自にテストしていません。
WSL 2 はどのように準備しますか?
サポートされている Windows インストールでは、管理者として PowerShell を開き、Microsoft のインストール コマンドを使用します。
wsl --install要求された再起動を完了し、Linux ユーザーの作成を終了します。 PowerShell では、wsl --list --verbose にインストールされているディストリビューションとその WSL バージョンが表示されます。 WSL がすでにインストールされている場合は、コマンドによって新たに分離された環境が作成されると想定するのではなく、まず現在の状態を検査してください。
Linux ディストリビューション内では、Linux バージョンの Node.js、pnpm、Git、Python、tmux、GitHub CLI、および DeepSeek Harness を使用します。 Linux ツールを実行するときは、Linux ファイルシステム上に作業クローンを保持します。ファイルシステム間のアクセスは遅くなる可能性があります。個人トークンや本番機密情報をサービス ユーザーのホーム ディレクトリに置かないでください。
Windows ホストとテスト データをどのように分離しますか?
WSL は Windows と対話でき、マウントされた Windows ドライブにアクセスできます。別個の Linux ユーザー名または Linux ホーム ディレクトリ下のリポジトリは、偶発的な混合を減らしますが、それだけではホストへのアクセスを停止しません。信頼できないコードの場合は、意図的に分離され、ネットワークと資格情報が制限され、取り消しても安全な、個別に管理された環境を使用します。作業者にアクセスを許可する前に、共有フォルダとマウントを確認してください。
その環境内で、エージェント専用の GitHub ユーザーと別個の CLI 構成を作成します。テスト リポジトリ、1 つの許可されたリクエスター、およびブランチ保護から始めます。ワーカーはサービス ユーザーの OS 権限で実行されるため、アクセスは OS およびインフラストラクチャ レベルでも制限される必要があります。
WSL セットアップ シーケンスとは何ですか?
- Linux シェルを開いて、
node -v、pnpm -v、git --version、python3 --version、tmux -V、gh --version、dsh --versionを確認します。 - プロトタイプの現在の前提条件とハーネスのバージョンを確認します。範囲。環境内でモデルプロバイダーと専用エージェントの GitHub CLI アカウントを構成します。
- プロトタイプのクローンを作成して構築し、新規インストール用の専用プロファイルを作成して、バンドルをインストールします。既存のプロファイルに対して profile-creation コマンドを実行しないでください。設定が置き換えられるためです。
- ローカル パネル、GitHub ソース、許可されたリクエスタと実行者のワークツリーの準備を設定します。人間によるレビューと自動マージを無効にして、推定された候補に対して
observeから開始します。 scripts/dsh-superagent statusを確認し、テスト リポジトリで小さな明示的なリクエストを使用します。明示的なリクエストはObserve モードで実行される場合があります。
問題からレビューまでの完全なフローについては、既存の SuperAgent のセットアップとコストのガイドを使用してください。依存関係チェックが成功したことは出発点にすぎません。チケットの作成、ワークスペース、権限、および結果の差分を個別に確認します。
何かが失敗した場合は何を確認する必要がありますか?
| 症状 | 検査内容 |
|---|---|
tmux または Python エラー | 必要な Linux ツールを使用して、WSL 内で Linux サービス スクリプトを実行していることを確認します。 |
| GitHub の応答がありません | エージェント ラッパーのログイン、リポジトリ アクセス、許可されたリクエスタとソースのステータスを確認してください。 |
| チケットはチェックアウトを準備できません | Linux クローン パスが存在し、prepare コマンドが正しいファイル システムを使用していることを確認し、 |
| ワーカーに予期したツールがありません | DSH とバンドルのバージョンを記録し、ワーカーのプリセットを検査します。 Windows レポートでは、あるバージョンでこれが確認されました。これは普遍的な診断ではありません。 |
| パネルがサービスに到達できません | プロセスが実行されているかどうか、およびパネルがどこにバインドされているかを確認してください。適切な制御なしでローカル管理パネルをネットワークに公開することは避けてください。 |
よくある質問
WSL はサンドボックスですか?
いいえ。 WSL と Windows は相互運用できます。信頼できない作業用に実際の分離を個別に設定します。
このガイドは Windows のネイティブ サポートを証明しますか?
いいえ。ここでは、エンドツーエンドのネイティブ Windows テストではなく、公開された要件と個々のコミュニティ レポートについて説明します。
普段使用している GitHub アカウントをエージェントとして使用できますか?
プロジェクトでは専用のエージェント アカウントを推奨しています。通常の ID から分離し、テストに必要なアクセスのみを許可します。